Sunday, July 10, 2005

Space Crack: Component Bible

This is part 11 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about getting the game ready to prototype. This time I'll create a bloody long list of all the assets we'll be needing. This is more exciting than it sounds.

Breaking the rules of prototyping
As many of you may have noticed as you peruse my website, I’m more of an artist than a programmer. One of my goals is to create as much of the artwork for the game up front such that the programming has no bottle necks when full on production begins.

In the ideal world, this is the exact opposite of how you ‘should’ do it. When prototyping the game, it is best to rely on cubes and other primitive graphics so that you can focus on polishing the core game mechanics first.

But I do not have a dedicated programmer at this point in the design process. Sometimes you just have to push on through to the other side, regardless of what resources you may or may not have at your immediate disposal. Persistence is a marvelous quality during the very early stages of a game design. This applies to both big games and small games.

The component bible: A theoretical underpinning
I need a way of organizing all the various art resources necessary for Space Crack. A common technique is to have a master list of all assets in the game called the Art Bible. Typically this includes a list of all the art resources required for the game.

Since I’m using Anark Studio, I can extend my art bible to include state information in addition to standard items such as models and textures. I want to introduce some basic nomenclature for defining objects, states and sub-states:

  • Component: A component is a self-contained object that includes a variety of states. For example, the end of game screen might be a component that has states ‘Off’, ‘Intro Animation’, ‘Body’ and ‘Exist Animation’. I’ll denote Components with a ‘*’ character
  • State: A state is a unique mode of the component. A component can only be in one state at any time. A state can have unique properties, objects, etc compared to an alternate state. I’ll denote States with a ‘-‘ character.
  • Components can contain other components: For example, our end of game screen might have another component called the ‘Exit Button’ that only displays when the ‘Body’ state is showing.
  • Each sub-component can contain its own states. This is how sub-states are created. For example, our Exit button might have it’s own states of ‘Normal’, ‘Mouse Over’ and ‘Down.’

With this system, I can define most objects in most games. There’s still a lot of programming left to set up, but with a fully finished set of components, it should be much easier to hook up the final game.

Asset Management
A huge undertaking for most commercial companies is asset management. When you have thousands of assets, keeping track of them is a miserable activity. I have less than 50 assets in the game at this point in the design. For small teams a “Naïve Asset Management” system in the form of a simple order list can be remarkably useful. Keep this on a Wiki and you can solve a rather major problem quite simply.

Some “Naïve asset management” Rules:

  • Components that are finished will be moved in to a separated Finished Section of the Bible
  • Components are prioritized by importance so that they can be tackled in an iterative manner.
In total, I have around 21 components that I’ll need to create for this game. This will grow dramatically in future passes on the game design, but for now it represents a manageable work load.

Take care

Components left to create


- Launching
- Firing
- Exploding in devastating ball of flame. (aka The Boom State)
- Landing: Conquest
- Landing: Merging
* Planet

- Neutral
- Captured
- Perimeter World
* Player Flag
-- Remote Source Flag
* Territory Connector

- Off
- Connect Animation
- Connected
- Detach Animation
* Missile

- Launch
- Fly
- Explode

* Upgrade Platform

- Normal
- Over
- Open Menu

* Upgrade Choice 1
-- Normal
-- Over
-- Select

* Upgrade Choice 2
-- Normal
-- Over
-- Select

* Upgrade Choice 3
-- Normal
-- Over
-- Select

* Upgrade Choice 4
-- Normal
-- Over
-- Select

- Upgrade Selected

* Crack Counter

- Empty
- Full
* Command Counter

- Command Points Empty
- Command Points Remaining
- Turn Ended

* End of Game Screen

- Off
- Intro Animation
- Body

*Submit Button
-- Normal
-- Over
-- Down

- Exit Animation

* Welcome Screen

- Off
- Intro Animation
- Body

* Exit Button
- Normal
- Over
- Down
- Exit Animation

* Flare Object
- Black Flash
- White Flash
- Red Flash Slow
- Invert
* Sun
- Normal
- Flare
- Pre-Nova
- Super Nova

Finished Components
Ultimately, this section will contain links to the finished files.

*Planet Selection Gizmo
- Deselected
- Selected
*Planet Destination Gizmo
- Deselected
- Selected

*Ship Platform

- Empty
- Over
- Building Animation
- Built


  1. hi Danc!! What a pity I've discovered your blog only recently! At this moment I've just finished reading your posts about Space Crack and well... you know it, it's so rare to find such a smart and elegant game design!

    But let's get to the point... when you speak about how the game begins, there's a crucial element you did not address: the initial configuration of the game board.

    Three are the possibilities:
    (i)designer'designed (as in Risk, or chess)
    (ii) randomly generated each time (you know "Strange Adventures in Infinite Space", don't you? -->
    (iii) player designed (as in Go)

    I wonder which solution you were thinking about... according to me player design would suits best: the board could be conceived as a sort of grid, and the player could have a initial stock of planets to distribute. And to avoid the potential problem of two (or more) players trying to put their planet on the same spot, you could present the grid with different 'areas': each area will be then populated by a different player.

  2. Hi Splash,

    Good point about the initial board set up. My thought was to have a relatively uniform board filled with planets that are a standard distance from one another. I'll most likely jiggle the positions a bit so they don't look like they are on a grid. Whether this is algorithmically generated or hand placed will just be an implementation decision during the development phase.

    I'm leaning ultimately towards a mix of your options 2 and 3 ( player designed and randomly generated.) First, a bit of a redefinition of 'placing planets'. In Space Crack a 'neutral' planet is the equivalent of an 'empty space' in Go or chess.

    You give the board definition by conquering planets. Taking a planet is the equivalent to placing a stone in Go. So in a sense, this is a player created environment.

    The random map generation is a layer ontop of this system. I'll seed the spaces with various bonuses and powerups. I'm holding off on describing this section in more detail until I bang out the details of the upgrade system.

    Your idea of 'placing planets' is interesting. This assumes that there are important strategic elements associated with the position of neutral planets. In the early versions of Space Crack, the planets are rather generic. It is only by taking planets and building upgrades that they become strategically interesting. This particular philosophy needs to be balanced against player's urge to explore exciting new worlds.

    take care

    PS: SAIS is one of my current favorite games. Waiting with great anticipation for Weird Worlds.