Year 2011

I was looking at my dev diary from summer to this point and there is surely an interesting trend for increasing amount of development. It's also showing in the new LOC chart (starting from summer):

LOC has increased "only" 2000 lines, but it's quality code! Most of the source code is already in place and only involves some adjusting. Not to mention removed code, there has been some of it also.

This December was actually the best month in development point of view. I was able to complete or almost complete several major classes and the work is now more and more focused on narrow set of classes which have the most difficult problems to solve (AI, item routines, advanced level generation, etc.).

Rebuilding gameview

Areas of the gameview are starting to update properly again. While refactoring I ran into something quite unexpected. The main stats were updated inside the stat class and signaled to GUI, but of course it was done for all creatures, not just the player. So, had to backtrack and create wrapper routines in creature class to adjust stats and check if the creature is the player, and only then signal GUI. It was easier than I thought so I made it in one run.

It looks like other parts are fine, although I have to add parts that weren't there in the first place: two explanation text slots and quick item slots that can be used with keys 1-7. Then I have to clean up some manual updates, especially check out calls to Redraw in the dungeon class.

GUI class ready

Another part of the source code is now as ready as it can be. I think the GUI class is looking pretty good now. I don't even hope for good looking graphics at this point, I'm happy that basic drawing functions are done. The gameview still can't update itself so it looks a mess and even messages aren't shown and need to check out n+1 things related to drawing functions, but I'm still happy that something was done and finished finally. It may not sound very exciting, but for me it surely is, having spent so much time on this project.

Next I'm going to concentrate on that gameview drawing. The gameview now has clearly set areas so it should be easy to check out them one by one.

GUI development

I was right about text updates, most of them work without update inside the Text class. GUI class is actually almost ready and it's doing the job properly for most of parts. The biggest problem is how to draw and update parts from different sources. They also probably need notification instead of direct update which would lead to multiple drawing operations per turn. The good thing is that a roguelike doesn't have that much GUI stuff.

Back about three or four weeks I injured my elbow. The doctor said, judging from x-ray images, that it's some kind of calcification resulted from a long period of inflammation. I guess it's probably right, because I've had tennis elbow for a long time now. The injure came in weight training of course and I think it was a disaster waiting to happen. So, it looks like my training days are over, at least until this is healed completely. I don't want to reach the point where I can't move my fingers anymore. That would suck.

The bright side is that I have more energy to spend on something else like roguelike development. It's going to be a positive thing for this project and I already feel I'm getting more results in shorter time.

Update on update

Rewriting GUI for update rectangles is going to be worse than I thought. There are manual updates in some wrong places, namely in text output routines and keyboard routines. It was quick and dirty way to implement some linked updates, but they were in wrong place. Things like that should be there, but they belong to GUI. Text update is silly, because text is usually printed on some self-updating surface like window or gui background graphics. That's why there are double updates in most text routines.

It's more complete rewrite than I thought, but essential for that consistent flow of drawing and updating.

Update rectangles

Gameview is also being re-designed for consistent behavior in drawing and updating. The gameview is divided into rectangles which are updated only once during a turn when a flag is set for that area. It removes multiple updates and makes things both faster and also aware of what should be updated. Update rectangles are needed, because Kaduria is using only software output without any hardware acceleration. It's easier and more portable in the end, and I feel that a roguelike has no need for hardware routines.

I have also finished the structure of the gameview. It's going to have quick item icons for using items with keys 1-7, and status icons. Both of them will have explanation text when hovering over with mouse cursor. One thing I'm not sure about is the debug radar which is a small level map. I guess it could be visible in non-debug mode also, but it should be re-written to display only what the player has discovered.

Load and save game

Most of the classes know how to save and load, but the main routines are still under development. It's looking quite good actually and only some things need to be tweaked to make sure that there are empty versions of instances for loading saved data. Load/save can be difficult to program, but I'm now much more prepared for that task than I was before.

Debug routines... ready?

Yes. It appears so. I've finished debug routine module, it's as ready as it can be. Of course there could be some new routines needed, but it's only when I can figure out what they are.

It took only 15 years. And this is not a joke, it's a real number.

Hero coder

People keep calling me a hero coder (literal translation from finnish language). I guess it's some kind of joke, because sometimes I write comments about social media games like Minecraft and Angry Birds. Even writers of popular Pelit-magazine (biggest gaming magazine in Finland) make regular references to me. It's cute and flattering, but I don't care about that kind of thing a lot. You know, being a celebrity.

I think there has been misunderstandigs about my comments on social media games. I don't hate them or lucky developers who get zillions by taking advantage of the social media. They are game developers just like myself. Except that they own ridiculous amount of money and some of them wear a hat which attracts women.

The biggest misconception is that people think in their own terms like being jealous about money and girls. I don't get that. Game development is my hobby and I'm pretty devoted to it. It means I'm interested in game development itself, not money or girls. Being a roguelike developer means you are in the forefront of game developers. We don't just make games as products but in the next generation roguelike genre we make something new. It's a way no one has explored earlier. And that exactly is the reason I'm making games.

Some people measure success in money (or amout of girls) which means Minecraft is a great game. But if you were a game developer and look at Minecraft from developer's point of view, then it would not be that interesting. Still, as I stated before, I'm happy about the unexpected success of social media games or more like products. They just don't have a lot to do with hardcore game development which is a small sector of game genres living and surviving under the pressure of this commercial world.

Basics

Sometimes I feel really dumb, because I realize I'm programming some basics that should have been there way back. I'm still working on container code which is moving items from objects like barrel to inventory or somewhere else. It's a kind of feature you would suppose to be implemented in early stage, but somehow isn't.

I guess this is the case with some other features as well. Maybe there is no proper order to complete features. Then again I have spent a lot of time creating this simple turn-based RPG with random content and I'm still wondering how hard this could be? What is the problem with roguelikes anyway?