So here's how the game world works

I've come up with an explanation for how the game world works, or at least how part of it works.

In Dungeon World, the monsters are magical creatures. There's a fair amount of loose magic floating around, enough to sustain the creatures, so they can exist perfectly fine just wandering around loose, which is their natural state. They also eat normal food, with most magical creatures having a particular fondness for rat.

In Dungeon World, there are also wizards. Through intense study, wizards have learned how to tap into that ambient magic and use it to produce incredible effects, often amassing great power for themselves along the way.

Eons ago, one of the most powerful wizards ever to live discovered that a very small portion of the population had an innate ability to absorb, concentrate, refine, and channel magic. Some of the individuals with that gift became wizards, their power subtly boosted by their natural talents, while most went about their lives blissfully unaware of their potential. This ancient wizard, Sheifan, was one of the gifted, and discovered that with the proper ritual, he could channel some of his power to magical minions, greatly increasing their power and resiliency. He raised an army, marched on the civilised nations, and was crushed brutally when he forgot to bring enough food for his minions and they deserted him. They carried with them the recipe for the ritual of binding, and now most monster tribes have at least one wise old monster who knows how to perform the ritual.

Monsters benefit greatly from association with a Channeler. With the refined magical power supplied by their liege, monsters are able to learn much more quickly, and steadily develop their powers. Many of them grow steadily stronger, faster, and smarter as time passes, and virtually all monsters gain new abilities with continued service to a powerful lord. Most importantly, while a normal monster can be disrupted and even killed, a monster linked to a Channeler has a constant stream of magic coming in to keep them healed. The end result is that a monster serving a Channeler can be knocked down any number of times but never completely killed until the Channeler is killed.

Channelers, in turn, gain virtually nothing from acting as living power sources. They gain no abilities and no powers, although they also aren't weakened by the process. This makes it a pretty one-sided deal, so to convince Channelers to feed them power, monsters offer to serve Channelers and obey their every order... when it's reasonably convenient to do so, and as long as they're well paid and well fed.

The life of a Channeler is often difficult.

Now, in terms of gameplay, what all this means is that you're going to have a couple different resources to manage. The first is food -- if you don't have enough food (which is to say, a steady stream of rats) you can't feed your minions, and they'll get unhappy and eventually desert you. Before a monster agrees to work for you, they'll check out the food situation, so you can't even hire a monster unless you're producing enough rats to feed your existing minions plus the new one.

The second is gold. Gold is required in order to pay your monsters, buy them gear, and buy ritual components so you can perform a ritual and bind the monster's essence to you.

The third is mana. For now, there won't be any player spellcasting in the game, but I'm thinking of a few mechanics that would allow you to tap your mana pool to improve some aspect of your dungeon's functioning (accelerated building, increased gold production, zones of improved combat effectiveness, that sort of thing). But mana is also used to feed your monsters. More powerful monsters require more mana to sustain them, and as with food, if you don't have enough, monsters won't sign on with you in the first place.

Acquiring rats will be fairly easy, I think. I'll probably set up rat farms as a furniture item your monsters can build, with each rat farm supplying a steady stream of 1 rat per turn or something to that effect. Fighting adjacent to a rat farm will likely create a small chance of breaking the rat farm, giving your minions reasons to protect the farms and put them in out-of-the-way places.

Gold is also likely to be pretty simple to acquire. I'll most likely go with something as basic as gaining gold by looting the bodies of your fallen enemies, although the monster who delivers the killing blow will likely get to keep a percentage of the gold.

Mana is a little trickier. I was thinking of having it generated by creatures, but then it just amplifies itself and having lots of mana causes you to have even more mana. Instead, I'm considering some variant where it's based on the size of your dungeon. But then I need to create some sort of balance so you can't just dig out a massive, sprawling, mostly-empty dungeon and gain crazy amounts of mana while you've only got a couple kobolds kicking around. It's gotta be tricky to maintain. One possibility I've been considering is that your dungeon might need maintenance, and every bit of work your monsters do costs you gold, and maintaining your dungeon in an orderly state - necessary for mana generation - costs gold. Higher-grade dungeon areas (polished marble floors instead of dirt, for example) cost more to maintain, but attract a higher grade of monster and also provide more mana.

So, anyone have any thoughts on the topic?

AI gets some of that I

Up until now, I've been working with some really stupid AI code for my game. Basically, the algorithm I used for the critters was: "If you're beside an enemy, hit him. Whether or not you hit an enemy, move in a random direction." Not surprisingly, this wasn't the most effective AI in the world.

While I ponder some of the nitty-gritty details of gameplay mechanics (I'll probably post more about that tonight) I decided to fix the AI and make it appear a little less brain-damaged. I've introduced some code that looks at all possible enemy targets and prioritise them, and even try to move towards them. Of course, it's still only moving in straight lines, so if it happens to bump into a wall before it runs into the enemy, well, it'll just keep running into that wall.

Sometime this week, I'll be adjusting that code even farther to implement something called the A* pathfinding algorithm, which allows monsters to do things like walk through open doors. It's crazy, I know! But it works! And honestly, it'll probably only take me about 2 or 3 hours to write, at which point I'll have monsters behaving almost intelligently. That should make a huge difference to the feel of things...

And in the meantime, I think I've come up with some fun gameplay mechanics, which I'll post about later. For now, I'm going to go make the monsters dig out unwanted walls and then watch the NHL All-Star game.

The ecosystem has been unsealed!

How many months into the development process is it, and I'm only just now putting in an entrance to the dungeon? Whatever. The important thing is: Hey look, it's a set of stairs! No way to actually USE the stairs yet, but that's probably next on my list. I discovered a whole host of problems with having intelligent spawn points, and I could just hack something in to get started, but I've got an elegant solution partially worked out that'll save me a lot of problems in the future. I'm going to stop coding for today and spend some time thinking about design.

Apparently I'm not the only one...

Looks like someone else had the same idea.

It's nice to get some validation of my idea, although to be honest I'd prefer that validation not come in the form of someone else (with substantially larger, ie any, budget) building something very similar.

Even from the brief promotional materials they've put out, I can see that they're going in a different direction than I'm planning, so I'm not super worried about it. I will have to be careful not to check out the game too closely though to make sure I don't accidentally steal any of their ideas.

One big advantage I'll have is that where those guys are using boring ol' goblins, I've got Tom Fowler art to work from. So my monsters will be WAY more awesome. Pbbbt! Take that, other developer! ;-)

Digging has begun!

I know, I know, I keep saying that eventually I'm going to move off the visual stuff and into gameplay... and look, I have! This screenshot shows what the game might look like when you tell your monsters to dig out some walls to expand some rooms. It currently works by basically laying the shovel/pickaxe icon on top of the wall, so as the camera rotates around the texture moves too. I'm debating switching it to a system more like the health bars, where the icons float in a fixed point in space. I think the tinting needs to stay -- it makes it really easy to pick out which squares are going to be worked on. Right now there's a problem with the tinting, in that it only works to bring things basically to black, so if I wanted to have different tints for different things going on (e.g. tint some squares blue to indicate that they're ice-cold) I can't do it. So there's work to do there.

Tinting goofiness aside, what do you guys think? Like the icons, or no? Have them floating, or leave them as an overlay on the wall top texture? Maybe lose the pickaxe and have just a shovel in that icon? Or vice versa? Any other thoughts?

Now with randomness!

Having the same texture repeated over and over and over and over again gets pretty boring to look at. I came up with a very clever solution yesterday and spent four hours coding it and troubleshooting it -- this was really hard stuff, mind you, very complicated work in an area of XNA I hadn't played with much, so four hours of work is pretty intense -- and finally got it working. I hit Run, and the game started up... and played at about 4 frames per second. Or less.

That solution got thrown out.

Today, I came up with a new solution. A little less elegant, and it adds a lot more files to the project, but with a little attention to organisation things seem to be under control. I ended up having to create a batch of new textures, and while I'm not entirely thrilled with them -- they seem a little bland to me -- I still think it's less ugly than the old version was.

I've currently only got 4 textures for the wall faces, and still only 1 for the floor, but I have 8 for the tops of the walls. Not the most exciting thing ever but at least it breaks up the monotony.

So soft and cuddly!

One thing that's been bugging me as I've been building the game is the appearance of the walls. Even aside from the questionable texture choice, they look very much like they're assembled out of computer-generated blocks -- the corners are harshly, mathematically exact. They just don't look like walls that have been hacked out of the earth. So over the last couple days, I've been fiddling with the code I use to render the walls. It's been some pretty heavy work in the back end, but I'm finally getting pretty close to where I wanted to be on the walls. I still need to tackle the top of the wall though, because that corner's still sharp as can be, and I need to smooth it out a bit. That'll probably be another day or so of fiddling. In the meantime, at least the walls are looking a lot softer.

I will eventually be getting back to building real gameplay, but I'm kind of stuck on how I want some things to work and I can feel the back of my brain playing with ideas, so I'm trying to stay out of its road and let it figure stuff out while I keep myself busy with other stuff. One way or the other, by this weekend I intend to have a fairly detailed plan for how I want gameplay to work, because I've got next week off and I want to spend at least a couple days really grinding out a lot of progress in a hurry. I'm not going to get another chance to spend whole days focusing on code for the next while, so I've got to make the most of this opportunity and get as much done as possible. So by next weekend you should see some pretty significant progress, I hope!

Back to the bit mines

After a brutal cold that laid me out for a couple weeks, followed by a busy week at work this past week, I've finally gotten ambitious again and gotten some work done on the game. The only thing a user might see is that units slide more smoothly on the minimap; other than that, the game behaves exactly the same as it did before I spent two hours fiddling with it tonight. But the code that makes it happen is a whole lot cleaner and easier to understand, and WORLDS easier to extend for anything I add in the future.

There's a term gaining popularity in the software development world called "technical debt". Technical debt is a way of thinking about the trade-offs that are made while development is happening, and can be used as a tool to help communicate certain technical costs to non-technical people. A very simplified version goes like this: Any time you hack in a quick fix in code, you've added an amount of technical debt equal to the time you saved by doing the quick version instead of a really good solution.

The problem with technical debt is that it accrues interest. Every time you work in code that's burdened with technical debt, your work goes slowly. The more technical debt, the slower the work goes, until eventually things grind to a virtual halt.

Of course, at any given moment, when faced with any given decision, the quick-and-dirty road will ALWAYS get you faster results in the short term. And yet by consistently avoiding technical debt, overall development speed is significantly higher in the long run.

So as much as it might not be super-exciting for other people to look at, a fair bit of my development effort is actually spent just moving code around and rewriting things I don't like the look of. But in the long run, it means that the few hours a week I can currently find to work on this game will be spent working in really clean code being as productive as possible. And with a new baby on the way in a couple months, anything I can do to make sure I can step in and get some development done quickly is going to be a huge help.

I think the next item on the agenda is more code cleanup. I'll be tackling the code I use to render walls and floors and making that code a lot smarter, and as a side-effect it should make it almost trivial to add in the concept of explored versus unexplored terrain, allowing me to hide areas of the map that haven't been explored yet. So there might actually be a visual update there, which would be exciting.