Category Archives: Programming

Mr Cleaner, Adventures in Time (alpha).

Here’s a short alpha release & status update of a project I’ve been involved into during the past 3 months.



Background :

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
  • Joypad controls
  • 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…

MrCleaner Win32 Version 0.7 download link.

Controls :
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 🙂

Read the full story & the weekly-updated devlog on the TigSource.com’s forum !

Global Game Jam Paris 2011

Global Game Jam Paris 2011 is now over. It took place at ISART, School of video game, digital art & design. The place is great, the organizers brought a perfect support. The Jammers were amazing.

The GGJ Concept really brings a full cycle of the life of a video game. It’s definitely the best concept of game jam I’ve ever tried (compared to Demoscene events or TigJams, for ex.)

Game list

Borrowed from Olivier Lejade’s twitter :

Tweet Uranus http://www.globalgamejam.org/2011/tweet-uranus
Follow the white light http://www.globalgamejam.org/2011/follow-white-light
Appetite for Extinction http://www.globalgamejam.org/2011/appetite-extinction
Dark Naze http://www.globalgamejam.org/2011/dark-naze
Master Beer http://www.globalgamejam.org/2011/masterbeer
Kazz.ed http://www.globalgamejam.org/2011/kazzed
Decline http://www.globalgamejam.org/2011/decline
Extinction des feux http://www.globalgamejam.org/2011/extinction-des-feux
GameXtinction http://www.globalgamejam.org/2011/gamextinction
Light Extinction http://www.globalgamejam.org/2011/light-extinction
Colors Wars http://www.globalgamejam.org/2011/colors-war
Don’t win! http://www.globalgamejam.org/2011/dont-win
Light Cylinders http://www.globalgamejam.org/2011/light-cylinders
VR Escape http://www.globalgamejam.org/2011/vr-escape

GGJ Paris Website :
http://www.mekensleep.com/GGJ-Paris/

Isart Website :
http://www.isartdigital.com/

A few notes for my next jams

(and for any future jammers I guess)

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 :

Demoparty
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.

GameJam
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 🙂

GlobalGameJam
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.

Period.

MGT Project DevLog #4

Game Items

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


//--------------
class GameItem
//--------------
{

item_trigger = 0
inside_trigger = false

enabled = true

project_script = 0

tank = 0
tank_script = 0

function OnUpdate(item)
{
if (!enabled)
return

if (tank == 0)
{
tank = SceneFindItem(ItemGetScene(item), “tank”)
tank_script = ItemGetScriptInstanceFromClass(tank, “SteamTank”)
}
else
{
// Test the player against the trigger
if (item_trigger != 0)
{
if (TriggerTestItem(item_trigger, tank))
{
if (!inside_trigger)
{
print(“GameItem::OnUpdate() tank inside”)
ItemTaken(item)
inside_trigger = true
}
}
else
inside_trigger = false
}
}
}

function ItemTaken(item)
{
print(“GameItem::ItemTaken() – Stub method called.”)
}

function OnSetup(item)
{
print(“GameItem::OnSetup(” + ItemGetName(item) + “)”)

local _item_trigger
_item_trigger = ItemGetChild(item, “item_trigger”)
if (ObjectIsValid(_item_trigger))
item_trigger = ItemCastToTrigger(_item_trigger)

project_script = ProjectGetScriptInstance(g_project)
enabled = project_script.GetItemStateEnabled(item)

if (enabled)
Enable(item)
else
Disable(item)
}

function Enable(item)
{
print(“GameItem::Enable(” + ItemGetName(item) + “)”)

ItemActivateHierarchy(item, true)
enabled = true
project_script.SetItemStateEnabled(item, true)
}

function Disable(item)
{
print(“GameItem::Disable(” + ItemGetName(item) + “)”)

ItemActivateHierarchy(item, false)
enabled = false
project_script.SetItemStateEnabled(item, false)
}
}

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
{

function OnUpdate(item)
{
base.OnUpdate(item)
}

function ItemTaken(item)
{
print(“ShieldCellItem::ItemTaken()”)
tank_script.ShieldUp()
Disable(item)
}

function OnSetup(item)
{
base.OnSetup(item)
}

}

 

The Inventory

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.


class Inventory
{
inventory = 0

constructor()
{
inventory = []
}

function AddItem(item_name)
{
inventory.append(item_name)
}

function RemoveItem(item_name)
{
print(“Inventory::RemoveItem(” + item_name + “)”)

local idx, val
foreach(idx,val in inventory)
if (val == item_name)
{
inventory.remove(idx)
return true
}

return false
}

function FindItem(item_name)
{
local i
foreach(i in inventory)
if (i == item_name)
return true

return false
}
}

 

Video Capture

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.

Trying to model an outdoor scene.

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 🙂

First test of level design …

Once all the (old) assets where converted to the new engine, I tried to assemble that and design some rooms, with gates, elevators, and levels.

The main idea to far is to design an acceptable gameplay, and not to polish the graphics until there’s something funny to play 🙂

no images were found

no images were found

no images were found

no images were found

The Flyin’ Island

Recently, I became sort of addicted to the competitions organized on www.tigsource.com
Those are short contest (1 month), on various topics, aiming to create a game.

Some games are made with GameMaker, some in Java, some in Flash/AS, some with custom C++ engine, etc.

My contest entry depicts a ship’s cockpit, and more precisely, the Bridge Deck. The view is entirely in realtime 3D, including the cockpit.

All the visual assets in the game were modeled in a more or less accurate way, technically speaking, to focus on the immersion & visual appeal. Zelda Wind Waker was my main inspiration source.

I wrote my game with a friend’s engine, that covers all what it takes to create indie games. The engine was written in C++, but my game is enterely scripted.

The final delivery almost looks like a “game”, with interactivity, and stuff to do.

Now for a short sequence of credits : I did the visuals & scripting, Maf (maf464.free.fr) gave me some Amiga mods I could use, and Mazami Tanzi (www.tanzi.jp) did the (short) Japanese translation.

TO PLAY THE GAME, read below

  • Download & unzip
  • install OpenAL
  • install VC Redist 2008
  • Click on Start.bat

I included all you need in the archive.

Right click here to download the game.

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.

VipeUt Bootleg Demake Finished (well, almost)

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.

Credits :
Code / Graphics : Astrofra
Music : Rez (Chiptune.com)
Engine : nEngine (pre-GameStart3D)

To download that thing, click on the link below :
VipeUt-install.zip

Tech Notes:
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

Press ESC to quit the game.

ENJOY!