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.