next »

[BleakProspects]

As far as working on the game code goes, I have been doing these things:

1. Attempting to port to MonoGame. This is not going well. Several important features are missing from MonoGame. Most notably, hardware instancing is missing.

2. Fixed subtle error with C# random number generators not working when used in multiple threads

3. Considering ways of making the AI easier to debug and extend. Embarrassingly, I'm thinking about abandoning GOAP and symbolic planners altogether and just going with scripted co-routines again. State machines are obviously not the answer, but neither is planning. I also want to avoid behavior trees. The Dwarf AI does not need to be as complicated as I had originally hoped, and this symbolic planning stuff is mostly academic anyway. It's very hard to debug, and I end up writing hacks to get around its limitations.

I've begun to suspect that most "AI architectures" are invented with non-parallelism in mind. They're just little tricks to allow an agent to do something very simple every tick without blocking the whole process. Unfortunately, this leads to programmers creating all kinds of horrible boilerplate code which gives nothing over just programming the AI as a straightforward script which is assumed to run asynchronously.

It's true that I can't handle every case using a script, and that some intelligent planning would solve more kinds of problems -- but the sheer complexity of the planner makes it impossible to debug, and similarly makes it impossible to modify by users.

I'm just ranting here, but basically what I *really* would like to do for every AI task is just write a function called "Solve()" or something along those lines which behaves like a complete program and is allowed to block all it wants. Threads would work, but they incur huge amounts of overhead and synchronization boilerplate. That's why coroutines are appealing.

[Graham-]

AI imo is about reducing primitives in a system to digestible chunks. ... all of those things you listed are just tools. state machines are god awful. they just teach you about systems. but they are so unnecessarily complex because they assume relevant behaviour for every state. usually you want to severely restrict the scope of any "state." state machines accomplish the opposite of this. but simplicity is often overlooked by ai designers ("theorists").

multi-threading is a whole different thing. normally there is one or two really good ways to split your code. general splitting is often complete overkill.

(state machines are okay if they pepper a system, but they should not be a back-bone because they are so restrictive).

If you discuss the details of a particular problem then I can offer better advice. ai is my forte.

[doihaveto]

I'm just ranting here, but basically what I *really* would like to do for every AI task is just write a function called "Solve()" or something along those lines which behaves like a complete program and is allowed to block all it wants. Threads would work, but they incur huge amounts of overhead and synchronization boilerplate. That's why coroutines are appealing.

I'd definitely support time-slicing a serial algorithm across multiple frames. Parallelizing search is not going to be fun, especially wrt synchronizing access to the shared data. Fortunately, C# has coroutines built-in.

Then again, planning might be overkill anyway. What are your particular needs? Most games are so simple that people implement the equivalent of universal plans (in the Schoppers sense), often represented as behavior trees, because their state space is small and predictable - instead of trying to create plans on the fly...

[Tynan]

Regarding your AI issues, I may be able to be of some help.

I've been tackling these problems pretty hard over the last six months through the development of Eclipse Colony. There are a lot of interrelated problems and needs; I've redesigned the whole thing at least three or four times and come up with an expandable, clean, traceable, fast, debuggable way of getting them to coordinate among lots of tasks and competing priorities.

I've found this to be by far the most difficult part of making the game. The rules of the world are relatively simple - what's hard is making an intelligence that can understand and interact with those rules.

I'd be happy to write something up about my solution if you like.

[gimymblert]

Yeap planner and behavior tree are pretty indistinguishable in game industry, planner are going out of favor, at least PURE planer

[Iso]

1. Attempting to port to MonoGame. This is not going well. Several important features are missing from MonoGame. Most notably, hardware instancing is missing.

Seriously? Wow, good job I didn't port to MonoGame yet.

What are you using the instancing for as I noticed your game's graphics mainly seems to be sprites on billboards. If you're using it for the blocks themselves, you could try looking into VertexBuffers to see if they work. That's what I'm using at the moment. Just be careful you don't load too many on to the VRAM at once.

[BleakProspects]

Okay, so I've been working on redoing the AI completely to use Behavior Trees rather than GOAP. Unfortunately, action planning, while awesome in principle, is too difficult for me to extend and debug. So I basically ported over the behavior tree library from our robotics project, and started writing dwarf behaviors in it. I also wrote a simple behavior tree viewer that made it much easier for me to see what was going on. This is now present in 1.024.

I've been looking at getting rid of all the initialization cruft and throwing it into JSON files. Also, thinking about getting rid of XNA content pipeline and loading most assets on our own. All of this to allow for more modding and customization of our game. This part is nowhere near done yet.

We also have a bunch of art coming down the pipeline.

PhD program has started. I have way less time now, but still make about as much time as I was last year for the game. This means we're going to have to start using the money to contract help. We're going to start this in private among people we know.

All of the materials for rewards have come in, but we have yet to ship them due to a lack of a working label printer (coming in the mail).

By the way, as for digital distribution:
* We're currently #12 on Greenlight. Whenever the next batch is, we'll be in it.
* I've been in talks with the Humble Store. We will probably be able to distribute keys through there.
* Desura has also talked to us.
* Adult Swim Games contacted us and asked to discuss "possibilities" for DwarfCorp. We haven't responded.

[BleakProspects]

1. Attempting to port to MonoGame. This is not going well. Several important features are missing from MonoGame. Most notably, hardware instancing is missing.

Seriously? Wow, good job I didn't port to MonoGame yet.

What are you using the instancing for as I noticed your game's graphics mainly seems to be sprites on billboards. If you're using it for the blocks themselves, you could try looking into VertexBuffers to see if they work. That's what I'm using at the moment. Just be careful you don't load too many on to the VRAM at once.

Everything in our game is a sprite on a billboard, which is why instancing is quite nice. Storing a vertex buffer for all the sprites would be really memory intensive. The blocks themselves are already vertex buffers.

[Pineapple]

* Adult Swim Games contacted us and asked to discuss "possibilities" for DwarfCorp. We haven't responded.

Dammit. I hoped the alias would at least get me a chance.

[JobLeonard]

We're going to start this in private among people we know.

Watch out with that - on one hand, friendship can make them go the extra mile for you, but on the other hand you need to be able to be a bit merciless if the result isn't as good as what you paid for.

[BleakProspects]

Monogame porting is coming along. Weird stuff is happening with the depth buffer right now...

[JobLeonard]

Actually took me a while to spot the error - probably very visible in motion though.

[Iso]

Okay, so I've been working on redoing the AI completely to use Behavior Trees rather than GOAP. Unfortunately, action planning, while awesome in principle, is too difficult for me to extend and debug.

I've been using a more restricted idea of GOAP and this worries me. What exactly became so difficult about them? I've had no problem debugging them so far, as every action is tightly defined, whilst larger 'jobs' are just a collection of small actions. For me, it's been very easy to extend as I can add a new job by just building a list of actions (Find item, calculate path, path to item, get item, calculate path to destination, path to destination, interact with item + target).

Surely in such a complex A.I. driven system, a behaviour tree is just going to have so many different possibilities/paths that you're going to have countless amounts of branches? I'm just speculating though as I'm still very new to game dev. I originally had behaviour trees too until I dropped it because it was so polluted with nested ifs.

Also, what do Adult Swim want with DwarfCorp o_o? That's definitely something I didn't expect to hear!

[gimymblert]

Maybe the problem is concurrency and coordination on same task

[Excy]

This game scares me.

[emacs]

Congrats on getting Greenlit!

[Whiteclaws]

Yeah , congrats 

Also , you program your robots with c# ?

[BleakProspects]

We got word that the game was greenlit today!

Also , you program your robots with c# ?

No, C++ mostly, with python sometimes.

Okay, so I've been working on redoing the AI completely to use Behavior Trees rather than GOAP. Unfortunately, action planning, while awesome in principle, is too difficult for me to extend and debug.

I've been using a more restricted idea of GOAP and this worries me. What exactly became so difficult about them? I've had no problem debugging them so far, as every action is tightly defined, whilst larger 'jobs' are just a collection of small actions. For me, it's been very easy to extend as I can add a new job by just building a list of actions (Find item, calculate path, path to item, get item, calculate path to destination, path to destination, interact with item + target).

Surely in such a complex A.I. driven system, a behaviour tree is just going to have so many different possibilities/paths that you're going to have countless amounts of branches? I'm just speculating though as I'm still very new to game dev. I originally had behaviour trees too until I dropped it because it was so polluted with nested ifs.

Also, what do Adult Swim want with DwarfCorp o_o? That's definitely something I didn't expect to hear!

Debugging the planner is hugely complicated and annoying. If you get the set of rules wrong, and the agent's internal state is not updating correctly, you will just get weird behavior and have no idea what is happening. In my case, dwarves were just picking up crap randomly and putting it back down for no reason, or (most of the time) just stopping in place as a "find whatever" or "path to whatever" failed over and over. To combat this I was just literally inserting pre-computed solutions to some sub-tasks, which made the planning useless anyway. Behavior trees and other such hardcoded solutions are obviously much more limited, but at the same time the behavior is repeatable and much easier to debug.

As for Adult Swim, I haven't talked to them. They've been snapping up indies lately (Paranautical Activity, Volgarr the Viking, etc.) and I think they wanted us on that list.

[JigxorAndy]

Congratulations on Greenlight! Looking forward to seeing this one on Steam!

[John Warner]

Fantastic!! Way to go, I look forward to seeing it on Steam. I voted for this thing.