next »

[BleakProspects]

A bit of a rant. Having a somewhat frustrating time getting dwarves to place blocks. This should have been an extremely easy thing to do, but for some reason I didn't even think about this possibility when I started constructing the AI system, and I ended up writing in a lot of assumptions about what the AI could do (namely, just putting things in and out of "rooms"). So I've been wrangling this clusterfuck of overengineered, hacky code around to make this happen:



You can see that the dwarves fail to even put down the third block. This is because there is a race condition somewhere deep inside the (asynchronous) GOAP planner that's running each of the dwarves' AI. At the end, all of the dwarves are waiting on an A* plan that will never come.

I'm starting to regret even making this advanced STRIPS-like action planning framework and applying it to the dwarves, since it leads me to write 4-5 hundred lines of boilerplate code to even get dwarves to place blocks, and, as you can see, it doesn't even fully work. The whole thing was basically mental masturbation. But clearly, state machines don't work well here either (as I had to write huge amounts of boilerplate to make that work too).

I may step back for a bit and think very critically about the fundamental things dwarves can do, and re-write the whole thing using a much simpler framework. Probably something that isn't agent based. Like, I should just have a manager that keeps a list of dwarves, understands what hardcoded actions dwarves can take, and then assigns each of them actions in such a way that no dwarf conflicts with another dwarf. And I should avoid over-engineering the thing and just focus on getting stuff to work with as little headache as possible.

[gimymblert]

So it's a problem with priorities?

[Pineapple]

It's okay, Bleak. I still love you.

[Iamthejuggler]

This looks bloody amazing. Totally feel your pain with the whole "overengineered, hacky code". Struggling with some of my own at the moment. It's embarrassing looking back at some of the mess you make when trying to just get stuff to work.

[cragwind]

I can sympathize with your neighbor tiling combinations! Just went through a bit of that myself, but not nearly that many combos.

So what's the bottleneck now? Is the actual rendering an issue, or is it mostly iterating through the data? Are you storing full chunks by slice/row/column, or as smaller chunks for (better?) cache access? Since there appear to be sizable swaths of the same voxel type, can those be aggregated and rendered together or would that be too complex for not much reward?

Any thoughts on using behavior trees for your AI? Don't take that as a hint to go off on a coding tangent though . For my own debugging, I've had difficulty balancing the need to visualize what's going on in my behavior tree with the time it takes to implement the feedback visuals. So far, I really don't have much feedback beyond drawing simple debug gizmos and relying on lots of unit tests for the core.

[eobet]

One of the cool things that the new Sim City did was to treat all moving entities as a particle system, essentially seeing the homes as faucets turning on to spill its inhabitants down the streets, flowing into the factories which acted like buckets with localized gravity in them... sort of.*

Maybe that sort of abstraction isn't necessary here though.

Another new idea is the "flow fields" of Planetary Annihilation, if you care to watch that video. I found it really incredible. Maybe these ideas aren't suited here, but perhaps considering them will yield some new inspiration?

* Sort of not cool that the marketing department then stated the exact opposite, but still.

[BleakProspects]

I've been busy with moving / conferences / job / etc. and haven't done too much work on Dwarfcorp in the meantime.

A few days ago, I was looking at the core of the rendering system to figure out why sometimes, the game runs at >60 FPS, but while in others it runs at something like 10 FPS. I narrowed down the problem to trees/shrubs. If there are more than something like 20 trees on the screen, the game slows to a crawl. It was pretty embarassing, as it caused me to avoid making any videos in tree-filled areas.  In the core of the rendering system, I was doing something called "batching" where I would just draw objects that shared the same properties (like texture) together, but still make a large number of draw calls. For grass motes, I was just putting all the grass sprites into a huge model (that wasted a bunch of memory).

The trouble was, for trees, having too many on the screen would cause a huge drop in FPS due to the overhead of making all the draw calls. Ditto with other batched objects like the particles in the particle system. For the grass, I got decent-ish FPS, but each grass chunk uses a large amount of memory.

I discovered an alternative called "hardware instancing", where you send data to draw the same set of triangles over and over again with different properties. This is perfect for my game, since I mostly just draw the same (simple) model over and over again. With hardware instancing, I can get the speed benefits of putting everything into a model, along with the memory benefits of batching.

I also discovered that since I'm using pixel art without anti-aliasing, I can just skip Z-sorting and instead use alpha testing for binary transparency. This is *way* faster than sorting the sprites, and fixes the z-fighting issues I was having.

I threw together a little test of these two things together to see if they worked in principle. I give you 10,000 tree sprites sorted perfectly and running at >60 FPS:



In the future, I will re-write the way static geometry is handled so that I can take advantage of this and run the game much faster.

I also fixed the AI problems I was talking about by hacking at it and adding a few special cases to prevent dwarves from, say, picking up the same resource or placing a block at the same location. They do this just by "reserving" certain resources for themselves, similar to the concept of how a mutex works in multithreaded applications.

One of the cool things that the new Sim City did was to treat all moving entities as a particle system, essentially seeing the homes as faucets turning on to spill its inhabitants down the streets, flowing into the factories which acted like buckets with localized gravity in them... sort of.*

Maybe that sort of abstraction isn't necessary here though.

Another new idea is the "flow fields" of Planetary Annihilation, if you care to watch that video. I found it really incredible. Maybe these ideas aren't suited here, but perhaps considering them will yield some new inspiration?

* Sort of not cool that the marketing department then stated the exact opposite, but still.

I think flow fields and other techniques for pathfinding are cool for some applications. They're very efficient, and don't require much intelligence on the part of the agent. The trouble is, an agent in a flowfield can't easily form a "long term plan" and will fall into local minima, perhaps getting stuck in a loop. I want the dwarves in my game to be able to decide "I need to go to this stockpile, grab this thing, and then take it over there." without the player telling them each step. At the moment, planning isn't a huge bottleneck -- its just annoying for me to code.

So what's the bottleneck now? Is the actual rendering an issue, or is it mostly iterating through the data? Are you storing full chunks by slice/row/column, or as smaller chunks for (better?) cache access? Since there appear to be sizable swaths of the same voxel type, can those be aggregated and rendered together or would that be too complex for not much reward?

Right now I apparently spend 36% of my time on updating (AI, physics, input, etc.), and the remainder on rendering. I spend most of my rendering time rendering things like trees and shrubs. The actual voxel rendering is now so optimized that it's negligible in comparison. Even rendering the water is pretty fast.

Any thoughts on using behavior trees for your AI? Don't take that as a hint to go off on a coding tangent though . For my own debugging, I've had difficulty balancing the need to visualize what's going on in my behavior tree with the time it takes to implement the feedback visuals. So far, I really don't have much feedback beyond drawing simple debug gizmos and relying on lots of unit tests for the core.

At my job (at a robotics lab), we started out at the very beginning implementing behavior trees, and code everything at that level. It turns out that the benefits of behavior trees (online code creation, inspecting the logic as it runs, automatic parallelization, etc.) are *far* outweighed (at least in our experience) by the numerous disadvantages. To implement even basic logical constructs (like nested if-else statements, loops, switches, etc.) requires a ton of boilerplate code. Sharing state requires boilerplate code as well. Even with operator overloading, or using data files, constructing behaviors is still tedious. I guess this is why most games I have heard of resort to scripting languages of some kind rather than state machines, action planning, or behavior trees.

[gimymblert]

To implement even basic logical constructs (like nested if-else statements, loops, switches, etc.) requires a ton of boilerplate code.

Heh? That sounds very suspicious right there It looks like that's exactly what behavior tree solve ... Maybe I miss something?

[BleakProspects]

To implement even basic logical constructs (like nested if-else statements, loops, switches, etc.) requires a ton of boilerplate code.

Heh? That sounds very suspicious right there It looks like that's exactly what behavior tree solve ... Maybe I miss something?

That's what the tree is attempting to solve, but it does so really poorly in my opinion (at least in our implementation).

This sort of code:

int foo = 0;
bool condition = false;
while(foo > 10)
{
   someFunction();
   foo = someFunction2();
   if(someFunction3())
   {
      break;
   }
   else
   {
      foo++;
      condition = true;
   }
}


if(condition)
{
    someFunction4();
}

Would be really really difficult to replicate with a behavior tree. In our implementation it would probably look something like this:

Code:

bool isGreater(int* value, check)
{ 
   return *value > check;
}

bool increment(int* value)
{
   *value = *value + 1;
    return true;
}

bool set(bool* ptr, bool value)
{
   *ptr = value;
   return true;
}

bool isCondition(bool* ptr)
{
    return *ptr;
}

Behavior someBehavior()
{
    int* foo = new int();
    bool* condition = new bool();
    return 
             Initialize(foo, 0)
          && Initialize(condition, false)
          && While(Behavior(isGreater, condition, 10),
                   Behavior(someFunction)
                && Behavior(someFunction2, foo)
                && (!Behavior(someFunction3) 
                    || Behavior(increment, foo) 
                    && Behavior(set, condition, true) 
                    )
                  )
          + (Behavior(isCondition, condition) 
             && Behavior(somefunction4));
                   
                
}

In other words, pretty horrible. If you have some better way of creating behavior trees, please let me know!

[gimymblert]

I haven't implemented it yet, but was interested to know about that, in case of I meet that. My understanding come primary from http://aigamedev.com/insider/presentation/behavior-trees/ and some article on altdev. Personally I want to toy with hybridization with utility tree (utility match concept on a blackboard that is used by the BT) but i'm not there yet in my project.

But it looks like you want to integrate an "action" directly into the tree. How it was presented to me, the tree is just decision logic that manage actions and conditions. Maybe it's a granularity problem? Maybe this kind of code should be hard coded in a task node.

The question is, does behavior tree in robotics are "exactly" the same than in game programming. There is precedent for adapting terminology and concept to game needs.

This is loosely how i see it:
(sequence node)
-sequence node (loop decorator)
--test
--task2
--priority node
---sequence node
----test
----break
---sequence
----inc
----set to true
-sequence node
--test
--task

Now I can see the "&&" is the sequence signifier "||" the priority but what is "+"

Remember I'm a non programmer too, more like a designer, code is way slower for me to parse and write. Behavior tree might be more suited for our kind, since programming is logic you don't really need it as a programmer and just have to implement it directly?

RDIT:
http://aigamedev.com/open/review/planning-in-games/
Maybe this might interest you if you haven't seen it yet.

[BleakProspects]

Now I can see the "&&" is the sequence signifier "||" the priority but what is "+"

In our implementation, "&&" = sequence, "||" = select, "+" = sequence which continues regardless of success or failure. And yeah, granularity is probably the issue.

[BleakProspects]

Yet again development has been kind of lacking as Dwarfcorp has moved onto the back burner due to life things. However, I have had a little time here and there to work on it. I have been looking into improving performance a bit more, and now it no longer really slows to a crawl whenever I go into forests or whatever. I've also made the particle system much faster. As a consequence, I can have nice particle effects like this (using basic collision with the world):



I also made a minimal implementation of fire (which required some additive particles):



The project has kind of exploded into a billion different unfinished directions. It's a bit hard for me as one person to keep track of. If I'm going to continue I need to focus on a few minimal features to make an interesting game and then just disable the other ones for now. That was my original plan, and I kind of strayed from it. The trouble is, for this kind of game, that minimal set of gameplay features is still huge. I need to do the hard work of constructing a set of coherent design goals and working out exactly what I need to implement them.

[Pineapple]

Get some people to help?

[Cellusious]

 

[Barch]

If you allow it for other people to mod it easily what you do is create a good game that can be perfected by a group of people larger then you can imagine;

For example - Morrowind

Morrowind was made in 2002 full of bugs errors annoyances graphics are outdated as well combat was shit but thanks to the modding tools and community that spawned from that. We saw a game that turned into this That can still hold up to games a decade later, a game that lasts. I'm talking about a full scale makeover for the game, two full (about double the original game) community expansions for it as well a community of people rebuilt an equivalent sized game o the original release amazing.

Many indie games still do not see the value or are too lazy to implement these features when in truth they can take your games in directions you had never dreamed of. Because even if your life seems complex. All of us here have as rich backgrounds as you! teeming with backgrounds as artists, programmers musicians designers storytellers. We are masters - novices, they will fill in the blanks of faulty code, they will provide better soundeffects. They will fill your game with music, quests, storys etc. But only if you give them the tools to do so. Like you do right now with the code because you have all the means. provide community the means. This is how the game seizes to be a game but the canvas in which we draw our dreams in

Creators make the game - Modders expand and perfect it.

[eigenbom]

Yeah, focussing is difficult, mainly for your motivation, as the once huge idea you had now seems tiny. I went through a similar thing with Moonman, and the scope of the game is now much smaller than originally planned.

I think your best bet is to make a really niche game, that does something quite different to the status quo. So write down the top 3 things which will make your game stand out. Is your game like The Settlers, like an RTS, or like Lemmings? This blocky RTS got 500k from kickstarter, so there's some info on what not to pursue.

I looked at games similar to mine (KAG, Crea, Starbound, Epic Inventors, ...) and tried to figure out what I could do that was different enough to set my game apart. Out went multiplayer co-op (for instance), and in came some more rogue-like ideas.

As for modding, you have to have a strong game there already, otherwise you're just giving people a paint program and telling them to have fun with it. People modded Oblivion because it was a great game. Level editors aside, in general I don't think solo developers have time to build a great game and a great modding system.

[Barch]

the modding system doesn't have to be great - it could be something like dwarf fortresses system. Where the external resources are loaded outside the program, statistics and that. That way your allowing for external resources to be changed texture packs that type of thing. This could be things like code loaded as a text file while the base game is still inside.

Of course build a great game then if you have time at least provide the ability to mod

[Seiseki]

The project has kind of exploded into a billion different unfinished directions. It's a bit hard for me as one person to keep track of. If I'm going to continue I need to focus on a few minimal features to make an interesting game and then just disable the other ones for now. That was my original plan, and I kind of strayed from it. The trouble is, for this kind of game, that minimal set of gameplay features is still huge. I need to do the hard work of constructing a set of coherent design goals and working out exactly what I need to implement them.

So what's needed for the game to be playable?
Attacking enemies, disasters or accidents. (anything that hinders the player and forces them to deal with stuff)
Resources/Resource gathering.
Buildings/Rooms that produce things/refines resources.

I think you should focus on the crafting and building. Since that's what drives the game forward.

[BleakProspects]

Good points to everyone. I spoke with the project's artist and we developed a game plan for going forward. Long story short: we're confident that we have enough content to start fundraising. We're definitely going with kickstarter. Not ready to share any details on that yet. Currently developing a bunch of meta/marketing stuff + mockups + videos in a marathon of work. Part of that work is updating the site to make it better:

http://www.dwarfcorp.com/

Hopefully I will be updating both here and the site simultaneously from now on.

[BleakProspects]

Some goblins: