Day 5 - I always wanted to have inertial dampers for my Asteriods game!  Kinda like "air" brakes.  I was one of those kids who was determined to get the highest score in Asteroids, so I'm well aware of the repetitive stress factor, so I found a way to slow down the ship just enough to get a break from the constant flight.  Now I want weapons.  Right now, the ship just collides with the heavenly bodies around it, which are set up as "sensors" (collision events) that signal mp3 explosions.

Other things to outfit the ship and enemies: shields, cloak, and vapour trials.

I also managed to tackle some CPU and memory issues to keep the frame rate down.  Caching objects, offscreen baddies, etc.  I didn't think I'd get the hang of this, but I'm baby stepping my way to game codedom.

Still no touch controller - the solution is more complex than I anticipated.

Day 3-4: Today I'm still working on coding up game examples and working with p2.js physics - and so far only working with hooking up keyboard event listeners.  I'm investigating how to build a spaceship controller for touch screens, and looking at games that implement joystick style controls for ships in physics driven games, to gain insight into the user experience (I don't want to be responsible for repetitive stress syndrome for my user base by picking an awkward control strategy).  Learning how to create and integrate audio for games has been great fun.  Finally,  my audio engineering college debt has a purpose!  OK - time to get back to the space ships game!

OK, day 2 - I'm learning about JavaScript physics engines, and using pixi.js to create a game.  My game idea is for a physics based space fleet strategy/2d action top-down scroller, reminiscent of Deimos Rising, with strategy and commerce aspects (think starlancer and Freelancer).  Some challenges are mainly in the realm of cross-platform/device development.  Maintaining keyboard support and touch in one code base is already top of mind.  Any comments on how you've solved this challenge?  Getting artwork into the workspace and workflow is another, since I'm developing the full stack.

Hi, I'm Mark Cafazzo.  This is a blog of my first game development project.  I've been creating software for some time, but for business or industrial automation, not games.  I've been playing and enjoying games on computers since Pong, but I've never considered working for a game developer or making a game on my own time.  I'm really pumped about getting started!  There is now an array of development tools, platforms and libraries that best suit my game idea is proving to be full of options and I'm finding it difficult to make a decision.  My requirements are:

1. A game that doesn't require complex art resources, or an artist, since I'll be creating the game from scratch, and working on it alone.
2. One code base for both Android, iOS and Windows Phone with minimal build steps.
3. Libraries that make scenes, game physics, effects and orienting players a snap, even if that means making the code to do these things easier to connect to the visual assets (not afraid of complicated code).
4. Any library or cross-platform toolset I use should allow for as close to vanilla JavaScript/HTML5 as possible (no crazy new DSL or syntax, please).
5. If a server side aspect of the game engine or play is considered, one that keeps the list of programming languages I have to use to a minimum.  (Again, complex code is not an issue, but I'd rather concentrate on a handful of technology and not spread skills too thin)

I'll revisit these requirements as I go along.  Here goes.  Next post should have a short list of technologies I'm considering or have tried out, plus an outline of my game idea.  All ideas I share will be adequately copyrighted, so no plagiarizers should get any "ideas"...