Friday 30 January 2015

Life hack & slash

During my unemployment period I've alarm clocked myself up early, leaving 5-6 hours sleeping time, but it didn't went that well and now I have to say that I need at least 7-8 hours of sleep. Maybe I'm getting old. Since I'm a kind of person that can't go to sleep early I have to oversleep. It doesn't even matter since I don't have a job. But I've set the alarm to wake me up 10:00 just to make sure I don't sleep too much.

The second hack is coffee. When I quit drinking coffee almost six months (or whatever) ago the problems with my prostate condition started. What is quite ironic is that coffee works better than alfusozin, a medicine designed for prostate diseases. I can't get over it how funny it is. However the effect of coffee is somewhat amplified in my case, because I'm a highly sensitive person. Also, I have to watch out drinking too much coffee, it's not good either. Two or three cups a day.

I'm still working on Level class. I knew it takes some time to sort it out, but it's a special case of course since so much is going on in Level such as dungeon generation and interactions between creatures and everything else. Creating some kind of rough versions of level themes is the next big task. More on that maybe on the next blog update.

Friday 23 January 2015

Mushroom patch simulator

Every modern roguelike that respects itself should have a mushroom patch simulator or MPS. In Kaduria it's only a fractional part of the entire dungeon generation and plant simulation scheme, but it's good to have.

The idea in MPS is that generation of mushroom depends on host plants, usually trees. This is what happens in nature and even we think plants are scattered "randomly" in nature, it's the opposite. Plants as well as animals live in a world where they fall into ecological "slots" each depending on their skills to survive in that environment. We humans also have our slot, it's just quite large. But if we think of it there are environments we can't live in like extremely cold or hot areas or water. And if we think the bigger picture our slot starts to look small when we include our solar system or even the galaxy.

Random generation that depends on some other factor could be called dynamic random generation which is less predictable than older static random generation where each part of the generation process has very little to do with another one or there is no connections between them at all. But rather than following strict rules of nature it's often better to use random components to produce pseudo-natural results. The main reason for this is that if you would follow strict rules your simulation would have to be extremely detailed including realistic plant growth and environmental conditions. It's little bit too heavy in context of a computer game I think.

But let's return to previous issue with role-playing system. I still have problems with it and that's why I have returned to dungeon generation with another iterative process to find and store todo-items for the main todo list I was talking about. The supermassive Level class certainly needs lot of work even to detect all problem areas, not to mention how to fix them later. So I have plenty of work to do before I have to think about the RPG system.

Friday 9 January 2015

Real world

The problem I have with the RPG system is how to combine somewhat "realistic" physics of game world with character stats and creatures as game objects that have to follow the same rules of physics. It's been always a thing to talk about "more" realistic games, but actually it's strange when you try to design a game like that. Using simple numbers and calculations as in tabletop RPGs is both easier to program and also easier to understand as a player.

Well, maybe it is possible to use simple stats, but derive something more complex out of them. Maybe stats can just be hidden from the player to avoid unnecessary confusion. I know I'm confused right now, but I have to solve this problem, preferably soon.

Sunday 4 January 2015

Todo: todo

I've began to create a class/function level list of things that either need some simple fix or require more design and thinking. This far my project management skills have been limited to a bug list and some random todos both in a external text file and source code "notes". It has been quite messy to be honest and now that I have scanned through some of the files I'm already convinced that this new todo list was a great idea. What I probably should do is not try to create a full list in one go, but first check smaller files, fix problems in them and then continue to larger files down the class hierarchy.

A recurring issue I'm quite often detecting is the way small data type classes don't have as much code (functionality) as they could. There are even classes that have a list (enum) of things and Get_Name(), but nothing else. Yet this is not a simple thing to fix, because the multitude of ways you can implement something. It's possible to use a really simple data class and just code the relating functionality elsewhere. The somewhat ironic notion is how increasing the data type class functionality often means the member functions literally become more functional as in functional programming paradigm. But it's not always a bad thing.

I'm looking at the new year with steadfast determination that defies the insignificant background noise of negative comments I've received.