The editor
I have written a few level editors, often only intended to be used with a certain project and once something that was intended to be used a common tool. Often I see it as welcome change and use the chance to work on something else.
For my current project I was conflicted about what to do with the terrain editor. I had two choices, either create a seperate tool or integrate the editor in the game. The first choice always has my preference as a tool and a game have different usage requirements which is reflected in the way they are programmed. The second choice is also a risk in my opinion as you might couple part of your codes that should not be coupled. Decoupling them afterwards is, as many programmers can tastify, a pain.
However the advantage of combining the code is that I don't need to duplicate code or functionality. This is also the reason why I have decided to create the editor in the game. The cool thing however will be I can review the results of my work in realtime.
However before I can start working on terrain editing, I need to write the terrain code, which means that I need to start thinking about the culling acceleration structure and refresh the knowledge about terrains.
Scared to code
The project I'm working on at home is making steady progress. I'm on schedule, the code is of high quality (even higher than I had expected it to be at this point) and as the architecture becomes more and more mature I'm getting more and more optimistic about my goal: A commercial game.
So why, if everything is going so well, do I write an blogpost that is titled "scared to code"? Was I not getting more and more optimistic?
That is because soon I will be done with the majority of the architecture and I have to actually write the game code and to be honest there I no complete design document only an feeling that I want others to have when they play the game. The game design is therefor mostly informal which means that without a formal definition I won't be able to measure how far the game is complete. Now I know there are plenty of people who are able to work that way and get incredible results, but I know that unless I have a formal definition I will continue working on the game forever. So either I have to make a formal game design or learn how to cope work with informal game designs. I don't think I can do the first part as good as I used to and I fear what would happen if I choose the second option.
Now don't get me wrong, I have worked in both ways and got results. I do prefer formal game design as they are more predictable and it is easier to know what is inside or outside the scope of the project. The problem in this case however is that I have decided on a hybrid method. The game should be developed until the end of Juli which means that somewhere in August I need to release the game, as this is one of the restrictions I have applied on the project. So what I at least have is an schedule and I'm happy to say that I'm good with scheduling tasks and projects. However I have never made a schedule without having a formal definition of the end result of the product. It's not the way that I usually work and most certainly not the way that I prefer to work.
Writing a decent engine is pretty straight forward, there are some things you need to take in account, but if you have written a few, than writing a new one is more like a warming up then actually trouble. Each game however is a different so there are no warming ups. You might be able to use a few tricks that you have used for other projects and use it here, but overal the code is completely new. Now next to me is a single piece of paper on which I have written the schedule. The schedule is quite decent but at the moment I'm afraid of moving on to the game code.
The strange thing is however that once I start working on the game code, I know that the fear will disappear, but until then I'm scared to death, uhm.. scared to code. 
Only one more day
Tomorrow I will be defending my graduation work and if all goes well (it must be a strange turn of events if doesn't go well) I will know if I have completed my graduation.
Only one more day 
Nova’s Achilles heel
Nova’s Achilles heel is the math and a lot needs to be improved there. Instead of attempting to improve I thought I would use a high quality math library instead (in this case vmmlib). Using SVN external I added it so that it would automatically fetch the latest version from their SVN and be done with it. Problem is that I’m using DirectX which uses row major matrices and vmmlib was written to be used with OpenGL which uses column major matrices. So after a huge rewrite and removing the old math headers I tried to run Brick and see if it worked, I had hoped that by setting the effect files to use column major matrices I would let it use one system. Seeing the result, it either didn’t work or something else had gone wrong.
I don’t know what exactly went wrong (besides the obvious) but I guess that instead of using another library I just have to finish and improve my own math library. It’s a good thing SVN allows me to revert.
A good math library is essential for a game developer. It has to be easy to use and clear but I also want answers on the following questions when I’m using it:
- When I define a quaternion is it written as W-X-Y-Z or as X-Y-Z-W?
- Does a multiplication operator between two matrices do a matrix multiplication or an unit multiplication?
- Also how safe are the functions?
- How do I prevent hidden cost?
- And how easy is it to cast from one to another? Vector3<float> to Vector3<int> might seems obvious but it requires code to support it. And I could also cast Vector3 to Vector2.
Then there are the bigger question about optimization, like do we use SIMD or not.
The biggest problem is of course to ensure that all math is correct. Most of the time I use it by instinct, but in this case I actually have to relearn all the math again, double check, ensure that I’m using the right version, triple check. Obviously I experience it as a pain, but it as they say:
No pain, no gain!
Brick4 in week 10
Well, the major glitches in the building creation system are finished. The graphics also look nice now. Anyway a picture says more than a thousand words in this case.
Nova – Alpha 1
I have given Nova, my graphics engine, a milestone named “Alpha 1”. This means that the engine will need to fulfill certain conditions at a certain time.
The good news is that I might release it to the public for free (including source) if I find the quality good enough.
I have been using Nova for quite sometime now for my graduation project and except for a few small issues (the math part is not to my liking) I have absolute no issues with it. This is rare since I tend to over criticize my work (I once argued with my teacher after getting the highest possible score because I felt the need to point out the mistakes I made).
If your expecting a fully fledged engine with scene graphs, model loaders and million of other features I think I will have to disappoint you. Nova was intended to be an engine that was in the first place easy to use and in the second place was flexible. At the current state it is a perfect engine for rapid prototyping and highly specialized low level work. But that might change with later iterations. After all this is only the first release (an alpha to boot).
Anyway I will post more information about the possible release over time. The milestone for now has been set on 1 may of 2010.
Brick4 @ 90%
Guess the title says a lot. Brick4 (my graduation project) is nearly finished. Actually I wanted to say it was completely finished but as things goes there are quite a few minor things that need to be done. Also there is a good chance that while writing the paper (which will have my main focus besides the graphical improvement) I come across some new ideas that I feel I must implement. Even as I’m writing this entry there are quite a few ideas that I’m thinking of however finish the paper takes a higher priority.
Another course at school has recently contacted me about the graduation party and although I don’t often go to parties, I’m looking forward to this one. Also because there is a good chance I will be holding a small speech. I'm not shy about being in the spotlight. I know that some people don’t like it but personally I always find it enjoying. The only thing I worry about is the fact that I talk too fast
Maybe the Dutch proverb “Good things come fast” applies to me, after all, I’m currently way ahead of my schedule 
Brick3 has become Brick4
Brick3, my graduation project, will be no longer developed and instead I will be working on Brick4.
The reason I abandon Brick3 is because the system has become too hard to maintain and there are too many pieces of legacy code around for me to quickly improve it. On top of that Brick3 was the first incarnation of the Brick project series in 3D with some advanced features, the new way of memory management (a 37 MB instead of 2 GB). So I had expected I would need to rewrite it, even though I wanted to avoid it.
Brick4 will have unlike its predecessor cleaner code a new way to some things (XML instead of custom file formats) and it will make heavy use of the command and strategy patterns. This will allow me to developer faster and safer in the long run, although I fear that rewriting the application will have an heavy cost and that any advantage I gain will be lost to that.
The good is that this will allow me to revisit some off the old features and make some notes and see if I can improve it.
If I’m lucky everything should be rewritten at the end of this week and with even some more luck I will also have implemented a new feature. Guess time will tell.
Information about Brick3
Brick3 is the third iteration of the grand project I decided to call "Brick" and I think I have mentioned it quite a few times before, but never gone in to detail, which is the reason for this post.
I'm from the IT sector and one of the things I thought myself early is that the computer should work for me and not the other way around. In the Netherlands IT used to be called "Automation" but I'm not certain if many people still know that or try to write programs by that principle.
In the game industry we have something called procedural generation (also known as procedural content generation) which is letting the computer generate the content in game. This can be music which changes depending on the amount of danger the play can be in (adding rhythmic drumming) or textures which are generated by the computer instead of an artist. Those are all examples of generating content by the computer instead of by human.
Any process can be fully converted to logic and any logic can be programmed. A computer can be used to execute any process as long as I'm able to convert the process to logic and program that logic.
-- Wouter Lindenhof
The above quote is mine. And what I'm saying is that in time a computer should be able to replace any human, although I don't that to happen in my lifetime (and I'm young).
However the above quote is what brick3 is all about. The earlier examples were all based on the fact the design was done ahead of the actual content generation. After all the music was composed and the texture that was generated was most likely done based on an algorithm. An example for the last one but then for a mesh can be found in this blog post Donuts! (Procedural Torus in C++).
Brick3 is a bit different as it wants to let the computer do the design instead of you. It tries to generate a flat and based on requirements (you don't want a toilet in your living room) it will place the location of rooms and places the objects (lamps, light switches, paintings, trashcans et cetera). If you would use that in game like for example Grand Theft Auto you would be able to enter every house and assuming everything works correct you would have a fully designed interior while as a programmer (or artists) you hardly have to do a thing.
Anyway since a picture sometimes says more take a look the following screenshots.
This screenshot shows the minimal graphical quality I want to have. Graphics are important as they play part in deciding whether or not to buy a game. Besides that it also says a lot about the level of finish and the dedication put in the product. Although walls appear to have depth, they are flat, but using some smart programming code an illusion is created and when you look at the next screenshot I think everyone will agree that high graphical quality is a requirement for this application.
This screenshot shows the current state of the application. You will see that everything has a dummy texture and you will notice that not all walls are attached (this is because that a door is not generated and once it is does it will show a nice door frame). Both rooms have the same function and the big room that is directly in front of the camera is a test room (it is 27 by 27 by 27 meters big).
Besides the obvious issues the application is reaching its completion. There are some minor issues with placement and I need to improve the performance at some points but after that I only need to add some new models (the furniture is not procedural generated) and I will give some extra requirements and the application should design a room according to my specification.
Although I have to admit it doesn't look like much at this point, I think many people will be surprised once the end result is ready. Not only will it be able to generate fully random interiors of flats, buildings and rooms but it will do so as if it was designed by a human and only I have to do is hit one key to generate a complete new result.