New year released soon

I guess it is unless world is going to end. It didn't end in 21. December which was a bit of disappointment even I'm not a believer of ends of world. It means I have to go on and try to finish Teemu's next version.

I've scanned through and improved level themes. There are two themes which need more work than others, but then the world structure is ready again. The big issue is how to create content in form of game objects. I have an attempt to create a data-driven system which allows new game objects without any special tweaking. Then I'm going to use up to all ascii letters for monsters and items.

However game object generation is the only part with that kind of system, because in other areas I'm just fixing problems fast when I find one. I'm not trying to create a neat engine based solution, because that kind of stuff is time consuming.

Hardware tweaking

My laptop suffered from multiple problems. Since bios didn't keep the time Windows was unable (who knows why) to update itself. After setting the time there were 104 updates, starting since 2010. At first Windows needed to update the update system itself and then it took a couple of attempts and errors to update everything. Some updates failed, but I think they were covered by newer ones. SP1 failed too, but manual update was a success.

The reason why Windows had not been updated was no internet connection. Fixed it by loading manufacturer's drivers (.exe with manual update overriding the idea of Windows already having up to date drivers). Then WPA2 and internet started to work again.

Still need to change the bios battery. You can't buy one I guess (for Amilo Pi3560 model), but it's some kind of small battery covered by plastic "sock" (I don't know how it's called in english).

Vacationing

More or less vacationing. I had big plans, but I guess I'm applying (r)est command for now. Took an interest to finish an ongoing home (music) studio project by ordering some equipment. I'm also building a 1x12 guitar amplifier cabinet from an old combo, removing the amp part from it. I guess Christmas time is making me kind of lazy. It's like waiting for it to pass and then life can continue. Why do we have Christmas at all? Everyone is spending money like crazy.

Forays Into Norrendrin is a cool new roguelike. It could have more catchy name. It's highly tactical and looks like it's got only practical stuff in it. Everything you do has some kind of meaning, every item and spell must be used wisely. There are some interesting design decisions like weapons and armour which are fixed, you carry a selection of them with you from the start and use one at a time.

Vacation days

Due to strange vacation day law my vacation days had been stacking and there were 9 on them which we noticed at the workplace yesterday. So from today to end of year I'm in vacation. For unknown reasons you have to keep vacation days so here I am. Of course this is great time to crunch some projects. I'm programming all three major projects, but I'd like to get Teemu's version 1.3 ready as soon as possible, because there is not that much missing from it.

I have good plan how to proceed in Teemu so it's quite nice project compared to Kaduria and Brick Atelier. However there is one thing I have refactor out from Teemu. It's the message event. I realized that when the regular message type went to kind-of event type (added in a list) it's confusing the event message system which I suppose is displaying messages in wrong order. Other than that there is just regular content stuff and trying to figure out more generic way to create monsters and items in levels.

It could be awesome to get 1.3 ready before Christmas, but I'm a little bit skeptical about it.

Roomies

The routine to search rooms was simple to implement, but problems started then. There is no mask map tech in Teemu so it's impossible to tell apart room floor (area) and regular floor. Doors could be created to another room, never connecting that room to the maze.

Luckily it was quite easy to add mask map, although it doesn't work perfectly. Also there is a bug in rooms next to right side of the level (also bottom side). There are no doors in them. I can't seem to figure out how the bug works, but it has to do something with checking out-of-bounds in level. If there is a bug in it it's quite hilarious since I've been using it always like that.

Digger part 2

Experimenting with steps and cloning values I soon noticed (which can be considered obvious) that fast cloning rate fills the entire level and leaves very small empty areas.

This version is made with 4 steps and 2-4 cloning rate. However turning fast makes the clones reach dead end quite soon.

This is more relaxed version with 4-11 steps and 3-6 cloning rate. More steps means longer corridors and makes possible for small empty areas to appear. This generator is actually quite good as labyrinth, since it's all connected, just pick locations from opposite sides for start and exit.

So how about roomies? Or rooms, as I tend to call them. One idea I had was actually create some rooms first, then labyrinth routine would go around them, but you could connect rooms later with a simple search routine to create a connecting piece of corridor.

Or it could be possible to extend some of the dead ends to rooms, or even search for those empty spaces and turn them into rooms.

Digger

There was an idea at the Temple which I had to try. The dungeon or in this case more like maze is created using robot diggers that move in some direction and check if it can continue. It also creates clones along the way which move in different direction and create branching corridors.

These two examples were created with the same routine. Now it's obvious that in some conditions the level can be quite small and not usable as a labyrinth. However there are three things which affect the generation process:

1. Number of diggers at the start (this is using one, starting from the center of level)
2. Turning speed (how many steps a digger continues in one direction)
3. Clone rate (here it's after 10-20 steps)

However adding more diggers when starting means that the generation paths are separate, since diggers wont touch any of corridors. Joining areas can be tricky, but it's doable.

Nice thing about this type of generation is that you can use it in a level that already has other features, like rooms and regular corridors.

Transition

The way stairs are created in Teemu is simple. I found out it was too simple, actually. It works by creating automatic pair for an entrance. So called border exit is a special case which is made in outdoor levels you enter from the island, such as the forest or hut area. Border exit is simply "stairs" activated when the player steps on the border of the level.

What I needed in one of the dungeon levels was a border exit to another level at the same depth. However a border exit can't be an entrance to another level. It can only be a way to return to the previous entrance and to change that would have required a large scale refactoring in the way nodes (connection data between level themes) work in level theme data.

I tried to use a border exit, but it of course returned to previous dungeon level from where you came from due to automatic node setup. I knew then I had to hack it. Just hack it any way I can. After some time I managed to come up with a quite neat solution. First of all, I created a new type of entrance called Transition. Then I added a code checking if there was a transition in that level when trying to exit the level from edges (border exit).

The destination level could have a normal border exit of course, but there was one problem: IF the level has a border exit, it's the place where you enter, no matter from where you enter in the level. The issue was another stairs in that level, leading out from it. This is where some clever hacking was involved by checking the particular source and destination levels in node setup, then changing the destination stair type to upward stairs, preventing a regular enter to border exit location.

This is yet another example why hacking can be a viable solution, because the engine can be too restricted to do something more specific like this. Now the feature (transition) is there and it's working. It took way less time to code than actual engine support for that feature and there was a minimum amount of source code hacking, actually only 3 lines of code in the border exit routine and one line in node setup.

Aarr

Progressing slow as usual. I've programmed Teemu only couple of days during this month and that's it. Mainly some engine tweaks, actually nothing on content. It sucks. Not knowing how to proceed with the role-playing system is one of the main issues. Then there is additional dungeon generation and data-driven object creation on top of that. It's way more complex than what was in previous version.

I don't know if my real life job continues next year. Wish I was unemployed just to concentrate on programming games, but it's hardly a good plan.

Arrrp!

Arrrpp! There be pirates! I've unofficially continued my pirate-theme roguelike Teemu. The plan is more roguelike with multiple solutions to problems rather than strictly following the current plot. Teemu's engine is the biggest problem right now, but I'm quite optimistic that I can fix main problems and concentrate on increasing content and complexity of the gameplay.

Open source

Recent discussion about ADOM's source code is asking for my opinion. If you really think the benefits of open source I can only think one and it's the ability to compile to another platform. People always say that open source is great because everyone can take part of development. I think it's the worst thought, because people per se are not good developers. Even if it is open source we need a great game designer (preferably a team leader) who knows what to do. There are not many people who know the stuff and most of them work in commercial game development.

Then maybe someone can fix bugs, yes? Not likely. Bugs are typically hard to find and/or fix and people seem to be reluctant to take part in that work. It's tedious and not fun.

Even when it's easy to change the game content it's less obvious that anything good will be produced. Is there any Angband variant better than the main game? I don't know.

The usual problem is however that the source code is really difficult to understand and it's even harder to make any modifications without breaking something elsewhere. Nethack is notorious for that. DCSS has been a kind of success, but it didn't happen easily when the developers continued from the original Crawl source code. I have seen it and I can imagine it was not an easy task to continue from the state where Linley left the source code.

Trying to work with open source people is difficult, because there are no rules or obligations for anyone. Good graphic artists are impossible to find to work free. It's also difficult to match another programmer in the development, at least someone who don't want to be a game designer like you. Two or more game designers is not going to work well.

Now that ADOM Deluxe is going to be a commercial game Biskup made a wise choice when he did not release the source code. He has eliminated the possibility for someone to make ADOM Deluxe Free based on ADOM's source code. I bet we will never see ADOM's source code open so please stop whining about it.

Elitism in roguelike scene

This subject was discussed in the roguelike radio with Hugh "Darren Grey" Grant and Ido Yehieli. What I think of this whole matter is that some people are too keen to accuse others to be elitistic if we even can use that term in roguelike development scene. I think roguelike developers are actually the least elitist group of developers out there. Just think of it. Most roguelike games are not only free, but include open source to share ideas, design and programming techniques. It's not like we were typical software developers with silly amount of money and couple of sports cars. I'm proud of the fact that game development for me is anything else than trying to make money.

There has been some talk about how to make roguelikes more accessible to "average" players. Isn't that kind of thinking actually elitism? I like to think that players are clever, possibly even more so than me. I don't design games for dummies like all commercial game developers seem to do. I want to make roguelike games which are as complex as possible. (Of course it's easier said than done.)

There is something I kind of agree with and it's the discussion about "what is a roguelike". It's a pointless discussion, because the genre isn't strictly defined. Well, other than being turn-based, including permadeath and random content. And role-playing. I think that should cover it. But I think we all know when a game is more than just @ walking on screen or one-trick pony like 7DRL games.

When you try to make games more accessible or try to think what players want you end up creating games like Fable. For me the most important thing in game development is having a clear vision of what you want as game developer and a player. However it's good to keep yourself open to suggestions if there is something in your game that players might hate. Let's not forget that most game developers are not good at what they do. So it's important to learn from the feedback, while keeping your own mind.

Two problems

It looks like I run into two main issues in roguelike development. It happened with Kaduria and now with Teemu. First problem is the way I'm trying to write "perfect" source code and move from hacky to more pure style of source code. It would be good of course, but it's taking time, moving release date away to distant future.

Second problem is the role-playing system. When you try to develop one from a scratch it's not easy. I think most roguelikes have something like D&D or similar which is taking the easy way. But when you try to figure out everything yourself and build a rpg system it's just chaotic. The current system in Teemu is really simple so it wasn't hard to do, but anything more complex than that means you need to plan and think hard. And as we know, thinking is not something I do.

Random monsters

Update scheme and whole GUI class actually is now in much better shape than it was before. The gameplay feels a bit faster.

I've moved on random monsters and trying to create a generic system which then accepts any new monsters added in the data, except special monsters made only in special level themes. In more generic creation there is a need for automatic balancing which prevents creating too many difficult monsters. Or another option is non-balanced and make the game more difficult.

Update scheme almost ready

New GUI update routines are now ready, but there is a clean-up of old manual update routines yet to finish. One major thing I noticed was that there was a call to world->Update (now Redraw) which cleared the screen and then redraw everything in each turn. The new version is designed to prevent that kind of stuff which is slowing down the game even it can't be noticed on modern PC. Another thing I need is the actual redraw of elements to have same kind of notification that FOV rebuild has. I think gameview (Level::Show) needs it at least. It could be called Level::Request_Update to mimic World::Request_LOS_Rebuild.

There are quite number of manual updates which have to be resolved by better program flow with less calls to update routines, mostly concentrated running only once per turn. It's time consuming trying to build a "perfect" solution, but I think it's worth the effort.

Teemu 1.3 on its way

After a while of thinking I decided to finish Teemu 1.3. It deserves that, because I already had refactored it and didn't want to forget it like that. I think I have to reduce some of the original plans, but let's see what happens. The main difference to previous version will be more complex game engine and role-playing system, which I hope is transforming Teemu more a roguelike.

Good thing is that my job begins later than I thought, it's taking yet a month so I guess it could be a nice amount of time to spend on Teemu.

To rogue or not to rogue

With Teemu I proved that I can release a game. While Kaduria is under development I would also wish to prove that I'm a good game designer. I think now it's the time to do that with all new game project. With it I'm stepping out of the narrow roguelike style and simply create a game. I wouldn't be writing this if I had not come up with an excellent idea. The best thing I guess is that with my current knowledge about game design I can and will plan the game before writing any code. I can also do that at least in three stages and also possibly release the game after each stage.

Got a job

I've got two weeks free, then I'll return to my work where I was more than a year ago. I "promised" myself not to do that again and find a real job somewhere with more income. Well that didn't happen and I was kind of forced to accept this job, because the way unemployment system works here in Finland. If you don't accept a job they stop giving you money, so it's a lose-lose situation for people who are not active enough to find a proper job. Low wage jobs are the result of current right-wing politics. These people want to return to good old slavery times, really. Not only that, I met my new boss briefly and there is something wrong with that person. He pulled me away into a corridor to explain what were my tasks in the job, as if it was some kind of secret no one should hear. What a creep.

I'm actually quite depressed. Maybe I need to be more to get out of this situation. I don't like what's happening in my life.

7DRL dev diary - days 6-7

For 7 days this project was a failure, but I will continue it later. One thing I'm waiting for is bmesh for Blender. I've pretty much stopped making 3D stuff until bmesh gets into official release. For those who don't know it's n-gon support for Blender which this far has had only triangles and quads, making certain type of models hard to do. Also with bmesh comes vertex based bevel which for me is the number one tool to build models.

I feel bad about roguelike development right now. It's a phase that will come sometimes, but it should pass in couple of days or weeks. In the meantime I try to concentrate on Brick Atelier which is in many ways a lot easier project than games.

7DRL dev diary - day 5

Day 6 has started, but let's report day 5 first. I was supposed to model 3D yesterday, but didn't do anything. This time of the year is possibly the worst for 7DRL type competition. In arctic regions it's spring time. Snow is starting to melt and sun is rising above the horizon which means it's a blast of bright sunlight after dark winter. It has strange effect on body. On the other hand it's increasing the amount of testosterone, but it's also backfiring in form of tiredness.

It's snowing pretty hard right now, so spring has to wait for a week or two I guess. So does this project, with realistic development time being more like month than 7 days.

7DRL dev diary - days 3-4

I've got a plan of the ship and some basic tiles planned on paper. I haven't yet programmed anything. The small number of tiles made me think of making 3D models of them with 2D rendered tiles from the top side. 3D is cool, because you can then change lighting, colors/textures and the size of the tiles. It also means I wont finish this in 7 days, but it never was the idea of 7DRL for me.

The biggest problem still is the idea of the game. I have no idea what the player should do. Maybe fix something before the ship goes boom? Battle alien creatures that were attached to the ship while visiting a distant planet? Maybe I should just create the game without content and wander around the ship, trying to think it that way. Or I could just release the game without content, making the player think what the hell he is supposed to do.

Update: Got the idea and it's a good one.

7DRL dev diary - days 1-2

This far I have planned the user interface which is going to have a nice style (I guess). When thinking of the theme I was first planning to place the game in a mansion and then on an island with a lighthouse. Boring.

Now it's second day and I felt that I need something different. Then I had an idea: a large spaceship with cargo container halls as central place. They can be just like regular caves in fantasy roguelikes. Places are connected with elevators. It could be cool to create a 3D level structure so elevator shafts (and everything else too) would be placed in their real location.

I've only started day 2 so it's time to plan stuff. The structure of the spaceship and levels, what items you can find, how about some vending machines? And I need some kind of story, what's happening in the spaceship and what the player needs to do.

Framework classes

There are now 15 classes in the framework. Still, I want to extend the framework to higher level classes. Some of my goals are GUI itself and a generic Message class to output roguelike style messages. The current one in Kaduria is a real mess, it's very big and confusing so I have to think hard to create a better one.

This is the current list of classes and enums. Tar_Ball is a serialization class with binary/text data format. I'm quite proud of it actually. One of the problems I have to tackle is how class instances should be created. This far instances like Keyboard and Random_Generator are global, because there is only need for a single instance. It's not modular, but I don't know a better solution. Although Random_Generator could have several instances in classes where random numbers are needed, but the seeding should then happen somewhere else. Classes that are global usually can't be used as local instances, because they load stuff or are otherwise heavy to initialize.

Framework

Thought it would be a good idea to create a generic framework for the next project which is that 7DRL I was talking about in the previous entry. I have programmed some modular classes during these years which I have used in my projects. You can view some of them in Teemu's source code, especially in 'classes' subdirectory. What I want to do is make them even better and for that I'm using GCC which is more anal about purity of C++. I will also compile the code with Visual C++, because it's my main development tool.

Building a framework or a library of useful generic classes is wise. It reduces the amount of time spent in setup of a new project and improves code quality since usually those classes have experienced a good amount of testing. What I also would like to achieve is a number of higher level classes that could be used as a base for each new project. For example this far each GUI class has been specific for that project, but I'm hoping to create a generic GUI class which then can be extended with new features.

Plans for the next 7DRL

I have an idea that could be implemented as 7DRL. While working on Kaduria (and Teemu) I have possibly started to think that a tile should own everything it has. In practice this means that each tile should have container list for items, flags for different stuff etc. For some people this is the way to do things anyway, but it's new to me, because this far a map has been just a collection of tiles, a simple 2D matrix. But when you think a tile as an object that can hold and own stuff it begins to look more and more a good idea. It makes many things easier, but could possibly make others harder.

Another thing I want to try is game objects without inheritance. Just one class for all game object types. It should be easier to do now when I have more knowledge about data-driven style.

If the "tile based" approach works really well there may be a brief refactoring session in Kaduria...