Today I want to talk a little about the process behind Adolfish. Well, the most important part of a game is the game editor, so the first thing I did when I started Adolfish was using a game engine I knew, Irrlicht, to build up an editor from scratch. Maybe Irrlicht wasn’t so great for a simple 2D game, but it had a feature I really liked at the time, a simple in-game GUI.

Building up the editor is like building up the game itself with all the needed features, like the bullet system, the physics, the animation system and all the stuff. Well, where is the editor, you might say? In Adolfish, every level is built up of several enemies, called entities inside the editor, each with a different AI attached using an external LUA script, several skins to create the world you see and several vertices for the physics. Let me explain with a picture:

Adolfish Game Editor – Level0 Wireframe

As you can see, this is level0, the first level you play in Adolfish, and all that purple lines are the vertices I was talking about. When building a level, the level designer places as many vertices as he wants and then presses the button “New Object”, this command connects all the vertices togheter and create a new object in the physics system. Ok, now let’s see level0 complete with all the skins and entities placed:

Adolfish Game Editor – Level0 Complete

The level is now complete, but the entities don’t move! In the level0 directory there’s an AI script for every entity, but completely void. Now the developer can write the AI as a finite state machine and pack it all togheter to build the final level.

Hello there! We have been really busy doing levels and testing the new functions of the game.

Today I want to show you a technical stuff: the AI.
Every enemy in the game is called internally “Entity”, it stores the position (x,y), the direction (xd, yd), the physical properties (friction, density, dimension…), the status, the life and few others.

The AI is attached to a LUA interpreter and each “Entity” has its own instance and a script file defining its behaviour.

function OnIdle()
if (GetMyY() > coord_y) then
direction="UP"
end
if (GetMyY() < coord_y-path) then
direction="DOWN"
end
if (direction=="DOWN") then
ApplyForce(0,1)
else
ApplyForce(0,-1)
end
end
function OnRage(distance)
end
function OnCollision(object)
if (object=="Player") then
status="DEATH"
end
end
function OnDeath()
end

As you can see it’s a state-machine, starting from the IDLE state. When the player hit the bomb a signal is sent to the AI, moving to the DEATH-state, determining the explosion of the bomb.

But what if the player doesn’t hit it? Simple, the bomb stays in IDLE-state, moving UP for a certain amount (the path variable) and then switching to DOWN (the direction variable).

There are other functions: GetMyX(), GetMyY(), ApplyForce(); These are internal functions written in the game engine and called from the script, their names are self-explainatory.

Now we can do wave effect and bomb-implosion effect, maybe we can add some shader to the fans or when the player is in danger. For now the demo doesn’t have shaders, so here’s an image to show you what we have done.

For now we have this hard-coded buttons:
Triangle is used for “BACK” and Cross for “ACTION” while the axis are used for movement.
Download the new demo and post your feedback!
P.S.: We are working to enable xbox 360 and PS3 gamepads!