Showcase and discover digital art at yex

Follow Design Stacks

Subscribe to our free newsletter to get all our latest tutorials and articles delivered directly to your inbox!

What is Flash Game Programming

I want to be a game programmer!

Most of todays commercially popular games are huge monsters that are deployed on several CD’s or on DVD, feature tons of high quality graphics and music and have the latest top notch 3D engine that allows all kinds of freedom.
If you want to develop such games then I’m sorry, you are wrong here, please move along to a more suitable site like The Game Programming Wiki or gamedev.net! However if you want to develop interesting 2D games with unusual ideas or if you want to be the new Andrew Braybrook who writes a swift Uridium Flash clone then don’t move, stay where you are, you are absolutely right here!
If you are already familiar with Flash I don’t need to explain you the pro’s and con’s of it but if you’re new to it let me explain quickly what Flash is good for and what not …

Pro’s:

  • Compactness. Flash’s format keeps a compact size and is especially useful for the web (but not limited to it). Also the programming style with Actionscript is very compact. The native movieclip structure makes it possible to handle graphical elements with ease and it takes few lines of code to get things moving.
  • Platform independence. Flash movies run on the most common platforms like Windows, Macintosh and Linux. Many mobile devices like cellphones and PDA’s support Flash Lite (a limited version of Flash) and recently some of them even support full Flash MX support (like the Wilcom WX310K).

Con’s:

  • Slowness. Yes it’s true unfortunately. Flash is slow compared to most other languages, even compared to Java which also has JIT compilation. But improvement is in sight! With player version 8, Flash experienced a decent speed improvement and with the upcoming Actionscript 3.0 and Flash Player 8.5 there will be once again a big speed improvement. It’s amazing to see all the AS3.0 demos that currently pop up on the web and show things that weren’t possible before.
  • No DirectX. to maintain platform independence and compactness Flash sacrifices DirectX support and therefore it isn’t really the choice for fast 3D graphics. There is limited DirectX support by using some third party tools like mdm Zinc or swfXXL but these are usually to display the movie on a DirectX screen resolution to improve the framerate. Currently I have no information if Flash will ever support hardware accelerated graphics support like OpenGL and while it would be unexpected it would surely be a welcome feature that would once again unlock a whole lot of new possibilities.

Game programming with Flash in short means to create interactive games either for deployment on the web but also for offline use and installment to the users hard disk. Flash is an ideal environment to develop video games of the two dimensional nature. That said it is still possible to create limited but interesting three dimensional content with Flash.

Flash games can be written by using the commercial Flash IDE but since a while it is possible to use open source tools like the AS2.0 compiler SWFMill, the Eclipse IDE with ASDT or any other additions of the ever growing open source pool to create them.

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.

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!

Designing the Game

Don’t take this step easily! 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!
  • 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. 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! Such people can provide you with feedback to prevent unnecessary problems in your design.

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.
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?!

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.

Comments