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.
Input
- Keyboard input and control (from scratch and using Gamepad library)
- Mouse input and control
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
- 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
Comments
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
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 :(
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
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.
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.
btw... it will be awesome book i think XD
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.
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...
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)
One extra suggestion under "Security":
- Highscore encryption and anti cheat techniques.
- 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.)
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.
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.