Lost Garden Awards

Lost Garden is one of my preferred blogs. The owner, Danc, always posts interesting articles about game design and also provides nice 2D graphics to developers who want to prototype his designs. From time to time, Danc also launches game prototyping challenges and assigns virtual bronze, silver and gold awards to the best works.
Now it's the time of Shade, the latest game prototyping challenge, the first that is not designed exclusively for 2D, in fact shadows play an important role in the game.

Since the game is based from the beginning on a 3D environment, I can finally develop a prototype based on APOCALYX, instead of my less powerful TooDee engine. As you can read in the article that describes the game, all the necessary features are already available. Shade needs a flat terrain, a simple HUD, several moving objects (the player avatar, the mushrooms etc.) and blocks that cast shadows. Since APOCALYX is completely scripted, it's the perfect tool to develop a fast game prototype: a challenge that one has no excuses to refuse.
Danc describes the basic gameplay as follows: "You play the part of a rugged mushroom rancher who must collect adorable sentient mushrooms living in the shade. All you need to do is run up to a planted mushroom and touch it. It will pop out of the ground and start following you around. Lead it back to the start location and you'll be awarded multiple point based off its size.
Unfortunately, it is a scorchingly hot day. You can meander about the landscape of giant grassy blocks with impunity due to your meglo-awesome wide brimmed hat, but the mushrooms wilt quickly in sunlight. To lead them back successfully, you'll need to keep to the shadows and plot the optimal path home."
For more details, read the complete article at Lost Garden.

Tubing and Extrusion

After the addition of a few primitive shapes in the last preview of the engine, I realized that is easy with only a little effort to add also other more interesting shapes. In fact, the engine already includes the GLE Tubing and Extrusion Library because another library, that draws 3D text, need it. In practice, GLE is useful to draw tubes or extruded surfaces in several fashions according to chosen parameters. The implementation is almost straightforward and I'm writing it right now.

As the author says: "GLE is a graphics application programming interface that consists of a number of subroutines for drawing tubing and extrusions. It is a very fast implementation of these shapes, outperforming all other implementations, most by orders of magnitude.
More in detail, GLE contains a collection of routines for drawing sweeps and extrusions. A "sweep" or "extrusion" is a 2D contour (polyline) that is swept or extruded along a 3D path (polyline). For example, sweeping a circle along a straight line will generate a cylinder. Sweeping a circle along a circular path will generate a doughnut (torus).
The library also includes a set of utility routines for drawing some of the more common extruded shapes: a polycylinder, a polycone, a generalized torus (circle swept along a helical path), a "helix" (arbitrary contour swept along a helical path) and a "lathe" (arbitrary contour swept along a helical path, with torsion used to keep the contour aligned).
The most general extrusion supported by this library allows an arbitrary 2D contour to be swept around an arbitrary 3D path. A set of normal vectors can be specified to go along with the contour; the normal vectors determine the appearance of the contour when lighting is turned on. A set of colors and affine matrices can be specified to go along with the 3D path. The colors are used to color along the path. The affine matrices are used to operate on the contour as it is swept along. If no affine matrices are specified, the contour is extruded using the mathematical concept of "parallel translation" or "Gaussian translation". That is, the contour is moved (and drawn) along the extrusion path in a "straight" manner. If there are affine matrices, they are applied to the contour at each extrusion segment before the segment is drawn.
The affine matrices allow work in a quasi-non-Euclidean space. They essentially allow the contour to be distorted as it is swept along. The allow the contour to be rotated, translated and rescaled as it is drawn. For example, a rescaling will turn a polycylinder into a poly-cone, since the circle that is being extruded is scaled to a different size at each extrusion vertex. A rotation allows the contour to be spun around while it is being extruded, thus for instance allowing drill-bit type shapes to be drawn. A translation allows the appearance of shearing in real space; that is, taking a contour and displacing it, without otherwise bending it."

APOCALYX 0.9.3 alpha2

I made some modifications to the engine, not enough yet to justify a new release. Anyway the blog readers can download here the new executable.

A description of the modifications:

• The collision between ODE objects and BSP geometry is finally fixed. Try the demo "BallsOnTriMesh.lua", and you'll see that now the balls bounce correctly on the BSP level
  
• The IUP GUI, now includes the IM Imaging Toolkit: this means that also images and icons can be displayed in a GUI created with IUP
  
• Added a few new primitives: Cylinder, Disk, PartialDisk, and Sphere
  
• the MDLModel has 3 new functions that are very useful to perform smooth transitions between different sequences
  
• The AnimatedTexture class now contains functions to stop the animation and show specific frames
  
• Added the functions setPointerVisible() and isPointerVisible()
  
• Removed the AngelScript, SMALL and CSL scripting languages
  

SOCCER TACTYX delayed

As usually happens in the game industry, and in particular in my projects, I must announce that the planned release date of SOCCER TACTYX was too optimistic. I had desired to release it before the beginning of the European Football Championship (Euro2008), then I was happy to publish it before its end, now I plan to complete it before the next Football World Cup (2010). Jokes apart, I coudn't devote all the necessary time to the project, so I need a few more weeks to complete it.

However, since the beginning of the project a lot of interesting small improvements has been made, so the final release will be better that the one originally planned. To list only a few: MDL animations are now smooth, the IUP native GUI library revealed itself as a very powerful tool to create intuitive interfaces, a new scripting language was added to the engine.Yes, you need an additional amount of patience, but you are going to play SOCCER TACTYX as soon as... it will be ready.

ScriptBasic

The results of the last poll about the preferred programming languages (read the post) had an unexpected side effect. I discovered the existence of ScriptBasic, a BASIC interpreter that is easy to embed and extend.

As you may know, I designed APOCALYX to be a 3D engine that people can program without the need of a compiler. That's why all its features are accessible to Lua scripts: this is the main characteristics I was looking for in 3D engines years ago, but then I had to develop one by myself because the engines available at that time were only C or C++ based.

Lua possesses very powerful capabilities (eg. its tables and metatables) that make it a language opened to different solutions and programming styles, but also a bit particular and, probably, not easy to master for novices. Recently I succeeded in the modification of the default behavior of the Lua interpreter, so now I can control its execution instruction by instruction, also control the memory allocation (read the post) and this language became suitable for games like GUN TACTYX.

Only a thing is still missing to make the whole thing accessible to novices at a very basic level... to use BASIC as the scripting language. I don't mean that I want to drop Lua, of course; I simply realized that the BASIC language is simpler and well known by amateur programmers, so it's not a bad idea to embed it into the engine. In conclusion, I started a poll to remove languages not very useful, and now I'm back including an additional one, that I hope more useful.

The BASIC flavor that was suggested is ScriptBasic. In a few hours I have analyzed its features and realized that a programmer can easily extend and embed it in his own applications. There is also an easy way to control the memory allocated by the interpreter; moreover its bytecode can be executed instruction by instruction and then suspended. As I already told above, these are the characteristics that I was looking for and it's a real sin that I never found this interpreter years ago in my searches, on the contrary even the old GUN TACTYX could be based on it, catching much more players than the difficult to use SMALL interpreter did.

I have already successfully compiled the interpreter and linked it to the engine. The next step is to provide a sandbox similar to the one used by modified the LuaScript interpreter, so players can program the bots of SOCCER TACTYX (and the forthcoming GUN TACTYX 2) in BASIC.

A further step could be to bring ScriptBasic at the same level of the Lua language, so programmers can write directly their APOCALYX demos or games in BASIC, side by side with Lua, but this is a larger step because I should expose all the engine functions to ScriptBasic and that is a very long work. I think that a limited support, devoted to SOCCER TACTYX, is enough for the moment.

The ancient origins

Users sometimes ask how much time I have spent in the development of the APOCALYX 3D engine, but I don't know which is the correct answer. In fact, I have developed most of the engine in intensive short periods, then for long weeks or months I couldn't write a line. They also ask about the name: where does that "APOCALYX" come from? The current logo has nothing to do with the origin of the name. It is a recent acquisition, suggested by a reader of the blog, so it appeared long after the name.

To answer, I must tell when precisely the engine began its first steps. In the far 2000, after a few years of experience in Java programming and the initial success of my online game JROBOTS, I planned to create a similar game implemented in a shiny 3D graphics, that became in 2002 the first GUN-TACTYX. My early attempts were DirectX based (at the time still version 6 and then 7), but I wasn't very satisfied because I ignored the basic techniques on which 3D engine were based.

In 2001, the owner of the famous NeHe site (who has published for years tutorials about OpenGL programming) organized a mythic contest known as the 2001 NeHe Apocalypse Contest. Among the entries there was one of an italian programmer, good enough to win the third prize of the contest. The author included in his demo the complete sources, based on OpenGL and written for my beloved Borland compiler. That sources were a revelation and the author kindly gave his permission to use them in my first demos and, as time passed, a more complete and powerful engine has grown up. Some lines of the original code are still there at the base of a more complex structure, now completely based on Lua scripts.

In conclusion, I must thank Matteo "Fuzz" Perenzoni and his "Apocalypse demo" written for the "NeHe's Apocalypse Contest", that's where the engine and the APOCALYX name, modified in the final characters to become unique in Google searches, come from.

Preferred languages

The users answered the question about their preferred languages. The resulting list in order of importance is: C++ (21), Lua (9), Java (7), Python (7), other (5), ASM (4), C# (3), JavaScript (1), lisp (1), PAWN (1), Prolog (1), while AngelScript, CSL, Perl, REXX, Ruby and Squirrel were ignored.
As a first comment, we can say that C++ is the preferred language, then follow at a distance Lua, Java and Phyton. Since the poll was started to get useful indications about the scripting languages included in APOCALYX, I must say that the choice of Lua was a good one. Also Java and Phyton are popular, of course, but their main disadvantage is the requirement of large installation files and I prefer to link the script interpreter to the engine executable to avoid complex installations.
Another comment regards the scripting languages already included in the engine, Lua apart, that are AngelScript, CSL and SMALL (now PAWN). They don't seem necessary to any user, so I'm going to remove them from the next releases to reduce the size of the executable. Then other languages does not seem so necessary to anyone. Of course, I'm still going to support TinyC and FASM, because they are useful to optimize pieces of code where performances are critical.
Finally, a comment about the "other" option. A user told me that Pascal is a nice language too, especially in the Delphi flavor. Effectively the Nout's NsEditor is written in Delphi, just like the engine itself is written in C++. Another user suggested BASIC instead. This is not a bad idea since a lot of amateur programmers develop in BASIC and ignore other languages; he also suggested the ScriptBasic interpreter that seems very promising, since it possesses most of the Lua interpreter characteristics (easy embeddable and extendable), it provides also the well known BASIC syntax and I'm seriously evaluating it as an additional scripting language. The ScriptBasic author says:
"ScriptBasic implements a rich set of instructions that are available under Win32 as well as under Linux/UNIX. Programs written in ScriptBasic are portable unless you work hard to insert some system specific code.
If you miss some functions in the language itself there are external modules that implement several features, like CGI handling, MySQL access, regular expressions, graphical user interface, NT/UNIX specific functions (in case you really need something system dependant) and several others.
ScriptBasic is fast, it generates a compact internal code, which is interpreted. This internal code occupies a single, continuous memory chunk and is usually saved into a cache file. The cache file is automatically checked by ScriptBasic and thus it compiles the source only when needed.
You can also save this code into separate file and deliver it as your application without giving out your source code. This is to protect your intellectual property if you wish to use it. What is more ScriptBasic can be compiled to C and this way you can generate standalone executable on UNIX as well as on Win32 operating systems free of charge.
Finally: ScriptBasic is LGPL. This means that you can use it, alter it, extend it, embed it. The extra L before GPL says that you can embed it even into commercial application that you sell for money."

Spain-Italy 4-2

Just a screenshot to remember
the italian goodbye to Euro2008
Penalty: Di Natale -> Casillas

NsEditor V3.1 is released!

Great news from Nout! After a few weeks from the first annoucement, another release of his game editor is available for download. Nout says:

NsEditor is a script editor customised for use with APOCALYX plus a game framework, using entities, strongly tied with the editor. Download now the new version of NsEditor!

In this version only minor improvements have been added and a few bugs are resolved:

• The property editor keeps the picklists updated after changes are made to the zip file


• Files are put in picklists selectively


• ScriptFiles directly point to the script directory


• A default tool directory was added


• The APOCALYX screen starts by defualt with a larger screen size


• A script file can be opened directly from the property window


• etc...

Few updates have been made to the framework and a set of new entities is added

• HUD: to display scores, health etc... in a graphical way


• FlipBook: To show one out of multiple pictures by index, or the run a short animation, eg. an explosion


• Menu: Shows an array of graphical buttons. Can be toggle, click or radio buttons. Can be used, eg. as popup menu, or selection menu


• AviToTexture: enables to use avi's as a texture for a billboard or a texture for a splash screen in just a few clicks


• Text3D: Add a 3D text to the scene


• And some more small improvements where added into multiple existing entities

Thank you again, Nout, for this great tool!

Open Dynamics Engine

Among the other libraries, another very useful one is the Open Dynamics Engine (ODE), a library devoted to the simulation of rigid body physics. It's obvious that such a library is very useful in a game, because realistic physics behaviors in the bodies that surround the player is a strong requirement nowadays.

As usual APOCALYX defines a Lua interface to the ODE functions, so the script writer can easily access their powerful capabilities. There are also very simple scripts, such as "BouncingBall.lua" and "BallsOnTriMesh.lua" in DemoPack1, that show how to call some of the simplest functions ans set up a simple environment.

The author describes the library as follows: "The Open Dynamics Engine (ODE) is a free, industrial quality library for simulating articulated rigid body dynamics. For example, it is good for simulating ground vehicles, legged creatures, and moving objects in VR environments. It is fast, flexible and robust, and it has built-in collision detection."

Finite State Machines

Since other interesting news are still missing, I continue to describe the libraries included in the APOCALYX engine. After eSpeak, MicroPather, and in some older post OperSteer, Stellarium and SimulAxion, it's now the time of FSM, a library devoted to the management of finite state machines, to which APOCALYX adds an easy to master Lua interface. A demo that shows FSM in action is the "FiniteStateMachine.lua" script available in DemoPack1.

A finite state machine is an abstract device that defines a collection of states connected by transitions. Each transition between two states occurs when some specified event happens. Sometimes is useful in games to manage this kind of devices, to keep track of the states in which the game or is characters are.

The authors describe their library as follows: "FSM is an implementation of an extensible dynamic configurable finite state machine. The configuration of the state machine is not compiled, but loaded at the runtime from a file. The manipulation of the states, transitions etc. at runtime is also possible.

The FSM consists of a number of states. One of them is defined as the initial state. Each state is associated with a number of transitions. If a certain event occurs, a transition that is associated with this event causes the FSM to change its state. Such a transition may be limited by a set of conditions, that have to be fulfilled before the transition is activated. Each transition may be associated with a number of action, that are executed, when the transition occurs. Also may a state be associated with a number of actions that are executed each time the FSM enters or leaves the state.

The mightiness of the FSM was extended by introducing variables. A transition may be associated with a value range of a variable as an additional condition and is only executed when the variable value is within the specified range. The value of a variable is manipulated by special actions."

Path finding

Yesterday I talked about eSpeak, the text to speech library included in APOCALYX. Today let's talk about MicroPather, that is a library devoted to path finding, a feature that most games require.

MicroPather provides an implementation of the A* algorithm and the engine includes a Lua interface to the original MicroPather functions written in C. In practice, the programmer must define arcs that connect several nodes, specifying the weights of each arc. For example, the room of a level are the nodes, the corridors are the arcs and the lengths of the corridors are the weights of the arcs. Specific functions of the library can compute the shortest path from one room to another along the room and corridors of the levels.
As its author says, the goals of MicroPather are easy integration into games and other software, easy to use and simple interface, fast enough for real time use. You can find samples of application at the MicroPather site and a simple (abstract) example applied to APOCALYX in the "PathFinding.lua" demo available in DemoPack1.

eSpeak: text to speech

From time to time I describe a library that is hidden in the features of the APOCALYX engine. This is the time of eSpeak, a library devoted to the conversion of text into sound from a voice synthesizer. The version included in APOCALYX is modified to support 3D sound, so one can make his characters speech with different voices and different languages according to their positions is space. You can find a demo performing some simple text to speech conversion in the "Speak.lua" script included in DemoPack1. Here follows the original description of the author of the library.
"eSpeak is a compact open source software speech synthesizer for English and other languages.
eSpeak produces good quality English speech. It uses a different synthesis method from other open source TTS engines, and sounds quite different. It's perhaps not as natural or "smooth", but I find the articulation clearer and easier to listen to for long periods. The library includes different voices, whose characteristics can be altered.
The eSpeak speech synthesizer supports several languages, however in most cases these are initial drafts and need more work to improve them. Assistance from native speakers is welcome for these, or other new languages. eSpeak does text to speech synthesis for the following languages, some better than others. Afrikaans, Cantonese, Croatian, Czech, Dutch, English, Esperanto, Finnish, French, German, Greek, Hindi, Hungarian, Icelandic, Italian, Lojban, Macedonian, Mandarin, Norwegian, Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Spanish, Swahili, Swedish, Vietnamese, Welsh."

Italy-France 2-0

Just a screenshot from Euro2008
De Rossi -> Henry -> goal

SOCCER TACTYX API

Finally I've found some spare time to spend on SOCCER TACTYX, just before the Euro2008 match between France and Italy. Now I'm implementing the API through which the players will program their team of bots. Thanks to Kr0meel, who designed the API, I can work on a well defined set of functions.

For example, there are several functions that control the movement of the bot, such as: SetWalkSpeed(), SetStrafeSpeed(), SetRotationSpeed(), Jump() and Dive(). Then there is an important action, Kick(), and several functions to communicate with the teammates. Finally, there are a lot of input functions, like GetBallPosition(), GetPlayerPosition() and others, that are absolutely necessary to the bots to be aware of the sorrouding environment.
Users, who know about JROBOTS or GUN TACTYX, are already familiar with this kind of API. In practice the bots interact with their environment through input functions, that mimic the sensors of a robot, and output functions, that represent the actuators of a robot. A simplification, in comparison with other similar games, is the complete knowledge of the position of the ball and players on the field: in other cases a Watch() function that returns the positions of the objects in a limited angle of view is returned, but in this case we adopted a solution easier to manage.
At the end, the player, who will write the best algorithm, is going to score more goals and win more tournaments. Win the best!

Is it fast enough? (POLL)

The usual objection raised when a 3D engine, like APOCALYX, provides an interface based on scripts is: "Is it fast enough?"
To answer the question, you should consider that Lua scripts control only functions that are written in C++. Speed is not a real issue, if the critical functions are compiled, and the flexibility of a scripting language gives more freedom, especially in the prototyping phase. In practice, Lua is not used at a low level as happens for example in my TooDee engine (read here to know more), where a 2D engine is written in Lua passing through calls to the SDL functions.
In some cases, when no suitable support function is already available, it's also important to write portions of code in a language faster than Lua. If the programmer does not want to modify the original sources of the engine, another approach is possible: he can write the time critical functions in C and then compile them during the execution phase, thanks to the built-in TinyC compiler. The TinyC compiler can't optimize the code as other compilers do, but is very fast and the generated code is obviously executed faster than interpreted code. The programmer can also write the critical functions in ASM, then the object module in ELF format, generated by the FASM assembler, is linked by TinyC during the execution phase. The approach above solves in a script-like fashion any speed issues related to particular needs of the game.
I described above the core languages of the engine: Lua, TinyC and FASM. A normal user is going to write his scripts in Lua only, of course. I added also other scripting languages to the engine, but I'll drop their support in the next release to reduce the size of the executable, in fact, those languages has a limited access to the features of the engine and no one seems to need them. I'm talking about AngelScript, CSL and SMALL. They are there only because their interepreters can be controlled in a very fine detail, but recently I accomplished the same task also with the Lua interpreter (read the post), so I don't need them anymore.
That's why I start this new poll: to know if anyone needs those languages (as they are supported now) and also to know if other languages may be useful. For example, I received a suggestion some weeks ago about the implementation of a Java interface. In conclusion: look at the list of the poll and check all the languages that you think useful for your games and demos. Feel free also to suggest other ones: in that case check "other" and then discuss the topic in the comments. I don't promise anything, but at least is interesting to know which languages are preferred and deserve more attention.

Cal3D models (II)

The visitors of the APOCALYX Blog have chosen again. This time the choice regards the improvements of the animated model formats supported by APOCALYX. The list in order of importance is the following: MD5 (13), Cal3D (10), X (4), MDL (3), MD3 (2), MD2 (1), MS3D(1), Other (0).

Cal3D models from the "Cally demo"

It seems that the APOCALYX users want to adopt in their games mainly MD5 or Cal3D models, then X and MDL follows. Probably MD3 or MD2 are too old to be still interesting, while MS3D models require a commercial tool (MilkShape3D), so it's not so useful for amateurs.
At the beginning of the poll, MD5 took immediately the head of the competition. Then someone have commented that Cal3D is a very nice model format, especially because it is supported by Blender, the well known free modeller. Immediately Cal3D regained a better position in the list. Finally, X and MDL come. The latter is another very old format, but compared to MD3 and MD2 is more advanced because it is based on skeletons, while the animations of MD3 and MD2 are vertex based.
Users, that regularly visit this blog, knows that I like very much MDL models. That is true only because there are a lot of MDL models available and I can find a lot of them good for my demos or games without searching too much. I'd prefer Cal3D, of course, because more advanced, but I can't easily find good models in this format. As I said in a past post, I have found only the three that you can see in the screeshot above. They are too few to put together interesting demos. However, if a modeller wants to donate some of his Cal3D models for my free demos, they are welcome!

Italy-Romania 1-1

Just a screenshot to remember the

penalty saved by Buffon at Euro2008

Cal3D models

Because of a comment to yesterday's post, I surprisingly discover that at least one user wants improvements on the Cal3D format support (probably more than one, as I can see in the results of the last poll).
I say "surprisingly" because until now I was aware of very little interest on this kind of format, that on the contrary I judge very good. I usually evaluate the popularity of a format considering the number of free models available on the internet, in fact being not a modeller, I often use free models for my demos. Years ago, when I included the Cal3D library in the engine, I also expected to find a lot of free Cal3D models available, but I coudn't find any. I realized that format was not so popular.

In practice, the only interesting models that I could find in that format were those three available in the demos of the library (the paladin, the skeleton and a female figure): not enough to build beautiful demos.

Anyway, some time ago, a user wrote a useful tutorial on the creation of Cal3D models in Blender and explained how to load them in APOCALYX. That tutorial is available in the Users' Gallery. I thought that was enough to renew the interest on this format but nothing happened.
Of course, if someone is really interested in an improvement of the Cal3D format can give his vote in the poll, but I'm also curious to see some new Cal3D models before, because it's easy to ask for this and that, but if no one is going to use a feature, I'm simply going to lose my time... and I have no time to lose.

MD5 models

It seems that the preferred model format chosen by the visitors in the current poll is the MD5 taken from Doom3. Effectively it's going to be the most advanced model format supported by APOCALYX, in fact also GLSL shaders are applied to this kind of models. Until now, only Cal3D already supported vertex and pixel shaders, but no one seems to use it, so MD5 is welcome. I'm going to implement it, if the poll will confirm the current results.

Well known characters from Doom3

Transformers

Probably you think that I've forgotten "City Racing", but that's not true. Now I spend my spare time in the development of "SOCCER TACTYX" because this is the right period to take useful inspirations from the matches of UEFA Euro2008, but "City Racing" is always the next demo that I'm going to develop.

For what regards the car models performed in that demo, I've already chosen those shown in this old post, but I've recently found also these nice models in the "Transformers Q2" MOD for Quake2.

It's surprising to see these running cars or flying airplanes tranform seamlessly to fighting robots, so it's not a bad idea to archive these models and take them in consideration for a future demo.
Imagine a slow running robot that becomes a fast racing car: I don't know yet what it has to do with with a race in the streets of a towm, but at least it's amusing!

Netherlands-Italy 3-0

Just a screenshot to register the

(last?) Italy's defeat at Euro2008

Models formats (POLL)

I have no news about the projects that I started in the past days. The scheduled activities are delayed, but I hope to find more time for their development soon.
Anyway, now it's the time for a new poll. Since the available time is limited and I want to improve the engine especially for what regards features really used, I want to ask about the animated models formats that are going to be used in your projects.

As you know, the model format currently supported are: Cal3D (the well known library), MD2 (Quake2 format), MD3 (Quake3 format), MDL (Half-Life 1 format) and MS3D (MilkShape3D format). There are also 3DS and OBJ, but they are not animated (at least not in the flavor that the engine supports). If you want that some of them are the one improved first (I mean higher rendering speeds and better final results), vote them. Then I add also to the list the X (DirectX) and MD5 (Doom3) formats, that are not supported yet, but I have found in the past source code that can help in their implementation. If you think that also the last two are important in your project, vote for them, too. You can also suggest other formats, but in that case you must also suggest some free source code that explains how to load and render that format using OpenGL.
You can vote at will any number of formats, but choose only the ones you absolutely need, so I can focus my efforts (and my spare time) in a useful direction.

RPG environment (III)

It was a long struggle, but finally the poll has given its results: the background of the next RPG game that I'm going to develop, based on APOCALYX, is the Middle Earth-like.

The results are: Middle Earth-like (29), Ancient Japan (25), Buccaneers (11), Western Fronteer (11), Post-atomic (11), Roman Empire (9), Galactic Empire (6), Gangsters (5), Ancient Egypt (5), Arthurian cycle (3), Other (1). The latter was about a RPG based on several environments, where the player travel through the ages. A nice idea, but let's start from something less complex.
Since the stuff about the "Lord of the Rings" is copyrighted material, the game will roughly inspired by Tolkien's world, in practice we'll see the usual races of trolls, orcs, goblins, elves, dwarves and humans and, probably, the usual classes of wizards, warriors, merchants, craftsmen and so on.
Now I'm only collecting materials and ideas for the first demos, to convince someone to join the team. Of course, I still have to complete some projects that I have begun in the past weeks, but this is the right time to send suggestions and ideas on how to develop the best amatorial Role-Playing game based on a fantasy-medieval asset. Thank you in advance!

SOCCER TACTYX Editor (II)

Short news about SOCCER TACTYX. The development continues, but as usually happens, I have to modify the release date. However, I still hope to publish the game during the period of the European Football Championship.

In the meantime, Kr0meel, the author of the scenery, has designed a well thought API through which the players will program their bots, while I have refined the script editor included in the game. Below you can see a screenshot showing a few pieces of the control panel.

Now it's time to complete the simulator and the Lua interface between the programmer and his bots. Still some days of patience and you'll drive your bots towards the victory they deserve.

RPG models (II)

Still a few hours to wait to know the environment of the next RPG game based on APOCALYX. I foresee a brilliant victory of the Middle Earth-like background. So I'm still looking for good models to be used in the first demos as placeholders for the real brand-new ones.

In the screenshot you can see several models from the "Master Sword" MOD for Half-Life 1. As you can see, the dwarf model is a recycled version of the famous Psionic's dwarf model (you can already find it in a demo of the engine in MS3D format). Then there is a quite naive troll, a beautiful eagle, a frightening wolf and two swords. The MOD is huge in size because of a lot of scenery, but the good models are quite few, so the search continues.

Procedural textures

Yesterday I talked about the different ways the programmer can draw in a texture. Today it's the time of the libraries that define procedural textures, that are those textures useful to generate natural looking surfaces without using real images. Below you can see several examples of textures generated by the TxSynth library included in APOCALYX. The screenshot is taken from the TextureGenerator.lua demo included in DemoPack1.

As you can notice, tuning different parameters, one can generate portions of the Mandelbrot set, wood, marble, cloudy skies, fire or plasma, bricks and so on. Spending a few seconds of CPU time, the programmer can save a lot of memory, because there is no need to store and read large images, instead the images are generated on the fly according to the specified requests. Thanks to the TxSynth library, the procedure is fast and the results are quite good.
Another library with similar characteristics is the "noise" library. Using particular algorithms, among which the famous Perlin noise, several kind of images can be generated.

The screenshot above shows a terrain generated by the "noise" library from the Flying Circus demo. A characteristics that differentiates this library from TxSynth is the capability to generate colored textures with shadows, in fact grayscale images can be interpreted by the library as heights from which the shadows are computed. This feature is very useful during the creation of terrains, in particular when the programmer specifies that the image must be seamless: in this case the APOCALYX engine can render very large or, better, infinite terrains, every time different, because their textures are generated at random.

Draw on textures

One of the recent messages on the forums make me think that most of the features of the APOCALYX engine are not so evident. For example, which are the ways that a programmer can use to write on a texture? Some of them are shown in the second movie of the engine and also in DemoPack1: they are called "Avi to Texture", "Render to Texture", "Graphics to Texture". In the screenshot you can see different kind of textures applied to the same flag.

In the first case you can show an Avi movie on a texture, in the second you can render a whole 3D scene on a texture and in the third you can draw 2D graphics on a texture.
Let's consider the latter: the programmer cad draw on a texture thanks to the LuaGD library included in the engine. LuaGD is simply a Lua binding to a graphic library known as GD. From its documentation: "GD allows your code to quickly draw complete images with lines, polygons, arcs, text, multiple colors, cut and paste from other images, flood fills, read in or write out images in the PNG, JPEG or GIF format. GD does not provide for every possible desirable graphics operation. It is not necessary or desirable for GD to become a kitchen-sink graphics package, but it does include most frequently requested features, including both truecolor and palette images, resampling (smooth resizing of truecolor images) and so forth."
APOCALYX contains other hidden treasures made available for free like this one, so dig deeper into it to find them and... let's draw on our textures!

RPG models

The head to head between Ancient Japan and Middle Earth-like continues. Only a few days remains, but it's already clear that the first RPG based on APOCALYX will be located in one of these two backgrounds. Waiting for a response, I'm already looking for good materials (scenery and models) to create the first demos of the game, in fact I'm going to develop the first tests using ready-made resources, to build only in a second phase the original models and scenery.

MDL models from "Pirates, Viking and Knights"

If the Middle Earth-like hypothesis will become true, I have already some good models from the "Pirates, Vikings and Knights" MOD for Half-Life 1 that you can see in the screenshot, then there are the usual MD2 models included in my Dragon's Ride, that are good enough to replace models on the orcs' side.
I'm looking also for mounted figures, but they seems very rare. I know only one: the Dragon's Knight by Magarnigal that you can see in the first post of this blog. Then I'm looking for some NPC, like blacksmiths or merchants, always useful.
It's a lot of material to be found, but I think that I should create some appealing demo showing the game mechanics, before trying to convince someone to work hard on a project and create new models and graphics. So, if you know any good animated models of japanese or european medieval theme in MD2, MD3, MDL, MS3D, Cal3D, or static models is 3DS or OBJ formats, tell me: I need them.

SOCCER TACTYX Editor

Thanks to the release of the NsEditor, I was inspired and realized that an in-game editor is going to be very useful in SOCCER TACTYX (ST). So I read carefully the IUP documentation, the native GUI included in APOCALYX, and set-up in a very short time a control dialog for ST that includes: the main panel used to choose the properties of the matches, an options panel to set several preferences and a script editor.

The script editor is only a simple text editor, nothing comparable with the script editor included in NsEditor. I mean that there is no sintax highlighting or automatic completion, but at least some buttons to simplify the writing of scripts are available.
This first release of ST is becoming not only a nice game for programmers, but also the occasion to test a lot of engine features that were almost ignored until now.

NsEditor V0.3 released!

Great news from Nout! The last release of his game editor is available for download. Nout says:

NsEditor is a script editor customised for use with APOCALYX + it is a game framework, using entities, strongly tied with the editor. The idea for NsEditor was born about 2.5 years ago. The main driving force was to make it easier and faster to develop a game.
Want to give it a try? Then download the complete package at FileFront. For any questions or remarks, please use the APOCALYX forums, under Tools, NsEditor V03.

In most games, quite some features that are needed repeat. Eg. you often will need a player that can walk around, a weapon, pickable objects, a menu, controllable avatars, lights, moving objects, a HUD, a conversation or text message, collision detection etc. Entities are small pieces of code that own one of these functions and the framework is the core code that makes all these entities to correctly interact. With a rich library of entities, building a small and working game takes some hours (assuming you have the media available) rather then weeks. The framework is open and allows to interleave entities and standard coding.
The main features NsEditor brings are:

• Script editor with multiple editor windows, syntax highlighting and function parameter list preview
• GlGooey skinner build in
• Media previewer build in
• Entity property editors with picklists
• Zip file support (adding, deleting, preview)
• World Editor for APOCALYX (Goto, Select, Move, Rotate, Scale objects + Resize bounding box, top, side, front view, automatic BBox calculation etc.)
• Function and variable lists for all entities, with a goto feature
• A today still very poor working debugger (to be improved in the next release)
• The full framework including about 40 entities, all of them open source

Thank you Nout for this great tool!

Indoor soccer field (II)

Just a short news to let you know that the SOCCER TACTYX development is in progress.
The playfield design by Kr0meel has almost got its final form. As you can see in the screenshot, the ceiling has become more complex and is full of lamps. There are also speakers at the corners (not visible here) from which players can listen at running commentaries.

You can also see the bots running all around, in fact finally they have got a goal in their life: blindly follow the orders of their creators. Actually, the more complex script simply chooses direction and speed at random, so the bots move quite erratically on the field, but I'm improving the sets of available functions. The complete set will include commands to make the bots run, jump, kick, see the field and goals, find the ball, friends and enemies, evaluate the available energy and so on. I think that a real working demo is not so far.