Friday, 10 June 2011

Flash game development book ideas

I've been mulling over the idea of writing some kind of book or eBook in the future. Rather than being a set of example games like most Flash games books seem to be, it would arm you with the techniques to create your own games, so when you are stuck on a specific topic it is quick to look up.

The book would be almost completely source-code based (with plenty of comments). There would be almost no "waffle" sections of description. It would be more of a look-up (or copy-paste!) technique reference than a traditional "blah-blah-blah" book. Due to this format I think it would be better as an ebook than a dead-tree book. What do you guys think about that?

Anyway, here are my topic ideas. Could you please let me know if there's anything that should or shouldn't be in there?

Input
- Keyboard input and control (from scratch and using Gamepad library)
- Mouse input and control

View
- Top down (+2D Camera)
- Side-on (+parallax)
- Zelda style (+Depth sorting)
- 3D third person (using Away3D)
- 3D first person (using Away3D)
- Mini-map / radar

Rendering
- Blitting
- Using DisplayObjects efficiently

Maths
- Useful maths
- Vector maths

Security
- Site-locking a game

Game engine
- Time steps (basic, deltaTime, fix your timestep)
- Game loop (and pausing)
- Entity systems (inheritance-based, and component-based)
- Object pooling

Collision detection and Reaction
- Circle-circle
- Square-square
- Square-circle
- Line-line
- Line-square
- Line-circle
- Separating axis
- Using hitTestPoint
- Using bitmapdata getPixel
- Using bitmapdata hitTest
- Collision reaction for platform games (player and projectile)
- Collision reaction for top-down games (player and projectile)

Physics
- Top-down car physics
- Platform physics
- Projectile physics
- Using a 3rd party physics engine (Nape)

Environments
- Tile-based techniques
- Using Flash as a level editor - parsing etc
- Creating an in-game level-editor.
- Procedural level generation

Animation
- Bones animation
- MovieClip animations
- Creating your own simple tweening system (+ easing, springs)
- Using a 3rd party tweening engine in-game (TweenMax)
- Sprites sheet / image sequence animations

Audio
- Creating a reusable sound manager
- playing sounds and music
- mute button / volume controls

Gameplay
- Scoring, achievements and saving your game.
- RPG characters - inventory, stats, health, buffs/debuffs.
- Weapon management

User Interface
- HUD
- level select menu
- Main menu
- Shop

21 comments:

crookedspoon said...

sounds like an awesome idea and a very useful reference.
Wondering about the book format though:

wouldn't it make more sense to have a moderated-wiki-reference-kind-of-webpage to do so?

That way, different people could contribute and there's room for a updates and discussions.

bart

Iain said...

Yeah but how could I sell that?!

PhotonStorm said...

A book covering all of this would be bloody massive! Still I'm going to add more to the list that I feel are important:

1) Enemy AI - both basic i.e. platform traversal to path finding and seeking

2) Particle effects

3) Game State management, swapping from Menu to Game to Highscore without leaving crap running in the background!

4) Projectiles - bullets, firing effectively, multiple angles, collision between fast moving bullets and baddies (CCD) etc

5) Grid Management for puzzle games (actually quite a complex area if covered in depth!)

6) Preloaders. For some reason I see this cocked-up SO many times :)

7) Writing JSFL scripts to make IDE life bearable

Those are off the top of my head anyway. I think such a book is a massive under-taking. So many large areas to cover :(

Damian said...

+1 for the Game State suggestion. Game States make it so easy to separate out different logic and stop your game becoming a spaghetti mess. Plus, they work nicely towards AI as well.

Others:
1) Optimisation: It's surprising how many people don't really know what's going on behind the scenes in flash, be it garbage collection, or what happens when you set cacheAsBitmap etc. You could probably capture a lot of people that want to make games for mobile and flash is a good way to start. For that, you need optimisation so it doesn't run like crap. Similarly, in social games, you have a lot of devs coming from other languages, where it's easy to kill the game if you're good at coding, but don't know the specifics of flash.

2) Explaining the "why" you do something as well as the "how". A good example would be game timers. You can show a good fix your timestep example, but it's more valuable to a dev "why" you do it that way, why you use enterframe over timers etc

3) Resources: all the different libraries, links, and people that make your life easier

Mark Hardisty said...

Top-down car physics is something that's never featured in any book with good collision reactions between two rectangle or other shapes.

Particle engines and linked lists is something else which is quite thin on the ground.

Monetizing may be another subject, along with the XML structure of maps and downloable levels.

matt said...

I'd love to see this. In fact, I'd love to see this sort of book exist targeted at any language or platform!

Iain said...

Thanks for all the brilliant suggestions so far!

Malo said...

dynamic sounds out of left / right channel depending on distance from object.

I suppose these have documented API's etc, but there may be scope for instructions on implementation within a reusable framework.

Analytical data - GA, Mochi...

implementing social API's into your game, such as Kong, FB etc.

GrindheadGames said...

Not sure why it said im called Malo!!?

alijaya said...

isometric view? :-?

btw... it will be awesome book i think XD

Renegade said...

I would buy a printed copy of this book (assuming it didn't cost like $200). An ebook doesn't have much value to me, if I'm learning something new I much prefer to read about it away from my PC first, and then sit with the book by me while I'm trying out the coding.

For me the book would need some "waffle" - terms like "blitting", "object pooling", etc mean nothing to me unless you say what they are and why I need them.

Iain said...

I would definitely give a quick explanation of why each technique is needed, yes.

Really not sure about the need for a printed version. I quite like the idea of self-publishing and keeping 100% of revenue, rather than the 10% I would get from a publisher. Guess I could look into how print-on-demand works...

Mark said...

Sounds like a brilliant idea Iain.

Off the top of my head, it'd be good to bring this into the tablet era. So it would need sections for touch, multi-touch, accelerometer in the Input section. State management and asset management (multiple resolutions) would also be good topics to cover.

Mark
(@mark_star)

Peter MÃ¥seide said...

Good ideas!
One extra suggestion under "Security":
- Highscore encryption and anti cheat techniques.

Iain said...

@Peter - ha ha - that would be a short chapter: unfortunately there is no such thing, other than putting all your logic on the server.

gludion said...

suggestions:
- collision manager (just the basic architecture, not the shapeA-to-shapeB collision algorithm, nor the details of spatial optimization)
- UI controlable both with mouse and keyboard (pretty useful in keyboard games)
- what the IDE can be used for (ex: level editor, visual layout of game actors with parameters, synchronizing events with animation, etc.)

Ziro said...

Hey.

Sounds like a cool idea. You have lots of ideas here.

+1 for the collision detection and reaction, and preloading (especially if it's an all-in-one SWF, and you don't have [or refuse to use] the IDE for preloading, and prefer factory class).

+1 on the monetization suggestion.
+1 on optimizing.

I would suggest multiplayer, but that's probably a book all by itself. (:

Event listeners, and why one would choose to write them as:

object.addEventListener(type, function, false, 0, true)

with emphasis on the last three parameters. (:

SWFs loading SWFs. This is a big topic I think, and there are some caveats to it. For example, if the parent SWF and the child SWF use the same class, the child SWF will inherit the class from its parent. So, for example, say the parent SWF is some gameloader not written by you (came from client, etc,), and it's using some 3rd party AS library. Your child SWF is also using this same 3rd party library, but you're using a newer version. This could cause some problems that might not be obvious, and may not necessarily be caught at compile time.

Everyone seems to be jumping on the Facebook bandwagon these days. While not exactly game related, a section on how to use that cryptic API of theirs might help for those that want to go that route.

You have enough material here where someone could build their own engine from the ground up, especially if they don't want to use something like Flixel, etc.

This is quite an ambitions idea, and should you decide to take it on, we all wish you the best.

___________________
- Ziro out.

Ickydime said...

Awesome listing thus far. I have to agree with PhotonStorm though and say this is going to be a massive undertaking.

I am not sure what your personal goals are, but perhaps you could find games that really tackled some of these issues well and see if their developers would want to write a chapter on those topics.

Similar to the good ole days of Friends of Ed's Masters of Flash.

MC said...

I'm not sure, but i think it's easier to earn money with advertisements than selling an (e)book... but you know some developers that have made ebooks recently (emanuele feronato, freelanceflashgames, etc) why don't ask them? (and share the information) :)

wacks said...
This comment has been removed by the author.
antique car restoration said...

nice article. thank you so much.