Jump to content

  • Log In with Google      Sign In   
  • Create Account

Gnoblins - Development journal of an indie game



April update: the new procedural dungeon generator

Posted by , 02 April 2016 - - - - - - · 712 views
Gnoblins, GameDev, IndieDev

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.

 




One week of optimizing: doubling your frame rate

Posted by , 08 March 2016 - - - - - - · 711 views

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).

 

Posted Image

 

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:

 

Posted Image

 

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:

  • physics engine
  • behavior tree (lua)
  • garbage collection (lua)
  • path finding
  • environment scanning
  • filling “rendering command queues” (not API supported yet !)
  • particle processing
  • decal processing
  • audio processing
  • animation processing

 

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 ;-)

 

Posted Image

 

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 Posted Image




February update

Posted by , 21 February 2016 - - - - - - · 694 views
Gnoblins, Indie, GameDev

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.




Closed test session, could need some helping hands !

Posted by , 06 February 2016 - - - - - - · 1,281 views
Gnoblins, Test

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 Posted Image

 

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 Posted Image

 

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 Posted Image




Preparing my engine for Vulkan API

Posted by , 27 January 2016 - - - - - - · 1,018 views

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 .










PARTNERS