Merlz (Josiah Walker)
Here is a brief compilation of my thoughts on AI for characters/actors in games.
Learning method: many learning methods depend on the model used to represent the AI choices. In addition, complex models can often hinder training by not moving toward the solution in a natural or uniform way.
Following some discussions on IRC, it has been decided that for the time being automated unit responses and AI (such as patrol, auto-attack, and auto-repair) will be kept server-side. This should reduce lag responsiveness issues for players - which can be an issue in quite a few games when playing online (especially if your housemates like downloading the internet).
Currently there are a few bugs, but the general idea is to hold queues of commands server-side for execution. This should mean that you can continue queueing commands for units in the client's UI, and the units will execute their queue regardless of whether your client is hitting lag spikes or not. That might not sound like much, but if a client supports this explicitly (say with a modifier key) you could do neato things like specify a kill order in a fight and then tell the units to regroup somewhere else afterwards.
I think that for game developers, using parametric movement and modelling is something of a golden egg - it allows infinite resolution of positions for timesteps, and makes a whole bunch of things really easy to handle. This is great, but as I learned when I tried to create a parametric physics engine, you can't really track collisions and deviations from the current course parametrically. Actually, I did manage to integrate asteroids-type control (arrow buttons for thrust/turn) parametrically and that was pretty cool. It was also a nightmare to debug, and slow because of sin/cos. So I had a better idea.
I have uploaded the source for version 0.1 of the kruel map lib here. This creates and weathers height fields and has been the source of all the pretty pictures I've been uploading recently. The pictures themselves are rendered with scripts you can easily google for POVray/megaPOV
I've previously blogged about the thermal erosion process this uses, but map creation is now also covered. This is a very very simple process. I define a random point a inside the heightfield. I then define a random 2D vector v in the range [-0.5,0.5]. The height added to point p is dot((p-a),v), clamped to [0,1]. This is a variation on fault line mapping (another variation and more explanation can be found here).
While reading through some background papers for terrain creation I stumbled across a very interesting idea:
"Newly formed terrain is more clearly fractal in nature. This can be demonstrated in that fractal terrains look similar to themselves when inverted. As terrain is eroded, it becomes more familiar to us." (not an exact quote - there was a whole paper describing this phenomenon)
After testing out Py++, and getting a whole bunch of bizarre C++ code and compiler errors, I've come to the realization that Py++ was not really made to generate UI-driven interfaces. I think it will be very useful to automatically wrap parts of our interface like the server/client messages, but not so useful to create a full UI.
One reason for this is that Eon-UI takes control of its execution thread and only passes control back to the client occasionally. This is what Python also wants to do to libraries. They fight. I am currently thinking that it might be best to create a python class that can start its own thread to interface with our C++ program. The class would initialise an Eon-UI that stores its client-side data in pythonic objects. The python class would do this in a separate thread, and pass itself into the C++ code. The pythonic data objects would be added to this class inside the C++ code (inside the main client side loop in fact).
I have recently been looking into the generation of terrain using tunable parameters. After some difficulty with matrices, I discovered POVray has perfectly suitable perlin and other noise functions for generating heightmaps. POV's noise appears to be deterministic too. I'm not 100% sure about the ability to adapt to spherical and other shapes, but I think using a 3d perlin field might work. I think this solution is neat, since POV is free and easy to use. It doesn't sidetrack much effort to develop these scripts, and it's a legitimate and useful content creation tool for multiple projects.
So I'm looking at some python bindings for eon (for AI and maybe other things). I stumbled across this blog, which deserves posting:
The draft storyboards have been drawn up for the operation of the M4 user interface additions (allowing to edit units - a big one!). From this, we need one more widget implemented in the system. The widget needs to be a list of buttons that can scroll, and it needs to translate mouse positions for buttons positions like a pane. The scrolling part should use a pair of arrows (or possibly up/down keys - but this might be too complex atm) and have a listener it calls with the current scroll position on change.
At the last K gathering, I managed to comment the majority of the SDLGUI code. All functions should be commented (except for a few that simply overrode virtuals) but internal variables are still todo. This should make it relatively easy for new people to pick up the code and start building extra interface bits and pieces themselves.
I'm aiming to finish the documenting sometime in the coming weeks, but am unsure when I'll have the time to do so at the moment.