This project has some features that have been unfinished for a long time - for various reasons. I thought this message count thing was going to be the next one, but in just a few minutes ago it was fixed. What I now often do when I get a difficult problem is that I close my computer and get some paper to plan how to fix it. Surprisingly it works often than it doesn't. Planning on paper is free from any distractions and you can literally visualize the problem by drawing it if it's something you need to do.
When I look at the list of unfinished features I have to evaluate them again. And again.. but it's difficult to make a decision to delay the feature or even worse - remove it.
Monday, 22 July 2013
Friday, 19 July 2013
Ducks & Barrels
Refactoring the message routine was easier than I thought. I had already changed old c-style msg()-function to use message "event", a list where messages per turn were stored. It was essential, because there are zillions of calls to msg(). In fact, I'm not even planning to replace them, unless a part of code is refactored for other reason.
I made a clever choice to create a dedicated class for messages that are displayed and stored in the list. It's storing the message itself, color (for future use) and amount of repeats. Everything else went well, but there is a bug or more like logic error in the repeat or count of a message.
So, when you get messages like this:
Duck.
Duck.
Barrel.
It's convenient to display first two messages like this:
Duck. [2]
Barrel.
But when you store messages in the list there are only two actual messages, not three. This wouldn't be a problem during a turn, but the glitch happens between turns: if there is no new message added to the list, the message is not displayed at all.
I was in shower when I had an idea that might work. It could be possible to store the count of the last message and check if it's different than before and display the message as an extra one before the messages that were added in the list during the turn.
I made a clever choice to create a dedicated class for messages that are displayed and stored in the list. It's storing the message itself, color (for future use) and amount of repeats. Everything else went well, but there is a bug or more like logic error in the repeat or count of a message.
So, when you get messages like this:
Duck.
Duck.
Barrel.
It's convenient to display first two messages like this:
Duck. [2]
Barrel.
But when you store messages in the list there are only two actual messages, not three. This wouldn't be a problem during a turn, but the glitch happens between turns: if there is no new message added to the list, the message is not displayed at all.
I was in shower when I had an idea that might work. It could be possible to store the count of the last message and check if it's different than before and display the message as an extra one before the messages that were added in the list during the turn.
Tuesday, 16 July 2013
Leaving a message
For some time I have planned to refactor the way message routine works. Since the data was largely centralized to the message class I had difficult time figuring out how to proceed. Then suddenly I had an idea while I was doing deadlifts in the gym. Who said weight training and roguelike programming can't co-exist?
It would be extremely hard to discard everything done this far. Rather than that I'll try to slowly include the new routine inside the message class so it can work at the same time with the old routine. I think it can be done and it's not even that difficult. However it may be somewhat difficult to distribute the centralized data, but in return it will give better modular structure for the message data as well.
I'm also trying to replace C-style variable parameter routine with std::string. I don't yet know how hard it will be, but I think it's worth a try.
What I hope to achieve with the rewrite is more flexible message routine which is less responsible for creating complex messages, but at the same time taking care of things that could be tedious to handle in the routine which is displaying messages.
It would be extremely hard to discard everything done this far. Rather than that I'll try to slowly include the new routine inside the message class so it can work at the same time with the old routine. I think it can be done and it's not even that difficult. However it may be somewhat difficult to distribute the centralized data, but in return it will give better modular structure for the message data as well.
I'm also trying to replace C-style variable parameter routine with std::string. I don't yet know how hard it will be, but I think it's worth a try.
What I hope to achieve with the rewrite is more flexible message routine which is less responsible for creating complex messages, but at the same time taking care of things that could be tedious to handle in the routine which is displaying messages.
Sunday, 7 July 2013
Puzzle adventure
As the source code has grown and also the scope of the project it looks like all I have to do is solve puzzles. They are unfinished features or some part of source code I've marked.
These days I try to find some kind of quick solution to these puzzles, just to get somewhere. It's also tempting to simply remove the feature for now, but then you go back to simpler gameplay and finally reach a game that has complexity of a 7DRL. All that in 30 years of development.
These days I try to find some kind of quick solution to these puzzles, just to get somewhere. It's also tempting to simply remove the feature for now, but then you go back to simpler gameplay and finally reach a game that has complexity of a 7DRL. All that in 30 years of development.
Wednesday, 5 June 2013
Rethinking artificial intelligence
A while back I removed AI system I had been developing for some time and merged it to a command structure. Maybe I was looking for a simpler solution, but after some thinking it's obvious that there must be a separate AI logic with the original primary/secondary task idea.
How tasks will be organized is not yet clear, but each of the creature has to keep something in mind, a goal to which it is reaching. A number of things can change the goal, but not secondary tasks which involve things like swimming or some other circumstance as a temporary block between the creature and its target or goal.
I'm too dumb to use any sophisticated AI algorithms, but I think you don't need any of that to make creatures do what you want. Also, algorithms tend to produce predictable patterns that can be exploited. I intend to create an unpredictable AI that can sometimes make huge mistakes or forget something important. If I can make it so that the player will see those mistakes then it's going to be cool.
How tasks will be organized is not yet clear, but each of the creature has to keep something in mind, a goal to which it is reaching. A number of things can change the goal, but not secondary tasks which involve things like swimming or some other circumstance as a temporary block between the creature and its target or goal.
I'm too dumb to use any sophisticated AI algorithms, but I think you don't need any of that to make creatures do what you want. Also, algorithms tend to produce predictable patterns that can be exploited. I intend to create an unpredictable AI that can sometimes make huge mistakes or forget something important. If I can make it so that the player will see those mistakes then it's going to be cool.
Sunday, 5 May 2013
Mountains of snow
I find myself again at the snow top. This level theme requires some new routines, but if I keep myself calm I can possibly create a brief sketch for each level theme per week or two. Anything new made in a theme can be used later and most of the time consuming stuff is creating things that don't yet exist.
When most level themes of Kaduria are quite static with some random structures it has made me think what I'm actually trying to do. It's like Teemu, I can't call it a roguelike. It's too static and more like adventure game. Still it has permadeath which even I find annoying. The interesting thing is that some people like the challenge permadeath is creating. Even when the game design is poor and often your character dies in a random situation which could not be avoided. This has made possible to create games that have quite poor game design, but some people still like them. ADOM is a great example. It never was really good as a game, but its difficulty became a feature some hard core players like anyway.
I know it's funny when you remember my strict opinion about what a roguelike should be, but I have to think about removing permadeath from Kaduria. I want to create a large game world and more static content. It's not good combined with permadeath. I think pure roguelikes should have relatively small game world and almost completely random level generation. However Kaduria will most likely be a fusion of "static" RPG and a roguelike. Maybe it could be a good idea to include an iron man mode with permadeath for hard core players.
When most level themes of Kaduria are quite static with some random structures it has made me think what I'm actually trying to do. It's like Teemu, I can't call it a roguelike. It's too static and more like adventure game. Still it has permadeath which even I find annoying. The interesting thing is that some people like the challenge permadeath is creating. Even when the game design is poor and often your character dies in a random situation which could not be avoided. This has made possible to create games that have quite poor game design, but some people still like them. ADOM is a great example. It never was really good as a game, but its difficulty became a feature some hard core players like anyway.
I know it's funny when you remember my strict opinion about what a roguelike should be, but I have to think about removing permadeath from Kaduria. I want to create a large game world and more static content. It's not good combined with permadeath. I think pure roguelikes should have relatively small game world and almost completely random level generation. However Kaduria will most likely be a fusion of "static" RPG and a roguelike. Maybe it could be a good idea to include an iron man mode with permadeath for hard core players.
Wednesday, 1 May 2013
Caverns of doom
In the next phase caverns or more like passages connecting them went through everything else as was expected. Passages wider than 1 tile were removed temporarily, since there is no routine to check rooms with the ellipse routine drawing passages. It's a minor problem to be fixed later.
Caverns itself were too small for some reason. Fixed that with proper data for the level theme. That way I can control the size on each level theme if needed.
Both actual rooms and caverns are separate "layers" so it's possible that sometimes those two don't have a connection between them. It's rare, but possible. I'm going to check that with flood fill and then searching a place where a corridor can be made without breaking anything else.
When looking at cavern interior generation I started to think too much again. There are 11 different interiors now and some of them are unfinished, but I realized that I can and should leave some of them to do later, namely those I don't need right now in this level theme. It may be even possible that caverns can't do something I need later and I have to create another more specific routine for that task.
Next I'm going to add small rooms which is the last feature for this level theme. After that I'm going to move on next level theme. The idea of the new plan is first create the physical structure of each level theme and only then add details.
Caverns itself were too small for some reason. Fixed that with proper data for the level theme. That way I can control the size on each level theme if needed.
Both actual rooms and caverns are separate "layers" so it's possible that sometimes those two don't have a connection between them. It's rare, but possible. I'm going to check that with flood fill and then searching a place where a corridor can be made without breaking anything else.
When looking at cavern interior generation I started to think too much again. There are 11 different interiors now and some of them are unfinished, but I realized that I can and should leave some of them to do later, namely those I don't need right now in this level theme. It may be even possible that caverns can't do something I need later and I have to create another more specific routine for that task.
Next I'm going to add small rooms which is the last feature for this level theme. After that I'm going to move on next level theme. The idea of the new plan is first create the physical structure of each level theme and only then add details.
Subscribe to:
Posts (Atom)