PGD Home

I have now moved on to the actual Game World Creation. I am using a similiar system to “Astral Realms”, my previous virtual world game, except I am writing it from the ground up for this project.

I am storing all of my world object in a database, not a mission file, this will allow me far more control over them, and is essential in a persistent world game like this. I am, for now, going to simply going to query the database for all of these objects, send their data to the client, and draw them. In future, of course, I will need a very complex optimisation algorithm. My experience with Spherical Terrain has taught me that this will likely be difficult. The easiest thing to do would be to return only objects within a certain distance of the player, however I am not sure how this could be done with an SQL table. For my previous project, I used a zone-based system, where I would calculate which zone the player was in, and return all objects in that zone.

This worked ok, but this could cause problems if the player was standing on the border between two zones, or if a zone was very heavily populated with objects. I really need a distance-based optimisation system, similiar to what I was trying to d with my spherical terrain system. I am sure I will figure something out eventually, for now however, I can simply return all objects.

I did run into some slight issues when working on the world creation code, however. The database connector code that I implemented is missing a data structure to return a set of results from c++ to script. This will need to be implemented, and it will need to be fast. I could have several hundred results coming from the database server, and I need to be able to access them easily from script. I also noticed a bug with the database code when one of the database fields is null, this will also need to be corrected.

I do have a working populateworld() function, however, which selects an object from the database and creates several instances of it in the world, in random locations, then adds those locations back to the database. I am using raycasting to make sure the z position of the object is always on the terrain.

I also set up a dedicated server and tested it on my development machine. I will likely use a single executable for the near future, since it is much easier, but I wanted to make sure there would be no major issues with regards to implementing a dedicated server.

I am using simple test objects for now (just textured spheres) because I want to get the concept working first, before I spend any time on the art. I have, after some effort, implemented collision on the staticshapes that I am using (Collision is easier to implement on TSSTatics, but they don’t support the guishapenamehud, which displays a very useful text box above the shape).

Finally, I began implementing the context-sensitive menu that will allow the user to interact with the world. I will again use raycasting here. The user will select an object, and a list of its supported actions will be displayed on screen (having been read from the database). The user will then be able to select an action, and that selection will be sent to the game server where the actions effect will be implemented by the behaviour scripts. Before I can finish this, however, I need to add quite a bit more functionality to the database connector code.