One vs All

Just a screenshot

Harvesters

Just a screenshot

New MekaWars demo!

The second MekaWars demo is finally here!
You can download MekaWars.zip from SourceForge (2.5 Mb)

Since the first demo was very primitive, this new preview includes several improvements:

• a static initialization screen
• an options screen with animated models
• users can choose the number of units
• radar tracks shown in the 2D viewer
• two different programmable teams
• improved info and Lua documentation
• a Lua language programs editor

Please, report any problem that you can experience with the new demo and feel free to post here comments, suggesions and constructive criticisms about the MekaWars simulator.

The 2nd MekaWars demo (II)

The second MekaWars preview is almost completed. In the screenshot you can see a preliminary mask to modify the number of items in the arena. The upload is scheduled for tomorrow afternooon.

The 2nd MekaWars demo

The second MekaWars preview is under development. The next demo is going to include some masks useful to personalize the test arena. Stay tuned!

MekaWars' radars

Very soon you'll be able to play with an improved MekaWars demo. In the current version, published a few days ago, there is very little to change: the starting situation is always the same, but you can already try to modify the basic AI written in "pilot.lua". Then, there is no documentation and some important features of the 2D viewer are still missing, like the drawing of the radar tracks (very useful to understand if the pilot's view of the surrounding environment is optimal).

In the next to come version, you'll get a short Lua manual to understand the differences between Lua and the other languages that you may already know, then a few dialogs to modify some properties of the playground and, finally, the radar tracks.
Stay tuned! The new demo will be available in just a few days.

MekaWars official site

The MekaWars official site is already online.

Not much to do on the site yet: it's simply a placeholder for the future official site that is going to manage the MekaWars universe, infact the game is still in heavy development. However, you can play a little with the very early preview the link of which was posted a few days ago on this Blog.
Improved versions with more documentation will be available soon, but be aware that, while the simulator behind the scenes is stable in its design, the "real thing" will be graphically much better, of course!

The Gun-Tactyx site is back

Waiting for MekaWars, I put online again the old Gun-Tactyx site.
It has been hosted at GameProg.it for years, but recently they modified their hosting policy and there is no more space for external projects.

I uploaded it for historical reasons only, in fact more than two years have passed since the last online Gun-Tactyx tournament. However, if you were addicted to Gun-Tactyx, you should consider to keep in touch with MekaWars, because its concept is very similar.
MekaWars renews the playability of Gun-Tactyx, extends the modularity of the units, but also simplifies the AI programming phase.

In practice, the main difference between Gun-Tactyx and MekaWars is in the programming language: Gun-Tactyx script were written in SMALL, while MekaWars adopts Lua (that is also the language in which the simulator is written).
The advantage to use Lua is in its versatile interpreter: it does not need a compilation phase, its syntax is simpler to master for beginners and it keeps all the advantages of the SMALL interpreter (full control on memory allocation, step by step execution of bytecode instructions, simulations completely reproducible).

Banners in Flash (II)

Another banner in Flash freely created through PowerBullet.

I think that this new one is cleaner and more readable than my two-months-old past attempt. The banner already links to the official MekaWars site, but the site and the game are still in development. While waiting for the final version, give a look at the very early 2D preview posted yesterday.

MekaWars very early demo

Since a reader has asked for it, I have uploaded a very early demo showing the MekaWars simulator at work. Don't expect too much: it's only the 2D viewer that I used in the past four weeks to capture a few screenshots and demonstrate some of the simulator features.
You can download the MekaWars very early demo (1.5 Mb) from SourceForge. Just for blog readers' eyes only.

Here just a few notes follow to describe what is available in this very simple demo (read the included readme.htm file for more details).
First of all, let's explain how to play. MekaWars is not going to be an interactive space combat simulator: it is based on the same design of JRobots, thus it is a "programming-game", those games where players program the AI of their team of bots and then watch them fight against other players' teams.
In the demo, you can experience only a few features of the real simulator and the situation at the beginning is always repetitive: 2 fighters and 6 harvesters that always start from the same positions, while asteroids and resources change the position at random. In practice, you must fight against yourself to see some action.
To develop the pilots' AI, you must program in Lua the file 'pilota.lua', that already features a few lines of simple behaviors. In the readme.htm, you can read a short list of the available functions.
Feel free to ask for any additional explanation and stay tuned for more interesting, more complete and more playable demos.

MekaWars trailer (VI)

Space station

Twilight on the sun

Orbiting fighters

The Wadfather

I always look for good resources for my demos and games and sometimes I find large repositories under the sun that I missed completely for years. One of these is The Wadfather.

The Wadfather is an important source of graphic files for game developers, focusing primarily on First-Person Shooters such as Half-Life, Quake 3 Arena, and Unreal. they currently feature: 552 environment maps, 198 texture collections containing 19004 textures, 69 desktop wallpapers.
Are you looking for a suggestive skybox for your game? Do you need nice textures in the public domain? Do you simply look for a nice wallpaper for your desktop? The Wadfather is the site for you!

MekaWars trailer (V)

Fleet flying over a planet

Fighters in an asteroid field

Orbiting fighters

Particle-based physics (III)

The particle-based physics engine included in APOCALYX is useful not only to simulate flags and cloths, but also other kind of objects with different physical properties.
In fact, the rigid constaints that link particles are resolved spreading the calculations over several frames (the method, known as relaxation, guarantees convergenge, but not immediately). If the satisfaction of the constraints is further relaxed, the body built of that particles and sticks looks like a soft body rather a rigid body, as the jelly cube that you can see in the screenshot.

Other links may be designed to achieve perticular effects and behave like ropes, bumpers, springs or dampers, instead of rigid sticks. To simulate those different links, there is no need to modify the core of the constraint solver, but only the required stick lenghts. For example, a rope is a stick that can be shorter than a given length, but not longer; a bumper is just the opposite of a rope; a spring restore its lenght at a rate proportional to that length itself; a damper restores its length at a rate proportional to the length restoring rate itself; and so on.
Even if the algorithm it quite simple, the range of effects that one can achieve is remarkable.

Particle-based physics (II)

Sometimes people asks how those cloth simulations that you can find among the APOCALYX demos are done, or more precisely how can a virtual cloth be affected by wind. Are they simple animations or are precise physics laws applied?

I programmed that effect several years ago and some simplified technique had to be applied, because there was no PhysiX engine running on the GPU at that time. The wind-blowing-on-cloth effect was part of my particle-based physics engine, that I called SimulAxion.
I first read about a particle-based physics engine in an old paper by Thomas Jakobsen, who designed the dead-body simulator of the first chapter of the Hitman series: “Hitman: Codename 47”. In that paper Thomas described a simple way to simulate rigid-bodies, soft-bodies and cloths, through the use of particles linked by sticks. In practice, the particles follow the usual laws of dynamics, but also they are constrained in their motion by rigid connections with nearby particles. The result is a very fast way to create a believable physics behavior with little computational effort.
In practice, the algorithm works on a grid of particles connected by almost rigid constraints, not the usual springs as you can see in other simulations. The distance constraint is solved by the particles themselves over several frames: they simply adjust several times their position to better fit the required stick lengths.
Finally, to create the blowing wind effect, the 3 vertexes of each triangle, that the cloth is made of, are displaced accordingly to the surface exposure to the wind direction: large displacements when the wind is perpendicular, no one when it is parallel.
It may be surprising, but this small set of rules (linked particles and wind direction) is sufficient to create in a realistic way those characteristics movements of flags and cloths.

Incoming missiles (II)

Just another radar-screenshot

MekaWars trailer (IV)

Just another screenshot

New FORUMS at SourceForge

Thanks to Tom, the official forums related to the APOCALYX 3D Engine has been hosted at xfuj.com for a long time. Now SourceForge.net has provided phpBB support to their users, so I have decided to free Tom's server and move to the new phpBB server. Thank Tom for you great service!

The new APOCALYX Forums are divided into the usual sections:

• GENERAL SUPPORT
  This section is devoted to questions about the general usage of the engine, such as, but not only, the use of a particular feature or library, report strange behaviors in your own code, or ask for help in the development of tricky algorithms. Also questions about the Lua scripting language are welcome, because Lua is the main language used in the development of APOCALYX-based demos and games.


• GAMES DEVELOPMENT
  This section is devoted to questions about the development of games using THIS ENGINE (not games development in general), such as, but not only, the application of particular features or libraries to realize a certain technique useful for your game, report strange behaviors in a large project, or ask for help in the development of the game itself.
  Remember also that I post daily news about the development of my own games on the APOCALYX 3D Engine BLOG.


• ENGINE DEVELOPMENT
  This section is devoted to questions about the LGPL C++ sources of the engine, such as, but not only, the included source code of a third-party library, report strange behaviors in C++ code that you have modified, or ask for additional built-in features. Questions about the C++ language are NOT welcome, because the modification of existent code requires a very good knowledge of C++.


• TOOLS SUPPORT
  This section is devoted to questions about the third-party tools that you may used to develop your APOCALYX-based demos and games, such as, but not only, the use of a particular source editor (there is a very good one, currently in development, known as NsEditor), the use of certain resource editors (like the BSP editor GtkRadiant), or the other tools listed in the Tools page of the official APOCALYX site.
  In this case, I can't guarantee to help you much with my answers, because my knowledge of those tools is not advanced, but I'll try to answer anyway.

I hope that these new forums are going to be a useful tool for all the APOCALYX users.
Feel free to post frequently! I'll answer as soon as possible.

Spore prototypes

As you know, the long waited Will Wright's Spore game is on the shelves. There are quite different reviews about Spore, but I think that a game designed by the author of SimCity ans The Sims can't be so bad.

Anyway, I'm not interested in the game itself, but in its development prototypes that are available for free and learn a lot about the step moved towards the real thing.
In particular I'm interested in their interfaces, for example that of the Space prototype, the screenshot of which you can see in this post.

Here is the news release of the Spore prototypes from EA.

Play with our Prototypes
Spore has been a huge undertaking. Along the way we ended up exploring countless design directions in gameplay, simulation and user interface. One of the ways in which we explore possible design directions is by building simple, playable prototypes that we can play around with to get a sense for a particular system. Usually these prototypes are never seen by the public, but we thought some of the more intrepid players out there might enjoy playing around with a few of our early Spore prototypes. Keep in mind these are not tested, supported or even easily explained.

Game Physics Competition

Havok(TM) and the Intel(R) Software Network start a game physics competition. Through the use of the Intel-sponsored versions of Havok Physics and Animation for the PC, you must demostrate an innovative use of physics in a game. Your game demo could earn you $40,000 in cash, a gaming PC and great exposure.
There are two caterories:

1. Most Innovative Use of Physics in a Game. Your entry must be a playable PC game demo that includes new or unique uses of Havok technology. They're looking for new ways for the player to interact with the game through physics, showing different uses of physics than what can be found in PC games today. This can be a FPS, sports game, casual game, or any other type of game.
2. Best Physics Knowledge Base Entry. They're looking for the best contributions that can benefit the game developer community. This can be a code sample, optimization tip, technical whitepaper, a technical abstract of your demo, or any other technical content that shares your knowledge of game physics with the community.

Submit your demo or application concepts by November 15, 2008 to be eligible for the finalist round of competition. Submit your entries to the Best Physics Knowledge Base category by January 16, 2009 to be eligible for the top prizes in this category.
Check out our Official Rules at SoftwareContests.Intel for more details about this contest.

MekaWars' decoys

Here they are! Now fighters and bombers of MekaWars can protect themselves against incoming missiles thanks to decoys. In the screenshot you can see decoys (smaller green dots) thrown by fighers and, some of them, followed by deceived missiles.

The vehicles detect the incoming missiles thanks to a particular device (queried by the threat() function) reporting the distance of the nearest missile that follows the vehicle itself, but no incoming direction is reported, so the pilot must estimate the best direction to throw the decoy along. Once the missile is near enough to the decoy, it decides to follow the decoy instead of the real target. Since the decoy has a short life, the pilot has better to move away that area, just to avoid unexploded missiles that could detect the vehicle again.

Incoming missiles

Finally the top level weapon of MekaWars is implemented: homing missiles. As already explained in past posts, missiles are driven towards their target, while bombs and torpedos follow a straight path. In the scheenshot, you can see several missiles and their targets linked by a line for clarity.

One may ask what can a target do to avoid the incoming missile. There are two main devices useful as defence: the threat device (once called sonar) and decoys. The threat device reports the distance of the nearest incoming missile, while decoys, once launched, confuse the missile that could explode against the decoy ignoring the real target. These two new devices are going to be implemented in the next days. Stay tuned!

MekaWars trailer (III)

Just another screenshot

MekaWars' miners

A further evolution in the simulator of MekaWars. In the original scenario, the environment show the presence of asteroids and resources all around (such as iron, silicon and uranium) and starships drop vehicles to harvest them.

During the development of collision detection algorithms, it was natural to consider also the explosion of torpedos, missiles and bombs against the asteroids: the obvious outcome was the production of resources just from the damages inflicted on asteroids. So every asteroid, made of a particular material, releases pieces of that material as resources.
In conclusion, fighters now have an additional use: to mine resources from asteroids to let harvesters collect them.

MekaWars' panels (II)

Just a screenshot to show
the VEHICLES BUILDER panel
currently in development

MekaWars' panels

Just a screenshot to show
the FLEET BUILDER panel
currently in development

Retro Remakes Contest 2008

When I heard of interesting competitions that involve the game development, I'm very happy to post news about them.
This one in particular is very intriguing because there are a lot of prizes, but also because the task is the development of games that has something to do, resemble or even clone, glorious games of the past.

The contest is divided into several categories, but all the entries partecipate also to the Grand Prize Competition. The categories are: 1) Retro Remakes, 2) Games That Weren't, 3) Sequels that weren't, 4) A Game For Helen, 5) 8 Bit Mashup, 6) We Like It Retro.
Here you can find the direct links to the categories, the rules and, finally... the prizes, just to wet your appetite.
The competition has already started in the past days and the submission line is around the beginnings of December, so you'd better to visit the site of RETROREMAKES for more info, if you are interested.

Lua-OpenGL binding

Someone may think that the basic radar-like screens on which I show the MekaWars' simulator capabilities and rendered thanks to specific code written in C++. In reality, those simple screens are drawn through code written in Lua, thanks to the LuaGL library.

LuaGL is a library that provides access to all the OpenGL functionality from Lua. It is a free software and can be used at no cost for both academic and commercial purposes. You can download LuaGL from its SourceForge project home page. That library works as a binding for all OpenGL commands, so you can have full access to the graphics hardware from Lua. Of course, there are performance penalties, so it's always better to use the high-level APOCALYX functions, except when a customized renderings are necessary.

In APOCALYX, the LuaGL support is useful mainly to create the so called ScriptObject, as shown in the "ScriptObject.lua" demo.
In practice, a ScriptObject is a graphical object that a programmer can add to the 3D world, but its particularity is an empty render() method. This means that no C++ drawing method is defined by default, while a Lua functions is called, instead. To explicitly draw the object, the programmer can use the LuaGL binding functions.
In the screenshot above, there is the usual background in which you can see a ScriptObject: a simple triangle strip with different colors defined at its vertexes.

MekaWars' torpedos

After cannons with their bombs (read The Guns of MekaWars), another weapon has been implemented with its projectiles: torpedo-tubes and torpedos. Of course, those are only names to differentiate these two kind of weapons available to MekaWars' spaceships and fighters.
In the small radar-like screen shown in the screeshot, the white pixels correspond to bombs, while the red pixels to torpedos. You can see also a chain reaction: a row of mines that explodes in sequence.

As already explained, there are a lot of differences between bombs and torpedos:
the cannon shoots bombs at a maximum constant speed, while tubes may drop torpedos at any speed (up to a maximum), even zero speed (in that case they act as mines); the number of bombs is limited only to the amount of energy available, while torpedos are finite; the cannon can't shoot when the shield is active, while tubes can; bombs explode at the end of their run or when they hit an obstacle, while torpedos can explode after the activation time has expired and, after that, they react when hit or when a vehicle enters the activation range; bombs are not affected by other explosions, while torpedos, when activated, react to nearby explosions (as in the shown chain reaction).
So torpedos are more versatile than bombs and I'm sure that very advanced players will create smart pilots who, being hidden behind an asteroid, will make their torpedos bounce against other asteroids to hit enemies on the other side: That's A.I.!

APOCALYX 3D Engine 0.9.3

The APOCALYX 3D Engine 0.9.3 release is finally available. It includes some improvements and bug fixes. To download the engine in a easy-to-get 60 Mb installer, or in smaller selected pieces, visit to the APOCALYX Official Site's Downloads page.

New features:

• Added MDLModel functions: setTransition(), setTransitionTimer(), getStoppedTransition()
• Added IM (Imaging Toolkit) support in IUP GUI
• Added primitives: Cylinder, Disk, PartialDisk, Sphere
• Added setPointerVisible(), isPointerVisible()
• Added string.pack(), string.unpack()
• Fixed bug in collisions between ODE objects and BSP geometry
• Added support for Arbitrary Precision Math (MAPM)
• Added support for Video Capture functions (experimental)
• Added support for MySQL databases
• Added support for SQLite databases
• Removed AngelScript language support
• Removed SMALL language support
• Removed CSL language support

New demo (in full-installer):

• Mushroom's Ride, that shows some of the engine features at work.

You can download the runtime of the engine and the demo packages from the Downloads page. For more detailed descriptions of the demos, visit the Demos page. Feel free to ask more about the new capabilities of the engine on the forums or by e-mail. Visit the APOCALYX Blog (this one) to read daily news about the engine and its development.