All posts by astrofra

Programming

Astlan, sunday late update.

Leave a comment

Both Saturday and Sunday were profitable days. I managed to stick on AstroLander and work a dozen of details, such as :

  • Normalize the audio tracks
  • Improve the touch/click reactivity of the main GUI
  • Write a few common function to create UI buttons and ultimately refactor the existing UI code
  • Implement a “Pause Menu” when in-game. Works perfectly and stops the game completely (display, stopwatch, physics, particles and whatnot)
  • Fix an inconsistent design in the score calculations
  • Renamed a dozen of scene files and their respective classes

Not bad, for a Sunday 🙂

3D, Programming

Ideas for my next project

Leave a comment

While it is too early to expose here the idea I have regarding my next game project, I can say it will involve robots…animated robots.

The challenge here will be to animate the robots using a procedural technique as I want them to be able to place their hands randomly.

For this purpose I will probably use two things :

1. This robot I modeled years ago (here in a shameless photoshopping)

20120106-231343.jpg

2. The physic engine of GameStart, and especially joints, to assemble a sort of ragdoll, so that I shall only need to animate the hands if I want to move the arms 🙂

Stay tuned.
I need to finish and release Astlan first, anyway!

Programming

Update on CosmicLander

2 Comments

Here I a quick summary of the most recents update I made to my latest game project:

  • The name was finally changed to Astlan, as in Astro Lander. I hope it will avoid any possible copyright issue.
  • 20 levels out of 24 are now completed, with different kinds of traps, such as doors, rotating barriers or lasers.
  • The game UI is slowly taking shape, thanks to the help of an amazing local artist who made the intro screen, displayed somewhere in this page. So far, the main title, settings screen and level selection menu are functional.
  • I recently manage to throttle my physics routines when the game happens to slow down too much. This was a matter of concern to me, especially regarding the Android version.
  • Yup, you read it right. There’s an Android version around 🙂

I will post a playable version including the updates listed here before January 2012 so that people will be able to test, and hopefully make feedbacks 🙂

20111229-073516.jpg

20111229-074758.jpg

Input

The iPhone 4S : software polish VS product differentiation

Leave a comment

I’d like to add my personal though on the current debate about ” how much is(n’t) the new iPhone 4S innovative enough versus its Android high-end competitors”.

While it’s always difficult to judge and compare products without having your hands on, here is my own experience with the iPhone 3G and the Android Motorola Defy.

 

9 months later, thruth is I’m writing this note on my iPhone, while the Android phone lies in a closet.

The facts

In feb. 2011 I decided to replace my iPhone 3G with the Moto Defy that was (at that time) vaguely marketed as a iPhone 4 competitor. 9 months later, truth is I’m writing this note on my iPhone, while the Android phone lies in a closet.

A question of software polish

My strongest disappointment with the Moto Defy is the objective lack of software polish. A smartphone is all about inputs to me, the touchscreen, the keyboard and the ability to handle texts, from entering an URL to editing an email or a blog post.

I/O

If the Defy’s touchscreen is excellent, the default keyboard behavior is still a mystery to me : he won’t be able to switch from French to English when it comes to word correction/suggestion, he will suggest the wrong word endlessly, and will add misspelled words to the dictionary.
Worse, the key prediction seems non-existent. The keyboard will let me enter 5 consonants in a row without finding it odd.
When your finger press an area between the E and R keys, aren’t there known probabilities if it will be a E or a R, depending what letters are preceding?

That’s the first reason why I switched back to the iPhone. I found out myself wasting my time negotiating with the MotoDefy’s interface, instead of being productive.

The Motorola Defy being shipped in France with Android 2.1, I quickly realized how much it was difficult to simply select/copy/paste accurately a piece of text from a website to my mail, from a mail to an app…

Is it possible that, in 2011, a long time leading company in mobile cellphone is not ashamed to deliver a smartphone with text editing capabilities actually really worse than an iPhone purchased more that 1 year earlier ?

The answer is YES. That’s a bummer.

The great openness swindle

At this point of my journey with the Android phone, I started to look for an original Google Android ROM to re-flash my MotoDefy and experience the freedom that the late Steve Jobs denied us on the iPhone. However, I only found out that upgrading a Motorola Smartphone was far more tricky than Jailbreaking an iPhone.

The truth is that there’s no way to install a stable release of Android 2.3 on a smartphone purposely locked by the manufacturer.

Put simply, Motorola won’t let you install a custom build of Android on your phone. They won’t care about providing decent OS upgrades either, because they are far too busy with their next piece of hardware.

There’s been 1 upgrade to Android 2.2 on my Defy, that’s all. And so far, this upgrade have proven unstable and sluggish, no matter its objective improvements.

That’s for the so-called openness or freedom of Android versus iOS. Android might be open, you’d better avoid phones with locked bootloaders and no software upgrades. And don’t trust your local dealer to tell you the truth about it 🙂

Why I prefer Polish over Openness

All in all, I have to admit that Android is a marvel when it comes to tweak your OS components :

The Motorola Motoblur app launcher was jerky (~15 FPS) and sluggish, so I replaced it by Launcher Pro that is perfect and free.

But once the app is started, what happens to it ? I’ve seen many idiotic comparison charts to claim that iOS (BSD-based…) is not multitasking. But is the Android multitasking better ? What are doing these apps in the background when I never invoked them ? Why is CardioTrainer launching itself anytime of the day ? Why is the Car Dock app doing the same when I don’t have a car ???

Why is it down to the end user to install some task manager that will chase and kill unwanted apps ?

Is that Google’s idea of a SMART phone ?

I recently found Swipe X, lost in the messy and unfiltered Android Market, a replacement keyboard that is ALMOST as good as the iOS one.

That’s an objective superiority of Android Market over iOS App Store. There are apps, but there are OS extensions as well*!

But is it a reason for Google or other manufacturers to ship their phones with the wrong OS components ?
Could’nt they have tried for us first, and deployed the best directly ?

Are they undermining their smartphones for the sake of brand differentiation ?

Obsessed by a plethora strategy, SmartPhone manufacturers are flooding the market and fooling customers with hundreds of hardware pieces embarking half-arsed versions of Android.

The Nokia way

Obsessed by a plethora strategy, SmartPhone manufacturers are flooding the market and fooling customers with hundreds of hardware pieces embarking half-arsed versions of Android.

This is what Nokia did for ages, helped in that by a Java, Symbian or Windows CE. Fortunately Apple ended that, and initiated an era of polished cellphones for demanding users.

The Apple cellphone landscape is simple to read, with a maximum of 3 models at a time. Their software releases are tested. It works their way**, but it works well.

Waiting for the 4S

That’s exactly why I’m positively impressed by the features of the new iPhone 4S and iOS5. They focused on what matters to me, and I know by experience that what ships from Apple was designed and tested.

If Siri works as well as the early reviews are saying, it might be a real breakthrough. Android embarks the voice recognition already, but Siri is about hands free assisting (a question to needed to be addressed for car owners), day life reminders and all the demanding details our brains are facing nowadays.

No matter the camera is only a 8MPixels, as long as the shots are clean and that the right “vintage photo” app is available on the phone (which, so far, hasn’t happened yet on Android).

Obviously there will be bugs, but there will be fixes and upgrades of the OS as well.

And so far I’ve been less disappointed by iOS bugs than by Android’s software nonsense and it’s confusing plethora of form factors.

 

*that’s a gap Cydia is filling, for jailbreakers only, alas.
**Syncing music with iTunes is an objective pain, partly eases by a couple of Cydia extensions.

Programming

Cosmic Lander, a new minigame project

2 Comments

I recently  started to work on a new indie game on my spare time.

The initial goal was to develop a series of really small games within very short development cycles, in order to address a largest spectrum possible with my favorite game engine to date: GameStart

It turns out that it rapidly evolved into something a bit more ambitious, even I’ve been able to prioritize the tasks, and especially to work on a gameplay before starting the real artworks.

From a basic “Lunar Lander” it ought to be, it moved to a gameplay with a series of closed levels (caves ?) in which the player must seek for a list of items, while struggling against the gravity.

The graphics are basic so far, as mentioned above, mainly because I want to focus on what I’m not confident with : the level design. The visual aspect of the caves might eventually get painted or textured, but the real challenge here is to create funny & challenging levels.

So far, the game features 4 levels, no score, the basic win/die gameloop, a minimap and a few bonus & traps. The physics engine plays an important part in the gameplay.

I’m currently wondering to what extent it could be relevant to create a level editor inside the game, in order to have people create their own levels… Want to share your opinion? 🙂

Programming

Mr Cleaner, Adventures in Time (alpha).

1 Comment

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 !

Input

Hipstamatic VS RetroCamera

14 Comments

A polaroid camera found on a flea market, photographed with the iPhone using Hipstamatic.

Accidental photography

I’ve been a long time user of an old Polaroid camera that I truly loved for its genuine output and its results with accidental framing. The low quality lenses and the color prints that renders a cold and blue light helped me to keep track of my travels in a distinctive and poetic way.

However, since the Polaroid disappearance, I’ve been looking for a smartphone application that could mimics a large range of low end cameras, Polaroid, Holga or Lomo.

I found two main apps to do that : Hipstamatic for iPhone and RetroCamera on Android phones.

RetroCamera is advertised as an equivalent of Hipstamatic in the Android Market, but is it a proper alternative ? To figure this out, it decided to conduct a rough test of these two apps.

The test protocol

To compare the output of these apps , I took a series of photos with two smartphones stuck together, at the same time, in the same place. Hipstamatic is running on my old iPhone 3G, RetroCamera was installed on my brand new Motorola Defy.

There are obviously several biases in this approach :

  • The camera and CCD of both phones are technically uneven.
  • The apps don’t provide the exact same filters and effects.
  • The framing and aperture of the phone’s lenses are different too.

However, as you can see below, I found the output photos to be surprisingly close, and especially close enough to compare the way each app can work. The framing is exactly the same, the color treatment is somehow similar, with a vignetting effect.
Of course, the Motorola Defy took a sharper photo with its 5MPixels camera, but in my opinion it is not a relevant criterion.

Left : Hipstamatic. Right : RetroCamera.

The frame is very close, the color temperature goes in the same direction and the vignetting is quite similar. Of course, the 2Mpixels CCD of the iPhone provides a less sharp image.

Point by point comparison

The image process

It appears that if both apps have similar process, they don’t apply the filters in the same order. In my opinion, the regular sequence would be :

  1. Acquiring the raw photo from the CCD
  2. Vignetting & various spots and scratches
  3. Levels processing & color correction

First comes the vignetting and other leaks of lights such as those seem on a Holga or Lomo. This happens when the light enters the camera, either through the lenses or the leaks previously mentioned.
Then, the purpose of the level process is to get the image burnt, under/over exposed, which is typical on a toy camera or a Polaroid on which the exposure is static.
Eventually, after the light came through the 2 previous filters of a rough exposure, a coarse lens and a leaky camera body, it will hit the film, and that’s what the color correction is about, because every color film has a different color response to the light.


The diagram above shows what kind of RGB transfert curves is applied to the raw image to mimic the color response of a real film. Notice how the lower (darker) part of the blue curved is bumped, thus making the shadows of the photo to be tinted in blue.

Now, how does it works in practice ? You can see below a situation showing a huge difference. The original subject shows a clear sky. In my opinion, the spots & vignetting added by Hipstamatic created a compelling result. On the other side, the vignetting of RetroCamera looks almost fake, and shows some middle gray values that do not match the color response of this kind of film.


Left : Hipstamatic. Right : RetroCamera.

Clearly the worse example I have found where the process of RetroCamera shows its shortcomings. Even though the color response is relevant, it is spoiled by the vignetting layer that brings back these shades of dark grey in the upper corners of the photo. On the contrary, Hipstamatic’s vignetting is properly interpreted and provides blue shades that subtly match the overall color mood.

To understand why RetroCamera was creating these irrelevant shades, I tried to simulate the whole process in Photoshop, starting for a classic iPhone photo. The image below shows the steps detailed above.


Process breakdown of a typical ‘vintage’ effect. This was made with Adobe Photoshop, the actual internal process of Hipstamatic & RetroCamera may differ.

I suspect that RetroCamera swapped the step 2 and 3, because the color correction is quite effective and works well. However, the grey shades seen in the corners of the image are really specific to what happens when the original image is alpha-blended with a dark mask (either vignette or scratches).

I really have no clue why RetroCamera works this way. Is it on purpose ? Some people may appreciate the result, of course, but in my humble opinion it is sometimes hurtful.


Left : Hipstamatic. Right : RetroCamera.

A case where the alternate process of RetroCamera makes something that still is worhwhile. Some people might even consider that Hipstamatic color’s are way too cheesy.


Left : Hipstamatic. Right : RetroCamera.

In this shoot, Hipstamatic’s result is almost too blue. It might be a matter of greyscale values, that are interpreted as blue under a certain threshold. Wether you prefer the right or left result is probably a matter of taste.

Color correction

This really is a delicate topic, for several reason. Each print color film ever manufactured always came with a document that shows its color response, among other data (example here). But in this case I don’t think it is necessary to look for such a genuine behavior. Hipstamatic and RetroCamera are both meant to emulate a toy camera. I my opinion, only the final result matters, even if it is not technically correct.
Besides, it’s important that such apps provides a lot of various settings & camera modes, because each user will look for a specific result and atmosphere. I think that booth apps fulfill this demand.


Left : Hipstamatic. Right : RetroCamera.

I tried here a different mode (or filter), but couldn’t find an exact equivalent between the two apps. It is not really a problem, and both result have their own qualities. I definitely love the red-ish output of Hipstamatic, that reminds some of my aged polaroids. RetroCamera, on the other side, made something with more contrast and subtly purple shadows.


Left : Hipstamatic. Right : RetroCamera.

This case is really interesting. Despite a trend to turn everything to blue, Hipstamatic created a photo with more dynamic & warm colors. RetroCamera made something almost monochromatic, which is very strange considering the result on the other photos with the same filter (where the blue tint is actually less strong than on the iPhone app).

Effect control

To emphasize the look of your vintage photo, both apps can add a wide range of different frames : a sober white frame of a polaroid, the torn sheet of Ilford paper, the side of a reel, and so on.
There is one major difference I could notice between the two apps : Hipstamatic allows the user to choose independently the film effect and the frame, which RetroCamera does not.
However, I suspect this won’t be an issue for most users, except for those who will find the torn or scratched frames a bit too cheesy 🙂

Processing time & reactivity

I didn’t spent too much time to benchmark the processing time of each app. It wouldn’t have been relevant because my iPhone 3G is a bit slower than my new Motorola Defy. Processing a full resolution photo on my iPhone can take up to 20 seconds, whereas the process is almost immediate on the Motorola Defy.
Furthermore, it is unclear to me wether these apps have the same kind of process, or not.

Anyway, in my case, having to wait 30 seconds between each shot is not a real issue. This quite close to my old Polaroid, and it helps me to think wisely about my next photo.

Conclusion

So, Hipstamatic VS RetroCamera, who’s the winner ? I can’t honestly tell.
I can’t consider RetroCamera as a real equivalent of Hipstamatic, because the outputs of these apps are really different. Moreover, the processing flaw I suspect in RetroCamera is a real issue for me. But considering that RetroCamera is absolutely free in the Android Market, it would strongly recommend to test it, anyway 🙂









A selection of shoots. Left is Hipstamatic. Right is RetroCamera.

If you want to know more

Here a few links for you to dig on the vintage/retro photo emulation.

All my Hipstamatic/RetroCamera shoots : flickr.com/photos/astrofra/sets/72157626023324700/

Virtual Darkroom : except.nl/lightwave/hdr/index.htm

About the photographic film : en.wikipedia.org/wiki/Photographic_film

Color Temperature (and how it affects photography) : en.wikipedia.org/wiki/Color_temperature

Model & inspiration on this review : flickr.com/photos/38623641@N05/

Hipstamatic : hipstamaticapp.com/

RetroCamera : urbian.biz/apps/retrocam/

Programming, Uncategorized

Global Game Jam Paris 2011

4 Comments

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.

3D

GameStart3D : an introduction to the Shader Tree

Leave a comment

What is this Shader Tree thing all about ?

Since its first beta release, GameStart came with an internal abstraction to handle materials (aka shaders). One of the major improvements of the latest release (namely GS Beta 6) is the ability to edit & create a shader with a comprehensive and visual editor.


A basic tree example.

The main benefit of this abstract representation of a shader appears when it comes to port your project & assets to several platforms. No matter its complexity, a shader designed with the Shader Tree editor is fully portable. Each node is basic and independent from any kind of hardware implementation.

As a testbed, and to demonstrate how straightforward and powerful this Shader Tree editor can be, I spent half a day to design random materials. The result is shown below :


A grid of experiments with the shader tree.

Animated Shaders

One of the funny features is a clock node, that allows the user to inject a clock tick inside a shader. Use it to scroll your UV coordinates, to blend colors along time, and so on. Here’s a video capture showing various use of this feature :


The same thing in motion.

Here you are, boys & girls. Feel free to download the source file below, and enjoy !!!

3D, Programming

MGT Project DevLog #4

Leave a comment

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.