Seed ES: Starfighter Refactored

And, we’re off to the races!

  • Built ES Framework Atom Smasher.  Cross your fingers:  it might be awesome.
  • Cleaned up the Nancy Game1 class they give you.
  • Created a StarfighterX Game State and set its wheels spinning.
  • Sqashed a lot of small bugs.
  • Added Position and RenderToy3D components.
  • With a crap-ton of pain, I got a RenderSystem3D built and working.  I borrowed from later versions of the Starfighter X OO classes.  Took me forever to figure out that the damn thing wouldn’t draw because I forgot to call Draw().  But I fixed a bug in my pooling system in the process.

Goblin Sanatorium

Previously, I’ve posted a meta-formula on complexity in video games designed to determine how long a game takes to make.  The idea was nice, but the premise was flawed.

Why, you say?

Because each element in a game has to communicate with other elements.  Using standard Object Oriented Programming (OOP), the reigning paradigm of computer science, that means each element has to be wired to many other elements in ways that are increasingly arcane and convoluted.

The result?  Well, suppose that e = the number of elements in a game, and c = the average complexity of those elements.  One would predict, given my former formula, that the total (t) amount of complexity of a project (and thus the time spent in it) could be expressed as:

t = ec

But Starfighter X has taught me that because of the way elements have to be wired together, the…

View original post 288 more words

Continue reading

ES Architecture.

NOTE: This blog post is a work in progress, which I am keeping visible because it may be of some use even before finishing.

Entity/System Architecture is causing a little buzz on the internet.  Some hackish form of it is already being employed in most games and game engines, according to Megan Fox (no, not that one…).

If you want to know how it works, the best quick intro I’ve found (for not-so-badass programmers like myself) is this article on the model as conceived, and this follow-up article on the model as modified and implemented in the Java Artemis framework.  Once you’ve read those two articles for the introduction, read the foundational essays by Adam Martin that inspired the Artemis framework.  Martin also has a wiki devoted to ES, the URL of which has escaped me for the moment, but you will get much farther by reading his essays on T=Machine.

If you search Amazon for books on ES game programming, you will find the literature just isn’t there.  If you Google it and surf around you will find a lot of pages that give overviews of varying quality.  The concept is really old, but it would seem it is just starting to get its own head of steam.

ES sounds like a dream come true to a budding indie, especially one whose strengths are not coding, but art and story and such.

For a long definition, check out the links in the order I posted them: first Fox’s, to see how it’s normally done, then the piemaster articles to learn the difference between the hackish standard technique and the more purist technique used in Artemis and in Martin’s work.  Then, if you like it, read Martin’s stuff.

K.  Short description:

Forget Object Oriented architecture.

Game programs are made of three things:

Systems do the work of the program… e.g. there is a Drawing System and a Physics System and so forth.

Components are clumps of data upon which systems work.  For instance, Drawing System needs a Position component (to know where to draw) and a Graphic component (to know what to draw).  A Physics system needs a Velocity component (to know how far to move) and a Position component (to know where to move from; also to write the result of the move).  Because multiple systems may need access to the same component (for instance both Physics and Drawing need to access Position), Components are abstracted away from Systems.

Think of systems as basically Turing machines; tape recorders working their way down a strip of tape.

Great, so if components are strips of tape, how do you know which position goes with which graphic?

Entities are names (well, really IDs).  Two components with the same name go together.

You can also picture it as a graph or table.  Each column is a Component type, each row is an Entity.  Each System rolls down the table, and if any given row has Components that System requires (such as a Graphic and a Position), the system stops and processes those components.

(And in fact, that is roughly how Artemis operates).

The upshot of all this is that you can add any behavior to any entity merely by adding the necessary components.  Want to turn a rock in your game from a chunk of static background to a chunk of destructible background?  Just add a Health component.  Bam!  Almost zero extra coding.

That’s a bad summary, but the internet is full of summaries which detail more advantages (and disadvantages).  The ones I’ve linked do a good job of defining my target.

The question is how do I get as close to my target as possible while slapping something together in C# and XNA and understanding everything I’m doing and having it up and running before I go to bed in a couple of hours and on and on and on.

Here’s my proposed architecture:

1. Components:  A Component is just data.  But every component has: 1) An int IDing the component’s Entity, and 2) A flag representing whether the component is attached to an entity or not (thus allowing us to detach components by setting the flag).  These may be the same data point (i.e. reserve one entity ID for “N/A”).

2. Component Manager: Contains a fixed-size array of one type of component.  Has a unique integer ID.  Maybe has some efficiency-related stuff (calls to add or remove components; pointers to the current earliest unclaimed component so we can claim/reclaim it; a pointer to the current last component so we don’t have to loop through the entire array unless it’s actually full).

3. Entity: Contains a string name for human reference, and an array of ints equal in size to the number of possible components, with the variable at the index equal to the ID of a given manager is either -1 (this Entity does not contain that component) or else the index of an attached component in its manager’s component array.

4. Entity Manager: This is important:  Entities are not Entity Objects.  Entities are numbers.  Integers used as names.  The Entity Manager has an array of Entity Objects.  That array is nothing more than a lookup table, allowing us to find components attached to the Entity that is the array’s index.

Hence, to attach a Graphic component to an Entity, (given OurHero as an int)  you might say…

EntityManager.Entities[OurHero].Components[GraphicManager.ID] = GraphicManager.Add(HeroTexture);

GraphicManager.Add would find an unclaimed Graphic in its array, claim it, load HeroTexture into it, and return the index of the Graphic.  Thus, the EntityManager.Entities array can serve as a look-up table in case we have something that may need to modify the Graphic (say an Animation system).

Which brings us to…

5. System:  A system does not crawl through every entity (that would be lame.  Most entities are going to be particles, for instance, and we don’t want to make the Enemy AI system look up a crap ton of — say — smoke particles that make absolutely no difference to enemy AI).  Instead, every system has one component type that is crucial.  One type that implies the system.  A Position component may be used by any number of systems, but a Graphic component implies a Drawing System.

The System only loops through the array of the component that implies it (i.e. DrawingSystem only loops through GraphicManager’s array), but it takes as arguments the managers of the other components it needs to operate (such as Position).  Then, when it processes that component, it check’s the EntityManager to get the indices of the other components it needs.  E.g.

int p = EntityManager.Entities[GraphicsManager.Graphics[i].Entity].Components[PositionManager.ID];
if (p > -1 && p < PositionManager.Length) Draw(GraphicsManager.Graphics[i], PositionManager.Position[p]);

These indices are pre-validated.  If the System doesn’t have access to all the components it needs, it simply skips that component.

So, the Entity/EntityManager, once again, does not maintain Entities; it merely maintains a look-up table.

That’s the plan.  Let’s see how it goes.

Step 1:  Entity.

using System;
namespace AtomSmasher
   public class Entity
      public int[] Components;
      public bool Live = false;
      public Entity(int NumberOfComponents = 1)
         Components = new int[NumberOfComponents];
      public void KillEntity()
         for (int i = 0; i < Components.Length; i++) 
             Components[i] = -1;
         Live = false;

Yeah… Atom Smasher.  It seemed the logical choice of names for an ES engine…

Note the lack of stuff in Entity.  Hell, I even stripped out the Name — we can attach the name as a Component.

K, now Components.

using System;
namespace AtomSmasher
  public virtual class Component
    public int EntityID = -1;

Yeah.  Most stuff will be implemented in the individual components.  ‘Nuff said.

#myouyagame — Gritty Reboot

I’ve talked to Greg and gotten a cautious optimism toward Gritty Reboot.  I have plans to propose it to the company when next we convene (in January) as a potential alternative to Starfighter XR.

OK… what am I talking about?

First off, Giant Inflatable Transforming Robot, LLC is dead.  It was an ill-conceived computer store meant to fund a media venture.  My rule for the media venture:  no company until we have a product, was dropped by the company in general (in fairness, I did nothing to oppose) on the principle that a computer repair store needed no product per se — it’s a service company — which could get me more time to devote to the programming and graphics.  This, in turn, led to a crunch as 1) one of our repair guys turned out to hate repairing computers,  2) the other guy turned out to be a problem, and 3) making computer games turned out to be more time-consuming and difficult than we imagined — a common ailment of pretty much every indie company (and nearly every game company in general, according to my posthumous research).  Those companies that succeed are those that push through and, from time to time, scale back.

Which was my purpose for Mega Hyper Parallax Starfighter X.  To just make a damn game.  And it succeeded beyond my wildest expectations, though it is almost sure to be a commercial flop.  Starfighter X is fun, no doubt, but it offers nothing new, and has no real way to stand out on the market.

Consider it one small step.

In the meantime, GITR LLC has closed down, on account of there’s no point filing paperwork for a company that does nothing.  And with me having finished a game, we plan on starting fresh in January, with the release of Starfighter X and the dawn of a new game project on my part, with more realistic expectations and goals.

Starfighter XR is the heir to Starfighter X, and the second indie game to go on market for Giant Inflatable Transforming Robot or Nerd Posse Studios, or Pen Dragon, depending on what our company game is going to be.  It is a drag-racing/space combat game inspired by Star Wars Podracer, F-Zero, and most especially, the Broadsword level in Halo4 — there isn’t enough gameplay of that sort on the indie market, IMO.  It was my intention to propose XR to the company at the reboot, maybe kludge together some gameplay over the last half of December.

butbutbut… there is Gritty Reboot.

A couple of pics is worth 2,000 words:

GR1 spaz

The first pic is a set of recent designs for an old GITR project:  a machinima with a custom-written engine, back when we wanted to make cartoons as opposed to games.  It’s a photo of a doodle I made on break at Le Zarci, my day job.  The idea is that obvious parodies of popular game characters are stuck in a reality show together.  Left to right, then top to bottom, we have Megaroid, a parody of Megaman/Samus/Master Chief, Jesse/Jessie (we aren’t sure which) a parody of Link/Cloud Strife, Spaz the Dragon, a parody of Sonic/Spyro, and Tony, a parody of Mario.  From the games Megaroid, Last Legend 29 1/2, Spaz the Dragon, and Super Antonio, respectively.

The second pic is from a rudimentary platform engine I scraped together over the course of a week, starring an older Spaz design, and using physics inspired by the actual Sonic Physics (but not conforming to them).

Lest you feel unimpressed, the engine automatically calculates the angle of each tile from the graphic itself, as well as recording the height of each tile, so that Spaz can run over the tiles in like manner to Sonic, fluidly changing angles and staying at the right location on the screen when grounded, not a bad accomplishment for someone whose previous credits are on the level of Space Invaders.

Recently,  Ouya started up a Dev Console Giveaway.  I thought, “what the heck?  Why not do Spaz?” Then I entered.

But a decent platformer for an indie company is a good 2-year project.  Plus, I don’t know a thing about Android programming.

Fortunately, the transition from C#/XNA to Java turns out to be not as hard as I anticipated.  More like changing accents than changing languages.  Also fortunately, 90% of platformer dev time is content generation, especially level creation, according to James Silva.

So, here’s the plan:

  • Gritty Reboot the game.  The worlds of four popular (fictional) video games are merged, resulting in a vortex that is world-normal on the outside, increasingly blended as you move in, and chaos at the center.  Our heroes have to stabilize the world.
  • Thus, you get to play them in each-other’s levels.
  • To keep the release date soon, the levels will be tightly constrained.  Two for each character — one normal, one with things going obviously wrong, then two sets of crossover levels (Spaz and Jess, Tony and Megaroid), then two totally blended levels, then two boss levels, for a total of 16 levels, with only four tile sets.  Most of the level design would be offloaded onto Greg and maybe David if I can conscript him as well.  If we need to cut back, we will do one of each, dropping it to eight levels.
  • Spaz’s physics are already done, for the lion’s share.  Jess will have his/her/it’s physics modeled after the character physics in Zombie Smashers XNA, the tutorial in Silva’s book.  The same engine can model Mario-like and Megaman/Metroid hybrid physics quite well, and will be used to do so (so effectively, two physics sets, one of which has three configurations).
  • Additional levels (and characters) to be released after creation as DLC (if I win the Ouya, or later on the Ouya if I don’t).
  • Source Code Open and Released!
  • Source Code Open and Released!
  • Source Code Open and Released as a tutorial on writing platform games.  Assets (graphics, levels, etcetera) not included, but if someone takes my code and writes a killer platformer with their own characters by mildly tweaking it, I consider that a win (more games that I enjoy playing).
  • I kludge together a working version of the game with single level and 1-2 playable characters in XNA as a demonstration that I can do it, for the Ouya contest, and a playable proposition for the company in January.
  • If I win the Ouya dev kit, I start developing GR for Ouya.  If not, I start developing in XNA for Dream Build Play and release for Ouya (and perhaps Steam) once Microsoft’s lawyers permit.
  • After the game is up and running, I start building in the recording and acting features for the machinima cartoon, and we produce that too.

Gameplay styles:

  • Spaz the Dragon works similar to Sonic the Hedgehog, with some tweaks.  He can breath fire.  His health is based on enemies defeated rather than rings.  He can curl and uncurl in midair (up and down, respectively), flap and glide (jump button), and wall kick, making him a bit more mobile and controllable.  The goal for him is to get to the end as fast as possible, which is facilitated by greater mobility with each power level he reaches (power levels are gained by defeating enemies, lost by getting hit).
  • Tony works more Mario 2 than any other Mario game, with picking up and throwing stuff, including enemies, as his primary mechanic.
  • Megaroid works a lot like Megaman X.  Charged shots, wall sliding, dashing.
  • Jess is a combo-based fighter who in his/her game proper would have a level-up system similar to Dust, but there’s really no time to implement that in this game.

So.. let’s see if I can get some steam!

Mech Game Redux Redux Redux

Read this article on Gamasutra:

A combat system well designed is a system which can entertain a player for hours. If the combat system is well conceived, the game will feature a large variety of combat.

A good way to obtain a such combat system is first to design very different abilities for the player’s character.

The player’s abilities can be differentiated in many ways. For example, designers can add special attributes to some of them: stun, regen, damage over time, repel…

The second point to keep in mind is to design enemies that match the player’s abilities. Each enemy has to offer a specific challenge which will push the player to use a certain type of ability to defeat him.

To finish this article, from my point of view, one of the most engaging feelings a player can experience with a video game is to feel smart and proud of his or her cleverness. And a combat system is a great tool to let the player experience this feeling.

..with many attendant examples from Mario to Halo.

This is one of my big issues with the mech game: it doesn’t have this.

The idea is to have a game where mecha wander around trying to kill each other using custom weapon loadouts.

The issue is, without terrain (which I don’t really have) and with mechs that are slow and lumbering (as planned), there aren’t really choices that allow for feeling smart and proud of cleverness.  If the weapons are balanced, then the gameplay boils down to “who can keep their weapons pointed at the enemy most consistently”.  If the weapons are not balanced, then the additional complication of choosing the weaponry with the highest rate of damage output will add about two minutes of entertainment to the game.

In the great granddaddy of all good mech games, Battletech, the tradeoffs that allow for decision making are thus:

  • There is terrain, and it does matter.
  • The more weapons and armor you load up on, the slower you move.
  •  Weapons have different effective ranges, with some being better close in and some being better farther out, which makes movement speed and terrain meaningful.
  • Armor tends to be weaker in the back, which makes movement speed and terrain meaningful.
  • Weapons trade off on damage amount, ammunition, heat generation, and weight, as well as maximum, minimum, and effective ranges.

Come to think of it, there are elements like this in Halo: you can carry around turrets, but it slows you down.

So, if there was terrain that mattered, and range that mattered…

Seed1: Aftermath

Expected time: 14 days

Time: 27 days

Game Awesomeness: 2 out of 5 stars.

Likelihood to make a dollar: Zero.

Seed1: StarfighterX

Current Image:


  • Camera and Model classes shamelessly stolen from ‘Dozer.
  • All models done.
  • Models displaying on screen correctly.
  • Resolution set.
  • Font located.
  • Got font working.
  • Got font to display at the same time as ship.
  • Created a Gamepad manager and hooked it up to the model.
  • Created a base physics tracker and hooked it up to the model.
  • Created a Ship class which contains the physics tracker, model, and padmanager.  Now, my game’s update function looks like this:


  • Added basic collision detection to the model.
  • Fixed the physics tracker so that it tracked scale as well as position, velocity, acceleration etc…
  • Created a Particle class to track bullets.
  • Created a Particle System class to track particles.
  • Created a Particle Manager Abstract class.  Next:  Bullet Manager.
  • Got the Bullet Manager, and the Particle Systems working!  Woohoo!  This, ladies and gents, is the first step towards custom weapons in the mech game.
  • Starfield!  My particle manager is truly versatile!
  • Particle Manager now handles three distinct particles:  Bullets, shrapnel, and stars.  Woohoo.  Time to stop playing with that and add some bad guys.


We can fly, shoot, and pause.  Now we need something to shoot!  Aaaaand…. go!

  • Made a copy of the player’s ship class.  Named ‘Minion’ in the fond hope that I might do a boss, somehow.
  • Switched out the ship’s gun locations.
  • After much wrangling, got a minion on the screen shooting two bolts out of his gun.  Under player control, for now.
  • Incidentally, even though I had built in the setup where the program finds the nose of the gun in the model data and uses it as the shooting point, the shots were still coming out of the nose of both models, even though I told the minion to use his engines instead of the nose.  Rooting around in the code for why that was also allowed me to fix a bug that would have made the collision detection malfunction.  Right!  Time to make the bullets hit!
  • Got the bullets to hit.  This is the first time I put the collision detection system I made yesterday afternoon and fixed twenty minutes ago to the test.  And it works like a dream.  The bullets only hit when they solidly hit the ship.
  • And now… SPLOSIONS!
  • Next on the list is giving the enemy his own ability to move, which means making a State Machine, the heart of Game AI. But first:  SHOWER!
  • Toilet crapped out on us.  [sarcasm]Haha, get it?[/sarcasm]
  • Built a base state class for the state manager.  Now for an evade class.


  • Score counter created.
  • Enemy respawn created.


  • Evade, Wander, and Search&Destroy behaviors created.


  • Swarm created.
  • Enemies given ability to maneuver around each other.  Kind of.
  • Bloom added.


  • Minions come in waves of six.
  • Initially, a minion dies upon being hit.  Every three waves, the number of hits a minion can take goes up one.
  • Every wave, the minions grow slightly more aggressive.
  • Every wave, the minions grow slightly faster.
  • Each time you hit a minion, you get a point.  Each time you kill a minion, you get two more points.  Each time you finish a wave, you get four more points, plus points equal to the number of waves thus far.
  • For each bolt that hits you, you lose a point.
  • You have a life rating that decreases whenever you are shot.
  • Your life regenerates at a rate of one point every ten seconds.
  • If you have taken damage, you emit red sparks in proportion to the damage you’ve taken.
  • You can die.  You have three lives.
  • When a new wave spawns, the enemies are temporarily invincible, but will not fire until they are vulnerable.  When you spawn, you are temporarily invincible but cannot fire until you become vulnerable.
  • Your enemies don’t waste shots if you are dead or invincible.
  • Characters are different colors when invincible.
  • The background starts out black and becomes faintly bluer each time you kill a wave.
  • The number of stars increases a small amount every time you kill a wave.  The effect is not noticeable during play, but will become noticeable when players are able to start a new game and go “Holy crap!  There’s fewer stars!”

7/16 – 20

  • Accuracy bonus based on shots fired/shots landed.
  • A Time Bonus that counts down as you play.
  • Enemies AI improved to something resembling actual non-random behavior.
  • Movement for everyone tweaked.
  • Dynamic life display created.
  • Bugs regarding life display mercilessly exterminated.
  • Caffeine consumed.
  • Enemies regenerate and emit sparks when damage, to encourage the player to take risks and chase down wounded foes.


  • Reset Function created so that new games can be played.
  • Control globalized (updated by the game, not the player’s ship), so that you can pause and stuff when the hero is dead.
  • AI taught to spread its fire out a little more, so you’ve got places to dodge.  Average programmer score now 550.
  • Pruned blog to put all Seed posts in one place.


  • Made a menu class.
  • Made a title menu.
  • Made a pause menu.
  • Tweaked the AI to be exponentially more jumpy the more alone a minion is, and to make sure that at least one guy is trying to kill you, thereby ensuring that the last minion doesn’t spend twenty minutes hiding in a corner while your bonus slips away as you try to line up shots.


  • Added a text centering and drawing class, to simplify things.
  • Added instructions.
  • Added Credits.


  • Created a countdown timer so that game modes switch at appropriate moments.
  • Created Hiscore changer
  • Created input methods for changing hiscore initials.

The game is functionally finished!  All that needs to be added are sound effects, (maybe) music, the reward pictures for the Prophesy segment, the altered control manager for the XBox, and the saving and loading of high scores and picture unlocks for the XBox.  The last two can wait for the App Hub account.