RPG environment (II)

After a week, the poll is already giving interesting indications. I asked the visitors to choose among different backgrounds for the new role-playing game that I want to develop. There are a lot of possibilities, from the Galactic Empire to the Ancient Egypt, but the choice seems already restricted between the Ancient Japan and the Middle Earth options, the latter prevailing. In particular the most ancient backgrounds, from King Arthur down, are almost ignored, while most recent ones share almost the same preferences.
I can't believe that only orcs, elves, trolls, dwarves and the like, deserve the attention of a CRPG, thus you have still a week to change your mind and choose something different. Of course, you can confirm your preference, but remember that also multiple choices are possible: if you like orcs, but also post-apocalyptic mutants, you can choose both.

MDL smooth transitions

Just a short news to announce that smooth transitions in MDL models between different animations are finally available.
Probably you remember a demo that I published a month ago: The Trenches. The main problem was a jerky movement that affected some of the transitions. That was caused by differences between animations intended to be in sequence.
In the next release of the engine, the programmer can set the transition time between two sequences, so the cut will disappear.
This is useful to GUN TACTYX 2, the model of which are in a too evident way affected by the problem, but also to the next SOCCER TACTYX.

Finally, the MDL support has improved enough to be considered almost complete, so I can look forward to the real game mechanics.

Indoor soccer field

Thanks to Kr0meel, the soccer field, where the SOCCER TACTYX Championships will take place, is going to acquire its final shape. Finally the textures are those intended by the author. In fact, you can see in the screenshots an improvement in comparison with the demo that I released yesterday (read yesterday's post for a link to the current very simple demo). I'm not sure yet about the light intensity, but this is a parameter that we can easily modify later.

Loading screen

In a few days I'll replace the basic demo with a playable one, at least in its essential structure. I don't know yet if the simulator of the bots' virtual CPUs can afford the effort to support 11 vs 11 matches, but I think that a 5 vs 5 is a more realistic objective and also more manageable for the script writers.
Imagine two teams of bots, each of them controlled by their own script, playing football in an indoor field, running and shooting balls to show who is the best: that is going to be SOCCER TACTYX.

MDL models during training

SOCCER TACTYX

Yesterday I began to program SOCCER TACTYX, a preview of the next to come GUN TACTYX 2 in which the bots does not shoot each other but peacefully... play soccer!

I put together some ideas on occasion of the European Foot-ball Championship (Euro2008) and then published a very early demo: nothing to play yet, but at least you can see the models at work.

You can download the demo here.
I asked for permission to use the models taken from the International Online Soccer, a great MOD for Half-Life 1. Recently a version of IOS for Half-Life 2 has been published (visit the official site). Then you can see in the demo a simple indoor field made by Kr0meel. We still have to set correctly the textures, that's why the room seems so flat.

Executing the demo, you'll see the usual loading screen, then, clicking on PLAY, you'll see the models performing their animations. A lot of work is needed to complete the game, the European Football Championship is near, thus I'd better to post and go back to the script editor. Feel free to post suggestions and comments.

Stay tuned for more news about SOCCER TACTYX.

Soccer tactics

On occasion of the European Football Championship, I'm going to publish a preview of the new GUN TACTYX 2 framework, based on the models of the International Online Soccer MOD for Half-Life that you can see on the left. I've found those models a month ago (read the post) and I immediately thought that they were perfect for the soccer mode of the game.

The (real) european football championship is going to start and I'll try to finish the preview of the game in a hurry. The simulator will be a simplified version of what I had in mind since there is too few time for the complete version, but I hope that the players will appreciate the simple and neat functions needed to program their soccer team. To drive eleven players after a ball is not a simple task for a script, but nodoby says that these kind of games are accessible to everybody.

For those who don't know yet what kind of game GUN TACTYX is, visit the official site at GameProg.it.

RPG Editor

Yesterday I opened another poll to choose among different backgrounds for the RPG game, based on APOCALYX, that I'm going to develop. In the meantime I received in a few hours some positive feedbacks about this subject. One of the most exciting comes from Nout, the author of the NsEditor (a quite old preliminary version is available on FileFront). He has recently improved a lot his editor strictly connected with APOCALYX (read, for example, this thread on the forums about recent changes) and he pointed out that the NsEditor and the related framework is tuned for Role-Playing type of games.
This is a good news for me, because to write a game completely from scratch is very time consuming, while Nout's editor and the related framework and entities help a lot. I always write my Lua scripts line by line, but it's time to learn some tool to reduce development time and not reinvent the wheel again!
Stay tuned for more news. Feel free also to send suggestions to my email address. Thank you in advance!

RPG environment (POLL)

So you have chosen. The next real game that I’m going to program from the ground up, based on APOCALYX, is a Role-Playing Game. In fact, the results are: RPG (30), RTS (12), FPS (6), Other (0). Now it's the time to choose the background of the game. There are so many possibilities that I'm disoriented: Is it better to choose the usual inflated medieval asset, or a more original one? The choice is up to you.
Here I simply list several possibilities, with just a few ideas about the possible careers, but you can also propose something different. In the last case choose "Other" and send an email describing your idea: the more original, the better. You can also offer your help, if you want: in that case contact me!

• Galactic Empire to boldly go where no one has gone before
• Post-atomic Mad Max-like earth or Waterworld-like oceans
• Gangsters from news-boy to gang boss or police chief
• Western Fronteer gold-miner, bounty-killer, cow-boy, gambler
• Buccanneers from ship-boy to governor or captain of galleons
• Ancient Japan ronin, samurai, ninja, shogun, emperor
• Middle Earth-like goblins, trolls, orcs, elves, dwarves, humans
• Arthurian cycle from esquire to king Arthur or wizard Merlin
• Roman Empire from slave to gladiator; from private to emperor
• Ancient Egypt from slave to Pharaoh or Minister of religion
• Other give your fantasy a chance: describe your ideas

How to load BSP levels

Sometimes APOCALYX users want to load ready-made Quake3 BSP levels without writing too much code, to see how they look like in the engine. Imagine several BSP levels stored in a single *.pk3 file, as usually Quake3 BSP levels are shipped. You don't need to write any line to see them, simply use the BspLevel.lua demo included in DemoPack0

BSP level from the "Q3 Rally" MOD

At the beginning, the BspLevel script, looks for the file pak0.pk3 and lists all the BSP levels included in it. Then the user can choose one of those levels and the avatar (the well known Wrokdam model) will appear in one of the spawn points. Use the DEL key if you want to free the camera, when the avatar is teleported in places where the geometry prevents it from moving.

Usually the levels don't look as in the original Quake3, because of the limited support of Q3 shaders, but some are not so bad. Since transparencies are disabled in the script by default, try also to enable them pressing the "T" key (as explained in the help screen).

In conclusion, if you want to view levels taken from the Quake3 MODs, simply put the original *.pk3 file, containing the levels, in the engine folder, then rename that file to pak0.pk3, execute BspLevel.lua and choose a level. Probably you'll find one that looks good enough to be used in your own demos, without losing time in the modelling phase.

Simple Flight-Sim tutorial

In my navigations on the internet I have found another resource related to APOCALYX that I completely ignored. In the section of Game Related Tutorials of the University of Southern Queensland (Australia), there is a tutorial based on the Isle Fly-Through demo available in DemoPack0. As you can see in the screenshot, the sea is really bad looking, but soon it will be improved by a more realistic water surface.

The tutorial includes a description on how to develop a (fake) flight-simulator based on an old version of APOCALYX. The author says: "This download includes all the files your will need to get started using LUA script and the Apocalyx Game Engine. It includes a workshop booklet. We usually run this as a workshop for school students grades 6-12 who visit the university" (here is the ZIP file).
The author of the tutorial is Penny Baillie-de Byl, she is also the author of the book "Programming Believable Characters For Computer Games" that describes several techniques on programming NPC characters in computer games (summary on the book and sample chapters). The book performs several examples based on an old version of APOCALYX.

Vietman War models (II)

As usual I executed a benckmark to verify the performances of the Vietnam War models that I have recently found. I put 50 soldiers together in the same shot and I got almost the same frame rate of the 64 WW2 US soldiers in MD2 format, that I benckmarked in April.

I tried also the same benchmark substituting the marines with helicopters and, surprisingly, I got a frame rate only slightly lower. I was surprised because the helicopter carries a pilot and his quality is not so bad. Probably the triangles count of the two models is not so different.

These results are very interesting, because I'm planning a crowded demo with running soldiers and flying helicopters in a Vietnam background to test the new realistic water reflections. Thanks to these beautiful models, it's going to look very nice.

First steps (City Racing)

I didn't forget the development of "City Racing" (CR). Finally, I had some time to spend and I set the usual framework that you can see in all the demos, that is the screen showing the logo, a view of the level and the scrolling acknowledgements.

The next step will be the programming of the player's car control, so we could drive at fast speed through the city streets, and finally I'll program the opponents' cars behaviors.
In the meantime, I'm looking also for good obstacles to put on the track. Something like the truck and the loader that you can see on the left. Unluckily, these two models are not textured, so they need too much work for a simple demo, but I'll search again: there are so many free models out there, that one has only to choose.

Terrain performances (II)

After the comparison between the terrains of Irrlicht and APOCALYX, now it's the turn of the promised comparison between the terrains of Ogre3D and APOCALYX. I have extracted the height-map and color-map from the Ogre3D terrain demo and, then, I have passed the data to the APOCALYX "infinite terrain". The following screenshots show the results.

Ogre3D above, APOCALYX below

Again it's not easy to compare the results. Also Ogre3D, like Irrlicht, applies the color-map to the height-map and superimposes the detail-map. Then the borders of the map are the usual unrealistic square linear cut all around. As I have already explained, APOCALYX applies a color-map (the shadows) to the height-map, then a coarse-map and, finally, the detail-map. No cuts are noticeable when the heigth-map presents periodic boundaries.
Another difficulty was to choose similar detail maps, because the Ogre3D original ones were too light for APOCALYX. Finally, I lost myself in the map and I couldn't set the same view. Anyway, those two pictures give almost the same frame rate.
At the end of the tests, the conclusion is the same as the other comparison: more detail in Ogre3D and Irrlicht, (fake) larger landscapes in APOCALYX.

Vietnam War models

As already done with Irrlicht, I’m planning a comparison between the terrains implemented in Ogre3D and APOCALYX. In the meantime I’ve found an interesting collection of MDL models taken from the “Tour of Duty” MOD for Half-Life 1.

The collection includes a lot of scenery and nice vehicles from transports airplanes to helicopters. There are also several classes of soldiers with different weapons, so I’ll ask to the authors for permission to use them in one of my next demos.
I’m dreaming of a demo (to be done right after "City Racing") with realisitc water reflections, palms and huts, US soldiers, flying helicopters all around and the “Apocalypse Now” soundtrack in the background. Stay tuned!

Terrain performances

Yesterday I compared the rendering speed of Irrlicht and APOCALYX. I used the same MS3D model and the performences were almost the same. Now it’s the turn of terrains.
I have extracted the height-map, the color-map and the detail-map from an Irrlicht demo. Then that data was read by an APOCALYX “infinite terrain”. The results are shown in the following screenshots.

Irrlicht above, APOCALYX below

It’s difficult to compare the results, because Irrlicht simply applies the color-map (that becomes the main texture) to the height-map, then superimposes the detail-map. In addition when you reach the border of the map, you can see an unrealistic linear cut all around. Instead, APOCALYX applies a color-map (that defines the shadows and the overall color) to the height-map, then a coarse-map (a periodic main texture) and, finally, superimposes the detail-map. No cuts are noticeable if the heigth-map presents toroidal boundaries.
As you can see, I had several difficulties in setting the same parameters in the two demos, but I got two roughly comparable pictures at the end. Unluckily, this time APOCALYX loses 220 fps against 260, but I think that there are too differences for a reliable comparison, because the two kind of terrains possess different advantages: more detail in Irrlicht, larger landscapes in APOCALYX.

MS3D performances

A few weeks ago I made a comparison between the render speed of similar models in MS3D and MD3 format (read the post) and I realized that the engine can render a large number of MD3 models at the same frame rate of a small number of MS3D models.
One may ask if other 3D engines render MS3D models better. Read below to discover that… APOCALYX wins again!

Irrlicht above, APOCALYX below

In the screenshots above, you can see the same MS3D dwarf model rendered by Irrlicht (top) and APOCALYX (bottom). The Irrlicht’s picture is taken from the mesh viewer programmed in C++ of that engine, while the APOCALYX’ picture is rendered by the Lua demo “ModelMS3D” included in DemoPack2 (I simply removed the shadow and the terrain, because the Irrlicht viewer does not show any of the two, only the skybox).
In conclusion, which are the results? APOCALYX beats Irrlicht 330 fps against 320. Well, let’s say it’s a draw, but this comparison says that the MS3D viewer included in APOCALYX is as good as the one of Irrlicht.
We get another surpsising results: an engine developed by a single coder can compete against more advertised engines developed by a team of programmers. For other surprising results read the comparison between the BSP viewer of Irrlicht and APOCALYX and the BSP viewer of Ogre3D and APOCALYX.

Ocean shader

One of the oldest features of APOCALYX was the Ocean terrain (uh, what an oximoron!), that is a simulated water surface where waves are computed with fast fourier transforms. To make that “ocean” more “realistic” an animated texture with caustics was applied. The effect was acceptable only for the very first years of the century, but now is very outdated, in fact, GLSL shaders can simulate very realistic sea surfaces.

You can see in the screenshot the old way to render an ocean on the left, while the modern way on the right. The right side is almost indistinguishable from a real water surface.
APOCALYX already support GLSL shaders, but there is still a problem. In the picture above, only the skybox is reflected on the water, while ships or seagulls and other objects above the surface are ignored. To make the surface reflect all the environment, one must render the scene upside down (like in a horizontal mirror), capture the result in a texture and then render the water surface, passing the texture as an argument to the shader.
The only step, that is still missing in the engine, is the rendering of the reflected scene in a texture, but in the next version all the procedure will be correctly implemented. Stay tuned for more… sailing!

GUN TACTYX at school

I have discovered, from time to time, that GUN TACTYX has been used in universities for researches in the field of artificial intelligence. When I developed the game, I had in mind CROBOTS, a game where several robots fight firing missile in a simplified arena. The AI of the robots is driven by algorithms written by the players: the best script wins. A version that is easier to play on modern machines is my JROBOTS. There C-like scripts are replaced by Java classes and the challenges are executed on-line, thanks to Java applets.
GUN TACTYX is more complex to master than JROBOTS, because the enviroments is more complex, but this is not a problem for researches on AI, because a complex environment is preferred.
This is the reason why you can find papers that cite, or even are based, on GUN TACTYX. Here is a list of some that I've found. The first 2 comes from the Universidade de São Paulo in Brazil and the last from Bournemouth University in UK.

• Towards Complex Reasoning Agents for Action Games
• Truth maintenance, Monograph, Final project
• A NPC Behaviour Ddefinition System For Use By Programmers And Designers

RPG vs RTS

It seems that the visitors of the APOCALYX Blog hate First Person Shooters games. It is very strange because FPS are the simpler games that one can create with the engine. Anyway I'm very surprised by the current result: RPG beats RTS with a result of 8 against 4. I must say that I'm more experienced in RTS, while RPG are quite outside my interests.

I like to play Real Time Strategy games like Warcraft or The Settlers because I'm addicted in the management of resources and in the building of armies, but it seems that I need to begin the study of the basics of Role-Playing games. Anyway there is still a lot of time to change the outcome of the poll: if you like RTS or FPS games give your vote to that genre, if you prefer RPGs continue to keep it at the top.

Model design (City Racing)

My second step in the development of “City Racing” (CR) is to look for a nice car model. This time I avoid to waste time in modelling something with Blender or MilkShape3D, because I tried too many time before and I know that my attempts are going to be frustrated again and again. There are already a lot of good car models out there and I will not use them for a commercial purpose, so let’s search on Google.

After a short search, I decided to use the Lamborghini-shaped car in MDL format, that you can see in the screenshot (and also in the logo already published days ago). It comes again from the models included in “The Specialists” MOD for Half-Life 1 (the same from which comes the Legionnaire for GUN TACTYX 2), so one can search more and more, but the sources of good models are always the same.
Of course, it’s a nonsense to use a format based on skeletons for a static model: a simple 3DS model would be enough, but there is no real reason to convert it. The model comes with 5 skins, so I can use a single model for all the racing cars, applying different skins.
Now only a few sound files are missing; once found all the resources will be available. Then I will jump deeply in the real demo development, the step that I prefer. Stay tuned for more news about the… making of “City Racing”.

Level design (City Racing)

The first step in the development of “City Racing” (CR), my next APOCALYX demo, is the creation of a nice city track. In fact, CR is meant to be a race among fast cars in an urban environment. I’m neither a modeller, nor a level designer, so my capabilities in the field are very poor. My only not-so-basic experience was the creation of the level performed in the “Urban Tactics” demo, while in other cases I usually borrow professional-looking levels from real games.

However, following the trial-and-errors of my previous experience, I used GtkRadiant, that is my preferred level editor, to create a track in the old Quake3 BSP format. Then I needed some good textures of buildings and walls and I chose the free texture pack from “Max Payne” (its authors provided gracefully a collection of texture for non-commercial use). Finally, I got a nice background (the one I recycle the most) and the materials to build the level were complete.
Now it’s time to put all things together. I begin to put large brushes on the level (brushes are the blocks the buildings are made of) to create the walls, in fact my simple design says that the cars will run between two continuous walls. Then I apply the textures on that brushes to make them look like ordinary walls with windows, bricks and so on. This step takes a while because I put several 90-degrees turns in my track and I’m trying to vary a little the applied textures. Anyway the final result looks quite schematic and a lot of work is needed to make it more complex.
At the end, I apply a sky transparent texture to the ceiling and lateral walls so the player can see the skybox. It’s important in this phase to choose the right inclination for the sun, because the shadows of the buildings must match the position of the sun.
The last step is the boring one: waiting that the level compiler computes all the lightmaps for the level. Since ray-tracing algorithms are at work, a lot of time is necessary to complete the task, but when GtkRadiant will terminate is job, I’ll got a nice city track to test the first runs of the cars. Stay tuned for more news about the… making of “City Racing”.

Choose the next game (POLL)

The last poll has given its answer. The next APOCALYX demo that I’m going to develop is “City Racing”. It has collected 10 votes against the 7 of “Worm-Holes” and the 2 of “Meteor Hunter”. In the next days, I’ll report step by step the progresses in its development, but it’s already the time for a new poll.
Now I’m not going to propose you to choose among a list of simple demos, nor between two set of models for a game already designed like GUN TACTYX 2. Now it’s time for a real game, the first real game that I’m personally going to program from the ground up, based on APOCALYX, of course.
Let’s start from the beginning. I’m going to ask you the most important thing: choose a genre. You can choose among the following short list, but you can also propose something different. In the last case choose “Other” and send an email with your idea: the crazier, the better.
Here is the list: First person shooter, Real time strategy, Role playing.
You choose the genre, but also can help, if you want: in that case contact me!

The IUP GUI

The latter GUI that I added to the engine was IUP. It was natural to choose it because its authors are the same of the Lua language, so it was very easy to embed it in the engine.
You may ask why I needed another GUI, when I was already so satisfied by GLGooey. The answer is simple: while GLGooey lives in the OpenGL window, IUP is a native GUI that acts outside the game window. It is very useful when a programmer needs to manage the objects rendered in the scene with a complete set of components at hand. For example, one can create an editor to control the world, like in the simplified example of the “NativeGui” demo included in DemoPack3 (see the screenshot).
In conclusion, APOCALYX users can program in Lua three different GUIs: one very easy to use and useful in the desing phase of the game (TweakBar), another to create in-game interfaces (GLGooey) and, finally, one (IUP) to build very complex tools, such as editors around the rendered world. This way, I think that almost all the possible needs are covered.

The GLGooey GUI

The description of GUIs included in APOCALYX continues. Now it’s the time of GLGooey, an interesting GUI rendered in the OpenGL window. You can see it at work executing the “Gui” demo included in DemoPack2.
This library defines several components, covering from buttons and lists, to combos and check boxes, to progress bars and sliders, and you can create and show them in the in-game window. Another advantage of this library is the easy to use skin manager. In practice, an APOCALYX user can set up dialog boxes is his applications and populate them with the necessary components, choosing in a long list of different ones.
Other GUIs with similar characteristics are available, of course, but GLGooey was easier to embed in the engine and revealed also very interesting hidden capabilities.

The TweakBar GUI

The first GUI that I added to the engine was AntTweakBar. It is an easy to use library that implements a nice bar with several components. It can be used to tweak variables in an application, in fact each component can manage boolean, numeric, text or color variables in a very intuitive way. You can define callbacks that modify the values of the interested variables, when the user interact with the component. The bar is beautiful to see and displays nicely in the existent OpenGL window.
Thus APOCALYX users, with not so much coding, can interactively modify parameters in their demos to try different what-ifs. You can see the tweak-bar at work executing the demo “TeakBarAndEmitter” included in DemoPack1.
Of course, the AntTweakBar library does not define a GUI as is usually intended, but it’s very useful in some situations, when you need to interact with a few components, but don’t want to deal with too complex environments.

The GUIs

Waiting for the poll results (I can’t wait to know which is the next demo that I’m going to complete), let’s talk about one of the most recent features of APOCALYX: the GUIs.
Since the early beginnings, the engine included some basic features to draw text on the screen and get mouse feedback, of course. You can still see how that basic GUI worked in some of the more complex demos (I mean the list of choices listed in the main screen of “HoverjetRacing”, for example). That simple interface was very complex to manage, in fact the programmer had to control the user-GUI interaction in Lua code: no default behavior was available. Luckily, there are a lot of freely available open source GUI out there: I had only the problem to choose one that worked with the already existing framework.

I have tried nearly all the OpenGL-based GUIs available, to add one internal to the game window, and also native GUIs, to add one around the game window. Almost all my tries failed, for one reason or other, except three that revealed themselves as very good choices: TweakBar, GLGooey and IUP.
In the next days I’m going to describe them, so you can choose which of them fits best your particular needs.

Worm-Holes demo

The third and last proposed demo is “Worm-Holes”, a Valve’s "Portal" clone. Well, it’s not a real clone, since I’m going to develop only a demo, but the idea is to implement those portals in the engine, even if they are not useful in other kind of games.
If you know Portal, you already have an idea of what I mean. In practice, I want to open two holes in the walls from which the player can see the same scene from different points of view. Moreover, the player can move through those holes, or push other objects through, performing almost impossible actions with coherent physics. As I have already said, the demo will not be a complete game, because the implementation of such a device in the engine is far from complete, but I want to show at least a demonstration of some possibilities.
Starting from here, you can imagine worm-holes that enlarge or reduce the player, or other that make it travel forward or backward in time, but I must say that… your imagination walks too fast!
If you want to see these hyper-portals in action in APOCALYX, vote for “Worm-Holes”.

Meteor Hunter demo

The second proposed demo, that you can vote for in the poll, is “Meteor Hunter”. Its screenshots has been around for a long time, in fact battles among space fighters are one of my preferred games since the nineties. This is the reason why I put together the resources for such a game, but I still have to complete it. In practice, the StarField class of backgrounds implemented in APOCALYX has been waiting this demo for years.
What’s “Meteor Hunter” about? The player will pilot a X-wing-like vehicle among asteroids and will fight against Tie-fighter-like opponents. Imagine a lot of laser beams, starships and asteroids all around… what’s better?
The enemies’ AI will be driven by the “OpenSteer” library, with a superposition of several behaviors with unpredictable results. Another particularity will be the drive system: I want to try something more realistic for outer-space than the usual airplane-like controls, but it’s too soon to describe it now.
If you like this short design, vote for “Meteor Hunter” as the next APOCALYX demo and… let the force be with you!

City Racing demo

Let’s go into the details of the proposed demos, so you can partecipate to the poll with a better knowledge of what you’re voting for.
“City Racing” is the least innovative of the three. It is, more or less, like ‘Urban Tactics meets Hoverjet Racing’, in fact the scenery is a large BSP level, similar to the one performed in “Urban Tactics”, where several cars compete as in “Hoverjet Racing” (but with a goal, this time).
Of course, the physics involved in the game is very different from the one the hoverjets were subject to, in fact the cars can’t follow the toboga-like path between walls with those 90 degrees turns. However I don’t think to use the functions of ODE, because my simple particle-based physics engine should still work well in such an environment.
For what regards the AI section, I think to implement a preview of the new script-driven AI that I’m going to include in GUN TACTYX 2. This should be more interesting than a built-in fixed behavior, because players could improve it, making this demo the first example of the new TACTYX series.
If you like this short description, vote “City Racing” as the next APOCALYX demo that you desire to play.

Choose the next demo (POLL)

The first poll was very useful, in fact now I exactly know which is the best model and design for GUN TACTYX 2. There were two good kind of models that could fit well, but now one has been ruled out, thanks to the votes of the readers. It does not matter if “The Specialists” won only for a vote against “The Trenches” (14 to 13): the important thing is to choose… and move forward. The final development of the game is still going to take some weeks, but now it’s already the moment for a new poll.

Some demos of mine has been in development… for years! It’s time to complete them. But which is the best to start with? Or which is the next mini-game you want to put your hands on and read its sources? Let’s concentrate on three.
The first is “City Racing”, a fast paced race among speedy cars driven by AI and physics in a urban environment. The second is “Meteor Hunter”, a space battle in outer space between the fighters of the evil empire against the outnumbered rebels, the screenshots of which have been around for ages. The third and last is “Worm-Holes”, a clone of “Portal” (developed by Valve after “Half-Life 2” and “Team Fortress 2”, where the player can open and enter portals to solve incredible puzzles).
The first two are more classic demos, while the latter is almost impossible, because the engine does not include yet the technology to create those portals.
In the next days, I’ll describe in more detail the three choices. Anyway, it’s up to you: choose your preferred demo and I’ll develop it.

Tiled terrains

A few days ago I talked about the infinite terrains available in APOCALYX. The main characteristic of those terrains is the complex heightfield, correctly shadowed, but mapped with the same uniform textures along their whole extension.
Tiled terrains, instead, are useful when it’s necessary a flat ground plenty of different features, similar to the levels of some 2D game, where complex environments are built from a small set of tiles. Even in a 3D world such a feature may be useful.
You can find an example of tiled terrains at work in the “Steering Behaviors” demo included in DemoPack1 (read the yesterday’s post) or, better, in “Dragon’s Ride”. In both cases, the terrain is built from the nice free tiles, known as “Circle Textures”, from “Lost Garden”. Those tiles can be arranged in several different ways: the “tiled terrain”, implemented in APOCALYX, takes a single large texture, including all the tiles, and applies them on the ground according to the designed fashion. Give new 3D life to your 2D tiles!

Steering behaviors

Recently I have described some of the open source libraries included in APOCALYX. This is the time of “OpenSteer”, a library originally developed by Sony that implements steering behaviors for autonomous characters.
At this point you may ask what these steering behaviors are. Do you need to move your characters on the scene in particular ways? This library includes the necessary functions to make your models act in a believable fashion. Starting from the concept of an abstract vehicle, “OpenSteer” defines functions to make those vehicles move in flocks with cohesion, separation or speed matching rules, follow a given path avoiding fixed obstacles or other moving characters, perform pursuit or evasion and more complex behaviors combining different effects.
Imagine to move a platoon of soldiers in a terrain full of obstacles following their chief, or consider a flock of birds or a group of fishes in the background of your level, or people along a road walking in two opposite directions. In all these cases, expecially the last, we want to avoid collisions or wrong interpenetrations. “OpenSteer” does all the necessary computations for you.
Among the demos of the engine, you can find one in DemoPack1 that shows how to drive two columns of armored knights along a path in opposite directions. It’s amusing to see how, in some situations, a group of warriors opens in a believable way to let in a single warrior, avoiding a dangerous collision (or, better, avoinding an unbelievable pass-through). Good flocking!