Teemu

[Krice]

When I know what to do next I usually stop working... it's a weird kind of procrastination problem. But if I have some kind of difficult problem I like that situation more. This is one reason why it's taking so long, it's not just that this is a roguelike. I think roguelike is just an excuse to create problems which are difficult to solve. I don't know if this makes sense.

 

[Krice]

Attacking works again, it was broken for a while. Now it is a single function that works for everyone (in old school C style), and it's combining both data-driven and virtual function design, since sometimes the attacker is the player, or the player is the target etc. There are of course couple of minor things to figure out such as the amount of damage everyone is doing, including weapon damage. Then also I think messages would be easier to read if the current turn's messages were different color than older messages, and maybe there should be more lines of messages on the screen, then again it requires possibly difficult refactoring of the gui when the screen size increases.

 

[Krice]

The rpg system is becoming quite interesting and this was kind of an accident more than anything else. Wearing a disguise is going to have much bigger role, because the protection is different in each one. You can choose to be in disguise or get the max protection from different parts of armours. It feels nice to be fine tuning the system, because pretty much everything else is ready. The shopkeeper AI is still bit iffy, I hope it's not too difficult to fix.

 

[Krice]

Visiting more levels, then loading game crashes.. Tried to look at the save file, there is something strange going with undefined values for game objects I guess? I don't know, it's at the end of the file, I should actually check out what is saved there. It could be just player's items. Now that I think about it, it could be "easy" to check out by saving a string of some kind with player's inventory items.

 

[Krice]

Entered into testing phase. I made a neat debug routine which jumps to next level in chronological order more or less, so I don't have to walk through any of the levels unless there is some kind of item I need or I want to test that level. In the first run of testing I want to check out what items and other objects are created in levels, and also keep an eye on that save/load bug, trying to figure out when it exactly appears.

 

[Krice]

I tried to write a makefile to compile Teemu in Linux, but I.. kind of failed. I know I would have done it sooner or later, but instead I wrote a python script to compile and link the project. So, I found out that in Linux (at least in my computer) SDL2 seems to have a double buffer, which looks strange in turn based game, because in every other step the screen shows random crap in places where the game doesn't draw anything. Windows 10 -version doesn't have that problem. I wonder what is going on. -Wall in Linux found exactly one warning, could fix it, it's just unsigned - signed mismatch.

 

[Krice]

Also, I found out after 15 years of using SDL2 that it does actually have a double buffer. Well, then. I guess the only weird thing is why and how it works in my Windows 10 PC without redrawing everything.

 

[Krice]

After a successful installing of SDL2 from source code (there is a youtube video about proper install procedure, the wiki manual doesn't work) on my intel OSX I was also able to compile Teemu to OSX with the exact same script, which I placed on my github page just to have some content there:

https://github.com/paulpekkarinen/Comp

 

[Krice]

Rewriting display routines. It's not that bad, the only thing to remember is that you need to fill the entire screen per turn. Display routines became a lot simpler actually, because they no longer need to check if something has changed etc.

 

[Krice]

I made a new "release" tag for the project management file. It gives more realistic picture of the project, because only tested modules can get release tag. Testing is quite interesting problem in projects like this.. I don't know if it could be possible to write automatic tests for stuff, testing here means I'm testing manually if something works. The release tag seems to be a good idea which I'm going to apply to all my projects.

 

[Krice]

Testing is indeed something that took a bit long time for me to figure out. If there is something that becomes complex it's quite easy to run tests for that feature. Like for example when message routines get complex, I can run all the permutations and see if they work. Sure it takes some time to write tests and sometimes you need to add debug functions to access class data, but it's worth the trouble. Maybe I can even finally nail the RPG system problems by writing clever tests for it.

 

[Krice]

I would say I'm on a release run. Mainly checking out stuff, but there are couple of problems I need to fix before I can start to playtest. This game is going to suck, well at least the first release of version 1.3. If I can fix the RPG system then it will suck less.

 

[Krice]

I have a plan to just go for release after I can perform a playthrough myself. It was already quite hilarious. I learned that wielding a rupee gives way more attack power than just punching, then I was killed by a panda bear in the ship beach. Also, I had an "idea" to use 'H' as handle weapon (wield), but it's just too weird, so back to 'w' = wield.

 

[Krice]

There is a need to touch the source code, because I can't get the AI logic to work properly. I think the reason is OOP in this case... but there is a solution, I just need to extract everything AI to procedures and simplify classes related to those tasks. It seems to work when there is too much confusion.