That pesky content - part 2

There has been a subtle but important change from engine programming to content creation in this project. A common misconception is that roguelikes don't require that much content, because they are random(ly generated). It's not that simple. Sometimes they do require a lot of content and randomness is only an extra layer on top of it.

An example is creating equipment for creatures. Today I started with helmets or headgear. For them the race and profession both determine the type of headgear. It's mostly the profession. Fighters and knights could wear a metal helmet, but wizards should wear a pointy hat. But if you always have the same decisions the gameplay becomes dull and predictable. There should be some kind of random variation, but in some kind of context. A knight could be wearing a crude helmet if he has lost his metal helmet and a wizard could be wearing a studded leather helmet. Helmets itself could have an importance value what comes to the decision how often they are created, because they were in reality the most important piece of armour.

The details of decisions can be complex and decisions or their "engine" itself are hand-picked content. More intelligent races and professions means more decisions. I already regret I made goblins an intelligent race like dwarves. Maybe they are removed or the amount of professions reduced.

Cloth armour fashion

Yesterday (Sunday) I had a headache that lasted the whole day. I took two regular ibuprofen pills, but they didn't help a lot so I took that day off. I tried hard to do nothing and almost succeeded in that. Today I feel much better, like almost sharp.

I've been reading about bronze age armour from the Bronze Age Military Equipment book and it has given me many ideas about how to use armour in more realistic way. Scale armours were probably most popular armour, because it allowed good mobility, enough protection and wasn't too heavy. Scales were made of almost any hard material. There were even bone scales and scales made of leather. It was also easy to fix a damaged scale mail by replacing damaged scales.

What I didn't realize before was that cloth armours were also very popular. They were usually made from linen that was layered even 14 times to create thick armour. You couldn't have endless amount of layers, because then moving became harder. Surprisingly, also felt was used as armour or more likely as pads.

Because I'm using more "realistic" physics I can use all those differences in armours to get trade-offs between mobility, weight and protection.

Bronze age style

I'm reading "Bronze Age Military Equipment" by Dan Howard. It's a cool book, because not only it tells about weapons of that age, but also how they were used and tactics involved in warfare. I was always thinking Kaduria will be low fantasy, but now I'm more convinced that it could be even lower!

Bronze weapons could be the main stuff used in combat, or even stone age weapons. The setting could be in between fantasy style bronze and iron age, making iron weapons extremely rare and efficient. This was the case in real life when metal weapons were invented. First they were used by only few, rulers and their elite troops. This historical fact could be a source of interesting weapon distribution where a simple iron sword is hard to find.

In fantasy context low fantasy doesn't mean there is no magic. In fact magic could be a noticeable part of the gameplay, possibly making it even more important than in regular role-playing games.

Over-scoped features

I thought it would be nice if you push something floating on water it would move in the stream. The movement was random, but then I realized it's silly. Of course rivers must have a direction where they flow, so it was something I added today. This feature was kind of easy to add. I just created four river tiles each with direction of flow and re-factored river creation which already had an orientation (horizontal or vertical) and direction where it was flowing.

I tried to test it with a barrel, but it didn't go into water. Sadly I had removed that feature for now, because I'm having difficulties with the terrain and object interations. But in theory it works and you can push stuff into river and watch it go downriver.

Another feature I still need to implement is a temperature map. I realized that if I have temperature it needs to be local and not in level scope. It would be funny to walk on lava in snowy mountain and still feel cold. Temperature map is going to have mixing between temperatures so near lava it's beginning to be hot and it could even melt snow and stuff like that. It's a good preparation for level events like lava eruptions.

Kickstarter roguelikes

There was a long post by URR (Ultima Ratio Regum) developer about Cult, a kickstarter RL project that now possibly has failed, because the developer can't create the game he was talking about.

What I find amazing is not why projects like Cult fails, but the way people are willing to support almost anything. In other words, let me phrase this carefully: people are idiots.

Well, there is nothing new in this, because people also buy poor commercial games. However they at least get something in return, an actual game.

Not just average developers try their luck with Kickstarter, but also old and young professional developers. One of the worst examples is Richard Garriott, one of my childhood heroes. He had the money to continue Ultima series when he wanted, but only when Kickstarter made it possible to ask money he did so.

Also, I want to correct something Darren Grey said about Kaduria in a comment. He included Kaduria to the list of big, over-scoped projects as he said. He is wrong. Kaduria was never an over-scoped project like, let's say, URR. The development time has been long for other reasons and rather than following the usual development history of a failed project it has followed a different path.

Theme park

Back to level themes. I have a plan to create quick versions of unfinished level themes, but even it seems to be hard. I need plans for my plan! I have a vague idea for each level theme, but it's not good enough. I think better way to handle this is plan each theme on paper as I have done for couple of them. Then it's easier to think how to implement features presented in the plan.

Level themes are difficult, because they involve content creation. Yes, that pesky content. I think even seasoned game developers can be surprised about the amount of content needed in a roguelike. No matter how random the creation process is you still need to design it. And the amount of design is multiplied by the number of level themes. On top of that I have ambitious ideas for level themes, most of them with special features.

Stairs logic

Previously I had created a node system for levels which is a database of level themes and connections between them. After the introduction of "static" or special room types in some levels I had to re-think stairs creation in their actual form as objects in the level. This far the generation process found some empty floor and there you had it.

What I needed was some kind of way to tell stairs creation about static places for stairs. For that purpose it was easy to set up a list of "clues" for stairs. It's a coordinate set during the creation process and then retrieved when creating stairs. There could have been many ways to do this, but I chose this way, because you browse through node connections which then can be matched with the clue.

At first it returned a wrong location. It was a bit of a mystery, but finally I realized the location was not set correctly, because the room interior was created later than stairs clue was pushed into the list. Some of the interior was terrain generation (with Blueprint class) which I then moved to the routine which is creating the actual shape and terrain of the room.

Now it works and I can set up special locations for stairs. Of course, it's not yet done. Even random generation needs better "clues" where stairs should be created.

As this example is showing. The sign of stairs is created next to door. It should be quite easy to prevent this by removing that place from possible creation locations. The same also need to be done for walls, because doors also could be created into poor place, next to something that's in the room against the wall.