Sometimes you can't see the forest for the trees. I'm looking for a simple data base solution for my game since two years now. My requirements were - simple setup - file based (no real database) - write custom export scripts - able to build a simple front-end - no $$$ I simply didn't found a solution.
I'm a senior software developer and it isn't really a problem to write something like this, even with a web-frontend based on a standard db or an application server. But in my spare-time I don't want to create tools, I more or less do this at work all day ! I want to make games, not tools. Sadly custom tools are an very important factor in game development.
Nevertheless, finally I found it: OpenOffice ...well, I worked with open office since a few years now, already utilizing OO calc for my game, but I never thought that open office is delivered with a simple, yet powerful, sql database called open office base. The best thing about it is, that you can add easily forms to manipulate the data.
For you, who don't know open office. It is the open source answer to microsoft office. I.e. OO writer is the solution for MS word, OO calc for MS excel, and eventually OO base for MS access. I think that MS office is more mature and powerful than open office, but open office is free and by far all I need at the moment.
Suspension of disbelief is always an interesting topic, I always catch myself trying to explain everything in my game world, a bad and not always necessary habit
So, what is suspension of disbelief in games ? In my own words, suspension of disbelief is the ability of a gamer to accept something unrealistic or unbelievable in a game world and still immerge into it. Take a look at wiki for more details.
The tricky part for us game designers is, that you need to take care to not destroy this illusion. It is not as simple as just to say 'hey, he starts playing my game and he suspends his disbelief, so I've done everything right ! '. But more on this topic later.
Ok, there are two important things to remember: 1. Suspension of disbelief is a personal thing. 2. You need to ground your game world in realism !
The personal thing is simple. Make whatever you want and you will find enough people who can sink into your game without any problems. The second option is more important and will be your tool to control your audience. Everything, even high fantasy and sci-fi is grounded in realism. This is like a slider, on the left a purely abstract world, on the other side reality. A purely abstract world will alienate almost everybody.
Think about roguelike games, where an 'E' attacks the player, just an abstract letter. But on the other hand the description, actions, items etc. are taken from known fantasy worlds. There're many people who find it too abstract, still the roguelike community is huge.
An other good example are toons. Take a standard toon with animals in it. The animals talk like humans, movement and posture contains human features, they equip and use tools like humans, have human emotions and habits etc. The designer wanted to create a world in which animals are the main characters, but the most important feature is, that almost only this fact is unrealistic. Almost everything else has a human touch, therefor it is grounded in realism we know and accept.
One of the best game ever contains one of the biggest misstakes in taking care of suspension of disbelief: Half-Life Well, suspension of disbelief is a personal thing, but I belief that many gamers think in a similar way. Half-Life is about aliens, conspiration,experimental weapons,zombies etc. all about unrealistic and unbelievable things, still it was just a matter of seconds to dive into this world. But, once you enter the alien world at the end of the game my suspension of disbelief broke. It was like a fist hitting you in the stomach. For me the game designers have gone too far, infact they stole my end-game experience.
So, what was the misstake, when suspension of disbelief is a personal thing ? Consistency ! They started in a realistic world, introduced the unrealistic part quite fast and hold this level for almost the whole game. But near the end they introduced the soldiers (in fact this is my remembered end-game), which is grounded in realism and then they throw you into ice-cold water, the alien world which needed a much higher level of suspension of disbelief then anything before.
If you want to address as many people as possible you need to went as far as possible to realism while keeping your game design, but never go too far with realism. Many genre already have some kind of template suspension of disbelief. That is, the audience which chooses a certain genre accepts a core world, you could ground your game world in this genre world template. I.e. a vampire world , you don't need to explain the existience of vampires to draw your audience into your game, they most likely accepted this fact about your world after reading a title like 'vampire worlds'. Still you can explain it, but only for sake of storytelling and not so much to hold up the suspension of disbelief.
Finally you should prepare the expected level of suspension of disbelief quite early in the game and keep it on this level, as already said, a genre world could help a lot.
Well, I will present just a little rant about visual styles in games. Here's a small background about why I'm talking about visual styles in game, feel free to skip it. I'm no artist, just a coder, but I'm trying to create a non-casual game 3d game which is not so far from completion. To be honest, managing my own game time as resource is incredible important and with a talented friend as artistic support I'm quite lucky to be able to add art to my game. Yet it is difficult to get this "more realistic, not stylized" tendency out of the head of my artist friend. He himself likes WoW and its art, on the other hand he dislike making something like WoW art.
When you talk about stylized art most people will think of comics/toons first, but this is just one extreme of 1000s of available possibilities to stylize art. Here are some of the most important elements: (disclaimer: I'm no artist and this is no teaching lecture :-) )
[subheading]Shape[/subheading] Shape is a strong stylizing element. Most toons exaggerated this (big heads, thin legs etc.). Games like TF2 works with this element to give each character class a distinctive silhouette. Games like WoW use it in a more subtle manner, still it is there.
[subheading]Color[/subheading] Color is another very strong stylizing element. As an example, toons try to use highly saturated colors, where's modern realistic games tends to use desaturated color (gray-brown). An other possiblity is the absence of color or to use a certain fixed color palett (think about movies like 300 or sin city). Take a look at Kingdoms of Armalur, an upcoming mmorpg. The general look is not really exaggerated, but the colors are highly saturated. Would you take a look at screenshots in grayscale you would consider this game more like a photorealistic approach, but the saturation of the colors shift it into the stylized space.
[subheading]Detail[/subheading] The absence of details helps identifying informations.The range of details reaches from small objects over surface details to color details. Toons try to get rid of almost all details, flat uni-colored surfaces with no unnecessary detail objects. Whereas photorealistic art try to get as much details as possible into its art. From a game developer view this is a most interesting element because it depends on hardware. To add detail, you need more vertices (detail objects), more surface informations (normal maps, highmaps,specular maps etcs.) and higher resolutioned surface informations(color,normal maps=>virtual texturing). In my opinion this is a major reason why games on hand-helds tend to have a stylized look, the hardware is not powerful enough.
So, why should we use more stylized art in games ? Currently there's a rush for the most realistic art in games (take a look at the latest EPIC Unreal trailer), but the really interesting part is, that the time between first show off (the wow ,amazing visuals time) to the release date (hm..visuals looks somewhat dated), often only few years, is enough to make a game look dated. Most modern games costs $XX mio. and the pressure to deliver a good looking game his very high and it seems to work for certain games, games with a low life duration (i.e. Shooter, COD ect.). On the other hand, games which costs even more over time (MMORPGS), tend to choke on the high development/maintainance costs. Take a look at Age of Conan, it looked amazing at its release time, a realistic, cool looking game, nowaday it already looks dated. The most successfully MMORPG (you know, WoW :-) ) have a heavily stylized world, but the people still love it, almost a decade later. Sure, you could argue that AoC has some major issues at the start, but WoW got similar issues.
The fact is, that people will always take a look at the visuals first. If the visuals pleased, they will be interested and keep coming back. The problem is, that photorealistic games aged too fast so that a timeout from technical issues (bugs, missing features) is often enough to keep the people away, because a better looking game has been announced or released. To get long term support from the gaming community, delivering a photorealist game is a simple top or flop story, you will never got a second chance. On the other hand a stylized game has the "chance" to unfold its potential over time. Best example is minecraft.
From an indie view we can't compete with multi-million dollar projects, so we don't have really an other option other than going for a stylized look. But on the other hand this is a major advantage because we could deliver a game and not a interactive movie. Take a look a tv-series. All the "dated" looking tv-series from the 70s,80s,90s are gone, but the simpsons are still going on.
There're always topics you are aware of, but which you are ignoring most of the time until it is too late. You will thought of it as some minor feature which could be added later. Well, this could be a bad idea.
I trapped myself with one of this minor feature: loading/saving Yes, it sounds simple. After more than 10 years of developing an engine/game I came to the conclusion that it is time to add it now. It turned out to be one of the tougher challenges of the last years. When you got a C++ engine and lot of scripted code (whole game logic), then you have a problem here.
So, how to save your game ? There come two approaches to mind.
1. Serialisation/Deserialisation: You serialize every object in your game to a file. You must have some special handling for associations between objects. I use a unique id for each object and save only the ids for references. Thought after loading your game data you need to reconnect the references. A problem with this approach is, that you need a lot of post processing and you need to change class models to support it (I.e. some script languages like lua supports refering functions). You can regard this as an almost 1:1 memory copy of you game data.
The major advantage of this technique is, that you can easily add and remove data from your game. The mechnism works almost automatically. But there're some pitfalls. First your saved gamedata is really fixed to one version of your game. Reloading it with an newer version could easily lead to some disaster. This is really an issue while developing a game and when you need to release some bugfixes.
2. Export/Import Instead of just saving a copy of the whole data to a file you export and import the data. In this case you define some kind of save-fileformat for each object, relation etc. When importing it you need some kind of special parser for each entity to create and connect the according objects in your engine.
The major advantage is, that this is a clean approach and you can change the game code while keeping the save files (just adjust the importer). But you need to put some work into it whenever you change the fileformat. But this could lead to high maintainance costs at development time.
Well, after forgetting about save files for years, I choose to go for de-/serialisation. I would have prefered the import/export approach, but it is just too expensive. To soften the negative upgrade effect (new game version makes older save files obsolete), I choose to use some kind of weak references to static content. Therefore I divided the data into permanent and persistent data. Permanent data are shared, static data which are used independendly by dynamically created content. I.e. game rules, templates etc. This static content get unique ids at design time and will not be saved to a save file. When reloading a file I can reconnect objects to this version dependent data. This allows me to upgrade and change the game to some extend without making the save files obsolete.
Once the game has been released I fear that a major game update will lead to obsolete save files, but this could happen to import/export files too. Atleast minor updates should work as long as I'm careful about changing the code and content.
I'm quite happy with the progress of dungeon fortress sofar. In the last weeks we have concentrated on the rpg part of the game and I would say that we reached a pre-alpha stage. Nevertheless, there's still lot of work in the rpg part mainly content, although content in a rpg is a never ending story.
Aside from this I bought a new ATI video card to do some testing and establish compatibility with ATI. I wouldn't be surprised if I have to refactor my shaders to get it running on ATI.
The next big thing in dungeon fortress will be the rts part. I've started to work on a way to dynamically change the dungeon, in other word, digging new tunnels. It reminds me of dungeon keeper, but it is more restricted. Still I guess that it will be fun to build your own dungeon and breed your own creatures.
When I switched from forward rendering to deferred rendering sometime ago, I really liked the elegant handling of lights. This is still the main reason I use a deferred renderer, but I always missed the ability to render transparent surfaces like water or "fog". Well, I succeeded in adding transparent surface support to my deferred renderer again, yeah, but only for one layer of transparency. Still, this is more than enough for the start and I'm quite happy with the result.
Here's what I've done. The basic idea is to use stipple transparency and a simple shader to get rid of the stipple pattern in a final run. My approach is a simplified version of the more common 3 layer model stipple transparency model.
Here's an overview of the technique: 1. Render g-buffer as always. 2. Render transparent surfaces with stipple pattern, write an alpha value greater 0 to indicate the tranparency factor. 3. Light pass (just one is needed!) 4. Final composition, combine transparent pixel with background pixels.
The stipple pattern can be generated by the following shader fragment (GLSL):
In figure 1 you can see my test level with and without a (stipple) transparent surface. The stipple pattern is clearly visible, but this is already some kind of transparency effect, even if it is fixed at 50%.
We want to get rid of the pattern and we want to use a fullrange transparency value of 0..1. This is done in a final composition step. In my engine I use this step to do tonemapping and adding bloom.
First I sample four samples of the framebuffer. Remember that we have used the alpha channel to store the transparancy value, so we check if any of the four texels have an alpha value greater 0. If this is NOT the case, we will ignore all neighbor texels. This way we will not introduce unnecessary loss of quality.
When we got the atleast one alpha value greater 0 we have to average the texel pairs in a cross fashion. Knowing that only one texel pair contains alpha values >0 we can add all alpha values to get the final value. Now we can simply alpha blend the background texel pair with the transparent surface texel pair, with one exception: we don't know which pair is the background and which is the transparent pair. But this is not a problem, just use the stipple pattern function to determine the background texel pair and do the blending. Here's a small GLSL fragment shader demonstrating the process:
// blend background and foreground color vec3 color = mix(avg_a.rgb,avg_b.rgb,alpha);
// apply transparent mask, if none transparency is present take the center texel color = mix(color_texel_a1.rgb,tmp_color,transparent_mask);
As you can see in the close up view, we half the resolution when we encounter a transparent surface. This can result in artifacts when we use transparent surfaces with high frequent highlights, but on the other hand it is very simple, fast and it enables transparency in a deferred shader !
Welcome to my second part of procedurally generated quests. You should be sure to read part 1.
First I want to define the terminology used in this series:
skeleton of a level - minimal spanning tree section of a level - a (small) portion of a level in which the player can walk freely around, these are the nodes of our graph gate - a connection between two sections, these are the edges of our graph goal - a certain section which has to be reached critical path - a path from the entry point of the level to a goal backbone - all edges which are used to reach atleast one goal
Well, this time I want to create goal chains. A goal chain is a collection of more than two goals, which must be reached in the correct order. A simple example are the red,blue,green keys in older FPS. Find the red key to gain access to an other part of the level to find the blue key and so on. This simple key-gate->goal principle is found very often in modern games, but the keys and gates are more sophisticated. In fact you have to do something before you are able to progress to your final goal, which is just a key. I.e. kill a boss, recover a stolen item, activate a secret button, disarm a trap.
The problem with generated goal chains is, that you must ensure that you don't add barriers (gates) which can't be overcome, because a key which is needed earlier is behind the barrier. This is some kind of gamelogic deadlock. Think about a red and blue door and the according keys. If you put the red key behind the blue door and the blue key behind the red door the game is in fact unsolvable, and even more frustrating.
In this installment I will show you how to divide your level into islands of sections. One or more of these islands define a quest space in which you can safely place a key without the danger of deadlocks.
As we seen in part I you choose a goal on the skeleton, calculate the unique critical path to this goal and you can place a gate on this path as barrier. This time will we take the gate and subdivide the skeleton into two islands by removing the gate-edge. The island, which still contains our level-entry will be used for the next iteration. The next iteration is simple doing the same, choose a goal, find the critical path, place a gate and remove the gate-edge. Each goal, except the last one, should contain the key to the next gate. Take a look at figure 1. Once we have finished this process we add all edges which lead to a goal, to the set of backbone-edges.
As you can see in the final graph version, almost all edges are backbone-edges, just two are not used in any critical path to a goal. This can be utilized to extend the chain of goals, or to start a new one.
For a new chain of goals we can repeat the whole procedure with one limitation. We start with the same skeleton, without any islands, but we keep the backbone set of edges from the previous run. The limitation is to don't add any gate to an edge which is already contained in the backbone set. This implies that any new goal-node is not part of any critical path to a goal defined in the previous run. The reason is that we don't want to block the "main" quest with a barrier from a "sub" quest.
In this part we worked out how to add chains of goals without blocking other more or less independent goals. In one of the next installments we will discuss fleshing out tge quest.
This weekend I've finally integrated my first attempt of a procedural level generator. I'm quite happy with the result and I think I want to take it a step further, generating procedural quests.
Most people got a bad feeling when they hear about procedural quests. Most will most likely think about the "deliver item X" or "kill X monsters" quests encountered too often in MMORPGs. I want to generate more complex quest, maybe even character specific quests. I've got some ideas and I want to develop a procedural quest system slowly step by step, beginning with a simple system and refining it with each iteration. My experiences and thoughts will be documented in this journal as a little series of entries.
Well, let's start. In my first entry I want to talk about a quest and level setup. First off, I can generate indoor levels and will incoperate this in my quest generation. My approach will most likely be applicably to "closed" levels not so likely to "open worlds".
Talking about levels, I define a level as a collection of sections which are connected by gates. Each section is an isolated island where the player is able to walk around and do something, but the only way to leave or enter a section is through a gate. Take a look at figure 1. Think about a survival horror game, you're coming from town and want to investigate the house of a mad scientist. To proceed in the story you have to find the secret research labour reached by a tunnel in the cellar. Cliche pure :-) As you can see, a section could be of different size. The kitches might be quite small, whereas the ghouse could be large.
The next step is to define a goal. We start with a simple but often encountered goal: find the exit and leave the area.
Now we need to introduce some rules, my first rule is: whatever happens, the player must be able to reach his goal. Sounds pretty standard.
We need some kind of critical path through the level which the player can follow to reach his goal. The level looks coincidentally like a graph and we use this to run a minimal spanning tree algorithm which lead to the result seen in figure 2. As you can see, there are two edges (or gates) which are not included in the spanning tree. These two gates will be closed for the start. In our example this could be a barrier, a fire, a jammed door whatever.
The next step is to find the unique path to our goal. A simple depth search will deliver the wished result.
To introduce a challenge we can lock one gate on the critical path and place the key somewhere in the level, preferable in a section which is not on the critical path. To find a proper placement of the key, start a conditional depth search at the entry point on the minimal spanning tree. Take the deepest section you encounter. But do not surpass the locked gate and prefer a node, which is not included in the critical path.
That's all for the first part. To sum it up:
- Devide your level into sections which are connected by gates. - Sections are isolated parts of your level which are only reachable through gates. - Determine the minimal spanning tree. - Block all gates which are not contained in the spanning tree. - Determine the critical path to the level exit. - Lock one gates on the critical path. - Do a conditianal depth search to find a proper placement of the key.
All this is pretty basic graph theory I will start to implement some basic graph structures and algorithms. Next things to do are alternative routes, sub goals, sub quests, quest story generation etc. , so stay tuned !
Well, I'm back with some breaking news :) At last I've made a simple banner for this journal and added some screenshots, yeah !
We have finally finished the first GUI iteration. The visualisation of buttons, text, infos, items, icons, hud, minimap etc. has been settled down and I'm quite satisfied with the style we have choosen. The art is mostly down by my friend. Take a look at our screenshots to get an impression of the gui style.
My major interest in game programming is visualisation and I couldn't hold back to implement a little improvement while doing the GUI stuff. When you take a look at the screenshots you will , at least I hope, recognize that the walls are rendered with a displacement map. I've tested two techniques, parallax occlusion mapping and (relaxed) cone step mapping. The preprocessing of the cone step mapping is reallly slow, but you will need less steps for good final results. One issue with image based displacement mapping is that texture distortion is a no-go. It seems that I've to rework one or two cave models to get rid of this distortions.
After all the gui stuff I will go back to gameplay and try to de/refine it more. My goal for the next step is to tie up loose ends and get some gameplay done. That gameplay will be quite basic stuff, like killing mobs, leveling etc. Although this is quite basic stuff (we have other gameplay focuses) it is still hard because it consists of tieing up almost all subsystems to play together in harmony.
Yesterday Ghostknight asked me about some details of the gamedesign, so I think it is time to talk about the content.
The game starts out as a single player survival dungeon game. As things are now the player can choose to play a mage, a warrior or a rogue, maybe a priest. Nothing special sofar. The core features are a rune magic system and a crafting system.
Each class has a special magic talent, the warrior has the ability to draw energy from his body, the mage has the ability to draw energy from the world and the rogue has the ability to get his energy from the world too, but only a fraction of the power of the mage.
To use magic you need to bind a rune. Runes can be found in the dungeon or looted from npcs. You are only able to bind a certain number of runes concurrently, similar to guild wars skills. The talent of the classes will define which runes are usable. A warrior must touch a target (through a weapon) to tranfer his energy, whereas a mage don't need any phyiscal contact. All classes has something in commmon. Drawing energy is hindered by metal armor. So, only the warrior is able to wear metal armor without sacrifing his ability to use magic runes.
A special case is the rogue. His abilities are by far not as powerful as the mages abilities and he can't wear any metal armor as the warrior, so he needs to use crafting for his own benefits. So rogue magic often needs ingredients.
Crafting will play a major role, all classes will benefit from crafting. The crafting system represents the only skills in the game, there will be no other. On the other hand the runes are similar to "skills" found in other RPGs.
The dungeon dwellers will mostly consists of animals and monsters. At the current stage there are spiders and "flying" worms. There're a lot of different varients of each dungeon dwellers. Each dweller has its own indiviual behaviour and it is not safe to say how it will react to you. Monsters will watch you, flee, or attack. They learn about the dungeon, about where they encounter danger or traps, and they will tell others ! They will loot other monsters, they will collect resources, they will eat and they will relieve themselves (leaving important resources).
So it might be a bad idea to attack a tame monster and let it flee, you could encounter its great brothers if you keep staying there. Some monsters are important to produce certain resources, other monster might help you fighting other monster hives.
Each monster is part of a hive, each hive will spawn new monsters and it will react to danger. If you or something else will kill every monster of the hive, the hive will react to the new danger by spawning more powerful dwellers, until the hive itself gets destroyed or runs out of resources.
Well, my development process is a classic iterative approach where I improve a certain part of the game for a few week until I go on to the next part.
January was the month of the "npc behaviour", I have implemented some improvements with which I'm quite happy about. So far, my dungeon dwellers are bred from nests and explore their surroundings. When they encounter some food resource they will start to take resources to their nests, on the other hand they will look for food once the got hungry and start eating. Once they encounter an object of interest, like loot lying around or an opponent, the react in different ways. Some dwellers will flee, other get curious and will take a look and others will start to hunt and attack the opponent.
Still there's enough to do, but it should settle down for some time before I revisit this topic again.
So, this month will be the month of the "player" with a strong focus on fighting mobs. This has a major visual factor. I already modelled and rigged some hands and test weapons (my game is played in the first person perspective), now I need to add some decent animations. My goal is to establish atleast 4 basic combat actions: swing a weapon, a special move, a heal spell and a fire blast. I think I have to play around with some special effects too.
Eventually I will rework the (derived)attribute system and the basic fighting rules. As a bonus I will try to invest some time into the gui. I got already a basic working gui with inventory, character sheet, character creation etc. but only with some placeholder grafics.
I'm still playing around with the AI. This weekend I got an issue with pathfinding: How to let a hunter follow its prey without recalculating a navigation path frequently ?
Well, I think I got it. My assumption is, that the hunter is able to follow the prey step by step. With that assumption I can create a path by tracking the movement of the prey, because if the prey was able to walk a certain path the hunter will be too. I know that this approach has it's shortcoming. If the prey has abilities the hunter has not, like jumping over a barrier etc. But there are two reason the assumption is acceptable. First, it is not realistic, that a hunter is able to follow a prey around the whole map. Once the distance is too great, the hunter has failed and will pickup an other task. The second point is, that if the hunter is not overcoming a barrier a quick A* could help him, if it is not helping, he will abort the hunt.
The idea is, to start with a A* (Figure 1) and create an initial path to the prey. Now, while folling the path, the hunter will expand the path by checking, if the prey leaves a certain area of the last position in the path (Figure2). Once he has left it, the hunters path will be expanded with a new node(Figure 3).
In Figure 4 you can see a path expansion of 4 nodes. An optimization would be to check, if the prey re-enters an area of any node but the last one. In this case the hunter can take a shortcut and the according nodes can be disposed.
How good it will work depends on the choosen radius. I think I will give it a try :)
This week I'm working at the AI system. So it seems to be the right moment to talk about the implementation of the AI system in dungeon fortress. I hope that it willserve as an little inspiration to other hobby game developers.
Well, I'm not an expert in AI and several things are quite new (in relation to 11 years of development), but I've learnt a lot about AI in the past year.
The whole system is build up of several AI related components which are displayed in the figure.
The most basic component is the finite state machines (FSM). I use several FSMs in my game engine, mostly for controlling entities, but although for gui and user interactions. They are quite simple, communicate asynchronous over a central bus system and can be designed in an uml tool for which I wrote a xml converter. I can attach several FSMs to an single entity to control it. Most dynamic agent got at least two FSM, one for controlling the actual movement-action and one for controlling decisions and reactions (think of body and mind).
The second basic component is the way-point system. Instead of using a navigation mesh, I developed a multi-layered way-point system. Currently only two layers are needed, whereas one is for mostly navigation and the second layer is at a lower resolution containing additional meta data.
The third basic component is a knowledge container, containing knowledge about locations (represented by way-points). There's no special knowledge data structure about entities or events. The knowledge contains data about explored, dangerous, inaccessible, or safe locations. Each entity has its own knowledge, but certain entity group are able to share knowledge.
There are two different "traditional" AI systems which works on top of the three basic components. This is a behaviour tree which controls the behaviour of a single entity and a blackboard system for a high level orchestration of entity groups.
The blackboard system manages jobs. Each entity is able to create certain jobs( like "supply me with food") or to apply to one job. I use the blackboard system to control group of entities in a economical sense. In dungeon fortress a group of entities, like a spider nest, is a more or less simulated community of entities. They need to eat, to gather resources etc.
The control of a single entity is done by the behaviour tree which is inspired by the work of Chris Heckler, who uses a similar system in spore. A behaviour tree, is a tree of "decision" nodes. Each node is quite simple, but by combining this nodes in a tree like structure you can create more complex behaviour with ease( I really love behaviour trees!). The behaviour tree make decision based on different entity properties, by scanning the surrounding for enemies, resources, objects of interest and eventually by a modified A*.
The A* is most likely in every game AI system present. I used a modified version of it to navigate on the way-point system by using the knowledge of the according entity. This way it is possible to navigate around dangerous areas or to avoid blocked passages.
I want to say hello world to the gamedev community. I'm a german based hobby developer and in my first journal entry I want to introduce my game based on my game engine. But first a little screenshot to show off the current state of development.
The game engine, as a hobby project, is in development since late 1998. After several attempts to team up with other developers, artists and several game projects attempts based on my engine I team up with an old school friend. The screenshots are from the game in development since early 2009, my friends helps out with art and we both work on the game design.
The project work title is "dungeon fortress" and is planned to be a rpg/rts hybrid, but currently only the rpg part is in development.
Yeah, that's it. I think that I will talk about the engine features and game goals in one of my future entries.