Friday, 14 April 2017

Namespacing 1.3

Notations for enums are in process to be turned to namespaces. I think about 1/3 of them is reprogrammed, but in most cases it's easy. When you remove special notation from the beginning it may sometimes create a name clash, especially when you open the namespace. But namespaces are better solution for other reasons like for functions tied to namespaces. It's also easy to find namespace instances from the entire source code.

This is probably not a healthy way to develop the game itself, but with this I'm planning for bigger changes to content and also to the RPG system. The key to success is keeping things simple for this one. I know very well what happens if you plan something major in context of roguelikes. Even now with actual RPG system the development has moved on to harder difficulty level from a simple 7DRL that Teemu was before.

Saturday, 11 March 2017

Planning the source code release of Teemu 1.3

I think the source code of Teemu 1.3 is going to be more important than the game itself, but it's just an opinion I guess. The game is also released with the source code, so there is no need to compile it in Windows environment at least.

Since last time I have learned some new tricks which are better use of namespace and functions. Namespaces have two main purposes in my thinking. The first one is replace notation additions to enums etc. using a module type name for stuff. Like for example door::Wooden, rather than use notation doorWooden in enums. Namespace is safer, and you can remove the door:: when using in some places. Also, what I find great is searching by using door:: namespace, you can quickly find all places where it's used outside of the namespace itself. The second use is with functions as a kind of module.

Functions are another funny thing, because when you learn OOP you may want to make "everything" a class which in some cases is clumsy, because you have to create an instance of a class to get some trivial data etc. Functions are even better with namespaces, because you can then create sort of static "namespace class" or module with C-style functions as member functions of it. The nice thing in C functions is that there is no need to create an instance so there is no problems with memory management in that case (unless of course you use memory management in those functions which I never do). Writing pure functions is really nice I think and they are very useful when generalized, because you can use them in any place of the source code without so called side effects.

Those are the two main improvements, but there are others like smaller classes with more focused tasks and so on. The reason why I think this is important is that I've been talking a lot about C++ programming and why you should do certain things. But when I only talk about it no one is listening. So I think it's far better to lead with an example. I want to show how you can write large-ish projects with zero bugs when you concentrate on creating a set of rigid rules in programming.

The release of Teemu 1.3 is not very far away I believe. Depending on how well I'm able to allocate the time for this project.

Wednesday, 25 January 2017

Blown away by Visual Basic

I've been in a stuck phase with my regular projects so I thought it could be funny to write a roguelike (what else?) using Visual Basic, you know, as a joke.

The current version of VB is something I did not expect. It's no longer that old, dumb language where you wrote code for Windows forms. It's a cool programming language built on top of a procedural past, but somehow seamlessly includes modern features (class being possibly the most important). Everything seems to work smoothly so you start to wonder why C++ can't be like this.

The only strange thing is how VB is managing resources. The reference/value system is automatic, some things are always references and others are value types. I guess it works somehow.

There is a problem with Windows console project which is that it's really slow. I think debug mode has something to do with it, but it should be faster. However I've found out that when you set the color of a character it's possibly the slowest thing you can do, so when you draw the level you can set the color (character and/or background) only when it changes.

The syntax of VB is quite verbose which I like personally. It's easy to write code that doesn't really need comments to understand what it is. The language doesn't seem to have ambiquity that C++ has. For example Sub never returns anything, but Function always does.

Saturday, 31 December 2016

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.

Tuesday, 27 December 2016

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.

Thursday, 22 December 2016

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.

Sunday, 18 December 2016

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.