Skip to content

As of today, th…

June 19, 2012
by

As of today, this blog has become an archive for what was done early on in the formation of xpod games. For future information on xpod games, please visit our website.

14 days of Akaldiroka – Day 5

August 12, 2011
by

As you read last night I was having issues with the file format, so tonight I concentrated on integrating the new one into the engine. One thing I discovered, is when I went to connect a relationship between the loaded object, and the GL calls, it made alot more sense
to build the presenter within the actual class. So after 3 hours of tinkering, I dropped the old mesh and vbo routines, and gave the new system a go. Woha 100mb I saved on memory consumption! It seems that this way of doing things suits the application much better, without really doing anything more than having a cleaner mesh class and hiarachy for the entities/presenter model.

As that has consumed most of my night, theres not really much more to blog about today, though I just wanted to take the oppertunity to thankyou all for keeping with me over these two weeks, It’s such a motivator to know you need to explain what you did each day, and actually I think that has possibly aided me crack some of the problems that were becoming slightly epidemic.

Tomorrow i’ll be seeing what I can do to clean up the scripting framework, wich will hopefully provide some decent overload’s that enable singular declarative instancing. Thus much smarter scripting.

Aimee.

14 days of Akaldiroka – Day 4

August 11, 2011
by

Ok so tonight im working out how to get a solid collision detection system using the tools I have created, already we have two bounding volumes to act as a range to limit the calculations we have to do, and also we have a function that provides brute force collision detection.

So now comes the tricky bit, where and how to use it. So far I have determined that having a function within the entity manager that takes the key of an entity is the best way to go.

Something happened at 1am this morning that really threw me a bit, currently we are supporting the wavefront obj file format, and everything is great ‘n’ all, but it’s actually a fairly messy format to deal with. So unfortunately I decided perhaps it’s best to create one fit for purpose. 3 and half hours later, ive finished, and wow using tricks from the TiledMax project such as XML and GZip really payed off. Even though there is a slight bit more padding in the structure, thanks to the fast compression, I’ve managed to make the format (which i dubbed .m3d, or mesh3d) which has the same speed performance, includes light mapping information, incorporates material data inside the same file, animation frame indecies where appropriate, and is far more easier to read than wave front OBJ files.

I know what your thinking, but what happened to the collision detection? Well as the file format issue set me back a few hours, it’s gotten a bit late, so i’ll have to postpone it till tomorrow. However I did manage to write the function that tests for collision detection. Looking at it without any tests, it looks like it should be fast enough, it uses the BoundingBox and a sensitivity measurement to detect near triangles only, then tests to see if the triangles facing the movement direction have ray’s that intersect triangles in the sensitive range, and report back the result. Obviously this is a little different to more preferred ways such as octree’s and bsp, but as collision detection is entity dependant in this engine, a fresh design was warrented.

Thanks for following, and I’ll update this blog again tomorrow!

Aimee.

14 days of Akaldiroka – Day 3

August 10, 2011
by

Tonight I started the process of resolving missing features that the engine should have in order for the game to be easily scripted, the main one I have been focusing on included hopefully debug free AABB collision detection tied into the entity system.

So I decided to design a BoundingVolume class that dynamically creates itself based on the mesh data found within an entity. Thinking about OOP priniciples, it seems sensible to have such an object coupled with the actual entity. Heres a doodle I did
to setup the bounding volume generator:

I worked out that as long as I knew the minimum and maximum of each dimension (X,Y,Z) based off the geometric data, then it should be quite easy to define the vertices for the bounding box, and guess what… took me 5 minutes 🙂

Now onto collision detection… OK so this is not the subject i’m most fond of, so it looks like i’m going to have to do some research on the subject. Either way though, I can’t imagine things being so hard as we have everything we need within the entity manager to be able to do such a thing, question is, should this be something the  engine handles automatically, or should it be something the script handles.

After 2 hours, and the knowledge I already have on the subject, it seems I have a  solution for it, as only certain entities will need collision detection, I’ve added a flag for it, those entities that have collision enabled now provide a bounding volume, and a 2nd one that is one unit larger so that detection is only preformed within a small range. Also I found a ray-triangle intersection algorythem that seems to fit perfectly with this method, so in the morning i’ll be applying it, and testing the jig to see weather we did good 🙂

14 days of Akaldiroka – Day 2

August 9, 2011
by

After spending a short while considering weather or not to have an seporate Entity property in the Scene class for the level mesh, I realised that it will always be better to host these in the entity manager it’s self, theres no guarantee that a level will just be one big mesh, so allowing the entity manager to deal with that dynamic, means that there won’t be a jumbled mess in the scripts working out weather to probe the entity manager or something else… what was i thinking lol!

On a side-note, I’ve added a constructor for the Scene objects so that scripts associated with a Scene can be loaded in-line.

Just had a breakthrough, after playing with the idea of allowing seporate definable scripts to handle their own render events, I finally found a model that works. From now on, if a script file wishes to handle a scene’s events, it must declare an overriding class named ajsCurrentScene, and provide internal functions OnFramePrepare and OnFrameRender. As this conforms to the engine’s state model, it is ideal for giving the script a true object orientated environment, and to be honest has left me relieved, and a bit more confident in the choice we made to use the JavaScript engine in the first place.

Note to self, as scene’s now use this model, it makes sense to only have a constructor that accepts a scene javascript definition file.

14 days of Akaldiroka – Day1

August 8, 2011
by

This week I’ll be posting each day, notes that normally I keep to myself about the development of Akaldiroka. I use these as a sort of developer diary, providing me with historic knowledge of decisions I made, why I made them, and what implications they possibly have to the final outcome of the game. Sometimes they may seem a bit jumbled, but hopefully it’ll give you an insight into what kind of work we do, and how deeply we are considering things during the development cycle.

Day1

Today I realised that perhaps things that I planned to delegate, will have to be done more close to the chest. Still at this point there are parts of the engine that most likely need work on, including a suitable set of cameras, and perhaps a way to catch callbacks.

After alot of head-scratching (and no i dont have nits), I decided to finish the scripting system by ensuring that events are fired properly. Interestingly I descovered a problem that was giving me a bit of a headache, the Noesis JavaScript bindings based on google’s V8 system stay very strict to the one context per process rule, so whenever i tried to create multiple instances of a JavascriptContext class, It would destroy the original context and fail miserably.

On top of that, when I moved over to sticking with one single context, I was still getting errors. Thanks to someone elses post in the discussion area on codeplex, I found that while the context is executing a Run() command, no others can be ran at the same time. So I decided to add a queuing system, which turned out quite well seeing as Apollo3D is afterall encapsulated within a tight loop, checks to see weather the context is free so that the next Run() command could be called was very simple.

A note to myself, the ScriptBuddy class has many methods at the moment that really should be placed instead within the ScriptNewHandler class, this would make for more consistant scripting, as they would instead appear within the ‘create.’ global parameter. Also as deep scripts are no longer executed in call-time, instead queued, there will have to be some documentation to explain this type of async model to those unfarmiliar with the concept.

Hey All

May 19, 2011
by

It’s been a while since we had a post, but lass we are not gone lol. It’s been quiet recently as people have been busy working on graphics, and so forth. So as we need to make sure we keep you up to date.

Recently, we have been playing round with the idea of incorporating 3D elements into the up-comping title Akaldiroka, however as always, along a route as such, many factors come into the light when deciding what works best. So this week we have settled on using a custom build parser for the X3D format, we feel it’s exactly what were looking for, and here’s a few examples of it in action:

Toodles!