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 !
Well, I've posted some shots of my experiemental outline shader over at polycount, so I think that it is a good idea to elaborate on some technical details here in my developer journal.
Outline shaders are always difficult to pull off. It is hard to get fine outlines done (most edge detection algorithm like sobel result in a atleast two pixel thick line). In combination with a high contrast color like black, the outline effect will be just too harsh and therefor many people will just dislike the effect, in games atleast.
I play around with a simple sobel filter to get the edge detected done. As detection criteria I use depth and normals. Currently I'm not using any AA filters, so it will look really clumpsy. In my first screenshot (upper part) you see a standard sobel edge detection in pure black. As you can see, it has an other negative effect, any bloom effect will be interupted. To counter this effect I fade out the outlines with distance (lower part, right arrow) and use a blurred,darkened version of the scene as input of the outline pixel. This has the advantage that bloom works (gets a bright outline) and the lines has lot less contrast compared to pure black.
An other challenge with outline shaders are particles. My next screenshot(upper part) shows clearly outlines behind the fire particle effect. This is really annoying, to get around it, I render the particle effects on a separate render target (btw. half resolution) and use the alpha channel of this render target as alpha mask for the outlines. You can compare it with the bottom part of the screenshot where you can see the effect of masking the outlines. The alpha mask is displayed in the bottom,right corner.
Next I will take a look at AA filter (FXAA, MLAA, ...). Here are some comparison shots displaying the game without (upper part) and with (lower part) outline effect applied.
I love procedural content generation, but I have to admit, that it is not as powerful as I once hoped. Procedural generation in games is quite old reaching back to the days of elite and rogue-like game. Today, atleast two decades later, processing power has increased incredible, but what about procedural generated content ?
When I was a child, I got the idea to write a tool to generate 16x16 , 4 color sprites by randomly generating pixel heaps, reviewing and rejecting sprites manually, which did not look good. The idea is basicly a procedural content generation tool, thought doing some basic math, it was not a very promising idea.
But it is a good comparision of the situation of procedural generation. Back then I would have seen images in randomly generated pixel heaps, much like your brain is able to see figures in clouds. But today we no longer have 16x16, 4 color sprites, we have artistically crafted, huge paintings. Even realistic rendering is really stylized, utilizing many tricks to communicate some important emotions and messages in just every possible detail, and here we are at the point where procedural content breaks.
You can compare it with reading a book and watching a movie. While reading a book you use your imagination to build a living world from some fix points, whereas while watching a movie you are confronted with a given vision, not really able to bring in your own imagination. Now think about something in between book and movie. No idea, me too, I can't see how it should really work, and I'm not seeing how real procedural content should work in a modern game without abstracting the visualisation.
I have experimented with procedural level generation for more than 3 or 4 years in my game now. The major issue was, that it feels, well generated. I think, that people who play an abstract game (rogue-like or minecraft) stepped already over the suspend-of-disbelieve threshold, therefore accepting to live in a procedural world. But removing the abstraction puts the pattern of generated content in the foreground which results in breaking the suspend-of-disbelieve for many people. Much like the uncanny valley, we have the situation that the improvement of a single aspect (visual) change the awareness of the audience, suddenly seeing flaws in details (generated vs design content) which were not previously an issue.
So, I'm the only one having this trouble ? Besides terrain generation, what game should have procedural generated content and the options and budget to archieve it ? At least diablo 3 should have and indeed they have kind of procedural content in a huge, painterly world. But taking a closer look, you will see that they are only really plugging together template created by some artists, which must not be bad, but which is not really what I would have expected, or hoped for. But I'm sure that the people over at blizzard looked for a way to maximize the content generation while keeping an artistically and lovely art style and environment.
Procedural content, much like art, must be consistent with the rest of your game to work properly and the current state of procedural content generation was not able to keep up with the pace of visual content creation making it really hard to incoperate it in a modern (non-abstract) game.
Therefore my final thought is, that you should consider to utilize the human brain to make sense behind procedural, though abstract, content, instead of making procedures which are able to simulate the human brain to create artistically content. The first worked so far, the latter not.
Procedural generation sounds great at first. Generating infinit content, the dream of every designer (or nightmare if your job get obsolete). But the reality tells an other story. Once you start developing your own procedural content generation you will realize quite fast, that most of it is just boring. The issue is, that players want meaningful content, not just huge amount of random content, and getting meaning into procedural content is really hard.
But it depends on where the player seeks meaning, and this depends on the human nature, where we as human individual seek meaning.
Lets start with a forest. When you walk through a forest, the meaning of this forest could be a location where you can feel good and free, a safe habour, a place you know. There's a natural order in a forest, the distance between trees, the light which reaches the ground determines the vegetation, but most people will not count the leafs on the ground, because the forest arised in a random manner depending on some existing parameter (i.e. biome). This is something we can try to capture with procedural content generation quite easily.
On the other hand think about an university. A great campus, with many buildings, different field of research gathered in only one or two building complexes. The cafeteria, parking slots, means of transport are structured in certain ways, sometimes in a logical way, sometimes historically based. Even if it is easy to generate buildings, streets, parking slots etc. it will be hard to generate a meaningful combination of it to represent an university. This introduce two difficulties, first how to generate something which has been designed by humans and how to combine smaller meaningful parts into something greater without loosing the meaning. Think about a parking slot, which has the meaing of, yeah, park your car to reach your destination on foot. Generating the parking slot 25 km of your destination would loose any meaning, on the other hand adding a fast traffic connection between parking slot and target destination would introduce a meaning.
The first class of PCG, natural content like forest, terrain, islands is easy, but the second class of PCG, human designed content, needs more engineering.
A practical approach is to start with designed content and try to break it up and recombine it in a meaningful way. The trick is, to start with designed content and don't try to generate designed content first.
In our campus example we would divide the campus into different areas like parking slots, mensa, research complex, inhabitants, traffic stations etc. The second step would be to define rules of combinations, i.e. the parking slots should be near the research complex, the inhabitants needs a connecting to traffic stations etc. When done, pick a part and try to break it up in a similar way, i.e. the inhabitants, they could be made up of different building types, a supermarket, a small park etc. This way you break up your target content in a top-down manner, but sometimes it will really hard to break it up any further.
The rescue comes in form of templates, that are small, meaningful, designed pieces of content. That's it, don't try to break up everything, sometimes it is much better and easier to design a bag full of meaningful templates instead of generating complex, chaotic, meaningless content.
Implementation tips: Implementation of the rules are the hardest part. Different content will require different rules which will eventually requires different algorithms and approaches, there's no best way to do it. But I found graphs really useful when recombining structured data. There're lot of graph algorithms (i.e. kruskal, dijkstra, A* etc) around which will help you to solve certain problems.
Conclusion: - use designed content in form of templates - design rules of combinations - work top-down, not bottom-up - never loose the focus on meaning
Bug finding is one of the more frustrating tasks when coding a game. Just yesterday I hopefully hunted down a very frustrating bug, thought I hoped this already 3 times before. Sometimes bugs are really nasty, coming up only after several minutes of active gameplay and once you see the result, you can't find a trace for the reason. Over the years I've added some useful features to help me finding bugs and I thought it is good moment to present them here. Larger projects will most likely utilize these and many others features, still you might find one or two ideas useful to tweak your own debugging tools for your game.
Log files Okay, this is one of the most basic debug features available and a must have.
HTML Server I think that your game should be a HTML server, it is not unusal, but nevertheless extremely powerful. For coding a server like this, you really just need a tcp socket and some basic http handling. HTTP is no magic and is really easy to parse and write. If you write out some simple html pages as responce to a http request, then your browser will suddenly be a very powerful debugging tool.
Shader Reload Reloading shaders on the fly (per html server plugin) and logging out some data (does it compile etc.) is really useful to track down this little nasty shader glitches.
Custom Script Execution If your engine supports a scripting language, add a possiblity to execute script-code on-the-fly. Very useful to log out information, or to modify game objects.
Ingame Object Information Add some way to have a ingame information about objects. Use the cursor/mouse to target an object and push out the data directly on the screen. I found it really useful to have two of this debugging outputs, one on the left side of the screen and one on the other side. This way I can track down two objects concurrently. Although helpful is the use of the page up/down keys to display multiple pages of information. Lock on a Single Object I can take a single object and put a debug focus on it. This results in additional debug output (logfile) etc and to in the option to set conditional breakpoints to isolate a single object in your debugger. If you debug every object all the time, then you will have just too much information to handle efficiently.
Custom Visualisation Just add some visualization to else invisible information. From a simple wireframe render output to displaying physics hullobjects and waypoints.
Persistent Gameflow History It is really useful to have a secondary logging mechanism to log and view the gameflow. This is similar to the standard log file with the difference, that it is part of the game (and will be saved with it), is more compact, describes only game related stuff (no technical stuff). It helps to track down these game design bugs, eg. if a tester said, that he never found the red-key, just look up the history file to get a hint (eg. he picked it up and dropped it later on). It helps to keep track of all these events you can't watch all the time (Why are suddenly half of my minions dead ?).
Time slow/forward Ok, if your game is realtime, you should consider to use a virtual clock. I have the option to speed-hack my own engine by slowing/speeding up the time. It is really useful to reproduce some time dependent events (7x forward and the bug will be reproducable in a few seconds), to slow it down (why are this animation transition so choppy) or to even stop the time completely to freeze your game state and debug it with your html plugins and script execution. One thought, your forward will most likely get CPU bound due to fix-your-timestep parts of your code. In this case additonal CPU power is really useful.
Today I'm proud to announce the release of the alpha demo of Gnoblins. You can download it directly from our homepage over here or from IndieDB.
Gnoblins is a 3d dungeon crawler game, a rogue-like in its heart, with a lightweight RTS part. You need to save the world of Amunlak from an upcoming peril. You, a former novice of the destroyed secret society of the guardians, found yourself in unknown underground world inhabited by the unimpressive appearing people, who call themselves the Gnoblins. But with the help of these people, you must find a way to save the world from its own greed and hate.
The demo features the first underground world consisting of several levels which contain randomized parts. You are able to explore the underground world in first person perspective and to seek hidden treasures and secrets which might be helpful in your quest. Additionally the Gnoblins will lead you a helping hand, at least for a small obolus. With their help you will be able to craft better equipment and build your own dungeon to survive the dangers hidden in the darkness.
The game is still in the alpha stage, therefore expect some bugs and glitches and consider that most, but not all features have been implemented yet (details). But if you like the game, please consider supporting us. Just mentioning our game on twitter, facebook or your blog would be really help to us. If you need some footage take a look at the screenshot section (including a small press-kit). Although vote for Gnoblins on Greenlight and on IndieDB. If you have some questions, take a look at our FAQ section or post your comments on either Greenlight, IndieDB or our own forum.
I want to start a new closed test only available to a small, dedicated group of testers. If someone has interest in helping me out, send me a PM and I will give you the download link
Gnoblins is a dungeon building game, similar to Dungeon Keeper and to some extend to Dwarf Fortress. You can play a single level (~1-2 hours playtime). There's no dedicated tutorial, but I tried to make the game accessible and a little in-game guide. There should be no crashes or hard bugs, but you will encounter some glitches for sure
Requirements: Best to have atleast a duo core CPU, windows Vista or above, a dedicated GPU. Thought it runs on an Intel HD 4000, it is really slow on such a GPU. I've tested it on NVidia/AMD/Intel GPUs on Vista/Win7.
Timeinvestment: As long as you find it interesting :)
If you want to help out, I would really love to get some feedback. Here would be a list of feedback from top to lowest priority: 1. Do you have any issues installing/starting the game ? 2. A brutal honest answer: Do you like it ? (Please, don't be nice, just honest !) 3. There's no dedicated tutorial, so, do you have a lot of issues getting into the game ? 4. More detailed: What do you like most ? What do you dislike most ? 5. What do you think need most work ? 6. What do you think would improve the game experience ? 7. Is the game to hard/easy ? 8. Is the game to slow/fast ?
Intersted ? Then send me a PM pleased
With windows 8 my willingness to try out linux has been tripled over night. Is windows really that much better than linux any longer ? I bought a new laptop and set a new pre-installed windows OS aside to give linux (ubuntu) a chance. Though I will not turn my back on windows completely (at least I'm quite happy with visual studio), it could be enough to wait until windows 9 is released, hopeful setting the focus back on a desktop OS again.
When it runs good, very good, I might think about testing out a port of my game to linux...
Speaking of Gnoblins, I plan to release the first public alpha version at the end of this month, so stay tuned. Further on I'm currently in artist mode again, trying my coder hands on some programmer art, here's the current wip of my new model , the elder.
I'm in need of taking a little break from coding, so there is nothing better as doing some programmer art instead. Trying my best at a new creature for my game, the ratman warrior thingy. Here's the first model attempt:
And a turntable :
Please feel free to comment and critique, there is enough space for improvements
Looking at the vulkan api so far, it could solve many of my rendering performance issues in my engine. My engine was based on OpenGL 1.2, followed by a transition to OGL 2.0 and lot of extension later left me with a more or less modern deferred render engine. Still, there exists some really old and ugly rendering code, most famous the GUI code. My gui code is based on pure immediate mode commands, calculating and rendering every single icon and every single text letter every single frame. According to gDebugger a screen full of text adds more than 15k api calls !
But... and this is the reason I never refactored it earlier, the performance impact was relative small. On my workstation the performance difference by enabling/disabling the gui is negligible, so API calls alone are not the reason for low performance. Thought this might have more impact on slower PCs. I took comfort in thinking, that once lot of text is displayed on the screen, atleast the performance impact while rendering the 3d world is not that obvious, better said, hidden by the wall of text ;-)
Immediate mode will (most likely ;-) ) be not available in the Vulkan API, so, it would be a good idea to refactor the gui first and take the gui renderer as test object for my first vulkan based rendering approach. Thought the API is not officially available yet, it seems that it will work concurrently with OpenGL. My gui renderer although shares some of the more interesting core stuff of the 3d render engine, that is texture/shader/pipeline management.
So, what did I do to refactor my gui engine ?
First off, it is based on buffers only. Buffers are accessed by un-/mapping it, gui elements are calculated, cached and batched. I implemented a buffer allocation mechanism (multi-core ready) including defragmentation, a command queue (multi-core ready) including multiple sub-queues. And eventually my shaders needed to be updated to work with the old and new system.
I can toggle both renderer during run-time and so far both work perfectly. The performance increase depends on the hardware, my laptop with i5 running the game on an intel HD 4000 benefits most of it, but the overall performance on a HD4000 is really bad, so the felt impact isn't that great. Nevertheless, some quick tests show, that fullscreen text rendering consumed up to 30/40ms per frame (horrible!) with the old approach , and 1-2ms with the new approach. I think, that the performance could be increaded further by utilizing the buffer better (eg double buffering), but the real performance killer is the 3d-rendering engine (too many state changed, no instancing, low batching utilization).
Next I will exchange my own math library implementation with glm, maybe I can get some more performance improvements out of it.
PS: after verifying the performance again, 30/40ms seems to be just wrong. It is more like taking it down from 5-6ms to 3-4ms. Thought the game is really slow on a HD4000. At higher settings I get only 7fps, the GPU needs 112 ms longer than the CPU to finish its work, without any further API calls or whatever involved. Reducing the settings and render resolution helps a lot, but it is not really comparable to the mobile dedicated NVidia GPU I have in my notebook, where it runs flawless .
Some random thoughts about the future of the game industry and where it will go in the future. The truth is, I don't know, nobody knows, but I fear that the current game industry heading towards a very large bubble, which might eventuelly burst.
There are many reasons, one is for sure, that the industry invest incredible amounts of money in top AAA games, but on the other hand it is often heard of, that many games don't break the even. We talk about normal games which are so expensive, that they need atleast 1-2 mio. sold copies to break even.
The result is logical: don't change a running system (aka cash cow), so make sequel XXIII instead and polish it like hell.
All who now think , that this is the day of indie need to consider, that we are talking about a spoiled generation of gamers. They expect to get AAA visuals,story and gameplay for free, so I fear that indies will have a very hard time too.
What about MMORPGs, the virtual grail of making endless money ? Well, how many MMORPG developers trying to archieve the sucess of WoW, but eventually herding into F2P seeing no other option to survive. The only really working concept seems to be Guild Wars, instead of counting on a subscription system, they counted on only selling the game once (+ add ons) and take the money to keep up a persistence world for some time.This resulted in a quite clever client-server architecture and a clever business model.
The game industry is still young, yet it already had a crash, maybe the bubble is ready to burst again, maybe it is even necessary, who knows.
I'm curious if the next generation of consoles will take off. Current gen games are already looking amazing, to top this you need really big budgets and the major titles will for sure be amazing, but what about the rest. If a studio can't compete with this budgets, it will need to tone down the game it develops, but toning down means that it could look although good on older hardware, or even tablets ?
Both, blizzard and valve, two really great video game studios, heading away from hi-demand hardware, smaller studios follow (e.g. torchlight) with success. There will be not many studios left over which are able to create games, which are really not feasible on the current gen consoles.
The trouble of the last console generation (to go DVD or not to go, harddisk) were tiny compared to the really complex situation now (consoles vs tablets, casual vs core, publisher vs kickstarter, F2P vs subscription, DRM vs free, retail vs digital distribution, PC vs cloud gaming). The budget of gamers is limited, especially in time of a financal crisis, but there are just too many parties which need a lot of money to survive, therefore someone needs to fall by the wayside, hopefully not the whole game industry.
We are still working on the art part. I've called the current goal Project 20, that is, integrate 20 different creature models into the game. In total we have currently 27 character models of different creatures (with up to 6 sub-categories), 20 of them needed to be textured,rigged,animated and integrated into the game. Well, art is always something to show something off, so here are some of the current models we are working on.
Doing art is somewhat cool and satisfying. When you are done, you are done. Either people find it good or not. Code is always difficult. You can't see it, only its effect, often you only see a small effect although you put a lot of effort into it and eventually you are never done with code, it will strick back with some nasty bugs in the future.
Nevertheless, here's a demon I have modelled and textured.
Here's a gorgon, the model is teamwork, the texture is painted by me.
And finally a model and texture made by Gerog, my development partner I'm working with.
And here is an image displaying the different stages of painting the demon. Roughly 3 hours.
The game market is changing, rapidly, still all are waiting for the next console generation. Sony presented its newest generation of consoles, the PS4. Nothing to say about its hardware, sounds great to me. I think that AAA titles are the problem, as already stated in a previous journal entry. With this hardware at hands, they will need immense budgets to lift the games to the next generation.
I compare it somewhat to the last DVD to blu-ray transition. After all the hype I bought a PS3, as blu-ray player and I have just bought one AAA title for the PS3 which was quite disappointing (streamlined version X of game francise Y, come on, this is no longer fun). So, most often I use my PS3 to watch DVD, not even blu-rays, because only highly polished movies with lot of effects really needs a blu-ray.
Back to the PS4. A lot of horse power, indie support (?). Therefor only highly polished and very expensive AAA titles would justify a PS4 ? If this is the only reason to buy a PS4, sony will be really in trouble. Sony has suffered in almost all of its divisions in the last years and PS Vita isn't lifting off either. So, what will happen if the PS4 flops ? Will be microsoft the winner ?
No, I fear not. I think that it could result in a chain-reaction similar to the one Lehman Bros. initiated. The reason is, that if PS4 fails, no AAA publisher will have the selling plattform to overcome the break even of the overaching costs of next gen titles (they already need to sell them on XBox+PS3+PC, even then many games failed the expectations).
This would hit microsofts new console too and I believe, that piracy killed the PC as selling plattform for AAA titles. A fail of the PS4 could rip off sony, microsoft would be fine, though the Xbox720 will suffer, but the AAA market will not likely survive such a hit, the bubble would explode.
There're hints, that others see the risk too. As example, EA is already preparing with stripping off titles and laying off workers. I think that the big publishers will focus on the most promising AAA titles, only a handful of tiles, but will this be enough to lift of a new generation of consoles ? Why the hack should I spend a few hundred bugs for a console to play the 10th installement of the same game, with the same story and streamlined, softened gameplay ? Maybe it is time to let go of the dinosaurs...
Always looking to improve the non-photorealistic rendering look of Gnoblins, here are two images showing off different rendering approaches, including two new cel shader. Currently the warp approach is in the game.
It is art time again :-) I'm working on the creatures you can encounter in Gnoblins at the moment. Currently there are almost 20 different creatures in the pipeline, most are still in the modelling state. But I've created lot of new blender templates for rigging certain types of models (like humanoid, quadruped etc.), a new texturing template and new tempaltes for baking and rendering models. The current pipeline is modeling->rigging->texturing->animation, all done in blender, even the complete texturing process. Here's a render of a golem I've almost finished so far.
The golem demonstrated the art guide we have developed over the time. The golem is one of the creatures I've created alone from concept over modelling and rigging to textureing, so by definition it is programmer art ;-) Nevertheless, I believe that it is a decent improvement over a simple ascii text in your common roguelike game ;-)
I mean the Gnoblins After such a long time of silence I have some news and something new to watch. Here's a reposting of the official statement:[quote] A long time since we last posted some information about Gnoblins, but eventually we are back with some great news.
First off, I will explain the reason behind the long period of silence. After we have released the first versions of Gnoblins, getting the first feedback of testers and gamers, it got clear, that the game was somewhat confusion , unfinished. Our attempt to create a hybrid game seemed to make it obviously very confusion for a lot of people.
For one we got the RTS gamers who didn't get warm with the first person interface to get into the dungeon building aspect of Gnoblins. On the other hand many people ignored the dungeon building part at all, just seeding a feature poor first person RPG. This put us in a really frustrating dilemma. a gimmick, an additional feature, the first person mode just stole the show of the core concept of Gnoblins.
Afterwards we first tried to fix it, but this was a very daunting experience. Like pulling at both ends of a rope at the same time, supporting one feature results in some design issues at the other end of the game. We had to admit, that we tried to create two games in one which doesn't seem to work very well. At this point we were really close to abandon the project at all.
But we put just too much passion in this project and after getting green-lit, we wanted to change the situation.
The only valid solution seemed a complete restart, going back to the core concept of Gnoblins, focus on this concept and start a massive re-factoring. This has been done behind closed doors, without any public information leaking out. The reason was simply, that we would like to present progress instead of talking about it all the time. We wanted a proof of concept first, a working foundation before presenting it to the public.
This time has come now. Here is the first glimpse a the completely reworked Gnoblins game. This time we focuses completely on the gnoblins and dungeon building aspect, cutting off the first person mode and the RPG player avatar. The game is presented in a more traditional bird-eye view, the dungeon building part is mostly integrated in the view. Thought the player avatar has been removed, some important features has been moved to the gnoblins instead. In example you are now able to take a handful of your minions to explore parts of the dungeon, fight creatures and find treasures.[/quote]
I needed more than a year for the refactoring.. but eventually I'm really proud of it. Here are some screenies
and a video, have fun
Btw. I used blender as video editing tool and I'm really impressed about the quality, workflow and simplicity of the video editing feature of blender, thumbs up
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.
Is it a RTS game, or RPG or dungeon cralwer , shooter ? In its heart it is a dungeon crawler in 3d, a roguelike, with RPG elements. But there are some tweaks. The most important one is, that you are not alone. You can build up a small community of gnoblins, which introduces elements of a RTS game. And no, it is not a shooter.
So, you are running around with an army of gnoblins ? No, the gnoblins live in your home dungeon. They work for you, but the want payment and they demand some level of comfort. The comfort level is represented by the reputation of your dungeon.
So, no gnoblins will follow you, you are running around in the dungeons alone ? You can take a single gnoblin with you as companion.
Do you only play in a single dungeon ? How is the game structured ? You play only in dungeons, but there are several of them. Each dungeon consists of several levels and a certain setting.
Why do I need this gnoblins ? There's no town, there're no merchants. The gnoblins are the only one who are willing to help you. The most important aspect is the crafting. You find equipment, but with the help of the gnoblins you will be able to craft better equipment, potions etc.
Can I only build caves in my home dungeon ? No, later in the game you will have the option to change the appearance of your dungeon, e.g. in a more castle like setting.
Are gnoblin just an other word for goblin ? No, gnoblin describes a fanatsy race of its own. There are goblins in the game too.
Well, what are gnoblins then ? Gnoblins are a mix between gnomes and goblins. They are not as aggressive and dumb as goblins, nor are the as skilled and intelligent as gnomes.
What is perma-death ? Perma-death is a game feature, that when your character dies, you will no longer be able to continue playing this character. This is tightly coupled with the save game. The game automatically saves the game state, but you don't have the option to save/load mulitple states of the game.
So, one unlucky hit by a monster and it is game over ? Not at once. The game features several difficulty levels. In most modes you will have several lives. If you die, you will respawn until you run out of lives. In easy mode your lives will be reseted at certain stages of the game, in hard mode you will have a set number of lifes for the complete game and in rogue-like mode you will have only a single life.
Do you really have perma-death in, and that in the year 2013, why ? Yes, once your character finally dies, it is game over. The reason is quite simple, you design and play a game with perma-death in a really different way as a game without this feature.
What art style is it ? It is a NPR style. NPR stands for non-photorealistic rendering. It is not a cell-shader or toon shader, but it uses outlines and handpainted textures. The detail level of textures,characters and environemnt is low to support this style.
Is this placeholder art ? Emm... no, sorry. The qualtiy of the art might improve over time, but expect that the art style will not change dramatically.
The art style is ok, but the outlines give it such a toon look, can you please remove them ? You can turn them off in the options.
What is the current state of the game ? The game is in the alpha stage. An demo of the game will be/is released in Februrary 2013.
What is the difference between alpha and beta stage ? A game in alpha stage is not feature complete, content is missing, have more bugs, the art is not as polished as it should be etc. A game in beta stage should be feature complete, but you still need to test and tweak the content and gameplay.
What is your target price tag ? In is not decided at the moment, but I think that the final game will most likely settles down in the teens.
What about early access ? We evaluate the possiblitly to release it as alpha funding download on desura. You can then get the game and ongoing updates for a lower price tag.
Will there be a kickstarter campaign ? Kickstarter is currently not planned.
Are these really frequently asked questions or have you invented them all ? Not all, but most :-)
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.
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 !