Top
CRank: 50Score: 0

Programming Workflow When Developing a New Game

By Alexander Presthus, Co-Founder at Lumi Games AS.

This post will hopefully be the first in many about the programming side of developing a game. This post is meant to be somewhat of a general overview of the process we go through when coding a game. In the future we hope to post about more specific techniques or concepts that people would find interesting.

Prototype stage:

First of all I get some specifications (usually from Erik) on what the game or concept is supposed to be about, what the most core mechanics are , and what we think is essential to see if works or not.

Then I start to think about how I would like to implement the core mechanics in a more technical fashion. I also try to follow a design pattern when setting up the prototype, keeping in mind what would make it the most flexible and easier to tweak for the game designer. I often use traditional pen and paper to sketch out the class layout and game structure, or even the structure that make up a game mechanic.

I'll use PAX HD! as an example since its a fairly simple game in terms of required functionality and structure. What we needed for the functioning version of this was approximately:

*Moving background (in these types of games, the player usually doesn’t move much at all, its just an illusion created by moving the background and or other objects).

* Enemies that are randomly generated by the game whilst playing. 
We quickly decided we did not want to do specific designed levels for this game, but rather spawn new enemies as the player progresses, always making the game experience slightly different for the player but also to save a lot of time in production.

* Increasing game speed (Difficulty). The game would quickly get boring if the player wasn’t challenged as the game progressed, so scaling up the game speed (or in this case the enemy speed) would be essential.

* Powerups that gives the player advantages. We wanted some other elements that the player would get some sort of boost from. This would also give the player something else to think about and not just avoiding obstacles.

Production / How we implemented this:

The moving background was simple enough to do, there are two backgrounds (1 on the screen, 1 just outside) The background on screen starts to move down and out of the screen, and the background outside of the screen moves with it, gradually coming into view. When the first background is completely outside the screen(and therefore the second background exactly where old background started), they reset back and do the same over again and again in a loop. A layer of moving particles where put on top of the background, moving at a faster speed to create the illusion of depth. This technique is reffered to as ”Parallaxing” or ”Paralax Scrolling” and is used in many 2D games.

Wiki: http://en.wikipedia.org/wik...

When tackling the enemies, we landed eventually on having only a single Enemy Class (they would all be identical except for looking visually different).

We accomplished this by creating internal functions to create shapes with multiple single blocks (1 block is the width of the players sprite) We made a number of shapes, and each time an enemy was created it chose one of these shapes after being assigned a number or integer at random from a given range each time.

In fact, there are at any given time only 3 enemies max present on the screen (one in each lane) and every time an enemy exited the screen it would give points to the player and reset its position and shape before moving forward again. We added a nice particle effect when a shape exited the screen to add in the sense of achievement and progression in the game.

http://s2.n4g.com/media/11/...
Lanes

Each enemy has a property called ”speed” which denotes how many pixels per frame it should move towards the bottom of the screen, for every 30 enemies that exited the screen the global game speed (and therefore speed of all enemies) increased by a factor we had set.

As for the powerups, these were separate classes (sprite objects) and manipulated the global game variables when activated (The warp increased the game speed for a certain time and activated ”God mode” (turning off collision detection), the health icon simply added 1 health point to the players health). We originally experimented with things like “bullet time powerups “for example, but found that this didn’t make for very fun game play in the end since the game was about speed.

Polish:

After we had implemented all the functions and were happy with the gameplay and mechanics we spent some time adding some polish to the game. Like adding the aforementioned particle effects when enemies exit the screen. We also added animations when picking up powerups, color changing on the backgrounds based on how far the player was in the game. We also implemented an old school arcade style high score system and added music.

Of course this is a very general overview of the process and is void of technical specifics, but the concepts used here are used in a lot of games today, regardless of platform and framework they were developed with, so we hope this will interest for some of you. And we also look forward to writing more in depth and interesting posts in the future :)

Day 13 | Lumi Games

The story is too old to be commented.
BiggCMan748d ago

Ah a little too much technical stuff for me.

MrxDeath748d ago

omg coding is hard !!
it must be hard for you guys to do this

oasdada748d ago

Me nd my friend are kinda tryin to make a game too... so i kinda get it

SpeedDemon748d ago

I've been watching tutorials on how to code on YouTube, the stuff goes right over my head.

Show all comments (36)
The story is too old to be commented.