• ### Blog Entries

• entries
12
12
• views
8365

Current project: Editor for my 3d action game.

## Picture of my editor!

Well, as promised, here is the 1st image of my game editor (called "Constructor"). It's a Java app running under 64bit openSUSE, using JOGL for rendering and Rhino for scripting.

Yeah, there's lots more work today. Please excuse the random models that have been stolen from the net.

## Another Game Editor update

Managed to do a load more work on the game editor this weekend. God-damn Java is a cool language. Managed to massively improve the UI AND add scripting support in just a few hours. Java SE 6 comes with Rhino for scripting.

I love it when editors have scripting (see Maya, 3ds Max, Blender for examples). In my game editor - every action that can be performed by the user can be replicated via scripting. I think this will be especially useful when adding undo/redo capability to the editor. Say the user moved a mesh in the scene (from [0,0,0] to [10,0,0]) - then the script to translate a node to position [10,0,0] is added to the redo stack, and the translate to [0,0,0] script can be added to the undo-stack. Not sure if this is the way other 3d editors do undo/redo stacks, but is seems sensible to be. Also means that the undo/redo stack can be saved with the file :D

## Been too long!

Oh dear - it's been way too long since my last entry (over 2 months).

Real life just got in the way :)

Got quite far with the game-editor. Instead of using SWT decided to use Swing for the GUI. Works out quite nicely when using it with JOGL (I should probably post some screenshots). You can place meshes and edit the properties - still lots to do though.

Also moved over to use netbeans as the my IDE of choice for Java and C++ development (from Eclipse).

## Eclipse oh no :(

Well after trying the new version of Eclipse, I gotta say I'm pretty disappointed. The new features are cool and everything, but it's really unstable on my PC (openSuSE amd64). It's so unstable it's difficult to get any work done. I mean 3.2 crashed every now and again, but 3.3 crashes every 10 minutes.

Tried to start work on the 3d editor that will be used to construct worlds and models from meshes. I'm planning on using SWT (the crossplatform GUI that is supported by Eclipse) and JOGL for 3d rendering. SWT is pretty sweet for GUI's, for example check out:

Azureus
and
Vuze

## New Eclipse

Wow Eclipse 3.3 is out - sounds like a few improvements have been made to CDT (plugin for C++ development). I'll probably give a quick review of it later after some playing.

I've implemented Cg support into my engine (for shaders) - so along with OpenGL, it should allow the game to run cross-platform without too much difficulty.

As someone who works for a large professional games company as the "shader guy" it always bothered me how "fiddly" shaders can be to write. The games teams end up writing loads of shaders that are only slightly different from each other.. but if a change needs to be made across all the shaders, then someone has to manually go through each one and make the change.

That's why I'm taking a slightly different approach with my game. I'll just knock up a simple Java command line program that procedurally generates the shaders (and all their permutations). Sure it's not as flexible or artist-friendly, but I think it will get the job done. So for example if a shader needs to handle 'x' point lights and 'y' directional light, then the Java program will create all those combinations for you.

er, anyway...back to work.

## 3d engine

I've had a slight change in direction for this project. I *was* going to 1st create a 3d engine and then make a game from that, but I do think this will take too much damn time. There's plenty of engines out there and the reason I chose not to use them was because I wanted to learn and I've never been satisfied with any of them. The engine I was planning on was to be quite generic, in that it could handle any game type (fps, racer, flight-sim, etc). Thinking about this some more, it does start to be a bit too ambitious.

So now I'm going to concentrate on the game a bit more, writing generic code where possible that will go into a "game library" for future use. At the end of the day it will be more interesting to work on i think.

The game is to be a 3rd person action fantasy game. I have quite a few unique ideas about how the animation and combat will work. I'm not planning on doing the artwork myself.

Of course, this is all thinking into the future, as presently I have to get the groundwork laid.

==Progress update==
- Finished Lua script helper class. Makes it easier to deal with the Lua API.
- Lua scripts are processed in the builder command line tool. Uses luac to check for errors.

## Coming along

So my 3d game engine is coming along nicely. I've got the whole pipeline working from art creation applications to the game engine. Ie, meshes from 3dsmax/Maya/Blender can be exported, then processed into efficient binary files, then loaded by the engine and displayed using opengl.

Then I got thinking about using a scripting language for various aspects, and after lots and lots of surfing the internet, came to the conclusion that Lua was probably the best choice. Scripting is an excellent option to describe the game worlds. In the previous post I mentioned using XML to describe the worlds, but felt Lua would do a better job. The "world editor" tool that I'm yet to write can then simply generate Lua code.

Lua was originally created to be used in configuration files, so I think this is the right choice.

Anyway, one day I'm going to post some screenshots, but I think creating some well conceived "groundwork code" will result in a better engine in the long run.

## 3d file formats

3d file formats:

Something that I've always struggled with is choosing a good 3d file format for games. In my programming life I have used:

*vrml
*3ds
*x
*custom format
*obj

That's the order in which I used them. Here's what I think of each one:

*vrml - quite alot of 3d apps can export vrml. Many don't do a good job. It's been some years since I last looked at this format, and from what I remember there was loads of features which weren't relevant to 3d games. I think it supports weighted bone animation.
*3ds - an old format with no weighted bone animation support. It's well supported though - almost an industry standard.
*x - specific to directx, so using this format in opengl is a pain. Very relevant to 3d games though and seems to be well supported
*collada - a new format in xml, that is attempting to be the industry standard for interchange between 3d apps. You can use "fcollada" to read/write the files. The format is attempting to support "everything".
*custom format - i wrote my own exporter for Blender3D, which used xml, was dead easy to import, and supported everything I needed. However if I wanted to use another 3d app, then i'd have to write an exporter for that one.
*obj - probably the most widely supported format out there. Doesn't feature hierarchies or animation or per-vertex colours (!!), etc.

It's always difficult to try and shape the non-custom files to your own requirements.

Currently I'm using the obj format - which doesn't allow for hierarchies or animation. You may ask then that that's a strange choice given my rejection of the other formats. My idea is to have 2 files:

*mesh files
*model files

The mesh files are the obj (or similar) files that simply describe the mesh data.
The model files reference the mesh files, and provide additional data - such as the hierarchies, behavior, properties, etc. The model files can simply be xml files, and can initially be authored by hand. Later on I'll obviously need some editor for easy construction of these files. The great thing about this system is that it can be used for both models (cars, characters, etc) and worlds/levels.

eg.

   car_body.obj   100] posy=[0] posz=[100]>car_wheel.obj   100] posy=[0] posz=[100]>car_wheel.obj

In the above example, in though there are 2 car wheels, I'll only need to load the car_wheel.obj file once.

## The name

In case anyone is wondering about my name "Orbital Fan" - then this may (or may not) be of interest:

-Orbital are (were) a UK techno band consisting of 2 brothers:
http://en.wikipedia.org/wiki/Orbital_%28band%29
-You probably didn't know it but you've probably heard their music in one way or another (quit a few films and TV programs have used them)
-The Dr Who remix has to be heard at an extremely high volume
-The track "Belfast" makes my spine tingle
-Yes, I am a fan of their's.

I love electronic music in general. Here are a few other favorites:
-Banco de Gaia
-Simon Posford (Hallucinogen/Shpongle)
-Dj Fresh
-... and 100's more

## Improving builder performance

So my asset conditioning tool (which I've just called "Builder") is kinda slow when loading obj mesh files. It uses Java, but I don't think that's the issue. The slowness is coming from the vertex indexer, which requires running through all the vertices of the mesh many times for each vertex (so it can compare it self to other verts).

I'm guessing i have to use some form of hashing here, but I can't quite get my head around how this'll work. My algo goes something like this:

	// go through each vertex	for (int i = 0; i < vertList.size(); i++) {						duplicateVert = findDuplicateVert(i);			// snip ...			}	// snip...	private int findDuplicateVert(int listPos) {				Vertex cmpVert = vertList.get(listPos);				for (int i = 0; i < listPos; i++) {						if (vertList.get(i).compare(cmpVert) == true) {								// found duplicate vert				return i;			}		}				return -1; // means we didn't find a duplicate vert	}

As you can see it'll spend alot of time in findDuplicateVert() doing compare(). For large meshes this is an issue. The compare function tests whether 2 verts have the same xyz,uv coords, etc. I've never really used hashing functions, but I guess I could use the x coordinates as they key... just to reduce the number of times it goes through the list.. Are hash functions able to have multiple keys? Would be cool to be able to use the xyz coords as a key. I'll have to investigate java.util.Hashtable.

## Progress so far

Well, this is the progress of my engine & tools so far:

*Started 'conditioner' tool : this is a java command-line program which i've just called 'Builder'. It takes my textures, meshes, etc which are in typical file formats such as jpg, obj - and it writes them out to a binary file which the game engine can very quickly load. I think this tool is the most important one of the bunch as it's the way to make fast file loading at runtime, and can also aid in maximizing performance of the game resources. eg, it indexes triangle lists, etc. This is far from finished, but being in Java I find it doesn't take very long to add new features. Every asset that you want in the game will need to run through this tool.

*Game library : this is the bulk of the work, and is there to provide typical game/3d/engine related helper classes and functions. It's in C++ and uses SDL with OpenGL for rendering. I've got the basics going...

*Game framework : this is where all the actual game functionality would go. It's pretty bare-bones and the moment and simply opens a window with a 3d mesh and handles fly-cam controls.

I think tools are VERY important in game development. It's not all about a snazzy 3d engine that does 10000000 triangles a second. The tools for my engine will most likely be command-line based because:
*Hate making GUIs. My day job involes making game tools with a UI, so I don't want to do it at home.
*Encourages the use of scripts for batch-building.

## 1st post!!!!

1st post!!!11

Well yes this is the 1st post into my development journal.

What the hell I'm I developing you may ask? Well, yet another 3d game engine. Mostly because I'm interested in the subject - and I have dreams of one day making a polished game with it.

If anyone cares, here's my development tools:

*Linux - openSUSE 10.2 : because I can
*Eclipse : for Java programming
*Eclipse with CDT plugin : for CPP programming (my main language)
*GIMP : For programmer's art
*Blender3D : For more programmer's art

Hopefully posting here will be a regular occurance.