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.

Screenshot from v1.3

The background graphics will still change a bit, but this is how the new font looks:

After a long battle I finally think the message routine is working. Of course all I had to do is show N number of messages from the tail of the list. That way it looks like it's descending from the top and then starts to scroll. Like, that was it? Well, I think it's pretty much ready now, other than it could be nice is show current turn's messages in white and previous messages grey or something like that so it would be easier to see what happened during a turn.

There will be some more GUI adjusting, but then that part is ready and I have to concentrate on the gameplay itself.

New fonts and stuff

The stuff has been an attempt to re-write the message routine. How hard it can be? I realized that for re-displaying the messages when screen is redraw you simply display 5 (or less in the beginning) messages from the list. It's really that simple.

The problem is again the repeat count for each message which doesn't count as an actual message, but should be displayed while not increasing the line count. Maybe I try to do something too complex for it, but I can't make it work. Maybe it's already there when message is added to the list, I just should record the number of messages displayed at each turn and if more than zero then re-display it.

I'm sure it wont work no matter how much my logic says it will. Besides I still have to solve what happens if there are more than 5 messages per turn, in which case -more- should wait for rest of messages.

New fonts are cool. The size is optimized for full HD resolution, but for laptops and smaller resolution there will be smaller font option later, hopefully using the new font in smaller size. There was some pixel editing to get the original monospace fonts to fit in their actual grid (and also changing some ugly letters), so much that in fact I created a new set of fonts.

Background color

While I have to think how I'm going to implement that new message routine I can always improve other parts of Teemu. An idea I had from one discussion at Rogue Temple was background color as option. This is another thing from the past (maybe it's in some current roguelikes) that the background color is always black. But sometimes it could be nice to try another background color, because black with bright colors can have too much contrast.

I have already programmed a background color option, but it's only for GUI parts and needs matching color sets for things like window background, stats, cursor color etc. Then there is the gameview which I think could have another option for background color, but it needs even more careful approach as not to make some font colors too difficult to see.

I think it's now likely that 1.3 is not ready before Christmas, but it's possible that it wont be delayed to next summer either.

Message lines

Re-writing message output. The thing with roguelikes has been that there is a single line on top of the screen and you get -more- when there are more message that can fit into that line. But why should it be like that with modern displays when you can just add more lines?

I've run into some implementation troubles with multiple message lines which is and isn't a surprise. You would think it's easy and for most programmers it is. Well, maybe one thing confusing me is trying to re-write the old rather than designing a multiple line message routine from the scratch.

I was thinking also to make the direction of message flow optional. I think it's easier to understand when message scroll up and the newest message is on bottom. Then again some games display messages on bottom of the screen and messages scroll down. It could be actually possible to make both optional in Teemu, just in case.

Other than that the Player class is almost done and started a gui color class mainly for optional background colors. When I get this message trouble solved it's also easier to finish routines that display messages, because they have to change somewhat, in some places.

Exciting development report

I've focused on fixing Player class. When thinking of the new combat system it could be quite easy to do, because you need to change only limited amount of source code.

There were not one but three bugs in Player::Eat to my surprise, but then again when I was programming the original version it was like an extended 7DRL so things went fast. Those bugs were only logic related (didn't crash the game or anything like that). The first one was that you couldn't eat a coconut, but it was erased from the inventory as if consumed. Then there were a check against item type if the item you ate was your weapon. It could fail. The third bug was that everything was delicious (fresh) or foul while there should have been also normal food items.

First day of this Christmas development time was quite nice. Mostly I know what to do, so everything feels much easier than when I'm programming Kaduria.

Teemu - Fifth Anniversary Christmas version (plan)

I'm trying to get the next version ready before Christmas. It's going to be called 'Fifth Anniversary Christmas version' even in the case that I'm not going to get it ready in time. It'll most likely in a middle of summer when it's released.

I've already browsed through the source code here and there to find something to fix. It's mostly content - those new level themes I have been talking about. But it can be a lot more if the story is changed. Not to mention the gameplay system itself.

Wish I can finish it this time, because I've abandoned this project many times since the initial releases.

Floor project

I need to move Teemu back to my tabletop computer, I can't do a shit to it with a laptop. I wonder if it's true with my music projects as well? Maybe I should get a real computer for it, too? And throw that god damn Fujitsu laptop to moon.

About moving, we're re-doing the floor of "my" music studio room. It means I have moved stuff out from the room for last two days and it's going to take this day too. It's crazy, because I realize now how much I have ridiculous crap I don't need. I'm either going to sell it or throw as far as I can.

Moving that crap somehow brings memories from the time when I was 14 and we went to Sweden for a brief period of time that possibly ruined my chances for a better life (than this I now have). Yes I want to whine, it's fun. I'm going to whine until I get my roguelike projects ready. And then I'm going to start another roguelike project.

Hardware talk

I've moved Teemu to my laptop, but I just don't seem to get anything done, because the laptop itself is just so crappy. It's Fujitsu-Siemens and it has extremely poor keyboard and bad screen with shiny surface (reflecting everything like a mirror). I never understood why they invented that kind of screen surface type.

My main computer (Acer desktop) is a bit noisy, but LG Flatron has proved to be an excellent monitor and I also have great Filco Tenkeyless keyboard. The reason I need another computer is music and for that you really need a silent computer like most laptops compared to basic (cheap) desktop computers. I have of course replaced the hideous default power supply of Acer, because it was ridiculously noisy, but still you would need extra equipment to make desktop computer silent.

I've planned to get another computer for music and one of the options could be Apple Mac Mini desktop. It's not too expensive, but the downside is a need for another HD monitor. So it would be around 1000€. (Or it could be iMac that has monitor included.) Since I'm currently unemployed that kind of money is not something to spend carelessly. But possibly selling some of my guitar gear will make it less difficult.

The reason why I'm thinking of Apple is Windows Fucking 8. I'll never going to use it and most new Windows computers have pre-installed 8. Besides I've heard that MacOS has much less those usual problems Windows has.

The best solution would be that hardware development would be updated to space age so we wouldn't need to struggle with computers like PC and operating systems like Windows. But I guess it's better to keep things crappy so people spend more money on equipment.

The control

When roguelike project gets past a certain limit in size it can become difficult to understand the project as whole. What I have noticed is that in some point I lose control of the project more or less. Relationships between different parts of the source code can become hard to follow and you can start to build structures that closely (or strictly) copy some of behaviours in other place. In pure game design point of view it's also difficult to track relationships between features, especially if they are not yet defined in a plan.

Modular design is a handy tool to reduce complex relationships, but it can only solve some of the issues and on top of that it also requires planning to work nicely. Sometimes modular design can become unwieldy and complex itself. But it's something you can do to reduce refactoring, because usually independent modules rarely require refactoring at all. They can also be reused in other projects.

I've always used open source or free editors to write source code, but they are missing better tools to control the source code. Something like graphical browsers for relationships between classes etc. Or simply a graphical representation of classes to see how bloated they are. The percentage of public and private exposure. Things like that.

Of course you could view a graphical output of classes by drawing them on paper, but it feels a bit outdated method and backwards when you already have programmed the class hierarchy.

Sometimes it could be something really simple like setting the color of the name of class or file in the project browser. That way you could for example use green color to mark files that are ready and red color to set files that still require work. In similar way there could be a list for unfinished functions to recall. Simple tools that totally are missing in VC Express and Code::Blocks, two of most commonly used IDEs.

Abura Tan project page

In case you missed it:
http://koti.mbnet.fi/paulkp/articles/aburatan.htm

Anssi moved the project to github and he has done something to it, but I don't know how serious he is about developing it.
https://github.com/anylonen/abura-tan

I'm focused to a 3D modeling project and keeping a break from programming. But last night I had an idea (again) of a new project that could be also a kind of framework at the same time with the new SDL 2.0 version included.

Framework programming is.. nice. I like it when there is no pressure to create an actual game, just a framework or engine to it. I wish some day I could create a good framework as a platform to real games with the main idea of having a small core that can be extended easily without getting into usual roguelike programming troubles.

I don't know when Teemu is going to be in release condition. It doesn't need much work, though. It's more about what I still want to add in it.

Abura Tan project update

I have now fixed all warnings in Abura Tan source project, changed the font a bit and also fixed a major bug that was made by me. It was a key name issue (keytostr function) which needed new data in form of a string rather than some kind of magic AT was using in that routine. I also fixed CppCheck cases that were suspicious, but not all warnings or other lesser issues.

So it's kind of ready. I'm still angry about the gameview routine bug (also created by me), but I'm sure someone knows how to fix it. I'm going to create a project page on my homepage with adequate information of what was changed.

Stone muffin

There was some talk at RogueTemple about Abura Tan, an abandoned roguelike project by Michael Blackney. I remember couple of years ago I tried to create an SDL version, but in HD failure I lost the open project. However I was able to find just one backup which I guess was the latest one.

It did not compile right away in the latest GCC version, but it was quite easy to fix couple of errors it had. It runs, but there is a bug in display routines which I guess is my fault. When changing from DOS (an old operating system) type output to SDL I made some kind of error. In fact the problem is that I don't understand the gameview code. It's quite weird.

There were 99 warnings (using relatively strict compiler settings). I've fixed them to 80, but there are still work to do. Lots of shadow variables which may be a source of possible bugs. I could also search for "the usual suspects" of C programming. Things like malloc/free, memcpy, void* pointers etc.

This is a "spare" time project that could be useful once it's ready for a release. Someone may find it easier to continue from a project which can be compiled and run in modern environments. Also, some better programmer than me can then fix the display routine bug.

For some reason I call this version the Stone Muffin project. I don't know where I get these ideas.

Teemu: I know your name

Last couple of days I've been creating a name generator with hand-selected name data which has been more difficult to create than I thought. Since I don't speak english it's possibly harder to remember common names like Charles. Rather than copy pasting all names in existence I've selected names that fit the pirate theme. Something like dutch, french, german, spanish and english names.

There are also pirate names and nicknames appearing sometimes. I think this was worth the effort and also I think I can use this system in Kaduria as well, since while it has a name generator it's not this well written or using std::string like this one.

Teemu: Bird or avatar?

After fixing some events I realized that parts of the event system I had in Game_Message could be changed to create message events. So it was even easier to fix than I thought. However other events still can produce message events which can happen in wrong order, but only if it can be noticed! There are only small number of other events so they are quite easy to check out.

Next thing was the sign object type. It went ok, but it required more than I remembered. First you had to add a new list type to Level class, but then also a genuine map for signs. For non-moving objects it could be easier to have a combined map for each object type. The problem with sharing object types for one map is that objects don't know their type. This was a design decision I had, because it's more OOP than knowing the type. I don't know it has any real advantage.

There is a lack of checking for overlapping object types during creation so it's possible that some objects can be created over others. In fact I have to create a routine to check that thing. I also need a debug text output routine really bad, because a lot of stuff is happening during the creation.

Teemu: Events

I started refactoring messages by detaching "long" messages (those which appear when you enter a new place etc.) from the regular messages displayed on top line of the screen. Then I rewrote Game_Message class with std::string style code taken from Kaduria. Messages are now event driven so adding a message will only add it to a list without directly showing it.

A while back I added a primitive event system for Teemu. What I didn't realize then was that direct messages and event messages created a logic error where some messages were displayed in wrong order. This also happens with current event driven message system, because messages and events to display them are two different layers of events! The reason why it went like that was that I suck as a programmer. Yes, I'm afraid it's the case.

Anyway, I think fixing the event problem is not going to be too difficult, because there are only few events happening. More so, only those events that have something to do with regular messages are wrong.

Teemu: Signs

The secret feature is almost ready, but it has to wait for other GUI elements to settle, because there is a new arrangement in that area coming.

For another new level theme I needed a new object type which is a sign. With the introduction of game objects (other than enemies and items) the source code has suddenly taken a step to more complex class hierarchy. I really try to keep the game object class (and derived classes, actual game objects) as simple as possible to avoid same kind of trouble as I have in Kaduria. Still, it already starts to look similar system I'm using in Kaduria, just in much smaller scale.

Started to const correct object strings, because I want to change message routines to std::string the way I now have in Kaduria. It's much better that way, but of course means some rewriting.

I'm also keeping a daily LOC count just for fun, to see how much code is actually written for the new version.

Teemu: New level theme

For ARRP I've continued Teemu. In two days I have added one new level theme, that one I was talking about earlier. It required one new algorithm created in short time. It's nice when you are able to create a simple algorithm that has cool and required output. The level theme's code is only 33 lines which isn't too bad. It's still missing items and monsters, but their creation is still open, because I'm planning more generic creation process for game objects.

Today I made a new feature which luckily has little to do with the core engine. For that reason it was easy to add and possibly nearly as easy to complete.

Brick Atelier 0.85

There is a new version of my in-house tile editor. Download it from http://koti.mbnet.fi/paulkp/brick/brick.htm.

Now when I got Brick Atelier out it's time to return to the island so to speak. I wanted to add one new level theme to Teemu, because I had an idea for it and it's not just another level theme. Yes, even I get ideas sometimes!

Biggest problem in Teemu is partially static level creation process. If you want to add "super lots of items" it's better have dynamic creation with some kind of logic for what is created and how much. Still I try really hard to avoid any kind of too heavy engine programming, but some of it is required. I want to keep Teemu a fun project as much as it is possible.

ARRP 2013

It's soon here, but what to expect? It looks like RL developers are not excited about it, because the development plans always follow their own schedule. Still, I could try to release new version of Teemu somewhere around the date. It's anyway the next thing, after new version of Brick Atelier is released which is very close. There is only one (easy) unfinished feature in BA and then some testing.

Teemu's to do list doesn't seem difficult, but the last version was released three (what the fuck?) years ago so it's never too easy.

New project day

It's actually an old project to which I have designed creatures as a starting point. I've talked something about script-based design before and now it's time to try it. It's a new style for me, but of course used in many roguelike projects since ancient days of Angband.

I'm looking at scripting as a tool to plan stuff before writing actual code. The script is a plan which becomes data when parsed.

This is also a good time to try new SDL 2.0. It's somewhat different than 1.2, but should be manageable I guess. It's better practice with a new project and then use the gathered wisdom to spread on older projects which I think will be converted to 2.0 sooner or later.

This new project is also going to be a roguelike. It has a cool basic idea or theme that I believe will carry over the usual development trouble swamp we all are so familiar with.

Pixel drawing tool project

Brick Atelier is a tile based drawing tool, but I have wondered if I could take good parts from that project and create a new drawing tool with regular canvas as drawing surface. It would solve some problems you have in tile based style, but also add new features I have never tried to program.

I have an idea for new type of user interface, but I have to try it first to see if it works. User interfaces are cool topic, because there always seems to be something to improve in them.

This time I could also try to think an alternative solution to SDL, because it doesn't have GUI features that could handle stuff like file dialogs. I really don't want to go in that kind of detail I did with Brick Atelier.

I don't know if this is going to happen, but at least I can make some plans on paper of what the user interface should look like.

The graveyard

The next destination in Teemu is the graveyard, an addition to places in the island. For that I have to create a name generator for graves, but other than that it's just choosing monsters and the usual stuff.

Finished reading The History Of Seafaring, a monumental book written by Donald Johnson and Juha Nurminen. I thought the subject was not that interesting, but that book surprised me. It also gave me much more accurate information about sailing boats than I knew before and there happens to be a boat in Teemu. I think it's going to have some improvements installed.

I try to work on all three main projects: Kaduria, Teemu and Brick Atelier. I don't want to let any of those projects dry out for too long time. It's just frustrating when you get stuck, in projects like this and in life, too...

Long message

There are long or level messages in Teemu when you enter a level theme that has it. You have an option to turn them off so I thought it would be good to be able to view last five messages just as regular message buffer. Storing the messages to a list was the easy part, since it's just a std::list in World class.

Programming the display routine took more time. First I had to solve how the window size knows its height, because each long message has different amount of lines. The "formatted" text output routine Write_F actually returns the amount of lines, but the routine to count lines was inside it. Of course you could always detach that part to independent routine, but it's not always that easy when you have local variables. So what I did was just call Write_F for each message and store the amount of lines. Write_F doesn't show the messages unless update is called, so it didn't matter. After that I knew the amount of lines, displayed the window and then displayed messages again on top of that window. Done!

It took about an hour or possibly more to write that routine. A perfect example why roguelike programming is slow. A roguelike can have hundreds of features, all of them waiting for implementation. And not only that, you can break the underlying framework if you need something new for a feature. It can then break some other features. The framework is extremely important, but sometimes it doesn't support something you need and changing how the engine works can be really difficult. This already has happened in Teemu with events that were carelessly mixed in.

Scripting hard

Teemu's unfinished features have been reduced from 23 to 16. I guess it's something, but hardest stuff is still to do. Once again I noticed that when you put something else in a class from another type of class as functional part of it it's usually a bad idea. But keeping those pesky classes strictly modular is quite impossible or at least unpractical in game programming.

I had an idea to use scripting in one of my roguelike projects. I guess scripting is widely used, but it's alien to me. I might as well try to go as far as possible and try to describe the game using only scripting. I think the good thing about scripting is that it's easier to stay away from static data structures and create a complete set of data for the game content. Maybe even before you write a single line of code. It's like planning the game content in a form of scripting.

Writing a parser for scripting is the hard part and also creating a game engine that can chew the processed data. It's going to be an interesting project. Or not.

Major issue

In IRDCon of Roguelike Radio was an interesting idea that roguelike is "major" when it has a lot of players. It's of course not like that. I think a strict definition is both unneccessary and funny, but when the game has complexity level of Nethack it can be called a major roguelike. However in my opinion even Nethack is too simple in a way. It has lots of items and enemies, but I've always thought that as "vertical" complexity. The "horizontal" complexity comes from the number of ways you can interact with the items and game world. It's an area that has a lot of room for improvement and I believe it's more important than the amount of stuff. You can have something like 300+ items, but the gameplay can still be extremely simple.

I'm working on several projects, but I haven't abandoned Teemu. It's a nice project, because it doesn't have to be anything like Kaduria which is really a seriously major project. I can put any wild ideas in Teemu and remove too complex ideas that would take too long to create (in the current version). Teemu has 23 issues to solve ranging from minor bugs to entire level themes. It's not that much, but there are always those difficult features that require more work.

International man of mystery

I heard they were talking about me on IRDCon. I hope it was all good things. Maybe some day I just appear there and surprise everyone. Well, maybe not.

I've cut down my forum time on some regular forums I visit. It's difficult for me, because somehow I have an addiction to forums even things often get into me vs. world situation. I hope the forum time will be allocated on game development in more efficient fashion.

Finally started to work on my new project. I know it's madness, but I need more projects to jump between them or I'll get bored. Besides this new game is a nice idea. It was one of those ideas you get suddenly before falling into sleep. It's almost like you could see the game in your mind's eye, the third one of course.

Mental block

Some days (or weeks?) ago I stopped programming all three of my projects. I didn't want to see C++ code, because I've been looking at it for... a long time.

It's temporary I hope. I need a vacation from this game programming "hobby". Actually it has been really warm in Finland for these two weeks, blame that too. When it gets warm it's hard for arctic region people to function properly.

I've been working on an unrelated 3D model and planning my next move for Kaduria and other projects. One of the big problems seems to be that the source code becomes difficult to maintain, because things like level class becomes really huge and it can get out of control. Maybe I need yet another "small" refactoring tour to do stuff like detach creation routines from level class or try to develop modular solutions in some areas of the source code.

The danger is that when you try to improve the source code you forget to create the game.

What is a roguelike?

Roguelike game has some essential features which makes it a roguelike.

1. Permadeath. What would a roguelike be without YASD? Not a roguelike.

2. Random game world. This one is a bit more complex, because you can't have 100% random content. It's against the laws of physics. However the structure of levels is often random in the limits of the rules that define the layout of the level. It's safe to say that even as low as 50% random amount counts as a roguelike and that there must be some kind of generator routine that creates some of levels on the fly (key levels can be static).

3. Turn-based and tile-based. These two are one feature, because they create the tactical topology of a roguelike gameplay. Tiles can be ascii or graphics, it makes no difference. Traditionally ascii was used, because display adapters at that time had no graphics support.

4. Role-playing. This one is controversial, because no one knows exactly what computer role-playing is. Good thing is that we have a long history of role-playing in computer game form. Games like Ultima-series and also games based on D&D role-playing system has helped us to build a firm role-playing experience. Role-playing can be limited or complex, but more character classes, items, monsters, etc. is better. Games like Nethack and ADOM are both fine examples of roguelikes with qualified amount of role-playing.

Return of the king

Richard Garriott joined the kickstarter frenzy with his game Shroud of the Avatar. It was a success in terms of funding, of course. It's as nostalgic as you can get. Ultima-series touched even me and I'm pretty solid person, a fan of few things. Ultima IV and V were influential games and I even had plans to do something similar, but roguelikes had more power so they took me into the dark side.

Shroud of the Avatar is not that interesting, although wonders may happen and it's going to be a great game. What I find interesting are the Youtube videos of Portalarium channel, a company that was founded by Garriott and some other developers. The video where Garriott and Warren Spector are talking is revealing, because of the body language both are expressing. Spector is both afraid of Garriott and also hates him. It's almost like he is forced to chat with Garriott in order to increase the credibility of the project.

I guess they have different personalities. Spector is a new generation (even he is older than Garriott) designer with less commercial thinking. He is more artistic. Garriott is like most old school game developers who joined the scene simply to get truckloads of money. It was different than now when a huge number of people is creating free games like roguelikes. Back then commercial success was an important part of game development and games itself were formed in certain direction and still today live under those rules. It's obvious when you look at what type of games are released in the commercial sector. They hope it's something people will buy.

Sometimes I feel envy of those early pioneers of game developers. It was easier to program some kind of blobs of sprites moving around and for that you got more money than you could dream of. And in 80's Internet had not yet destroyed social relationships which made it much easier to get in contact with real women. So they got money and women (and drugs judging from the games they made) like rock stars. What did we got? Nothing. I mean it. Nothing and on top of that people laugh at me when I talk about Kaduria.

Creature data design

Back a while I got excited about data-driven approach. It's still good, but if you type in data entries as C++ struct it can get messy. You know, those long lists of data for each struct data type. Then I realized you don't need to list everything as raw data. You can program a switch-case for some data type in a function that returns some data. It's better if you have like only couple of special cases and the rest of creatures are regular in that matter.

I think some of the data entries for creatures could be changed to switch-case style before I really start to add more creature types. Luckily there aren't that many creature types in Teemu so it's much more manageable than let's say the same problem in Kaduria. At the same time I need to start thinking some issues in AI and combat to improve the role-playing system of Teemu.

Actually there is some spark in the way that I feel it's possible to extend Teemu a lot from what the current release version is and it doesn't require impossible amount of work.

The plan

I drew a new world map of Teemu and placed new locations on it. It was then easier to visualize where new items would go and how they would contribute to the gameplay. The plan is now ready which is a good thing, no more wondering about what to do.

I have given up creating TEROS (TEemu ROleplaying System). It was too detailed and started to go in the direction of "never releasing it". Instead I'm going to model the damage system the simplest possible way and add only features that are needed. It's probably going to be something like accuracy and damage vs. dodge/speed and hit points.

Teemu on Bay 12 forums

There is a thread in Bay 12 forums about Teemu. I found it now about three years later. I also got some e-mail feedback when the first version was released, but nothing since then. Anyway, it was fun to read the experiences of players. I could get used to it, because it's somehow rewarding to know that people play the game.

It's also interesting to discover that players don't always do what you expect. Teemu is strictly plot-based and you should follow the plot to win. At least that was the plan. For instance the guy who started the thread didn't realize how the wire should be used. I thought it was essential to survive through the forest. Someone else told me that he killed all the pirates. How he did that? It was supposed to be impossible.

The main idea for the new version is create alternative ways to proceed in the plot (which mainly is about finding key items). The "problem" is that when the plot is less strict it can be easier to build a situation where it's impossible to continue. The good thing is that the player is responsible for that, in a way.

Tedious parts

I'm in a process to create another roguelike project. I'm kind of bored to finish Teemu 1.3 and, well, Kaduria... need to say more? One of the things in game development is that some parts of it are tedious and boring. I realized that when I think of a new project it usually ends up in my blank face staring at nowhere. You can always start with some kind of framework or using previous project as a framework.

Then what? I strongly believe that I was able to finish the first version of Teemu simply by using an actual plan written on paper. I drew the world map and locations on a piece of paper. I was thinking, why not use that approach again? Even there is no world map in this game. I should draw the layout of dungeon levels on paper and plan as much as I can.

It should prevent the blank face syndrome, because then you at least know what to do. How to reach the goals of the plan. Oh, I think I'm going to call the game 'Agduria'.

7DRL results

Over 300 game projects, some made it to a game. I think we need a summary of these games with clear indications on how well they made it as roguelikes. But who wants to do that? It's all mess now, no one knows what happened and what kind of games were made. There were too many of them.

I think 7DRL contest should be a way for developers to get contact in roguelike game development and try out ideas. But it wont make any difference if nothing else happens. If those game projects are left like that, unfinished or too light weight to be anything else than @ moving on screen.

When people talk about how easy it is to create a roguelike, they are talking about 7DRL games. Now try to create a real game with complexity of a major roguelike. Then you can call it easy.

The halls of Agduria

Agduria was kind of joke I presented back some years. I think it never was a real game project at all. Yet it has a page in Roguebasin. What the hell guys? I think Roguebasin has a lot of game projects that will never be a real playable game. Just remove them. It's difficult enough trying to find something in Roguebasin. Also I think various Angband stubs really need another web page. They aren't interesting anyway.

Jo had an idea for a 7DRL project to search an existing roguelike with tiles and then try to paint better graphics for it. It's actually a good idea, because roguelikes can have a bit rough implementation of tiles and it even feels like fun, something else than writing source code which can be boring sometimes.

The bios battery of my laptop died again. I guess it was old, because I found it somewhere. Need to get a new one from somewhere, then slightly improve the way the battery is connected. If it doesn't work then there is some problem in there. A new laptop could be a viable option, only this time try to find a computer that doesn't suck in so many ways as Fujitsu does.

Still underground

I was able to kick my laptop back into life by replacing bios battery and going through a long update process. I have plans to use it in music creation, but I also moved Teemu in it. I'm hoping to arrange some time for Teemu's development that way. I don't know if it will work, but it's something to try.

Some laptops have strange native resolutions like 768 pixels height. The current version of Teemu doesn't fit into that resolution. The easiest way to fix that could be shrinking the gameview. I think it's now 80x50 or something like that. Changing height to 48 or 47 fonts should fix the problem. The size of gameview can affect to gameplay in a way that if you can see enemies sooner it's easier to plan tactics. In this case the difference is likely too small to notice.

As usual the development of Teemu has been slow, much slower than I hoped. I think the main issue is the new combat system which is not yet planned. I'm not sure if I should even try to create a serious gameplay for Teemu. Maybe I could run into another direction and make everything go bananas.

Catacombs

Fixed room creation in the catacombs theme that was generated using digger bots. There are actually three, not two, unfinished level themes. I don't know what to use them for yet. I think it's going to become clear when I add more special items which could be located in those areas. Or I could just leave them empty and make players mad when they try to think if there is something hidden somewhere.

I'm now unemployed. I was supposed to go back to work, but stuff happens. More time and energy for roguelike development, but at the same time I wish to find another job.