My life as a Mac developer

So I was looking at possibility to move development of Brick Atelier to OSX, just for fun and maybe preparing for future releases on OSX platform. First block on the road was that I can't download XCode, the native IDE for OSX. You can get it from App Store, but when downloading App Store wants to know my billing information. I don't want to give it. Besides, I don't have a credit card which presumably is required in App Store. Yes, it's possible not to have it in some parts of the world.

Code::Blocks can be installed on OSX and it was a success. But then a disaster struck. SDL (a graphics library used in Brick Atelier) can be only used as a framework in XCode. In Code::Blocks you have to use so called unix installation, which I call shit installation. Since OSX doesn't have .dll files as Windows the user has to install SDL if using dynamic linking, because you (again presumably) need library files for SDL. If using static linking you have to release the source code of your project, because SDL 1.2 is LGPL.

OSX is taking worst from the both worlds. On other side there is App Store and Apple's development tools (and if you release on App Store having to join in the development program which costs 99 dollars a year). Then there is unix and open source problems with "good old" GPL. What the fuck is wrong with just writing programs and releasing them the way I want? It looks like I'm not going to write any programs to Mac any time soon.

Isn't it ironic that Windows is the best platform for developer? It doesn't force any suckage from open source ideology or try to force commercial releasing routes. You can do anything you want. You can release the source code if you like, you can use other licenses than GPL, you can sell your soul to Steam if you want etc.

People often ask why don't you join Linux happy open source family. I think it's restricting your options and open source releases are dangerous, because anyone can steal your project and create derivatives of it. GPL is the biggest reason why Linux will never appeal to developers who may want to change their mind and try to get some money from the hard work if or when their project starts to have a commercial potential. GPL and open source ideology would probably work in a communist Star Trek utopia where no one has money.

Developers are extremely important to any OS. What happened to Windows with version 8 was hopefully a good wake up call for Microsoft. If they make the OS like shit the developers are going to run away fast. Then again no one liked 8 and that's why Microsoft is trying to get it right with 10.

RPG system troubles

I realized that Teemu has the same problem as Kaduria which is the RPG system. Right when I started to create more sophisticated system for Teemu the new version has been in unfinished state for.. a long time. Of course it's not the only thing in todo list, but it's the biggest problem.

Creating a balanced RPG system is not that easy. I guess that's why many games use D&D or some kind of version of it. And worse yet, when you start to create a system you end up something with hit points, stats and stuff. How else it could be done? Maybe I need to think harder to make something different.

D language

I've studied D language. It's a kind of evolution from C++ as it says. The syntax is familiar to C++ programmer, but there are differences, some of them quite confusing (class vs. struct, immutable vs. const).

With long experience from programming I can clearly see where D is coming from. It's funny, but in a way D is a result of "bad" features of C and C++, yet I think it's wrong to focus only on those bad features. C++ is just doing things that way. Even C++ developers are breaking in constant pressure to become a "modern" language. Well, I guess those new features can't hurt.

Some features in D are nice as you would expect while others are less useful. For example assert seems to be a strong feature in D, but something I would never use myself. Not in C++ or D. Unit testing is also a waste of time in my opinion. D even has a unittest scope for that purpose. What I found nice is that D has built-in array slicing and easy to use string operations. D doesn't have header files which is one of the ancient structures in C++. It was also easy to start using D, because Code::Blocks has support for it, you only have to download the D compiler and point it to C::B.

I was thinking of programming a utility program with D, but it might be interesting to write a small roguelike just to see how different it is to maintain that kind of project compared to C++.

Nethack, Angband UI and warm days

I've played Nethack as a researcher trying to find out what makes it good. Of course I've played Nethack even before I started Kaduria (a long, long time ago), but I need to try different professions and also try to become a better player.

The biggest problem in Nethack is Elbereth which kind of fixes an inherent design flaw. Also in my opinion D&D has always been "broken", because it relies too much on magic. But even if the game seems to be broken it can actually create a gameplay that many people seem to like. And it's not fair to judge game design that was created mostly in 80's by regular students. In that context Nethack has stand the test of time very nicely.

Angband is another game I need to study more. I never liked it and didn't even want to learn how to play it. It's still difficult, because the user interface is really bad and tries to scare you away. I remember the old Angband was better (one with true 80x25 console). What they have now is way too many tilesets while they should concentrate creating one good set and ascii modes are also poor, with bad fonts. It's sad how the UI can't even scale to selected font size, you have to increase or decrease the tile size manually.

It's been really warm for over a week now. 25+ C which is extremely warm in arctic region. I'm trying to survive days at work and when I get home do nothing. It's hard to concentrate on programming so I have spent this time playing (or researching as I call it).

Field of field of vision

Roguelike developers have long struggled to invent good and fast FOV routines. I've had some good results with a regular line of sight (line drawing) and then fixing errors with a special routine. What I've also found out is that clearing the FOV map first is slower than setting visible and blocked tiles using only line drawing (drawing to the end of FOV area) at least in large open areas, because there are then two iterations through the map (even though line drawing visits a number of same tiles).

One day I had an idea about new type of fix routine that takes place first, before line drawing. It also sets each tile of FOV map to a preset value. Then line drawing takes care of the rest. But let's not get excited, because there is not yet a working implementation. In theory with advanced type of routine it would be possible to limit line drawing only to places where it's needed after the initial FOV routine.

I also wondered would it be possible to draw the level with the FOV routine itself (without having to copy the FOV data first to a map) using an update map to prevent multiple drawing of a tile. It could be something to try, because it seems always that you need to iterate the map or visible area several times to get things done before drawing.

The player of games

As a player I'm not very good. It has somehow become more evident when I've been watching ADOM gameplay videos on Youtube by Gordon Overkill. He also seems to make mistakes which fellow youtubers often point out in comments, but he is still way better than I am.

The main difference is that Gordon knows what to do. He knows where to go, what items to use and what kind of monsters there are in the game. Of course roguelikes require learning that stuff and using tactics to apply all that information. I don't play ADOM, but in Nethack it's the same story. What happens to me in Nethack that I sometimes get far, but then something bad happens and the game is over. Sometimes it's something new, but often it's just the lack of proper tactical response to a bad situation. In other words I don't know what to do.

This is somewhat important, because I'm developing games that should be difficult as roguelikes often are. But how can I do that if I'm not a skilled, tactical type of player? I really don't want to set up a closed game testing before release. Maybe I should forget about creating a super difficult game and create the gameplay easy enough for me to win the game. In case of Kaduria it will probably be something that happens anyway, because the RPG system is not similar to D&D.

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.

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?

I'm on a boat!

There are ten to do items that I was able to give some kind of estimation how long they will take. Then there are seven items that need more detailed plan so I can even try to allocate them on the calendar. Which I did for those ten items. I spanned them over a week, starting from tomorrow. So, now I know what to do for the next week.

I'm also trying to check out the actual time spent on that feature to see how well I could estimate the development time. It should be interesting, at least if your life is as boring as mine. Which I doubt.

If this works at least in some level it could be applied to Kaduria also, but it's too early to say. It would be interesting to get some kind of rough estimation of development time for Kaduria as well.

Guixcuse

I'm thinking GUI is something I start to improve when I know the gameplay would need serious work. I really didn't have to improve Teemu's gui or change fonts but I did it, because then I wouldn't have to handle difficult problems (yet).

I need to change that and leave GUI as the last thing to finish when everything else is in place. Even started it today I browsed through some of the notes left in source code for later fixing. I also got a kind of revelation in the usual problems with Creature and Player classes which I guess could really inherit from such a simple base class that there would never be need to check the player instance inside Creature class (from which Player is derived in my roguelike projects). Yet I'm wondering what kind of base class would that be?

About the unfinished features. Maybe I should even count the estimated time to finish them so I could possibly allocate the development time for Teemu, you know, using a calendar. Then again.. maybe it's too much.