Limegarden.net » Procedural

Brick4 in week 10

Wouter Lindenhof — Mon, 29 Mar 2010 12:29:08 +0000

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.

Brick3 has become Brick4

Wouter Lindenhof — Tue, 09 Mar 2010 07:04:41 +0000

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

Wouter Lindenhof — Sat, 06 Mar 2010 08:30:37 +0000

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.

Procedural story

Wouter Lindenhof — Mon, 25 Jan 2010 02:01:47 +0000

A little while ago I was meeting a good friend of mine and we had a lot of things to talk about. For one he had just returned from Kenya and he had a lot to show and tell and the things he told me where amazing. But as the day went one, we almost always seem to come back to one subject: Games and developing of games. Funny enough the two of us have almost had the same kind of ideas.
Both of us are developing games in our free time and both have the idea of trying to make as much as possible procedural generated. One of the things we are both interested in is creating the story. While I look for an infinite solution (where the player can play forever and has an interesting storyline) he has a more pragmatic approach.
As we discussed procedural generated stories he pointed out that a story teller needs to tell his audience what happens where and when (not to be confused with why). This triggered a thinking path I had not yet explored. Until then I had simply assumed events happen in a certain order. When a user is playing a computer game he will grow a certain emotional attachment to the player. Emotions in a story are important. For example Romeo and Juliet is a story about hate between families, love between two person and has a lot of betray. Romeo and Juliet is considered one of the classic romantic stories and by some it is considered one of the most romantic stories ever written.
So after the talk and some thinking a procedural story generator could be written as a system that tries to move from emotion to another emotion both for individuals as a culture. To give yet another example: The player gets betrayed by a general and while he was betrayed the general does end the war (and the country he fought for sees him as a hero), while at the other side (the defeating side) wants to see the general death. You now have four elements: The player, the general, the winning country and the losing country. The player is angry as he is betrayed. The general is content and pleased as he is being seen as hero. The winning country feels superior to the losing country and the losing country feels disgust towards all other elements. See the diagram.

At this point the computer needs to "write" the next part of the story. The computer could now plot a new scheme by just adding or removing some story elements. The player could for example become the leader of the rebellion or he could join the general as one of his right-hand leaving his feelings of betray or he could kill the general and become the new general. In this case I want to add another character say the princess of the winning country and make the player the leader of the rebellion. The princess finds out that the generals betray and for some reasons she encounters the player and they fall in love with each other. Yet they can't be with each other as one country hates the other ruler. The general at this point hates the player. The graph might be clearer.

Moving forward we arrive at a point in the story where the player and the princess are married and they rule both countries. The general is now hated by all. And here is another graph.

For the story generator the only thing is how the possible futures of all elements could be. Once he knows the possible futures all it has to do is create "story chapters" which move the story toward the possible features. If needed a chapter could have a branch which excludes one of the possible features, for example the player kills the general before the princess was able to find out about the betray of the player so she never finds out the wrong he did and therefore never encounters the player.
Of course a lot more thought needs to go in this, but it solved for the procedural "writers-block".

Donuts! (Procedural Torus in C++)

Wouter Lindenhof — Mon, 04 Jan 2010 12:13:45 +0000

Recently I got a mail through the contact form of my website about texture mapping on torus (a donut) who said that D3DXCreateTorus didn't not provide texture coordinates. The reason why DirectX and OpenGL (and GLUT) don't provide texture coordinates with these function is best seen when you generate a cube. A cube has 8 vertices, however when you add texture coordinates it will increase because otherwise they will share the same texture coordinate. With normals it is no problem (in fact you would prefer that) but if you have a dice (from 1 to 6) than each vertex would use a single texture coordinate for three sides. Just draw an unfolded dice on paper where each edge is connected, but does not cross another edge. It is simply not possible. These complexities are the reason why those procedural mesh functions are so simple. Adding these functionalities would increase complexity of the function and requires you to explain it. On top of that the developers have no idea how you are going to use that function. Maybe you don't want to use the legal texture range [0...1] but [0...3].

Anyway I have decided to take it on and here is the result. You can download the source code here: TorusDX.zip.I have not commented it, but it is pretty straight forward. The texture that I used is from Dilbert.