Nethack 3.6.0

The elusive Nethack Dev Team (or just the Dev Team) has released a new version of Nethack. It's not a big update, but they are in a process of trying to catch up the current vibe of development in this modern age of wonders.

I've been sick and mainly trying to recover, so it has been practical to spend time playing the new version of Nethack (rather than programming which can be strenuous). While it doesn't have many new features it somehow feels solid. You know, it just works. I still after all these years don't like D&D or the way it forces you to play the game. The nice thing about NH and many other roguelikes is that you don't exactly have to follow "powerplayer" rules and tricks. So it's possible to create your own "story" by trying out stuff. Usually it means rather untimely death, but it's the price you have to pay for freedom.

It's interesting to see where the Dev Team is heading with the next version. It could be difficult to change such an iconic game as Nethack. Maybe the changes are something like more complex environment?

I'm slowly getting my strength back and in fact today I did some programming. I have some nice ideas for Teemu in source code level to achieve more modular structure which is always a good thing, so I know what to do for next week or two.

SDL 2.0: Scancode and keycode

Graphics routines are now complete. What they mostly needed was alpha channel data for things like font colors, because everything starting from data is now 32 bit RGBA. The old update rectangles are gone, because SDL2 has (I guess?) only window wide update. In that I'm planning to use a trick where the screen is updated in the keyboard get routine, because that's how the program works in logical sense. That way I don't even have to keep a update flag for every single drawing routine would otherwise had to send to GUI. Just update when waiting for keypress, whether it's in a menu or during gameplay.

Keyboard routines also needed some work. The old unicode seems to be gone and now there are keycode and scancode codes for keys. I'm actually little bit confused about them and the way I wrote new keyboard routines was using keycode. But you have to do some funny things, because in Finnish key layout some keys are not where you would think they are. For example ? is shift-+ and greater/less than characters are in the same key with greater than requiring shift. To get ? I have to check for + with modifier key shift. But I'm not sure if it's the proper way. Will it work in other layouts as well? I'm also puzzled about scancode in 2.0, because I guess it's supposed to be the physical keyboard code, but keycode itself works pretty much like it already.

There were couple of other odd things. For some reason GetKeyName returns uppercase letter for letters, even keycodes are lowercase (SDLK_a='a'). More confusingly the keyboard event seems to receive lots of events when you press a key, but movement and everything else seems to work with normal repeat rate.

Now when the technical work is done it's time to return to content creation which is sometimes annoying. It's mostly technical as well, but you don't have any kind of reference or wiki for that.

SDL: Surface and texture

Teemu is running again, but as expected graphics were problematic. Fonts had reversed R and B components I think and when I tried to include texture as component in Image_Data class with surface it just didn't work.

That's why I created Texture class for static textures only and then Image_Data for SDL surface. That way I can manipulate the surface by first creating it and then adjusting stuff. For example fonts are created from only one template color which is much easier than use paint program to draw all colors. Surface class can unify all graphics data to RGBA model, because colorkey doesn't matter I guess. In texture the transparency is done with alpha blending value so alpha channel can be reconstructed in SDL surface using the colorkey.

If software drawing is an option then Image_Data can be used as it is. The texture is just a static copy of a surface data.

Other than that I think moving to SDL 2.0 was relatively easy. Keyboard has still some problems, because I had unicode routines receive ASCII for now which only works for letters. If the routine can't be fixed to return all ASCII codes (from keycode data) then I have to rewrite that, but it's a minor problem.

Moving from SDL 1.2 to 2.0

I've been sick for couple of days so I decided to do some less demanding programming and since there is some kind of problem with latest "legacy" SDL 1.2.15 I decided to jump to 2.0. I'm in a middle of the process and there is lot of guessing going on, but here are some thoughts.

The first project for 2.0 is Teemu, because it has the most light-weight GUI you can imagine. It has only graphical ascii letters with some background tiles and a title logo image. There are some classes with simple color data, then a surface class and gui for the window etc.

SDL 2.0 has some major changes in keyboard handling and in graphics. If the keyboard codes work as I think then unicode is not needed anymore, in fact there is no unicode field anymore in the keyboard data, only keycode and scancode. Some keyboard codes have changed, for example keypad codes are now ...KP_1 rather than KP1. I don't yet know how keyboard events works since keyboard repeat has been removed or moved and there is a new event for keyboard which is SDL_TEXTINPUT. It could be more suitable for turn based input, who knows?

New features in graphics are window, renderer and textures. I've always worked only with software rendering so I don't have experience from textures, but as far as I can understand textures are now the only way to display graphics. Surfaces still exists, but they are only data for images and allow pixel based operations where textures are static. Renderer is the canvas where textures are displayed and you can create textures from surfaces. I don't know how colorkey works with textures. It may have to be replaced with alpha blend value, but I guess it's quite easy to create alpha images from colorkey information by manipulating the alpha value of a surface.

So my plan is to replace destination surface in surface class with renderer. Then I guess the slow way to display images is create the texture before it's displayed and fast way is create and store the texture during the constructor of the class. I guess(?) textures are copied in the GPU which makes them faster, but the copy process itself is slow. And that there is of course limited memory for textures in GPU.

All this is speculation, but it shouldn't be too long to see what happens.

Dumb or clever AI?

Rewriting item use routines. I've always had problems with these, because there are couple of ways to implement it. You can first of all do everything in Creature class and check player specific stuff by checking out if the Creature is the player. Then you can do the opposite and create routines for creatures and the player, or you can do any mix of these.

Checking out the player in Creature class is I guess considered to be bad style, but whatever gets the job done is good enough. If there are lots of special stuff for player then it could be easiest to create some kind of basic routines in Creature class and use them in player's class. Sometimes the "linear" flow of the program logic can make it somewhat pesky.

Another issue to think is how clever the artificial intelligence will be. If for example you make creatures eat food items it will change the gameplay a lot, because finding unused food becomes quite difficult and may even result to situation where all food items in the level are eaten before the player can even reach them. In this case the AI is too clever, but in theory you could fix this by creating another type of food distribution, possibly placing food items in more secure places like containers which can't be opened by simpler creatures like animals.

One good example of impossible "mirroring" of functions for creatures is the food clock. It simply doesn't work for creatures, because the player could in theory just wait for all enemies to die in hunger! Yet even this feature could be fixed by making simple monsters harvest their food from nature and give more clever monsters food items and/or possibility to fetch food from somewhere.

Game objects as message actors

Last time I was talking about replacing simple string pointers to game object pointers and that's what I did. Now inside the message routine certain glyphs are replaced with object names. There is some uncertain stuff going on with how message routines are called. For now I'm using function overloading which is something I try to always use, but there may be later confusion with routines that have let's say one game object instance as a pointer. At the moment it always has to be something called an action object which simply means stuff creatures use like throwing an object at someone.

When refactoring the player's routines I realized that some of them are going to be moved into Creature class, because the artificial intelligence of creatures will be improved. Creatures are able to pick up and use them. It's a big step from the current engine, but I try to keep it really simple. The good thing with Teemu is that it's a goofy game so there is no need for serious AI code.

Another big refactoring part will be the map routines. As with Kaduria I'm planning to change it to "tile based" implementation where a tile object contains everything: the ground type, objects (items, creature, etc.) and other variables. The current implementation has several layers of maps containing that same stuff, so it's again a big change, but hopefully doesn't require too much work.

Even the Message refactoring itself is quite difficult, because it's not just simple search and replace. Most routines with messages are something that need to be changed so as the actor in the routine can be either player or some other object (usually a monster). As an example, there is a part where (this is probably not a big spoiler) poison arrows start to fly when you trigger a trap. Before the "arrow" was simply a piece of text, but since the object is passed to the message routine I had to make the routine create actual poison arrows (or darts). You can even pick them up if you need poison darts.

The you

Message pools are divided roughly for the player and other creatures which most commonly trigger a message. The problem with the second noun of a message is that it can be a creature or player, but when the name is constructed from the € and replaced with some name, it is "the you" if the target is the player. You could add "the" with creatures and only "you" with player.

How you do that is another problem. It's good that I haven't got far in the refactoring process, because I think the second noun could always be a game object. It means that rather than passing the noun as a string you should pass it as a game object. Then you can check in the actual text process routine for the type of the game object. The object name can be also a named object. It means mostly creatures who have a job, something like "Darren the shopkeeper".

The second noun could be indeed the target. The first noun is some game object and it should be also passed as a game object, since it can be that shopkeeper. If I wanted to go deep I could create a verb object that chooses from forms between for example "hit" and "hits" for player or npc, but let's not go in there. But it would likely mean that only one message pool would be required for both player and non-player characters.

Bad naming

I'm facing a big refactoring job with game messages, but it's worse than that. I was a bit careless about naming some things and now it's going to give me some extra work.

What I have already changed was message.cpp (and .h) to gamemess.cpp. The reason behind this is that you should always name the source file as closely as possible to class name which here is Game_Message. What happened in this case is that I wanted to create an atomic class for messages, called Message. Yes, it would be confusing to use another file name for that class.

Much bigger problem is that I'm using a global instance of Game_Message called msg. Yet another big mistake, because now I want to create a namespace for message ids and it's going to be msg. Not only that, I'm using a function called Message in Game_Message which should have been overloaded version of Write rather than Message, because for one I need Message for the new class and it would look really stupid to write message->Message().

Or maybe it would be better to preserve Message as the internal function for messages in game object classes and give the class some other name, something like Message_Data? The new Message class is for pointers in message data, so when you use a message id the location of text is retrieved from that class instance which also contains alternative versions for messages.

Inherit problem

T_Bag was ready for GO_Container to inherit from, but what blocked it was the way game objects are saved with a template routine which is creating only the default constructor object. Now I'm sure it's a bad way to do it, because what happens is that when you load the object all pointer composite classes are re-created in the Load()-routine. I guess it's not that bad, but still it would be more appropriate to always create the whole object with the constructor.

It's certainly not impossible or even hard to fix, because all you have to do is save the type of object and then write routines for each object type with specific extra information about the constructor parameters. In this case the container (GO_Container) has to know what kind of T_Bag class it has during the construction, in fact before it by passing the container type to GO_Container's constructor. This information has to be saved and loaded outside the class of course, because you can't create the instance before knowing what kind of class it is.

The way I solved the wrapper function problem for now was indeed making the container component accessible to the player and level classes, and using class->component->Do_Something(); notation.

Other than that I've pretty much cleaned the simple game object classes. The base class has some message related routines which need fixing, but it requires the new message routine not yet ready. The main focus is now in Item and then Creature classes. The problem with those is not only the size and increased compexity but the fact that they are often more connected to the role-playing system. When I was programming the previous versions it was quite easy, because there wasn't any role-playing system worth mentioning. The game has now a HP value and some damage amounts which are totally not in balance at all. The easiest way to kill enemies is just throw something at them which they can't do in return.

I have to be more clever with the RPG system than before and try to keep things really simple. Luckily there is no magic or other difficult issues, only damage with various ways and HP. The new RPG system is probably going to be similar to that, but more balanced and slightly more complex with armour protection.

Kingdom of Refactoria

So I had an idea to inherit container functionality to GO_Container which confusingly is a game object type (such as boxes you can move), not the container class itself. We have been told that you should use composite type classes which are instances of classes inside another class. However sometimes it creates a number of wrapper functions, especially when you use the composite class from outside the host class. One way to reduce that is expose the composite to outside, so you can use notation class->composite->Do_Something(); but then again, why not use inheritance?

I started by looking at the container class. In Teemu it's called T_Bag. I know, I know... It's an "abstract" class which is just a list of items which then can be accessed, removed and put into the container. I found something fishy about Get_Slot() function that took the item type as parameter. The function itself wasn't a problem but the way it was used in Player class (I think player's class was Player in Teemu, not sure).

There was a variable called 'weapon' in the Player class. I noticed that it was the type of the item and that item was retrieved from the container with Get_Slot(). I think my original reasoning was that items are always stacked so there will always be only one item type in a slot position. But I think it has changed or will change in the near future. It means that when you try to access the weapon item it can be another item with same item type!

I'm embarrassed to mention, but first I made a mistake and changed the 'weapon' to weapon_slot which pointed to a slot in the inventory. It's perfectly valid way to access the inventory and the only way to access items when you select an item from inventory. Then again if you use the slot to store the current weapon it will be a disaster, since you can throw items from the inventory and change the internal slot positions. I wasn't really thinking this, because I only remembered you can't drop items, although it also will change soon.

After realizing this I changed weapon_slot to weapon_item which is simply a handle or pointer to the item in the inventory. The solution was simple in theory, but required changes in Wield_Item and Wear_Item routines among other routines. This time I also wrote routines to handle simple operations with member functions and not just directly using weapon_item variable as I had done with 'weapon'. Even when you are using member variables it's sometimes good to limit the places where the variable is set or changed and "hide" it behind a member function. Not only it's easier to refactor but also less likely to create bugs.

As a refactoring experience this one was actually not that difficult. It seems like I didn't make much progress, but in fact now T_Bag is ready for experimenting as a part of inheritance structure of GO_Container and I have fixed that dubious weapon handling. To make things bit more complex T_Bag will also be a composite class in Player, because the player has two inventories, one for regular items and one for tools, but I think it should work.

The game object engine of Teemu

The way game object system is implemented in Teemu is similar to Kaduria where all game objects have a base class and derived classes for main object types (item, creature, door, etc.). The difference is that in Teemu the base class is a type-less class, without information about the game object's type. In Kaduria the base class knows the type of the object.

These two ways to implement the base class are not that different actually. The "pure abstract" version in Teemu is kind of what you should do when creating an abstract base class (aka ABC). When the base class knows the type it's possible to write functions in the base class that work with all object types, without having to write multiple virtual functions.

The current base class in Teemu has only the location of the object and a flag telling is the object destroyed. These two values are indeed abstract to the derived classes and for example the location doesn't need to know anything about the game world in the base class context. In derived classes you need to make decisions where the object can be placed and handle location according to that.

What I haven't explored is the possibility to use intermediate classes between the base and derived classes. These classes could include functions like moving the object and the container ability for an object.

There has been more development done in last two days than in this year combined. Not a joke. I've been checking out the game object system in general and found out the "usual suspects" which are creature and item classes. They always seem to get big and complex. I've also tried to refactor so called data type classes related to game objects and reduce the amount of getters. Each game object class has a static data type class with information about the object's name, frame, color and other functions. The more you can put functionality in those classes the less you need in elsewhere, but the static nature restricts some functions, which is what it's supposed to do. The reason for data type classes is that it's easier to handle static data that way and also it's possible to find out the basic data of the game object without creating an actual game object. This last one can also become a subtle source of bugs, because the type is decoupled from the actual object which can result to mismatch of types. It's possible to avoid that by watching out any external handling of game object data and bringing them back to the object by handling the situation through game object's member function.

The intermediate classes could be a good way to reduce the complexity of the creature and item classes and that's the next thing I'm going to try.

Teemu news

With new confidence from experiences in Kaduria about handling messages in a new way I'm trying to apply that to Teemu. The last time I touched Teemu's source code was in March this year. Yes. It's been a long time.

The way I'm approaching the development of Teemu is through refactoring. It seems to be a better option than just continue with the current source code structure. The changes are quite minor I hope, but an important step to get past the writer's block.

The good thing about Teemu is that it's way simpler than Kaduria. It's so much easier to program. The bad thing is that it's still a roguelike-ish project and is going to be more roguelike with the new features. So it's easier, but only in the context of roguelikes.

My plan for allocating time for each of my projects could be something like a week for each project at a time? I don't know, because it never seems to go according to the plan. But it would be nice to get Teemu 1.3 ready and also the next version of Brick Atelier to get them out of the way, possibly giving space for entirely new side projects.

How to exit a process on Windows

Reading Nethack 4's blog on this subject I wanted to be a bad person and tell how you can end a process in Windows (using Visual C++ of course). You should start the project with F5 to run in debug mode.

In case you get into a infinite loop you can exit the process with shift+F5 (debug - stop debugging in VC).

From programming perspective loops are something to watch out. It can be a typical programmer's idea to assume that a loop always has an exit condition. Just as it's difficult to control the index value of an array it's also sometimes hard to keep track of the exit condition. I'm always programming a panic exit logic in loops. It may sound like overdoing it, but it's a really good idea. Panic exit logic is a counter with max value which runs along the loop and exits when the max value is reached. For debug purposes it's also good to inform when panic exit was the result of the loop to find out the reason for the infinite condition.

Sometimes resource leaks in a loop can make the OS very slow. It happens in Windows, too. Programmers should be extra careful when there are resource management in a loop which I think sounds a bit odd, but then again I have more experience from C++ resource management which mostly happens in constructors and destructors - not in loops. This I think is another good thing about C++, because it's less likely to get into strange race conditions if the class hierarchy is a tree-like system where everything is released in a strict order.

This is getting into another topic, but C++ is not protected from certain type of leaks. When you think of dangerous things in C++ (which in C are typical everyday solutions) there are three things to be extra careful: passing and returning a new object and creating a clone of an object. In C++ returning a new object from a function is not a common style (and should be avoided), but passing object to another container is, as is creating a clone. You need to be careful to handle the ownership change (as it is called in C++) properly to avoid losing the object (and thus failing to release it).

Nethack 4.3 beta 1 notes

This version is old and there are new ones, but I wanted to write something about it since today I felt like playing something and found this one. NH4 is the other new version of Nethack, the another one is UnNethack.

NH4 opens a big screen full of information. The inventory screen is visible as side window. It's ok I guess, but can make the screen look more complicated mess of characters. The first problem I noticed was clipping of fonts. It must be a result of pseudo-console code, since real console never clips like that. Or it may, who knows. The programs looks a lot like console window, because you can set fonts as if using a console. Setting them smaller fixed it.

Keyboard commands in NH4 are somewhat different than in "my" classic Nethack (3.4.3). Kicking is 'n', but it doesn't even work. You can change all keys the way you want by opening Options, then hitting shift+I for keyboard command list. The default has hjlk-keys for movement which takes away 'k' as kick and others as well ('l' as loot). I really don't know why that should be default, because 95% of people who ever used hjkl-movement have died in old age by now.

I don't know why they changed AC to something else. In fact I didn't really pay attention to RPG system, have they changed it? The AC seems to be some kind of protection value with only positive numbers which is bananas.

Other than that it seems to be a regular Nethack, only with more bugs. Well I found one bug, but it was really strange. When hitting a floating eye I got this:

There was no save yet, since I had not saved the game. Maybe there is some kind of temp save and the final save game also went to... somewhere. Not in the game's directory. I hate when the program saves stuff to somewhere. In this case I didn't even find anything from AppData or those locations typical to Windows 7. Where the heck it saved the game? In registry?

It's really funny when people try to maintain the bullshit source code of Nethack and only manage to create more bugs. When will this end? What every Nethack variant programmer should do is completely restart the source code possibly not even using C or C++. The source code of Nethack is so bad and taking huge amount of time to fix bugs which keep increasing. The thing is that you need a better way to manage this kind of data and actions between them.

Not only that, I think NH4 also managed to make the user interface worse while developers should really concentrate to fix that shit if they want to create a better Nethack. For instance there should be a list of extended commands when you hit # and let player select from that list directly with a letter. Keyboard commands should be listed by category, so you don't have to scroll the entire list to find something. I could go on forever.

None of this would have happened if the Dev Team had not abandoned Nethack. I think it's time to let Nethack become history.

What happened to textattr?

While I was away from console programming they have removed textattr() function from conio.h. Reading some random explanations for why it's a DOS function. No, it's actually a console function. They (reptilians?) did keep printf and even cprintf which I vaguely remember is actually the color version of printf. When you look at conio.h it's not even that big and Microsoft has added bunch of irrelevant "secure" versions of functions in there. They could have kept textattr for sure, because WinAPI does have color actions, they are just more annoying with that WinAPI style.

I've had fun writing the tiny GUI for console. My plan is avoid (most) problems I've previously had. For example the output is strictly limited to Display_Matrix class which defines a rectangular area of CHAR_INFO (Microsoft's struct for letter and color data). It's a simple container where you can write characters and strings with color data. That rectangle is then output to actual console. With Display_Matrix each screen or window is its own area and I'm also including update flag in the Display_Matrix: when the matrix is changed the flag for updating is set. It prevents duplicate or more updates per turn in low level manner.

The usual problem in class programming is that you may start to add some stuff to class which clearly doesn't belong to it. In small projects it does reduce the amount of classes needed, but it's still less modular way to think programming. Classes should always be as modular as possible and do one task using various types of source data.

Console font size

I've programmed a gui class for console, but setting the font size seems to be difficult. I guess it's supposed not to set by the program, but by user as you indeed can do for Windows console. Not only that I noticed the Code::Blocks gcc version doesn't even have SetCurrentConsoleFont declared. Maybe I was foolish to try the project with gcc's windows.h implementation which really does not have all stuff included.

Should I start the project again with VC2010. Or not to change the font but let the user do it. Maybe I'll go with that and think about the font size later.

Console programming in Windows

I'm planning a new roguelike with ascii text in a console window. I guess curses is the only library available as cross-compiler solution and for some reason I didn't want to go there. Rather than using any libraries I started to investigate the possiblity to use Windows native console API.

I've only taken the first step and found out that you actually can set the console windows size other than default 80x25 from within the program. It's an important step, because I plan to make the size static, possibly smaller than 80x25.

The next step is a gui class to restrict all that ugly Windows API code in one class if there ever is need to change that to something else or port the game to other platforms. My prediction is that creating the gui is going to take some time because WinAPI, but once it's done it will be easier than working with graphical roguelikes as I've done this far.

This time I'm also going to use external script files, unlike in my current projects with only C++ data structures. In scripting I don't see any other advantages but "default" values which means you only have to write the data that is different from default type. Some people say it's good that you don't have to recompile the project to change data, but I think it's a non-issue in a modern IDE where only files that were changed are compiled.

The gameplay idea I have for this project is quite simple, so we are not talking about a major roguelike. If I can get the gui and parser for data done before abandoning the project it may be finished some day.

OSX developer experiences

I tried to install CodeLite, but because it's from unknown source OSX didn't allow me to do that. You can override that by installing with admin or whatever, but I just didn't have the energy. Besides I have Code::Blocks installed. When started it wanted to install some kind of developer tools (compiler I guess?) which I thought I had installed before. Or didn't I start C::B when I installed it earlier?

I wanted to try wxWidgets, but couple of reasons made me stop trying. First you have to compile it from sources to OSX. I tried quickly to search some kind of "how-to" for OSX, but no luck. Then I was looking at wx docs and while it's C++ it seems to be an overcomplicated system. I guess full GUI libraries are like that, but it's just so depressing.

I wish there were something like SDL2, but with simple dialogs, menus and above all a file dialog. That would be great for people who don't want to install an operating system (like wx), but on the other hand don't want to code everything from the scratch (like with SDL2 if you want a GUI).

There has been some talk about OSX becoming worse for desktop developers, because Apple is concentrating more on mobile platforms like tablets and phones. I think it is kind of hostile environment for developers, because at the same time Apple assumes that you want to use XCode and their technologies, but then also you have a unix system working in the background which allows pesky command line hacking I'm really not willing to handle myself. It's not for me, because I've been using IDEs since 1990's.

I was planning to move Brick Atelier to OSX and SDL2, but then again it would be easier to ditch SDL2 and try more advanced GUI library. Not wxWidgets I guess. Or who knows it might be easy when you get over the first impression?

Review of three development platforms

Windows 7. This is my main development platform and it's also the OS I'm using most of the time. I think people have strong opinions about Microsoft, but as a developer platform Windows is nice, because there are flexible options for releasing as closed source or open source, or whatever you want. Windows has good tools for development, some of them even derived from Linux world. Microsoft itself has a free version of Visual IDE family which in my opinion is one of the best there is available. Windows has been also surprisingly compatible in both backwards and forwards ways. Problems in Windows are often related to security and viruses. What I also find a bit annoying are frequent updates in the OS, yet the impression you get from Windows is that it's bloated and has a over-complicated structure.

Microsoft made a (GUI) mistake with version 8 which they now are trying to fix for 10. Both 8 and 10 should be less bloated, but I have no deeper experience from 8 so I can't tell for sure. I think we are all waiting for 10 to be at least in level of 7 with possibly better security and tweaking options for power users.

Linux. The main problem with Linux is open source ideology which in practice forces everyone to release open source projects with strong ties to GPL license. Linux is like communism where communists think their way is the only way of freedom, but in reality it's extremely restricted way of thinking. I don't actually have experience using Linux, but I think it's not possible to release your program as .exe (without the source code) that will work in all (or even most) Linux versions. The impression I have from linux is that most releases are open source and people are compiling programs all the time with recurring issues of libraries not being compatible for that specific version or brand of Linux.

The migration from a Linux program to commercial world is often difficult and a way to get around it are donations. However no matter how much some projects get donations they seem to remain only half-professional as Linux developers often have strong opinions about what kind of features their programs should have.

I would possible use Linux if it were possible to avoid GPL and release as a binary program for all Linux versions. I believe those two reasons are the main issues for some developers like myself.

MacOS. OSX is also quite restrictive, but in different way than Linux. The biggest problem is that OSX has a poor selection of development tools and there are also big difficulties to use technology outside OSX world (such as L/GPL libraries etc.) Development in OSX forces you to join Apple's development program which has 100USD annual subscription cost. For commercial developers it's fine, but for people who just want to write freeware programs it kind of sucks. The commercial aspect in OSX is strong and I believe it's something that has been a part of Apple's plan. They don't want freeware programs in OSX, they want to get their share.

As a regular user of OSX I don't have a lot to complain. The OS is based on some kind of Unix/Linux version. It's like a commercial version of Linux with a nice GUI and one standard for each version of the OS. The nice thing about OSX is that it's not updating all the time like Windows, except for occasional popup of Flash Player updater, but that's just good old Flash. Sometimes OSX freezes right after startup, but other than that it's very stable OS and it's easy to concentrate on working. I'm using a Mac Mini in my music studio which is something many people do, because it's such a stable system and almost completely free of viruses and pesky updates. But as a development platform it's quite awful and you are giving Apple that 100 dollars each year for the fun of writing computer programs.

A short history of gaming

When home computers and video games appeared in 1980's things were bit different. Most players and also developers were young male nerds. Girls didn't play games back then and gaming was certainly not a mainstream hobby it is now. Game development industry was created then from zero, when people started to realize that you could make lots of money from it.

1990's was a transition from nerd hobby to big commercial companies. Best selling games were still mainly good, because the players were still kind of nerdy and wanted different kind of games from variety of genres. The reasons why some games sucked were different in 90's than before, because in hope of getting rich quick companies started to pay attention to advertising and not the game itself.

Things started to change rapidly with new more advanced consoles like Xbox and PS2-3, because it was easy to play games with them (no nerdy programming or computer handling needed) and playing itself became more accepted for mainstream people. It stopped being nerdy and started to be cool. Game development was concentrated to big game titles so much that some game genres disappeared, because they were not selling as many games as were required to cover the ever-growing expenses of development.

Today mobile games cover a big portion of the gaming and the internet has also a big role in it. Indie game development has revived some genres, but the resources to create good games are often limited. The way people think about games is completely changed. The game is no longer required to be good, it can be anything that the big mass of people are interested, and often self-advertised in social medias. Games like Flappy Bird can become an instant hit and give the developer crazy amounts of money. A similar example is Minecraft, a "game" where you place blocks or remove them. It made the developer Markus "Notch" Persson a multi-millionaire.

There was no happy ending to all gamers. Some nerds grew up and started to think why they spent so much money in games and why they made a small group of developers so rich. What they got from it? Some good games and entertainment maybe, but at older age it all felt somehow empty. Not all developers were successful either. No matter how much they programmed and worked on their projects there were failures as well. Games that were quickly forgotten. Difficult hobby projects that made the developer swear he would never play any games or even think about them. Even good games that could have been much better with some minor tweaking before the release.

So in negative way today's games are developed to make money. Every trick or style that makes more money is in the gameplay. The press and reviews have long since been sold to advertising, but it has no point since there are no good games anymore. It doesn't matter how much they lie in their reviews, because casual people play games no matter how much they suck. Money is made and that's all there is. As if it wasn't bad enough there are people who create social media storms called GamerGate or something else, which can actually make the content of games suck even more with gender equality and other kinds of bullshit that restrict artistic freedom.

Game development may become more diverse in the future, because the technology to create games has became more accessible to game designers without strong technical skills. Game engines are getting better and easier to use. Money transaction over internet may become easier and hopefully doesn't require the developer to sign up as a slave for mega corporations like Steam or Apple. How things turn out depends a lot from what kind of future the gamers want to support.

Problems

For me programming (and game development) is all about solving problems. When I proceed in the project the difficult things are always also the hardest problems. Sometimes problems are algorithms like a FOV algorithm or some kind of level generation algorithm. Another type of problem is what I call logic problems. In my projects they are often in the flow of the program: something is happening in wrong time or wrong order.

An example is when you start to write some kind of walking or pathfinding routine. Here usually the game loop is static and can't be used directly in multiple step loops. You need to separate the individual routines and make them stop if some conditions are met. Most automatic routines are like that, they need extra stuff to find out things which typically are found by the player as human component of the logic chain.

I think it's important to solve these difficult problems as soon as possible, but another aspect of it is not only asking how to solve the problem but what is the problem. It's perfectly possible to create "artificial" problems by overthinking, when a simple solution is often the best one. As a micro-managing tool in programming I think it's extremely useful trying to give a clear definition to a problem and also try to find out solutions to it even before programming a single line of code.

Another example of overthinking is the quest for "perfect" routine or way to implement something. It can be fine when you are not planning to release the game any time soon, but in most cases you want to create something that roughly works and then move on to next problem as soon as possible.

One of the annoying things about problems is that sometimes they feel so difficult that you just want to go away and not even try to solve them. It's almost like problems in real life. And like there some people try to solve the problems no matter what while others just ignore them and leave unsolved for a long time, sometimes even many years.

Thoughts on inheritance

In my experience object-oriented programming concept constructor-destructor rule combined with the idea of ownership has reduced typical memory corruption bugs of C to a point where it has become almost non-existent problem, yet very common source of bugs to C programmers. C++ has also other useful concepts which are extremely simple such as the scope of a class.

In C++ and other object-oriented languages the concept of inheritance is an essential feature, but it's proven to be difficult to use properly. Rather than using inheritance as it was designed I've been using it sparingly and probably also wrong way in the first place. For a long time I was wondering what is wrong with inheritance and I think I've found a good explanation.

The main problem with inheritance is something that many roguelike programmers find in what we call a game engine. It's an idea where data is handled by a program core called engine and the content of game is in the data entirely or as much as possible. We have years of knowledge about engine programming which in mathematical term tends towards infinity. This means you spend ridiculous amount of time trying to write a roguelike engine which turns out to be extremely difficult.

The engine vs. direct approach to game programming is analogous to inheritance and class hierarchy, because both are examples of generic vs. specific case. Even if you write a generic engine you still need to solve the other problem, because each game is specific. I believe this is the root of the problem. You have an idea to write generic class library and/or program using lot of inheritance to make sure no similar code is duplicated, but the result is more or less generic. You still have to create the actual game which often include extremely specific content.

This is the reason why it's easier to create specific classes to solve some problem, because it's more direct style even from the outside it appears to be OOP with classes and all that. The generic solution is as difficult to program as is a game engine that can handle all specific cases of a game. It can be possible, but I think it requires lot of experience and planning, unless you have a talent for using inheritance which I guess few people have, according to my internet research on comp.lang.c++ and other forums.

When you look at the big picture I think object-oriented programming is still difficult to handle after 50+ years of its invention and that's why some people don't like it or they write inefficient code which sometimes can reach strange meta-levels not really required to produce computer programs. OOP can be a trap for people who think they are clever and who refuse to understand the concepts and admit that there is possibly something from which they have only limited knowledge.

Adventure games are back

I'd like to finish the next version of Teemu. It all started to go wrong when I wanted to have more sandbox in the gameplay. What I realized much later is that I should not be afraid of static gameplay features but continue in that path. So today I made a new plan for "quest items" and their locations which is going to make Teemu even more adventure game than it was before.

I think Teemu is going to be an adventure game with roguelike features rather than a roguelike with strong storyline. It's possible to add things forever in a game like this, too, so 1.3 will probably not be the last version.

The real time consuming part is the role-playing system which I guess will be really simple, but it must be different than now, because there are new enemies, slightly different storyline and stuff like that.