Here’s a short alpha release & status update of a project I’ve been involved into during the past 3 months.
In a laboratory located in the future, a Scientist is conducting experiments on time travel. Unfortunately, during the experiment, a large amount of radioactive cores are spread through time, all around the ages.
In order to save mankind from a massive radioactivity poisoning, he sends a Robot to clean all this mess, and bring back the cores to his lab.
Todo list :
Tutorial, gameplay details
Add the music tracks
Tweak the sfx (that are quite annoying atm)
Visually pimp the few latest levels
Download Link :
Here’s is a Win32 playable version of the game. Please keep in mind it’s an alpha version (some of the levels might be unplayable, some are not completely re-skinned, and the sfx might sound really annoying atm). Any feedback is welcome…
Rotate CCW, CW : Left, Right arrow keys
More forward : Up arrown key
Validate/Trigger Bomb : Space bar
Back to main menu : Esc
Minimum hardware requirement :
NVidia GEForce series 8000 or ATI Radeon series 3000 graphics card
Intel graphic chips are more than likely to make the game crash.
About the project :
This game was entirely written and level-designed by Andy, who decided to implement a Sokoban-like game with GameStart3D in order to test the engine.
It turned out the game was completely functional in 2 weeks of time, with a set of 50 levels partially designed. He made the initial placeholder graphics with Blender3D, wrote the game in Squirrel, and then entered in contact with me.
As the game was fully playable, Andy asked me to refine the visual side of the game, which I was glad to accept. I hope you will enjoy the result 🙂
1. Prepare a file-exchange solution :
You never know what kind of network environment you will meet in a Jam. I’ve done jams with an almost un-existant network support (cybercafé with overloaded wifi). Most of the time, you will have some network ports unavailable, especially those for SVN, Remote Admin, Unity Asset Server…
In that case, with such an hostile network support, how are you gonna exchange files rapidly, including multiple revisions, with your team ?
At the GGJParis 2011, we found out that DropBox was a rather good solution.
Preparing a small laptop that will serve as version/asset server can be handy as well, depending how much stuff you can carry with you.
2. Know your effing tool
If you’re going to create a game in such a short timespan, and embark a whole team with you, you’d better know your tool(s), your pipeline and their technical pitfalls.
During the making of a game, each time an idea arises, ask yourself : “have I already done this with my tool/language ? have I already succeeded ?”.
If it turns out that you never really tried to create an AI, code a level logic, setup a GUI, import a full rigged character into your engine, it’s rather unlikely that you’ll be able to do this during a jam, in a timely manner. And even if you do, it might spoil all your precious time, and you won’t have any left to think about/work on your game design.
3. Prepare your computer
Don’t arrive at a Jam with a PC that “just” needs a “quick reinstall”. Reinstalling Windows usually take a few hours, for you will have to hunt for the proper network driver, the right Redist, the latest Nvidia driver, and then make sure your tools work properly. It may only take a 2 or 3 hours, that’s A LOT in a 48h game jam 🙂
4. Bullet proof your engine
You wrote your personal 3D engine yourself. You’ve tested every part of it at least once and you know it will work. But have you tested all the features altogether in a single project ?
It sometime happens that using several features of an engine suddenly shows a loads of side effects and … bugs. And a game jam is not exactly the right place do debug your engine, especially a C++ engine 🙂
5. Talk pipeline/workflow before
If you are about to choose a team to work with, it might be wise, before embarking everyone on the same boat, to check that your workflow habits, and pipeline knowledge are compatible … unless you want to learn a completely know workflow during the Jam 🙂
However, I’ve met some guys who never worked together before, and they managed to bullet proof a common 3D pipeline and finish a proper game within 48h !
My personal hierarchy of coolness
I’ve done a few events during the past years. Among them :
I’ve probably been to half a dozen of demoparties, between 1995 and 2005. Demoparties are cool, but most un-structured. You work on the kind of production you want (non interactive demo, usually), on the theme you’ve chosen, within a totally free timeframe (several years to a few hours).
Too much liberty ends up in something that became way too unstructured for my own amusement. I found out that 64k demos, with far more constraints, can be much beautiful and fun to do and watch.
I recently found, a TigJam Berlin 2009, that GameJams can be more interesting than demoparty, for the very reason that if you game is not FUN, you will know it RIGHT AWAY 🙂
GGJ might be the ultimate achievement for me, because the whole event is really and wisely structured. The GGJ 2011 was a really intense experience to me, and I learned on many levels (technical, social …) so much more during 48h than all I could remember of my past years of demopartying.
There’s no adventure game without powerups, keys and doors. For this prupose, I needed a generic class that handles the basic operations on items :
– the item knows when it interacts with the player and calls the proper method/function.
– the item can be picked, destroyed, unlocked, and this state should remain if the player left the room.
– the item can increase the vitals/energy/shield of the player, or appear in the game inventory
To perform these actions, and any other kind of possible future needs, I wrote a very simple class called ‘GameItem‘
item_trigger = 0
inside_trigger = false
enabled = true
project_script = 0
tank = 0
tank_script = 0
if (tank == 0)
tank = SceneFindItem(ItemGetScene(item), “tank”)
tank_script = ItemGetScriptInstanceFromClass(tank, “SteamTank”)
// Test the player against the trigger
if (item_trigger != 0)
if (TriggerTestItem(item_trigger, tank))
print(“GameItem::OnUpdate() tank inside”)
inside_trigger = true
inside_trigger = false
print(“GameItem::ItemTaken() – Stub method called.”)
print(“GameItem::OnSetup(” + ItemGetName(item) + “)”)
_item_trigger = ItemGetChild(item, “item_trigger”)
item_trigger = ItemCastToTrigger(_item_trigger)
Basically, when setup, the class will look for a trigger parented to the main item. Then, during the update loop, the class will test the player against the trigger. If the item is triggered by the player, a stub method ItemTaken() is called.
Based on this generic class, I can derive (or extend) any kind of specific class, and overload the ItemTaken() method.
The class also provide two methods to enable and disable the item and its children. This is very handy when it comes to hide several items and lights. When disabled, the state of the item will be stored by the project, so that the item will know if it is enabled or not in case the player exits then enters the room again. Here, all the state logic is handled by two accessors methods I wrote directly in the project script : SetState() and GetState()
Here’s an example of a typical ‘power up’ class inherited from the base GameItem class. You will note how the ItemTaken() class is overloaded in order to perform the proper action : here it increases the shield level of the player.
class ShieldCellItem extends GameItem
Some items can be picked and must be kept by the player. In this purpose, they will invoke another class called Inventory. At the moment the implementation of this class is really basic. It is more or less a few accessors to handle an array that contains the game items picked by the player.
inventory = 0
inventory = 
print(“Inventory::RemoveItem(” + item_name + “)”)
local idx, val
foreach(idx,val in inventory)
if (val == item_name)
foreach(i in inventory)
if (i == item_name)
The following video shows the player that grabs several items (a powerup and a key), opens a first door, unlock a second door with the key he just grabbed. The key is marked as a X in the inventory, you can see it appear, the disappear when used.
All these dark level designs I previously started made me feel a bit gloomy… Going outside for a bicycle ride, and visiting the huge city of Berlin, I felt I should imagine something less confined, so I started to doodle this open air design.
I tried to imagine some sort of lost ruin, up in the sky, that the player would reach through a long way made of traps & elevators.
no images were found
no images were found
The screenshots were grabbed directly from the engine, with infinite shadow maps & SSAO, yaye 🙂
Going further with the experiments in GameStart, I started to design a room with a typical “sewer atmosphere” … It was rather promising, then Emman added a water reflection FX on it, and then it looks really awesome.
Choose your language with the left & right keys, select with [CTRL] or [SPACE].
Press spacebar on the title screen to launch the game.
In game controls : <- and -> to control the aim, CTRL to shoot boulders.
Destroy the ships on your route, bit hitting them with the boulders.
If you don’t destroy any of them, they will hold you back and you will never reach the island.
Use the compass to find the direction of the Island.
I finally put the [Finished] stamp on this thing I had started for the “Bootlet Demake” TIGSource contest, on tigsource.com
It’s all but finished, anyway, I mainly wanted to emulate the very original rendering of a Vectrex, and make a small and playable game. I think I more or less succeeded, so let’s settle on something else.
It should run on a PC, WinXP or Vista, with a rather recent 3D card. Vista users : make sure the UAC is disabled, the engine won’t like it.
During the install, u’ll be prompted to deploy OpenAL. Please install it, unless you already have it, otherwise, the game won’t probably start.
The installer creates two shortcuts on the desktop, one using the full featured renderer (OpenGL 2.0), the other one using a more consusual rendering method, not as pretty but fairly ok.
Controls : use the arrow keys. Up = accelerate, Left & Right to strafe, Down = brake. The paddle is not handled.
The ship have a certain amount of energy, that decreases when colliding against enemies. Then it blows up.
Catch some bonus, that will drive the ship for you (autopilot), or increase your energy (power up). Just drive till the end, for 6 laps, and you’re done