Code Progress

I am posting to drop like a bomb some of the source code I have been working on for the Enginue project. People other than coders will not find this release to be of any interest, but the basic skeleton of a game engine is coming together. The posted source code includes the seeds of a game engine, a simple console based lua interpreter, and the base class from which all Task objects (the basis of activity in Enginue) will derive, including a simple task Simple_Lua_Task with a lua, object oriented interface allowing for the instantiation and automatic garbage collection of C++ Task objects using Lua's garbage collector.

Things which still need to be done/immediate areas of progress:

1) Documentation

2) Engine/Thread integration. I should consider this carefully since I expect to eventually convert the console based console into a virtual/graphical console which can be accessed from inside a game session. I may need to think about that now.

3) Further refinements of the interface traditions so that they remain manageable for more complex tasks.

I think, generally, that I will work on enough Task types for a Tile based game engine first and then turn my attention to the more complicated problem of physics based games with ODE.

I am growing to appreciate C++ as I work more and more with it, but I do have the following gripes: the first is that there is no ANSI standardized way of dealing with console input in any kind of sophisticated way. This leaves me unable to write a nice interpreter without running the risk of endangering platform independence. This is a good reason to move to an internal console, despite the added complexity involved.

I still feel that C++ just misses the mark with respect to several programming techniques. In addition to being extremely verbose, C++ offers the possibility of higher level programming without most of the power. Sure, there are methods which let you map functions onto containers, but without anonymous functions, they are not extremely useful. There are other things like this, where you feel as though you are almost, but not quite, able to make use of a high level idiom. These annoyances remind me of my desire to make the lua wrapper thick around simple c++ code, so that I can make use of the abstractions that Lua gives to the user. For the remainder of the code base, C++ is turning out to be tremendously more convenient than C might have been for what I am hoping will be similar performance.

The code as it is can be found here. Lua is included along with a copy of its license. You need scons to use my automatic building process. If you have it installed, then simply navigate to the enginue directory and type scons. My code is published under the GPL for now (a copy of which is included in the source directory) and the other packaged softwares (lua, ode) are licensed under their native licenses. If anyone with skillz is reading this, let me know what you think.

.plan

The engine has a clever name: Enginue (pronounced ingenue). Its using an extended Lua interpreter, which we might even call Luanne just to keep with the feminine naming conventions. I would like Lua to be a rather thick wrapper on the very thin, simple C ++ code. A typical session would go:

[Launch Enginue]
* Enginue executes autoexec.lua
* This configures the screen, starts up the naked engine, registers a splash screen task

at this point autoexec would 1) pass control to another script which sets up other tasks or 2) call a function called enginue.console which will give the user a command line console. The user should be able to do things like:

>> print(engineu.ls_section_types());
['ODE','classic']
>> s = enginue.section('ODE');
>> s = enginue.activate_section(s);

These two lines should create a new section and make it the active section. A section corresponds to a single continuous area in blue_arizona (or any other game). A section should be of extensible type, that is, we should be able to support many different kinds of sections. Tile based sections, with tile based collision detection, and ODE based sections with ODE based collition detection, should be the first supported. We should be able to do things like:

>> polygon = { xpts = [0 0 1 1], ypts = [0 1 1 0], visible=true, type=SOLID };
>> id = s:add_polygon(polygon);

And a nice, blue, solid polygon should appear in at the position which you set.

The interpreter should expose placement of objects, their types, how they interact with the physics engine, how they react when collided with (which I think will be decided via Lua scripts)
the placement of the player, what abilities the player has (powerups), perhaps whether the little man is in the ship or not, if we decide to go that way. You should also be able to do something like:

>> callback = { toid = id; section = s; function call() { p = s:rm_polygon(id) } }
>> polygon2 = { xpts = [2 2 3 3], ypts = [2 3 3 2], visible=true, type=TRIGGER, callback = callback };
>> id2 = s:add_polygon(polygon2);

So that triggers, which are handled by the engine, be written in lua and registered with the engine. This way, its even possible we could write C++/C scripting functions, compile them, link them at runtime with Lua and do something like:

>> fastscripts = loadlib("fastscripts","lua_open_fastscripts")
>> polygon2 = { xpts = [2 2 3 3], ypts = [2 3 3 2], visible=true, type=TRIGGER, callback = fastscripts.cpp_callback };

Thats enough for now!