I'm back with a new progression video. I had skipped the last month update due to not having something useful to show off. I had optimized the engine and went from 20-25 fps to a stable 60 fps in my test environment. But it is really hard to display the effect of a performance optimization ;-)
At last I moved the level generation from a designed and semi-generated approach to the new, completely procedural, in-game level generator. In combination with the reworked sewer level design finally something to show off.
Here is a new video dev-log showing the sewer level generation step for step.
So, I have finally took the time to optimize my game. One week later and the following test scene went from ~30 fps(35-40ms) to ~60fps (16-17ms).
Well, it is not a secret that my engine is home brew and that there were and are enough optimizing potential hidden. The trick was to start profiling it in more depth. Therefor I started with extending the in-game profiling mechanism by adding a time-stamp based, detailed (microseconds level) frame logging of single threads and the GPU.
Getting a profiler I imagined was hard. Gdebugger was not enough. Many tools support DirectX , but not OpenGL, at least only halfhearted. So my first attempt to write a CSV file and transform it into a diagram with OpenOffice failed. It was hard, slow and really clumsy to show lot of data (several thousand timestamps per frame). The rescue comes in form of SVG. Scalable Vector Graphics. Really easy to generate, out-of-the-box support by browsers, good display performance, you can zoom in and out easily, and finally you can add meta information which will be displayed when you move over data with the mouse. Really perfect ! It looks like this:
So, after getting more detailed information about your game performance I was able to start tracking down issues. First off, I needed to get rid of sync points between the GPU and CPU. That occurs when the GPU and CPU wait for the other one to finish processing of certain task, i.e. uploading a buffer. Therefor I added some double and triple buffers to process data on the CPU while the GPU renders the result of a previous frame.
The next step was moving data processing from the main thread to the worker threads. Here is a list of jobs, which are processed in the worker threads now:
behavior tree (lua)
garbage collection (lua)
filling "rendering command queues" (not API supported yet !)
Moving this into a worker thread often requires some form of double buffering and sometimes it introduce some funny bugs, like this new alien gnoblin version ;-)
Finally I tracked down an old test rendering pass (additional geometry pass). And I only optimized a single shader by adding branching and reordering the rendering order.
There is still lot of potential in the expensive post-processing shaders and submitting the data to OpenGL (still not really good batching support), but for now I 'm quite happy with the result
Welcome to the February update.
This time a progression video to show off the new tutorial system, the garrison system, new difficulty levels and finally a much needed end game screen.
Currently we are working on expanding the room system to support a more compact dungeon design. This will most likely result in an improvement of the room art and additional game mechanism, so stay tuned for the next update.
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
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 .
Welcome to the January update. The focus of the last two month was the transition of the game from a developer version to something you should give someone for testing. That is polishing the art, the interface, play testing, tweaking the game mechanism, finishing all the incomplete stuff like guides, descriptions, animations, missing items and a lot of balancing.
But I'm really satisfied so far. I'm able to beat the level in half an hour, knowing exactly what to do. Others needed one to two hours, which should be a good play time for a standard level. Thought, there is still enough to do, the game level is in a good shape and I think about doing a closed test next month. Besides all the game testing and balancing I have finally added large creatures to the game, a garrison game mechanism, guard towers and more minions. There are currently around 10 kind of minions, mostly gnoblins. And eventually I added some new nasty creatures with some surprising special abilities. Here's a screenshot of a thriving dungeon.
Here is the September developer log. This time I'm showing off the development of the mining interface over several versions. Even if the current interface version seems to be a logical way to approach the interface, lot of constraints and limitations often ensure, that you need lot of design attempts until you come up with a suitable solution.
The real challenge in designing the mining interface in Gnoblins was the dungeon building system. Most dungeon building games are grid based which makes dungeon expansion a lot easier than the room-based dungeon expansion approach used in Gnoblins.
Here's the august update. This month I worked on improving the accessibility of the user interface. A lot of the more complex features have been moved on the main screen, especially the mining map has been removed and integrated directly in the game world now. I will show off the improvements next update, after testing and tweaking it a little more.
For now here an other improvement. A major goal this month was to increase the readability of the game world. The old version was too dark, your minions were hard to discover and it was not really easy to check what your minions are doing at the moment. Therefor we updated the rendering, make it more colorful and activating the toon-shading again to improve the perception. Further on I added new icons hoovering above your minions to show what they are doing currently.
Here is a comparison of version 0.2.39 and 0.2.40.
Although I added a new quest system, which will be introduced in one of the next updates.
So, the month is almost over and no update up-to-now. There's not much to show off. For one I was on vacation, on the other hand I play tested a lot and refined/rebalanced the game play.
The gameplay is more streamlined now. I have removed the crafting screen and transferred the game mechanism to the main screen. For one you no longer need multiple steps to craft stuff, you can hire minions directly from the main screen, research has been automated, you no longer need to craft interstage products. All this removed a lot of complexity.
On the other hand minions can carry objects now, which adds a lot of visual feedback of what minions are doing at the moment. I.e. wood logs needed to be transported to the carpenter shop for further processing and downed minions are carried to a bed room to recover.
And eventually you no longer need to place single furnitures, instead you can construct whole rooms. I.e. a bed room or a guard room. Here is a screenshot of the four most basic rooms every dungeon need as foundation.
It is time for an other developer log, this time in video form. In one of the previous videos I demonstrated the water simulation capabilities in Gnoblins and I have promised to talk about further simulation stuff. Being a dungeon building game, Gnoblins has a quite dynamic level layout and the water simulation doesn't make it easier leading to some interesting questions. How does water interact with the level, with objects, with plants ? Where do plants grow ? Mushroom ? On soil, on rock ? In light or darkness ? These are all questions I wanted to consider when developing an environment simulation and you can now watch the result in this video. Have fun and stay tuned !
Currently I'm playing around with the material system of Gnoblins. Many models in Gnoblins are recoloured dynamically to have the option to quickly add new colour variances. I wanted to add material which looks more like metal which isn't easy when working with handpainted textures only. I've come up with a system displayed in here:
As you can see, there are several materials displayed. For one I just recoloured the skin and clothes, or make the gnoblin look like gold or silver and play around with other effects.
Well, maybe a little bit. In my answer to this post over here, I mentioned, that I use HTTP as guideline to refer method/function calls in my game. I expected, that some developers will think that I'm insane, and this might be true to some degree . Still I had my reasons to go this way and I want to talk about this.
[sharedmedia=gallery:images:6362] When you develop, you need to consider many aspects. Clean code, bug-free, performance all the things which seems obviously, but you need to regard many more non-functional requirements. Budget, time, maintainability and many more. It is often just too expensive and clearly unnecessary to write the best code ever.
Being the sole developer in a hobby project puts a lot of pressure on you if you want to approach the goal of finishing your game in your lifetime. I've learned,that easy, fast to code and maintainable code is a key-element to support a hobby project of this scale. One reason to add (fake)HTTP request to my game was the easy maintainability of it. I don't use the full HTTP technology stack, just the general syntax and it reminds a little bit of REST, still parsing the HTTP string seems unnecessary, and to be honest, there are better and faster ways to archive it. Additionally I use it only for gamelogic events, which are executed quite seldom. The main benefit and the first reason to add it, was to support multiple Lua VMs, but this could be handled in other ways.
Nevertheless, so it was my decision and I believed, that it would be fast enough in my special case to justify the usage. So, here are some performance measurements. I tested it with 100 active game entities and measured 24330 frames. The decoding function (written in lua) was called 94091 times, that is roughly 4 times per frame for 100 entities (~roughly the max number of active entities in a game session). That is the first proof, that it is called quite seldom. All the decodes used 0.09% of the total frame time (~33 ms total frame time). Considering that the measurement will cost some time(I think that a large chunk of the time is sacrified to query the OS timer two times per call) and that it is written in Lua instead of C++. The decoding is neither rocket science nor of rocket speed, something you should review if you need to call it more often. Nevertheless, the key element is, that this kind of processing is called quite seldom in my case.
Still, this is not meant to be a general rule. One must evaluate the context you are developing in. Are you coding your hobby-game at night and weekend or are you working on a top AAA title with whole coder teams working on single game parts ? Does your game need every CPU power you can get, or can you afford the luxury to ease your development time. With the right reasoning everything should get a chance, even (fake)HTTP request in your game ;-)
I've added a screenshot of the debug output of a single entity, as you can see, the whole entity behavior is saved in character attributes utilizing HTTP-syntax.
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.
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 ;-)
Recently I worked on the fluid simulation in Gnoblins. Until now fluids in Gnoblins were merely a visual effect, but under the hood it was already a working simulation. To utilize it completely I needed to introduce the ability to swim. So, gnoblins and other creatures are now able to swim now. When swimming, each creature will be affected by an effect. Most creature will be slowed down and get exhausted faster, but there will be although creatures, which will get faster, get healed or get damaged.
I called it fluid simulation because it is not very good suited to represent water in a realistic way. For this task the simulation is not fast and detailed enough, but for slow moving fluids like lava and slime it works great.
An other feature I have added recently is the addition of environment agents, how I like to call them. Basically it is an AI which manipulates the environment. Currently it is able to change a lot of things, but I will present this in an other post. For now it is only important, that with the help of these environment agents the fluid is able to interact with static environment objects like torches. So, when watching the video take a look at the torches when the fluid level rises.
So, why add a fluid simulation to Gnoblins ? Well, I think that it smooths the way for some interesting gameplay. For one you are able to control the fluids by using doors or better floodgates. Doors will only slow it down, whereas floodgates will stop them completely. An other effect is, that fluids will damage or destroy your furniture and limit the abilities of your minions or even hurt them. On the other way, you could use it to fend off enemies.
Eventually I want to talk about what we are working on currently. First off, I have updated two additional tilesets for the dungeon, the sewer and castle/fortress tileset. I will show them off in a future post, I think that one of the next levels will be a sewer level utilizing some slimy sewage water :-) An other task is the addition of more creatures. Currently there are 6 different kind of creatures, each with 2-4 variations, which are in the state of getting finalized. Creatures are the most costly element of Gnoblins. You need to model, texture, animate, add some behavior and add some variation to them. There's a reason that many of the 100-200 people working on a AAA title are artists.
There is some interesting stuff in the pipeline I will show off in future posts, so stay tuned
In the previous posting ServantOfLord mentioned, that water could be interact with objects like torches. From a technical perspective it comes down to checking masses of objects. In the past I already thought about how to implement such a massive check in a real time game like gnoblins. One thought was, that torches run out of fuel or that plants/mushrooms grow over time and invade parts of the level, that lava destroys the environment and modifies the ground etc. In fact it is an environment simulation, and a quite large one. A level in goblins could have up to 40.000 passive objects and up-to 4.000.000 mushrooms and plants on the ground. Even if you only utilize 10% of this, it would be 4.000 objects and 400.000 plants.
So, what are the requirements and limits of such a simulation system ? 1. It should not try to update the whole level at once. 2. It should utilize multiple cores. 3. It should not be time-critical, a more relaxed approach would help a lot. 4. The user should be able to choose the update speed of such simulation. 5. The game design should be robust when regarding the speed of the simulation and the out-come of the simulation.
The basic idea I have is to add environment agents, objects which are like any other standard object, but are invisible and static. Each environment agent will grab an area of the level, analyses and modifies it. As every object in gnoblins, each object is able to execute its AI logic concurrently. I utilize this by adding 1 to 100 environment agents (player can choose). More agents will result in faster simulation.
This sounds interesting: 1. A light source is close => grow some plants 2. A water source is close => grow some mushrooms 3. The water level is to high => damage furnitures, turn off torches
But I need to keep in mind, that when running as low as 20 FPS and with only a single environment agent, you would update each tile in the worst case every 3 1/2 minutes. Okay, with some optimizations (analyse multiple areas per agent, use at least 3 agents), you could bring the update interval down to 10-15 seconds which sounds okay. Just don't expect that a little drop of water, once it touches a torch, will destroy it instantly. But this is something I can live with.
In gnoblins I use a dynamic water system, that is, some areas are flooded, you can flood or drain them. The question is now, how do your minions or other creatures react to water ? This is no trivial game design decision and here are my musing and thoughts about this issue.
First off, what options do you have when you detect that a creature is in water ? 1. You can kill it immediatly. Well, that would be little bit too harsh, wouldn't it ?
2. It would float helpless on the water, swinging wildly its arms and die after a certain time from exhaustion. Thought you could try to drain the area, it would be very harsh too. There's no option to help your minion if you can't reach the lever to drain the area and it would be a too easy way to kill of invading enemies.
3. The creature can swim around, but will not be able to do any other actions like fighting or operating a lever. Hmmm... sounds better, thought you can't operate with your environment or fight off any danger.
4. The creature can swim around and do most actions and still is able to fight to some degree. Well, we are approaching a game design zone where swimming is more or less just a visual effect and don't have such a strong impact on the game play. So, what would be a good solution ?
After some musing I choose to continue with 3. Creatures can swim, but will not be able to interact with its environment while swimming.
Done ? No, we need to check the game mechanism in more detail. Here are some questions: 1. Can a creature reach a goal by swimming through a pool of water or does it always try to avoid water ? The option to avoid water sounds easy, but what would happen if one of your creatures is trapped on a island ? You have no option to help it.
2. What is the behavior of a creature, if it is suddenly in water ? It should try to reach dry ground, shouldn't it ? But this could interference with commanding your minion to reach a certain point: entering water..eehh..water..leaving..ahh I need to reach my goal..entering water...eeehhh water...
3. Should it be allowed to have a goal in water ? This would result, that a minion would try to reach an area to execute an action, which can't be executed because it is under water. A movement command on the other hand would be valid. But what happen, when you start your movement at the time where the goal is not under water, but at the time when you reach your goal, it is suddenly flooded ?
4. Should doors work in water ? It is already hard to detect if a door is actually in water, there are floodgates, so on one side there's water, on the other side none. Not being able to interact with your environment could be deadly for your creatures, especially if you are not able to operate doors. Do we need a special rule for doors ?
5. What about flying creatures ? Hmmm.. flying creatures can ignore water, can't they ? What about interacting with the environment ? They should be able to fight swimming creatures, but can the interact with objects under water ?
6. Is water a safe haven from enemies ? Ok, most creatures can't fight when swimming. So, just command your minions to enter water to avoid some strong enemies ? This would be too easy. Water must be dangerous if you linger too long in it, so we need to drain your power during swimming resulting in exhaustion after some time.
Hmmm..I need some ruleset for the behavior of creatures and water. This ruleset should answer all the questions from above in a satisfying way. Here's my first attempt: Rule 1: A none-flying creature will not fight when it is currently in water. Rule 2: All other commands and tasks, which are planned by a creature do not depend on the creature being currently in water. Rule 3: Planing does ignore goals being in water (exception: flying creatures targeting swimming creatures). Rule 4: Planing adds a penalty to ways leading through water, but it does not completely avoid water. Rule 5: Doors can be opened by a creature being in water. Rule 6: Creatures can't interact with any other object in water. Rule 7: When idleing/roaming a creature try to reach dry ground. Rule 8: When in water a creature will exhaust much faster.
Eventually I need to think about how to implement all this rules. Impl 1: The engine needs to sample the water level at a given position. Impl 2: The pathfinding system needs to consider the water level at each waypoint. Impl 3: A parameter to modify the way costs. Impl 4: Each creature needs a swimming animation. Impl 5: No automatic swimming detection in the animation system, the game logic should add an animation overlay when the creatures body is deep enough in water. Impl 6: Creatures in water needs to exhaust much faster. Impl 7: Lax animation boundaries to avoid animation flipping all the time at the water threshold (eg. enter swimming animation when water is 1m deep, exit animation when water is less then 80cm deep). Impl 8: Sound overloading, we don't want to hear any footstep sounds when swimming. Impl 9: Target planing, check if a target is in water at the time of planing to avoid unnessary decisions. Impl 10: A in_water state at the entity to quickly check it in game logic. Impl 11: When executing an action, abort it once the creature detects, that it is in water. Impl 12: Physics: no change in the physics part, the entities will still be grounded. This way I will avoid trouble with doors etc. Impl 13: Rendering, add a visual flag to indicate, that the rendered object is floating at the water surface (Performance bonus, only rendered objects needs a detailed evaluation of the surface)
Sounds solid, enough to start a first implementation. Coding time
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
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.
It is a very long time since I last posted about gnoblins (almost 2 years). After a major shift in the game design and some major refactoring actions, I'm stablilzing the gameplay at the moment. I will present the result of all this refactoring/redesign in the future, for now I will write about my experience with the attempt to crash my own game engine...
From time to time I want to break my engine/game, pushing it to its boundary until it crashes or collaps. I think everyone should do it to learn more about its weaknesses. This shouldn't be too hard considering that my engine is a homebrew, hobby product.
Testcase: My testcase is spawning lot of entities, all having their individual AI, movement, sensory scanning, pathfinding, animation etc. active. I want to spawn them in a single spot. This is important, because many systems, including mine, scale better with entities distributed evenly in the world. But if you pack them all in a single spot, you suddenly have very high context density, you need to render them all, you need to simulate them all etc.
Okay... Let's go
Level 1: Task: Spawn 200 entities in a single spot. Assumption: Crash !
Hey, it crashed, my assumption was right Better said, some asserts kicked in. I use almost no dynamic allocation once the game is running. My engine design idea was: I will have enough memory, concentrate on performance first (and I dislike dynamic memory allocation and garbage collection). So, I needed to increase some constants.
Level 2: Task: Yet, again spawn 200 entities in a single spot. Assumption: Massive slow down..
It didn't slow down.. not a lot... well, party ... next step
Level 3: Task: Spawn 1000 entities in a single spot. Assumption: Massive slow down..
It didn't slow down...yeahh ... WAIT... Something is wrong . After watching the scene it didn't look like 1000 entities. *Facepalm* .. The entity pool is kicking in, reusing entities. Taking a look at the pool size, only 70... atleast the system handles massives entities spawn in a robust way.
I increase the pool size to 1000.
Level 4: Task: Spawn 1000 entities in a single spot. Assumption: Massive slow down.. finally ?
Crashed again (asserts). The problem is, that I spawn 1000 entities in a single frame. Fixing some parameters and finally not crashing..
Level 5: Task: Smaller steps, lets start with 250 entities Assumption: Massive slow down.. finally version 2.0 ?
Yep, its slows down finally. Entities spawn and start moving... well atleast partly. It seems that only groups of entities start moving, group after group start to move. A second effect is, that almost all ignore an enemy entity standing next to them.
Well, every entity is able to start multiple (4 at the moment) scanning/pathfinding requests which are processed concurrently. If the entities does not receive the answer in ~1-2 seconds, it will timeout and restart the request. The issue seems to be, that some entities will timeout at first, starting a new request. Starting a new request removes the old one from the processing queue and adding the new one at the end. This seesm to result in starvation. Once the requests of the first X entities are through, the workload on the multithreaded pathfinder/scanner is reduced and the next group of entities will receive their response in time. I could make it more robust (instead of enqueue at the end, exchange the old request with the new one). but this isn't my requirement yet, so I leave it for now.
Level 6: Task: Go for 400 entities Assumption: Massive slow down..
Yep, it goes down. From 90-110 fps to 6-8 fps at first. Later it crawls to 0.6 fps at times. The problem is a spin down (longer frametimes => more processing per frame). This was expected. Every single entity scan its environment for other entities to do steering, it scans for threats, it scan for tasks to do, it tries to find a path to its goal, collision detection with the world (not with other entities), AI update method and behavior trees.
Woah... what happens... suddenly I got 50 fps ? Hmm...ahhh... all entities are dead now. The game tracks invading entity raids and cut them off after a few minutes to prevent a system collaps during long game sessions. At least it works and the rendering system seesm not to be the bottleneck.
Level 7: Task: Final test with 100 entities only, which is more than the expected maximum number of active entities in a game session. Hope: Acceptable slow down...hopefully
Yep, it works finally like a charm. All entities start to react immediatly, hacking down two minions and a bed. The game is stable at ~330 MB, ~80 fps, 30-50% CPU (quad core) with almost equal distribution on all 4 cores ( no core reaches its limits).
Conclusion: I know, that a AAA engine is by far more powerful, but on the other hand it is really satisfying to see of what your own engine is capable of. There's enough potential for optimization left over, but eventually I'm really proud of result.
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.
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 !
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...