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.

Simplifying the source code

I have some problems with updates of the screen and parts of it during a game turn. I've tried to simplify the gameloop, but it still has some bugs like how alcohol content is not updating and stuff like that. It somehow became too complex and started to produce bugs as a side effect of that.

On the other hand my programming has become simpler. You only need the simplest possible way to solve or implement something. The problem is how humans overcomplicate everything and it's often evident in the source code. As a related item the source code of Incursion (by Julian Mensch) is going to be released, because I guess it outsmarted the developer himself. I remember him talking about the elaborated custom scripting and other weird stuff like that which likely became too complex to maintain.

It may prove to be another example of making things too complex, while simplicity would work much better. I have my own problems in Teemu even it is extremely simple itself as a roguelike project. That's why I believe you should simplify the source code when things start to look complex.

Simplifying is not optimizing. I have stopped trying to optimize my code for years now, because it's often a waste of time. Besides when you write simple code it also will probably be fast, because there is less source code and less structures to handle. The actual optimization these days is done by the compiler which handles that stuff much better than a programmer.

New features

Some features are done, but sometimes you want to add features before next release and the list is growing rather than getting shorter. Yet I think the next version can be ready quite soon. If I'm correct most of the time will be spent on testing the game, because Teemu is experiencing some interesting changes.

I have some real life issues as we all do sometimes, but I hope they will pass. I doubt they will affect the development other than positively, which can seem odd... but I guess it's the way I'm responding to problems with people, you know. That's why I got interested about computers, because you don't have to speak to anyone, just write good old source code and turn off rest of the world.

Bump to open door option

The problem with this one was that I was using direct enum values for collision types. A central routine in World class returns this collision type, but when you bumped on closed door it returned hitWall (simply because specific hit on closed door was not needed earlier). This kind of programming has the side effect that if you add something new it will probably make things go bananas elsewhere. The new in this case was hitClosed_Door.

As you may already guess the datatype class and public interface came to the rescue. It took some time to convert all (well, most of them, but it's a different story) direct references to hit...-enums to datatype class, but it was worth the effort. Now there are specific routines such as Is_Hard_Obstacle() and Is_Air() etc. These contain all the collision types and as new types are added no checks are needed through the source code for them to work.

Bump to door -option required this change, but there will be also bump check for things you can read. It will only require a new hit type when hitting a readable object and couple of lines of code to call the read function from the player's collision check routine. The new hit type will not confuse other things like pathfinding for monsters. This is the power of datatype classes.

Functional adventure

My month off was reduced to about ten days, but there was no reason to continue this odd vacation from roguelike development so I've been working on Teemu again.

I tried to study something about functional languages, namely Haskell. I learned only that purely functional languages don't use state (aka mutable variables, or commonly known as variables). While this information didn't help me understand functional languages it actually gave me an idea for my data-driven type classes which I guess helps keep them more modular. The idea is to pass parameters to functions rather than pollute the class with external references or write the code itself elsewhere (using that classes information). Those parameters can even be reduced to flag (bool) type information, not the actual variable or object.

Month off

When I was planning my 7DRL I realized that in fact I need some time off from roguelikes and programming. I think a month will be fine. I also try not to visit roguetemple's forum or any other roguelike-related place.

I'm not going to sit still, there are many things to do which don't get as much effort as I want. Well to be honest I'm in some kind of crisis... maybe it's this age issue and... stuff.

The big question is can I stay month off?