Case history: creating a successful niche Flash arcade site

This is the interesting story of Michael Edlavitch from Hooda Math, a 10,000 visitors/day successful niche Flash arcade site.

If you are an arcade site owner, you can’t miss this:

« Before Walmart moves into a small town they offer classes to the small business owners on how to keep their businesses a float. What do they teach?
Don’t be like us, find your niche. Read more

HiRoads developer Diary

If you remember 5 Commodore 64 games I would like to see ported in Flash, you know I am a great fan of Trailblazer, the game that inspired Tileball.

Today I am proud to introduce Filippo Bodei from Monkey Odyssey his Trailblazer-like game HiRoads.

Let’s read Flippo Bodei’s developer diary: Read more

Case history: Monkey Treasures

I want to share with you the experience of Ken, the owner of GameTweek during the creation of his first Flash game: Monkey Treasures

Since it’s a great example of a game started from a tutorial, I am publishing Ken’s story… it’s a great read for people starting their first game and for people saying publishing the source code in a tutorial encourages people to just cut/paste the code and publish their own “game”.

« I’d like to start off by saying that I really enjoy reading your informative blog.
You do a great job of creating tutorials and providing info for the online community.
Keep up the excellent work because I think emanueleferonato.com is the best Flash
blog on the internet. =)

I actually came up with the concept 6 months ago. The concept of collecting treasures from the sea was of 3 game concepts I had in mind. Since this would be my first Flash game attempt, I figured the programming for collecting treasures would be the easiest of the 3 concepts.

I had the idea of creating a game with cute/funny characters who’s goal was to collect treasures before being attacked by pirates. The game play mechanics of the original Gold Miner is exactly what I would be simulating in the game. This led me to google search for “Gold Miner Tutorial” and that’s how I found emanueleferonato.com. The sample source code I found, helped me to get started on my project.

My intent was not to create a Gold Miner carbon copy, but simply use the same game play mechanics and apply that to a “treasures of the sea” type setting. I created a mock-up drawing and sent it to Vaisaga Project, who did a great job of interpreting my idea. A few weeks later, I was given the initial artwork and felt it fit perfectly with the game. The cute monkey characters with pirates, boats, sharks, and treasures were exactly what I was looking for.

Now that I had the artwork, the next step was to put things together and make everything interact through Action Script. I had no experience with Action Script in the past, but since I have 9 years of programming experience in C++, the learning process was not that bad. This new Flash game was my side project outside of my regular job. Finding time to work on it was probably the hardest part of the whole process.

I read several different topics on your blog which also helped with development. The other 2 topics were: “Designing the Structure of a Flash Game” and also “Flash Simple Timer/Countdown”. I did not buy any books to learn AS2. All of the information I learned came from various online sources. Your blog was my first source for info. I also watched numerous Flash Tutorial videos from Entheos: http://www.entheosweb.com/Flash/default.asp and also downloaded some tutorials from Cartoon Smart: http://www.cartoonsmart.com/free_index.html. MochiLand also had some informative links for Flash game development.

I spent some time reviewing the API in order to know what functions I needed to use. After experimenting with the code, I started to get a good understanding of how things work. Your clear tutorials of course were of great help. The rest of my development time went into polishing the game play and in-game interactions. I searched for and added sound effects that would help with the cute/funny theme of the game. I also asked a few friends to play the demo version. I continued to update the code as needed and finally released “Monkey Treasures” on May 1st, ‘09. I hope that players will enjoy the game. If feedback is positive, I might create a sequel. I am still learning as I go along so all feedback will be helpful in improving future projects.

I really enjoyed creating the game and getting real experience with Action Script. The creativity of Flash game programming is something I will be focusing more on in the future. My next goal is to create a game in AS3. »

Making a collaboration work

This post is made by Esteban Gallardo from Free Creation Games. Esteban is highly interested in the work organitzation to maximize profitable work of a team, so any new information of how to manage the work organitzation in small teams is more than welcomed.

« Since I began with Flash games and considering my awful artistic skills, I have had the chance to collaborate with several kind of graphical artists. I’m quite fortunate since most (not all) of the experiences has been good. So, from all these years I have seen some common key points to keep alive a collaboration and try to finish your project with a good quality.

Let’s suppose that you are like me, a normal people who doesn’t excel in all the skills to make a game. So, you maybe are a programmer, or a game designer, or a graphical artist, or a musician or even a producer with a game idea you would love to see realized and… this is important… you don’t have a penny (or an extremely limited symbolic budget, let’s say less than 300$). So, it’s time to look for people who can be interested to participate in this idea.

Part 1: Looking for people
Some points that to present the idea:

Prepare a good headline:
The newspapers know really well the importance of the initial headline to attract the readers to keep reading. So when you present your idea, reserve the first lines to explain it in a short paragraph in a clear way what the idea is all about.

Explain the things clearly:
In this presentation, you must explain with a more details more things of your idea and its production, your experience, the people needed, the possible graphic style looked for, the target audience, the possible ways of monetize, etc… It’s important that in this presentation you keep the things ordered and clear. Remember that you are looking for collaborators so people won’t like confusion or feel that you don’t have a clear idea of what you want.

Don’t say you are going to do “The Next Best Thing”:
This is something clear for almost anybody who is minimal serious. Don’t speculate if you pretend to get serious people in your team. To get involved serious people takes times, sometimes years. Sell your idea like an interesting, challenging project.

Begin with small author projects:
Maybe you have bigger game ideas, but since to create a team takes time, it’s necessary that you begin with a small project. This small project can be inspired by other games, but you must be able to offer something really unique and appealing. If you don’t try to be really different from the crow, better quit, because there will be always others with money that are going to do a much better game clone that you can do.

Nobody is going to steal your idea:
Like someone said, ideas are a dime in a dozen, but implementation is priceless. Sure that you have some important key features or dynamics that will make the game different from the others, but the general idea of the game can be told without any problem, beat-em’up, shoot-em’up, puzzle, isometric, point&click adventure, physic based…. Even if you try to make an experimental game you can manage to look for references or explained without entering in this key details.

Save money for the project:
To get involved a talented artist when you don’t have any previous experience can be impossible. So if you really believe in your game idea you will be able to keep some of your savings for the project and then attract experienced people to the team.

Part 2: Keeping the collaboration integrity
So you finally made it. There are people who really like your idea and want to participate in it. So now it comes the really hard part. Making the things work:

Remember: It’s your dream, not their dream:
You can’t pretend that collaborators be from the beginning of the project as passionate as you about the game idea. They like the idea, they would like to participate, but they won’t like to feel any, I repeat, any work pressure.

Make the possible for them to enjoy the work:
If you manage to get the people gradually involved to the project, then the collaborators will begin to like it and maybe love it as much as you do.
For that happens you have to work hard to make their job the easiest so they can concentrate in the stuff they do best, if you are a programmer then make bad graphics that represent the exact meaning of what is supposed to be there, the character shooting, the character being hurt… If you are a designer, write clearly the rules, the actions, the flow of action, the screens, the effects… so the programmer can do always profitable work.

Do your best in the communication, even if they don’t care:
Prepare carefully the stuff so the collaborator can do the minimal effort to understand what is needed. Clean documents, clean email communications. Even if you prepare stuff that’s not going to be read, the collaborator will see that you are doing your best and he will work more comfortable in his side.

Be communicative, but not annoying:
Don’t send multiple emails daily, telling little or no useful information about the project. The good artist collaborator is quite independent, he wants the minimal amount of information really important so he can to work on the problem at his own pace. So be clear and concise, and add additional information so just when the artist has doubts he can come back to the email/document and consult that additional information.

Be open to talk about everything:
If you really want that the collaborators get in love with your project, listen them, don’t directly discard never an idea, think about it, consider the advantages and problems, if it’s possible program this idea to see the result, talk with the artist and take decisions together. The best things many times comes from fusion of different talents and points of view. Anyway, don’t change constantly the things only by the minimal request, try to keep a game vision and incorporate the ideas that can benefit the game. So, listen, think, talk and finally act if the new idea can improve the game.

Take it easy, don’t set any extremely fixed deadline:
It’s good to set deadlines, but the must be really long and really flexible. Again, it’s your game project, not theirs, so they don’t want to feel the pressure of a too short deadline.

Respect and Honest:
Amateur game developers are full of passion, and it’s terrible easy that this passion can cause to lose the nerves. So, when you feel that you blood is burning and you feel that you can say something you don’t want, stop for a while, take a walk, go to the cinema, rest and try to relax… and after that you maybe would be able to deal with the problem without sending everybody to the hell.
Also be honest about everything related the project, don’t hide information that can affect the others. It’s supposed that you are all in the same ship, and the people wants to be aware if the ship is facing an area full of icebergs.

Relationship broken:
Sometimes there is no way to make the things work, maybe the other person is involved on other things, or has personal problems and can’t put time on your project. That happens. The most important is to break the relationship with respect, even if the other part doesn’t want to, sometimes even the good people say things that they regret, so you are leaving open a door for reconciliation.

Part Extra: In the case that you are a collaborator
Some words if you are a collaborator, as I have been in several projects:

Don’t do it for the money:
Really, if you are doing for the money you are going to do a cheap job, because there is almost no money in collaborations. The worst is that you can damage your own image showing that you don’t care about your work, and the bad reputation can be something really dangerous. Do it because you like the idea, do it because you would like to collaborate and know this person, do it to increase your knowledge about an area, do it because you want to get new friends… »

The different dialects of casual game monetization

I had the permission from Ada Chen to publish this post on my blog.

It’s very interesting to read what Ada thinks about casual game monetization because she is the Product Marketing Manager for Mochi Media.

Ada also runs her own blog at adachen.com.

« Games are hot lately and GDC 2009 is just around the corner.
When talking about games, most people tend to think about the business of making games in the loose terms of console, casual and mobile.

However, the casual games industry is definitely a lot more segmented than that. The conversations become radically different depending on what group you’re speaking with.

The basis for why this is stems from the underlying economics of each industry. This can be summed up in one question: How are you monetizing your users?

Put a grab bag of casual games people in the online games industry together in a room, and the conversations will be incredibly diverse – ranging from CPMs, RPMs, ARPUs, sponsorship deals, publisher relationships, and viral co-efficients.

In the end, they are all trying to answer the same question (how much money can I make?) but speaking with with different dialects. Here’s how those dialects, in a rough way, break out.

Web games, defined as distributed browser-based games that are not dependent on a destination site, primarily monetize users via advertising.

Gamers playing these web games are predominantly monetized via advertising today. Developers monetize games via in-game ads such as Mochi Media (where I work) and game portals hosting the content monetize the games via around-game ads. Developers license their content, do custom development deals, and sell game sponsorships to portals, who do these deals as a vehicle for traffic acquisition.

Direct user monetization via micro-transactions and purchases are still emerging. In a primarily ad-based market – developers and game portals are primarily focused on advertising-centric metrics: number of sites where the game is distributed, number of game plays, RPMs, CPMs, average click-through rate of advertisements, page views, time on site, efficient traffic acquisition, and basic retention stats to get people to come back.

Casual downloadable games, which are typically downloaded games that users can trial and then purchase.

These are typically monetized via direct one-time user sales from the game publisher. Developers typically work with an oligopoly of game portals who publish their games and sell them to a user base which they maintain, paying back a rev-share to the game creator.

With these limited distribution channels, the success of a game is largely dependent on getting onto the Top 10 list for a long enough period of time to make a profit. With the glut of games coming into the market, margins are getting slimmer, however, and several suggestions to improve this model are emerging.

Due to this model, however, most conversations in the downloadable space focus on publisher partnership development, developer community, channel management strategies, franchisable IPs and the stats are transaction focused – conversion rates, sales, break-even sales, etc.

Virtual worlds, or destination-based virtual worlds where users inhabit the world and interact with one another with virtual representations of themselves.

These are typically monetized via a mixed bag of advertising, subscription streams and virtual goods. The creator of the website is focused on engagement, retention and content to directly monetize users through purchases.

These virtual worlds therefore, are keeping an eye on the advertising numbers but are most concerned about retention and payment stats – PVs/visit, payment fraud, cohort analysis, engagement funnels, ARPUs and balancing their virtual economy so that the available money isn’t too much or too little. In addition, they are very focused on community management and support issues.

Social games, which blur quite a bit with virtual worlds, are games which are deeply integrated with the social graph and APIs available on social networks.

Social game developers make money from the users playing these games, with a combination of incentivized CPA offer networks and direct payments. These developers are focused on honing their viral loops to acquire new users into the system, creating engagement funnels to engage those users and convert them, and measure ARPUs for the users.

Unlike virtual worlds though, there’s less of an emphasis on community management since everyone playing the game with you is theoretically managed by the social graph, but instead more emphasis on viral spread. »

7 reasons NOT to get your game sponsored

While most developers are trying to get their games sponsored in as much ways as they know, Ryan from Freelance Flash Games (great blog! a must read) is going to explais us why you shouldn’t get your game sponsored.

Sponsorship is one of the biggest revenue streams for flash developers. Flash Game License reported over 1 million dollars in sales since it has begun.

So why would you ever decide to forget the sponsorship route? Here are 7 reasons why you shouldn’t get your game sponsored.

1. You can promote yourself. By not having a sponsor intro to your game, you will be placing more emphasis on your own logo and game intro. This will get you more recognition as a developer and can be useful in future sponsorship deals.

2. You can increase your site’s traffic. The key reason a sponsor will give your game a sponsorship is to send traffic back to his site. By putting your own logos into the game the traffic will be coming to your site.

3. You can use your new traffic to generate revenue. If your site is well optimized for advertising, the players that come back to it will click on your ads. Depending on how well your game spreads, this can generate a good amount of income.

4. You can increase your site’s branding. Even if players don’t click on the link to your site, they are still going to see your site’s logo. By showing them your logo enough times, you will build brand recognition for your site. So when they think of how great your game is, they will also think of the site that made it.

5. You can earn in-game advertising revenue. Some sponsors won’t allow you in-game advertising, which can cause you to lose out on revenue if your game becomes viral and spreads to thousands of sites. By not having it sponsored you are free to choose whether you want in-game ads or not.

6. Most Sponsorships are a one time deal only. Sponsorships will only give you a flat fee for your game. By hosting your game on your own site, you will still be receiving revenue from it months or even years from when you released it. There is no limit to how much you can make off of it.

7. You can still make money from non-exclusive deals. Just because you don’t have a primary sponsor doesn’t mean you can’t make money off many of the sites your game spreads to. Sell them a non-exclusive sponsorship and you will be making more money from your game, as well as getting more traffic sent back to your site.

Sponsorships may be the right choice for some developers, but if you want long term monetization opportunities you will have to turn away from sponsors and start driving traffic to your site.

Do you think you can make more money with or without sponsorship?

The engine behind Splitter Flash game : working code

I think we finally have a working slicing engine. It started with The engine behind Splitter Flash game, then come The engine behind Splitter Flash game – first AS3 prototype and The engine behind Splitter Flash game – new AS3 prototypes.

Now Guillaume Pommey aka pompom sent us a working version.

I revised my prototype of slicing engine two days ago and I corrected a lot of errors. After an afternoon on my code, I resolved almost all my problems.

I am proud ^^, now the slicing engine works.

I joint the Main.as and the .fla cause I use radio button to change the cutter style, I let you discover it :) .

Ps : Don’t forget that I use the Raycast function so speak about this on your blog.

For more information about Raycast function check Box2D Raycasts post.

The engine works perfectly, and has two ways of cutting objects: the laser mode cuts objects when you press C while the cutter one lets you cut by drawing a line. Read more

Full Totem Destroyer prototype

Some time ago I posted Create a Flash game like Totem Destroyer, and now I am showing you a complete prototype made by Collin Douch.

The prototype features slimy and non-removable blocks and collision detection between the totem and the ground.

Such detection was made customizing Box2D’s b2ContactListener class. For more information about this class refer to Understanding how Box2D manages collisions. Read more

Erase Box: the tutorial

Some days ago I blogged about Erase Box, a Box2D game made with my tutorials, now it’s time to publish Rodrigo’s tutorial.

« On a game I was making, I needed a way to detect if a body was leaving the screen.

That can be done by checking the x and y positions of it, but I also wanted to explore Box2D features.

That was actually good, because I found another way to do that, and it can be of great help on other projects.

Sensors are bodies that won’t directly interact with others.

They won’t make a moving box stop when they hit, i.e.

That being said, they are still useful.

Box2D will keep track of it’s “contacts” just as if it were a normal body, so they can be used as exactly what their name means, a sensor.

Also, Box2D allows you to “attach” some information to a body, so that it can be distinguished from others.

Let’s see an example: Read more

Erase Box, a Box2D game made with my tutorials

I am going to show you a cute game Rodrigo made following my tutorials

« I created a Box2D flash game using some tutorials available on your website.
It’s not very cool, but being my very first AS3 and Box2D game, I think that I did a good job.

Erase Box

It’s a mix of your tutorials about “Box2D for absolute begginers” and “Totem Destroyer Prototype“.
I also added some other features, such as the one to detect bodies falling off the screen (which was a pain because I couldn’t find anything close to that). I can make a quick tutorial on how to do that if you want.

Thanks and hope you like it :) »

That’s it… while we are waiting for the tutorial, in my opinion a quick way to detect if a body is falling off the screen is checking if its x and y positions are inside the stage… anyway… let’s wait for the tut.

Next Page →

  

Posts