Incomprehensible ruins

The wall class works fine in the task it was created for, but I did try some experimental stuff by creating walls starting from even coordinates (to avoid wall created next to each other). This is how it looks after filling the level (which for testing purposes is just the lighthouse beach).

Let's point out that it doesn't look that great as a maze and also I think it could create closed areas, I guess. But maybe it could be something useful when creating ruins with larger grid. Only some walls would remain from what once was a great civilization.

The plan for now is go through each level theme and add whatever they require. I think it's a good plan. Testing for level scale (now that levels can have different sizes) has been fun, when you see how the generation routine fails to work in both too small or large levels. Teemu is also a nice project in a way that there is almost certainly something you can add to level themes to make them just a bit more interesting.

Wall object and an idea

We all know rooms are an important part of a roguelike experience, but what about just walls? I was thinking how to create a smaller room inside a room and in the process broke down a room to individual walls with a starting point, direction and length. Also with optional door placed somewhere along the way.

Then as usual for roguelike developers I had an idea. What would happen if the wall object was created with checking if the door is in valid location (empty space on both sides) and then you would just create a lot of walls, possibly even with a backtrace routine to clean a wall that fails to create properly (wall object is such a small part that it could save the previous tiles under it).

I guess it's just going to create some kind of boring maze. But it's probably an idea I'm going to test when I get the actual work done with rooms. Who knows it could be an alternative option to the current maze routine which seems to have similar problems as it's quite boring. It's difficult to make interesting labyrinths with "strong" algorithms.

Scalable level themes

I'm working on level themes now that levels can be resized. Detailed version: Each level is created as an empty version (not yet randomly constructed) in the world structure. At first I thought remaking level would be as simple as deleting an instance of level class and creating a new one. However that was not an option, because stairs structure (connections) are stored per level when the world structure is created. So, I had two ways to handle remake. Either tweak world structure or create routines to clean the level class and then remake it. Cleaning the level class was easier than I thought and also I was able to use cleaning and reset routines in constructor and destructor safely.

First and obvious test for the scalable themes was the island where the player first lands when starting the game. I went for conservative 60 to 100 tiles size which seems scale quite nicely, although bigger levels start to reveal the primitiveness of the island creation routine. The island is constructed from couple of ellipses randomly on top of each other to make them look less "ellipsy". Then I had an idea to really test the creation and punched in 500 tiles size. This is what happened:

The main island is still working as a structure, but the north island goes bananas. I have no idea why it does that, maybe I could take a closer look at the routine. It is a bug that doesn't appear on smaller map sizes. Also, 60 tiles seems to be a minimum size to fit everything required on both of the islands. It would also break in smaller sizes than that. I guess it will be an interesting journey to check out all different themes to see how they work on both ends of the scale. I'm a friend of small levels, because from tactical and navigation point it doesn't bring anything useful when you make bigger levels. If anything they can look boring and become tedious to explore.

Creating a RPG system

Teemu is finally moving from a simple HP only stat to an actual RPG system. It's going to be really simple and fitting the theme of Teemu which is quite wacky game in a non-serious way. The system is not directly based on any other systems that I know, but it's similar to many systems where 'stuff' is derived from couple of basic stats.

To help visualize the results of basic stats I have programmed debug functions to show what happens to things like hit points when you change the basic stat values. Stats for creatures start from the monster family data, then possibly adding special monster data. The by-product of stats is that you can introduce player characater classes at the same cost, so it's going to be fun I think.

Creating a RPG system is not easy in my opinion. Even a simple system like this requires a lot of balancing which mainly comes from playing the game and actually watching what happens, rather than trying to figure out a theoretic model for the system. I guess it could be possible, but it may be too difficult to program for what it is. The rest is left for random factor which can hold a lot of weight for the game designer.

Other than that I have started to change the static level size data to dynamic sizes with each level of theme having different size. Levels of a theme were always the same size in previous version which is not that bad, considering that in most old roguelikes levels were fixed to one size. I think many theme generation routines can already handle scaling quite nicely, but it's still early to know it.

It could be also nice to change the automap in a way that you wouldn't know the size of level by checking out the automap size itself. It could be then possible to add a number of secret places on edges of the level without the player never knowing for sure they exist.

I have a good feeling about development of Teemu and it really doesn't require that much work to get to the next release version. I know what I have to do which is also making it easier. The hardest part is sit down and through it.

SDL2 in OSX with CodeLite

If you are searching for information about things in the title I'm sorry, you wont find anything helpful in this entry. It looks like no one ever set up a SDL2 project on OSX using CodeLite. This far I have managed to install CodeLite. Then there were missing "developer tools" which can be installed typing gcc in terminal. OSX will detect if gcc is missing and asks to install developers tools.

I have SDL2 installed, it's in the Library as something called "framework". For some reason I can compile a large project with number of SDL2/SDL.h references, but the linker fails which I guess means something, but what. OSX can't work things the simple way. As far as I can understand you can't show the compiler and linker where SDL2 files are, it has to be done with "framework". I just don't know how, there is no such information on the internet. Yes, call the internet, I'm asking for that information.

Although, even if I can't run the project I can prepare the source code for OSX simply by making sure it compiles. But I'm going to continue the painstaking research about SDL2 + CodeLite + OSX and if succeeding pass that to my cv when I'm applying to fucking NASA. They will immediately hire me, because it's harder than rocket science.

Updates

I think my PC survived the notorious Anniversary Update of Windows 10. In fact I updated it manually, because the older version started to have that annoying 50% cpu updater loop problem. I hope Microsoft would just fix that problem, because it seems to come back on regular basis. It's a bug that prevents the Windows updater from updating and it was introduced I think after Microsoft first released Windows 10.

Also updated Teemu from VS2010 to 2015. It was surprisingly easy, I just had to copy SDL2 stuff to VS directories. It's the way I have always setup SDL, just copy include and lib stuff to the compiler's directories.

VS2015 is not that bad. It's a little bit slower than 2010, but it has more modern C++ compiler and I think W4 warning level works nicely, although it doesn't seem to catch all similar code for warnings which is weird. At first it was annoying to adjust "space rules", because there are lot of them for no good reason. It should have been an optional feature for those who wants that kind of stuff, not something you have to turn off one rule at a time.

I'm again trying to proceed in Teemu and it's possible if I try to keep the current technical implementation and concentrate on the game design.

F# language experiences

For quite a time I was looking for a different programming language I could try, because working constantly with C++ can be strenuous. My initial plan was Ruby or even Python, but I found out that just installing them on unix system (OSX) was more than I could handle. I had also planned to update from Visual Studio 2010 to 2015 and noticed that VS2015 is pre-installed with F#. So it was easy to start hacking with it. (Note: you can keep 2010 along with 2015 which is nice, because all my projects are on 2010.)

F# is mainly a functional language and it has been nice to approach programming from another perspective. In functional paradigm you are supposed to input parameters to a function and get some kind of result. It could be thought as a procedure becoming an algorithm itself, rather than containing it. At least that's the way I'm understanding it.

In real life programs pure functional style is difficult to use, because you are not supposed to have variables, but only constants computed from other constants. Yes, it does sound crazy. For convenient reasons F# does have variables that can be created using mutable keyword. F# has also classes which is another good option to have.

The learning barrier to F# is surprisingly low, at least when you get started with the language. Sometimes the syntax is bit confusing (for someone with mainly C++ background), but it's possible to get it right when trying hard. Couple of things I noticed were tuples (which are used in Console-routines). When you use (x, y) notation it's a tuple, not two parameters as in C++. Also, for some reason you have to create a tuple using let a = (x, y) and pass 'a' to Console-functions for them to work, for whatever reason.

Another subtle thing is unit as a C-style void return value. The proper way to write void function returning void is let function() : unit = //some code and also remember to call it like this: function() with parentheses. Or even more strictly using do-keyword: do function().

The way F# source files are arranged is also a bit crazy. They are in a list where top most files are used by files lower in the list. You can't call a function unless it's declared above. I guess it's actually possible to write large programs using this style, but it seems to be quite primitive. All source files are always compiled for this reason which makes compile times slow even on small projects.

I'm not really that excited about functional programming. I guess it solves some problems as it forces the use of constants. It's like having C++ const as default and mutable only when you need variables. This is something you kind of start to use in C++ as well when you become a better programmer. I've noticed that most of my variables are const type and you start to become more const correct with experience. Even so, the way F# has mutable variables and classes shows that they are useful to have, rather than trying to follow a strict functional path.

The obvious thing to do with F# is of course to create a roguelike and that's what I have already started to program. It feels like I have to proceed with caution to find more functional ways to implement stuff and I'm sure it's a good way to learn something new.

Messages and events

The small event system that I had started is now removed. It was kind of funny thing, because I didn't realize that when you have an event system it has to cover everything in the game. Otherwise you have two "flows" of program happening at the same time, resulting to random outcome.

The event message type was not removed, because changing that would have been hard. In fact it works just fine, because "event" type messages simply use another type of id in specific situations. These are things like opening a door. With events you can make the door opening abstract, detached from who is actually opening the door, so later it's possible to make other creatures than the player open the door without changing anything in the door opening routine.

I've been combing the source code for messages, because some of them are not working as expected. When messages are ok then it's easier to concentrate on rest of the unfinished stuff. It's mostly gameplay content (story) and some level themes which need more complex stuff. I really want to release the new version even without the new RPG system, as soon as it starts to look like a playable game.

The current version of Teemu has 98 source files so it has been growing since last release. The quality of source code has also increased a lot I think. One of the reasons I'm releasing the source code is that I want to show in practice why C++ (OOP) is such a good option in programming (compared to C). It's hard to convince anyone just by telling that C++ is better, this way it's obvious.

Level class inheritance

The Level class in Teemu is probably the last class that doesn't use inheritance (from those that needs it), but it's about to change. I've already started to break it apart. Level class shares almost every feature between different level themes, but the obvious difference is the generation process.

I was thinking before that generation part wasn't "good enough" reason for inheritance, but I think I was wrong. If nothing else it's easier to maintain source code one theme at a time compared to huge combined Level class. But it's possible to start think about more advanced inheritance schemes with intermediate classes between the base class and actual themes. Longer inheritance chains are better, because they emphasize the benefits of inheritance, but as always you have to be careful not to create wrong kind of inheritance.

This is an important change, because Kaduria has also one large Level class and even from this brief experience I can tell inheriting is much better than one class. It took me a long time to realize this, but things sometimes are set a certain way and can stay that way, because it feels like a big task to change it.

Cleaning up Teemu

It's surprising that I'm now a better programmer than I was couple of years ago, because I was really great then. When I'm looking at the source code of Teemu I can now see some issues clearly. The main problem is the way classes have functions (and functionality) that belongs to somewhere else. This is often easy to fix and I've been doing some of that already.

Sometimes functions could use another class using two or more classes to modularize classes to do only what they are supposed to do. But in some cases it's probably not that bad, especially in smaller projects like Teemu. Some classes could be broken into smaller ones, but it's not worth the trouble, because often some functionality is used in limited number of places. I've learned to avoid refactoring when weighing the benefits of better source code vs. time spent to fix some minor issue. Everything can be fixed later.

It's also useful to arrange files into small logical groups in the IDE using virtual folders (or filters as Visual Studio is calling them). This is more important in large projects, but it also keeps files in control in small-ish projects like Teemu.

Teemu news for 2016

After changing Teemu from SDL1.2 to 2.0 I've kind of abandoned it. The main reason is Kaduria, but somehow I also managed to mess up the source code of Teemu too much so now it's in state of minor chaos.

The problem areas in Teemu are message system and Level class. For some reason those two are difficult to get right for me. It's possible to copy some code from Kaduria's message system, but it's much bigger than Teemu's system and not that easy to use. I think it is also a bit different so it's not even possible to use it without changing messages calls.

The least I can do is go through Teemu's source code again and check out the problem areas, then try to figure out what to do with them. In game design I was first planning to change Teemu to become more a sandbox game without "story", but now I'm not so sure about it. I kind of like the adventure game style where you need to find key items to solve other things.

I would hate to leave Teemu in the current release state, because the new stuff I've made (and planning to do) is quite cool.

7DRL day 5: Failure

I had no motivation to continue this project, even though the amount of work required was not that much. I'd rather put that energy to development of Kaduria.

7DRL days 3-4: Mass with class

I gave up and copied some of the gui classes from Kaduria to this project. Mainly classes for loading tiles and processing surface data, plus some other basic classes. So I now have a procedural code mixed up with a bunch of classes and I can display some tiles.

It's obvious that this wont be done in 7 days if ever. But I could at least use full 7 days to see how far I can get. I still have some left of today (is it day 4 or 5 already?) to add fonts which is the next step needed in gui.

7DRL day 2: Tiles

I now have a program that runs, it has SDL 2 basics, but doesn't yet even have graphics routines. It seems I'm going to write this dev blog in advance to what I'm trying to do for each day. This day I should draw tiles and try to create a tile drawing routine.

I've already had trouble with procedural programming. I started to wonder how it's possible to store global data without classes, but of course it's possible to malloc memory and then point to it.. but how to use that memory without a class? I think C has structs, so they are kind of classes I guess. A class is such a fundamental building block in programming that I just gave up and created one to hold generic gui data, like keyboard commands and later graphics.

I think it was already a bad idea to try the procedural style. The source code will look quite strange if I'm ever going to finish this project. It's already a mix of functions, classes and even one datatype class I've been using a lot in my other projects. But who knows, maybe this is an opportunity to learn something.

7DRL day 1: Procedural routine

I woke up early, depressed and not ready for the 7DRL challenge. In fact I've had so called "real life" issues lately. But I started the project anyway. The first thing I noticed how stupid procedural programming really is. In class programming you set up variables in the constructor and they can be then used by member functions. But in C you have to pass everything to the function and not only that the function returns some kind of value or object that has to be maintained somehow.

I can do the first part, but I'm just going to use C++ style containers for the objects and that's it. I think it's possible to decrease the painful amount of parameters by creating compound data structs you then pass as reference. It's possible that I also need to shift my thinking from small C++ style functions to larger, more generic functions.

This first day is going to be setting up basics in the source code and I could also draw quick placeholder type tiles and other graphics needed. Lot of the source code is coming from other projects, but it has to be "proceduralized" which is going to be fun I guess.

Evolution blob

One of the ideas for my 7DRL is what I call an evolution blob. In that let's say you start your level generation with ocean tile. What's next? It could be probably sand tile, then sand tile could become dirt etc. Each tile would have the next evolution stage or several ones which then could create a branch in the evolution. To avoid everything become the last stage of evolution there needs to be some kind of percentage value for creation and also possibly a proximity check for stuff like creating dirt next to sand, but not next to ocean (where it would erase the sand tiles).

Then "blobs" are created over each other to proceed the tiles in that place to next generation. I don't know how far you can go like that, but at least simple terrain generation should be quite easy. I guess you could create some kind of rooms by applying a room shaped "blob" with extra value to proceed the evolution from natural environment to artificial walls.

I was talking about planning everything to paper, but it didn't work, because I had the kind of ideas that needs to be implemented to see if they work. Beside that I'm trying to think hard what is the role of classes vs. procedural functions, because I want to stay away from classes as much as possible.

Plans for 7DRL

This time I'm trying to participate to 7DRL. It's starting soon, but I think there is time to plan the game before implementing. I had an idea to plan the entire game to paper first, to smallest detail about what kind of datatypes you need etc.

I'm also going to try something different in programming which is using procedural routines in C++ as much as possible and also try to create some kind of component/entity model for data. Procedural functions (procedures?) was something I've noticed useful in some parts of regular class based source, but could it be somehow extended more, still maintaining some kind of object based implementation? Who knows, but if this works then we'll find out.

When working with quite large source code as Kaduria has I've started to think about problems in OOP, especially the large number of functions there seems to be in classes. Maybe it's just my fault and I write more specific functions than actually needed.