Flash:Getting Started
From GMpedia.org Wiki
If you just have decided to use Flash to write a game then congratulations on your choice! The Flash platform makes it easy to write games and compared to many other programming languages you will proceed more quickly to write your own first bits of working code.
Contents |
[edit] First Steps
As a first thing you should decide which ActionScript version to use. Currently available are version 1, 2, and 3 (while 3 is still in alpha state). I would say that ActionScript 2.0 is currently the best choice. Version 1.0 is rather outdated and messy to program with. If you are experienced in AS1.0 and don't know 2.0 yet, it makes sense to take the short trip and learn the differences to AS2.0. It will reward you with a much cleaner and object oriented structure. If you find it hard to get into OOP, I recommend Colin Mooks book Essential ActionScript 2.0. Nowhere will you learn OOP easier than in this book. While AS 3.0 is already more powerful and faster than AS 2.0, it is still in beta phase currently and many things will eventually change until its final release. If you want to go for version 3.0 you have to count with changing many things later in your source code once the final version will be public.
[edit] Choose your tools
The Programming Tools page lists a selection of tools used to write and handle your code. You will also need some tools to create the game media (graphics, sounds etc.). You can find an extensive list at the content/media tools page.
For writing ActionScript I'm using the Eclipse IDE with the FDT plugin and SWFMill. I'm trying not to use the Flash IDE at all, except for designing SWF assets that I'm going to use in a game (animated sprites for example) and I can say that it is a breeze to work with the Eclipse setup. However if FDT is too expensive for you, ASDT might be a good alternative. Either way, you can choose freely to use the official Flash IDE for coding or any other freeware editor like SEPY and MTASC as a compiler or anything else of your choice. The bytecode that comes out at the end will be the same!
[edit] Designing the Game
Don't take this step lightly! The designing process is probably the most time consuming part of your game. Don't be tempted to do newbie mistakes. Keep the following advises in mind:
- Start small. If you just started to learn programming and you want to develop the most wicked multiplayer online RPG with vast worlds, rich complexity and endless playing possibilties because you just had the idea for it then stop right now and take a deep breath. This is impossible to do! You should start off with something easy like a Tetris clone or a simple Poker game. Such seemingly simple games will already challange you enough as a beginner. Of course you should write down your ideas for more complex games into your note book so you can come back to them later! Once you achieved more proficiency you can approach more complex game ideas.
- Plan. The more complex your game should be, the more time you have to invest into planning you game! The planning phase decides the success of your game programming so be sure to take enough time and thoughts into planning your game on paper before you start writing the first line of code. Try to be as detailed as possible in the designing phase, it will save you alot of trouble later when it comes to coding. A typical design phase could look like this ...
- Get yorself a nice and small notebook (I'm using a Hobonichi Techo for this) and write down your ideas about the game into it. Just write down everything that comes to your mind about the game, useful names, story parts, technical details, features that the game should have etc. If your game is very story driven you should think about the story first. Write it down and work it out completely! Write down notes about your game's characters, about places that appear in the game or about weapons that can be used by the player. If you spontaneously get a good and original idea for a character name or a name for the game itself then write it down into your book before you forget it again.
- Create a design document for your game and include a structured version of all your game design notes, think through your game from beginning to end and document every gameplay feature and how to implement it technically. Also include case diagrams, screen layouts and artwork sketches into the document.
- If you plan to program object oriented, now is a good time to lay out UML diagrams about your OOP design. When using an object oriented approach it is very important to plan the structure of your code, i.e. what classes to write, how they interact, which OOP patterns to use where etc. If you skip this step you will sooner or later stumble about limitations in your code and you eventually have rewrite alot of it. Typical applications to design UML diagrams are Microsoft Visio or ArgoUML.
- Wait. After you had an idea for a game and wrote down notes for it, it's a good idea to wait and think about it for a while. Sometimes ideas that sound brilliant at first turn out to be not so brilliant anymore in practice later. Give youself enough time to think about the game idea before working it out, before it turns out that the game actually is very boring or overly complex for most people.
- Get feedback. Find a group of gamers to take a look at your game idea and get feedback from them. Such people can provide you with feedback to prevent unnecessary problems in your design. Try to choose people that are interested in the genre of your game! It doesn't make sense to give a roleplaying game idea to people who are mainly interested in sports games!
[edit] Create game media
This is a time consuming step for many game developers as we are programmers in first line and not professional graphic artists or sound magicans. Check the content tools page for an overview of available content creation software. If you are good at drawing or composing music/creating sound effects you have an advantage, otherwise you either have to find partners that do these jobs or you can check the game content resources page for an overview of freely available graphic and audio resources for games.
Even if you are a lone developer you can still try to create the game media by yourself. If it isn't beautiful, try to be original at least! Remember, an 8bit style pixel sprite has more charme than a ugly painted vector drawing! Many of the early 8/16bit game programmers were sort of a one-stop-shop for game development and usually created all the game contents by themselves, so why shouldn't you be able to do so?!
[edit] Coding the game
Time to get the hands dirty and start writing the code of your game! Keep the following points in mind ...
- Write flexible code. Changes will occur, no matter how thought out your plan is! To reduce rewriting alot of code try to code in a well planned object oriented structure. Write your classes modular, with code reuse in mind and keep them encapsulated. This means that you should write your classes so that if you need to make changes to it later, you don't have to rewrite anything in the other code parts.
- Prototype. Try to get your game to a quick-and-dirty working version as soon as possible. The graphics don't need to be complete or placeholder graphics can be used. Sounds doesn't need to be included yet. There is time to add more features later once you get a running version. Try wipe out occuring bugs immediately. Working around a bug - so called hacks - are not a good style of coding as they will almost always lead to even bigger problems later and make the source code look more confusing.
- Don't optimize early. Spending time optimizing your code even before knowing how the game as a whole will perform is pointless. Code flexible so that further optimization is possible, for example by using variables that just need to be tweaked.
- Reuse code. If you already have written and well-tested code that does the job, use it instead of starting from scratch! Save yourself the time to write everything once again. You can still make a copy and tweak the code to fit your needs if necessary.
[edit] Testing the game
After finishing major sections of your game, it must undergo a Testing stage before any problems turn too hard to find, that stage consists mainly of two parts:
-Alpha Testing This is were you run your own game and try as hard as you can to make it stop working, the objective here is to find bugs and runtime errors which need to be solved.
-Beta Testing Its not enougth to test your own game, since you programmed it its most likely that you wont find most of the errors in it, your game must undergo beta testing. Invite your friends, your parents, and everyone you can to try it; they should tell you if anything goes wrong and might, as well, give you advice in how to improve it.
[edit] Deploying the game
One of the most important aspects of improving your game development skills is to get good feedback on how well your game plays. To measure the popularity of your game and to see if people are copying your game to other websites you can use a tool called MochiBot(http://www.mochibot.com). It's free to use and a great tool to keep tabs on your games.
[edit] Selling the game
to be written.
