Shops

I'm refactoring Teemu for more random stuff. In the current version some items always appear in some places, but I want to change it that sometimes they don't. But what happens if they never appear?

The mind-boggling realization for me was that if they don't appear you need a shop where you can buy the missing item. So that's why shops exist in roguelikes! I never thought it that way.

So it looks like I need a shop and I have a shop idea fit for Teemu's theme. Creating a shop is some extra work, but I don't think it's going to be too difficult. Earlier someone was wondering why there already are rupees in the game when you can't buy anything. Well, now you know. I just have to sprinkle more rupees than there is now to make sure the player can get the required money to buy items.

Forums

I left Rogue Temple forum, at least for now. The way I feel about cencorship regarding "difficult" subjects is hate. I hate it when you can't say what you think is right and that some subjects are banned.

Second, probably more important reason is that I spend far too much time on forums. It's actually a problem similar to any addiction and in this case it's wasting my time in a way that matters. Why do I spend time on forums? I don't know, maybe it's the connection to people with same interests. Even it always seems to end up me fighting the rest of the world.

I've quit some other forums as well and try to reduce the amount of time on those forums I still visit. I feel a need to get something done and internet (mostly forums) is making it hard. Not just game development, but I also have more important things to do.

Sandbox vs. linear adventure

I had a plan to make quest item distribution more random, but it somehow went the opposite way... it's totally linear which means you have to fetch items in a certain order. The problem with sandbox approach is that it likely means you don't need quest items in the first place. Well, maybe some, but even they could be located almost anywhere.

It's possible to sandboxize a linear adventure by creating another way to solve a "puzzle" where the quest item is required. Or in some cases there could be more than one item, or the item could be used elsewhere. The old rum bottle could be such an item which can be used in many places without breaking the main use rule (that you definitely need it for a specific puzzle).

I think it's difficult to have both sandbox and linear adventure in one game, but it's possible. Then again I've already decided I'm not going to explore sandbox option in Teemu, but keep it more or less linear. It's way easier then to finally crunch the next version into release form.

Maze rooms

Sometimes the maze generation runs into a dead end sooner than expected and maze rooms fill the level.

Strangely this one can be navigated, but since doors are placed on a random wall (one per room) it's also generating room areas that are not connected to the level. The way rooms are created in the maze is actually nice, even if they take a lot of space, but they should work as a part of maze or be a maze of rooms itself. How it's done, I don't know yet. You could place doors to each wall, but then it's not very good as maze.

If everything else fails, I should keep rooms attached to maze level and skip rooms that would be created next to another room.

I should quit

...my work. I often have plans for some day to write code, but the time runs out. Funny thing is that I have only 6 hours of work a day (I must have mentioned this earlier). Then again, I have other obligations that take time. It feels like I never have enough time for myself. Big reason is my situation with other people. And a dog, that monkey needs my time, too.

Maybe I don't plan my days as good as I should. There must be an hour or two just for programming, yet I failed again today to clear that time for development. I guess it has something to do with concentration as well, because I'm easily distracted by other things.

Maze theme bug

I'm working on one of new level themes in Teemu. It's a maze type with 2x2 corridors. This is an example of current generation:

It's decent, but still needs some work. The way diggers work can be fine tuned to produce different types of mazes. There is some kind of bug which sometimes makes diggers stop before they can carve the entire level. In that case room creation process is filling empty wall spaces. This happens:

The level works, but those rooms are quite large and the actual maze is pretty weak. I think the problem is in how long diggers walk in one direction before changing the direction and cloning itself. There should be more copies. Also rooms could be restricted to a smaller size. Maybe also fix that double wall room creation.

Functions and classes

Maybe I should write a book about C++ because I'm always talking about programming stuff. But let's continue with the simplifying theme. One of the things that happen when you move from C to C++ (classes) is that functions often become simpler, but their amount increases. It's strongly related to the design of classes: how they return and get information from elsewhere.

In the best situation most actions would happen inside the class and then some simple return value or state can be retrieved from the class. What happens when you move from C's functional paradigm to object-oriented style is that you get maybe too interested about simple functions, especially aiming to decrease the amount of parameters to functions.

It's maybe ironic, but more complex functions with reduced parameter data can actually increase the modular OOP design of classes. I think it's good to look at the size and complexity of the public interface and try to create simpler way to handle the input/output of the class. This is even true for type classes that contain some kind of basic data and calculations based on it. You can add more complexity (in form of higher level functions that handle the data in that class) in those simple classes to reduce the complexity from the calling routines.

With functions one of the thing often happens to me is that I write a function just in case it needs to be used more than once. Then I notice it's called only once and in those cases (when it's clearly a part of the main structure of the program) the function's source code can be fused into the calling routine, removing one function. Less functions is good when dealing with a large scale project, because every function counts and contributes to the overall complexity.