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.

Plans for 2014

This year was not so great. I did improve Brick Atelier, but it's still missing important tools which are obvious each time I try to draw something with it. Maybe I have to find a real painting program that has the features I'm looking for.

Teemu is now in pretty good shape, the next version will be released in about two months or so. I hope it will be something much closer to a roguelike, with new more complex RPG system and more sandbox-style approach in the gameplay.

Kaduria is a mystery as always.. It's got a lot in it, but more content is needed. Things like AI, combat, level themes etc. I'm only happy that it has such a solid engine without tons of bugs.

This year's roguelike for me was Forays Into Norrendrin. The new version is amazing. It's highly tactical, combat-oriented game with solid user interface. I like all the small details like sliding along walls when walking to them diagonally and easy look command.

GUI themes

The optional background color was extended to entire color themes which there are seven to be choose from. Some areas still need to be adjusted as there were only static colors, but it's been such a fun actually compared to more generic game programming. Color themes surely makes the game look different and there are those lower contrast choices that was discussed. It was surprisingly easy to match background colors for the font colors. Only black was problem and still kind of is in the default black theme (black font on black background) but a viable workaround was a brighter reverse type shadow for that font color.

Set of features

Roguelike is a game with a number of features, randomly working together to form a totally random gaming experience that even the developer can't explain.

When I started to plan Teemu's next version I had already started to use a system where a number of features is put to to do list. I think sometimes planning can go too detailed and the plan itself becomes the project, most likely to fail even in the planning process let alone when the game is implemented.

A short generic list of to do items is a viable idea, because that way you can limit the number of features to important ones and try to think how long it will take. Not only that but I have started to keep the initial feature as simple as possible, in the logic of start small ideology. That way you can both try to implement the feature sooner than later and also test it in real world.

We humans want to think that our ideas and plans are perfect, but more often they are not. That's why simple and fast sketch of the feature is something that can create a better gameplay even you didn't expect it to happen.