The coordinate saga is complete and I guess the results were worth it. At least now I know it's not that difficult to expand the class hierarchy.
It's always great to plan stuff for the next year and then not get them done. But anyway, I hope in 2016 there will be more content and less engine coding. Level themes require a lot of work, but maybe it's less difficult than I think, because the vast number of existing techniques to create levels. It's more like combining those to create different kind of themes. Although I need a good labyrinth and town generator routines.
Next big task is the RPG system. Thinking of approaching it by creating interactions between game objects and the game world itself first, then object vs. object interactions. Exactly how to combine pseudo-physics to more traditional RPG rules is still a mystery. If it fails, it's always possible to degenerate to a traditional system.
Wednesday, 30 December 2015
Friday, 25 December 2015
Why location is a great idea
So it turns out that I really need the location data in the base class to make life much, much easier with game object messages. And with other things as well.
Of course I did change quite a lot, but it's not that bad I guess. What I will keep is the Mover class, nothing wrong with that. It just makes moving possible to proper classes. Yet the base class should have the location data for above reasons. You don't have to save the location, it can be reproduced for objects that are only in the map.
I hope I get this mess resolved fast, because it's getting on my nerves.
Of course I did change quite a lot, but it's not that bad I guess. What I will keep is the Mover class, nothing wrong with that. It just makes moving possible to proper classes. Yet the base class should have the location data for above reasons. You don't have to save the location, it can be reproduced for objects that are only in the map.
I hope I get this mess resolved fast, because it's getting on my nerves.
Wednesday, 23 December 2015
Recovering from game object hierarchy change
The main problem in the reduction of base class from location data were all functions that were using location. I'm really glad that there aren't many of those. Mainly the way objects were able to set their map frame by themselves and in other miscellaneous routines such as traps that had built-in routines for triggerers while it should have been the other way round by the design which means the action happens in the triggerer's class and the trap is simply providing data for what happens.
Even the number of routines that need fixing is relatively small it still takes some days maybe to fix them all. Traps are also a special case, because they can be triggered by other moving objects than monsters but there are no routines to handle those other movers. It could be quite nice to give at least some degree of functionality to things like barrels pushed on trap and then the trap is making some stuff happen to the barrel.
The most complex and time consuming routines seem to be interactions between game objects. Traps are the easiest one to handle while digging seems to be extra hard when everything can be interacted with the pick-axe.
Still even with all this hassle I think I made a right decision to reduce the base class and make the inheritance chain contain more classes that handle their particular task. It's going to make things easier in the future when all things are more or less where they should be. And it's also going to reduce both memory consumption and save game size.
Even the number of routines that need fixing is relatively small it still takes some days maybe to fix them all. Traps are also a special case, because they can be triggered by other moving objects than monsters but there are no routines to handle those other movers. It could be quite nice to give at least some degree of functionality to things like barrels pushed on trap and then the trap is making some stuff happen to the barrel.
The most complex and time consuming routines seem to be interactions between game objects. Traps are the easiest one to handle while digging seems to be extra hard when everything can be interacted with the pick-axe.
Still even with all this hassle I think I made a right decision to reduce the base class and make the inheritance chain contain more classes that handle their particular task. It's going to make things easier in the future when all things are more or less where they should be. And it's also going to reduce both memory consumption and save game size.
Friday, 18 December 2015
Refined game object class hierarchy
This is again a bit technical blog entry, but nothing new here. For long I have been cautious to not use inheritance as much as it would have been possible. A complex class hierarchy certainly has its own features to watch out, but now when the level map has become more of a owner of instances it was time to try something new.
The main problem with too simple hierarchy is that the base class may contain data not needed for all game object types. It's an easy way to handle objects, but with cost of having "empty" data for in fact most game object types.
I have learned to avoid big refactorings so I started to move routines from the base class to a new class one by one and then compiling to see what happens. The new class is called U_Mover and as name implicates it handles moving. It's sitting in between the base class and three derived object types: item, movable (objects that can be pushed) and monster(+player). Only these object types move so it's obvious that you don't need specific location data and move commands for other object types.
The surprising thing about this was how base class continues working as if nothing had happened. It's of course quite easy to explain by rigid use of the public interface. The biggest change was in a template routine that used to fetch the object from a list with Is_Here() function. Since it was moved to U_Mover it stopped working for all other object types. But it was about to change anyway, because the tile class will own objects that don't move. Even moving objects have a pointer in the tile class for finding them quickly without having to browse through a list of objects. It's still uncertain which object types should be stored in a list and which ones could be owned by the tile class, but it will be decided later.
Sometimes a list is better or even required, but it doesn't have to own the objects. It can be a quick way to scan through objects without having to visit each map tile of the level.
The main problem with too simple hierarchy is that the base class may contain data not needed for all game object types. It's an easy way to handle objects, but with cost of having "empty" data for in fact most game object types.
I have learned to avoid big refactorings so I started to move routines from the base class to a new class one by one and then compiling to see what happens. The new class is called U_Mover and as name implicates it handles moving. It's sitting in between the base class and three derived object types: item, movable (objects that can be pushed) and monster(+player). Only these object types move so it's obvious that you don't need specific location data and move commands for other object types.
The surprising thing about this was how base class continues working as if nothing had happened. It's of course quite easy to explain by rigid use of the public interface. The biggest change was in a template routine that used to fetch the object from a list with Is_Here() function. Since it was moved to U_Mover it stopped working for all other object types. But it was about to change anyway, because the tile class will own objects that don't move. Even moving objects have a pointer in the tile class for finding them quickly without having to browse through a list of objects. It's still uncertain which object types should be stored in a list and which ones could be owned by the tile class, but it will be decided later.
Sometimes a list is better or even required, but it doesn't have to own the objects. It can be a quick way to scan through objects without having to visit each map tile of the level.
Sunday, 15 November 2015
String class
After 15 days of Brick Atelier development (although not much happened there) I returned to Kaduria by creating a string class. Everyone familiar with C++ knows that you should not write your own string class. Well... it is not exactly that kind of string class. I just needed a class that takes in const text data and then you can do stuff like uppercase the first letter.
It doesn't happen often, but sometimes you need to change something in the text data and for that the data has to be copied and then changed. Sometimes std::string is ok, but it's kind of weird to handle individual chars. For example if you want to uppercase the first letter, you have to remove the first letter and then add uppercased version to front of the string.
I'm of course not planning to replace std::string with K_String class and surely the places where I need K_String are few and limited.
The overall development should change the focus from engine/source code twiddling to making actual stuff happen. This is an old and broad subject - the "engine coding" vs. content creation approach where you first decide to implement some feature and then just make it happen. I think Kaduria has enough building blocks for content creation in a way that really doesn't require any major rewrites in the future. I hope the message system was the last big rewrite.
It doesn't happen often, but sometimes you need to change something in the text data and for that the data has to be copied and then changed. Sometimes std::string is ok, but it's kind of weird to handle individual chars. For example if you want to uppercase the first letter, you have to remove the first letter and then add uppercased version to front of the string.
I'm of course not planning to replace std::string with K_String class and surely the places where I need K_String are few and limited.
The overall development should change the focus from engine/source code twiddling to making actual stuff happen. This is an old and broad subject - the "engine coding" vs. content creation approach where you first decide to implement some feature and then just make it happen. I think Kaduria has enough building blocks for content creation in a way that really doesn't require any major rewrites in the future. I hope the message system was the last big rewrite.
Monday, 2 November 2015
Focus on Brick Atelier
I'm switching the main project to Brick Atelier for at least this first week or two of this month. I've noticed that it's better to focus on one project at a time. And Brick Atelier is quite important, because I can't imagine using any other drawing tool for tiles. It's actually quite surprising how few pixel art programs there are.
Saturday, 24 October 2015
Back to messages
Terrain refactoring is done for now, but some stuff will be changed later. The speed problem was caused by Visual Studio's debug mode. When the .exe is run outside the IDE it's fast. It's still kind of problem in everyday testing and can't be solved easily.
Much bigger problem are messages, because even the number of calls to old message routines are not that many, each rewriting seems to take the time. But you have to be positive, because this time it's done properly. I hope...
Much bigger problem are messages, because even the number of calls to old message routines are not that many, each rewriting seems to take the time. But you have to be positive, because this time it's done properly. I hope...
Tuesday, 20 October 2015
Speed problem of terrain objects
Now the terrain tiles are objects and everything is fine, right? No. The map displaying is somewhat slower from average 5-10ms up to 40ms per step (in small rooms it's under 5ms though). It's not that bad I guess and optimizing gives more speed.
Then I noticed something strange. When I quit the game there is a noticeably long pause. And it becomes worse when you visit more levels. For some reason deleting objects from maps is incredibly slow. I guess it can be, because there are 10 000 tile objects in a 100 x 100 map. Still it's surprisingly slow, taking several seconds with just 4-5 maps. Imagine you visit all levels in the game and wait for 5 minutes for it to delete the objects when you leave the program.
Is delete really that slow or am I doing something wrong? There isn't a big difference in std::vector compared to raw array of pointers (which is easy to test, because the syntax is the same). Raw array seems to be a little bit faster, but not in a way that would make a real difference.
So, what you can do in a situation like this? Should I return to the model where only one level is stored in the memory at a time, loading the level data from files when changing the level? Maybe, if nothing else works. The class hierarchy for game objects is quite heavy, at least now when Tile object of a map could in fact own/contain many of the static object types which don't move. That would remove the "double" pointers for objects, one in the list and other in a form of quick pointer in a Tile. The entire model could be switched from list to a type where Tile owns all objects.
The base class for objects could be also simplified and some functionality moved forward in the inheritance level possibly to intermediate classes (which then would make the class hierarchy more complex and who knows what happens then).
The map itself could contain Tile objects only in the visible areas and empty pointers in solid rock areas of the level.
Or maybe this problem will go away by itself in 10 years when computers become faster.
Then I noticed something strange. When I quit the game there is a noticeably long pause. And it becomes worse when you visit more levels. For some reason deleting objects from maps is incredibly slow. I guess it can be, because there are 10 000 tile objects in a 100 x 100 map. Still it's surprisingly slow, taking several seconds with just 4-5 maps. Imagine you visit all levels in the game and wait for 5 minutes for it to delete the objects when you leave the program.
Is delete really that slow or am I doing something wrong? There isn't a big difference in std::vector compared to raw array of pointers (which is easy to test, because the syntax is the same). Raw array seems to be a little bit faster, but not in a way that would make a real difference.
So, what you can do in a situation like this? Should I return to the model where only one level is stored in the memory at a time, loading the level data from files when changing the level? Maybe, if nothing else works. The class hierarchy for game objects is quite heavy, at least now when Tile object of a map could in fact own/contain many of the static object types which don't move. That would remove the "double" pointers for objects, one in the list and other in a form of quick pointer in a Tile. The entire model could be switched from list to a type where Tile owns all objects.
The base class for objects could be also simplified and some functionality moved forward in the inheritance level possibly to intermediate classes (which then would make the class hierarchy more complex and who knows what happens then).
The map itself could contain Tile objects only in the visible areas and empty pointers in solid rock areas of the level.
Or maybe this problem will go away by itself in 10 years when computers become faster.
Sunday, 18 October 2015
Terrain as object - part 2
The refactoring of terrain from int to a game object is about half done. No big surprises, but the entire structure of Level and map is a bit complicated. I guess it's supposed to be, because it's not a simple thing.
The call hierarchy to the actual terrain object is in most cases Level - Level_Map - Tile - U_Terrain (the last class is the terrain object instance). Not only that, the U_Terrain also includes the static data class for terrain, named K_Terrain_Type. In most cases Tile is using most of static data information so to avoid some wrapper functions I made U_Terrain the friend of Tile in which case getting information from static data looks like this:
bool w=terrain->type.Is_Wall();
It's always a problem in class programming to decide the structure of functions that handle something. In ideal case you can avoid simple getters, but in real life.. well, they do happen once a while. I think it's important not to care too much about "bad" structure, rather than concentrate on making things that work in gameplay level. No one cares how bad the source code is if the game is great. Also, I think in most cases it's a matter of preference where the action happens. If you want to limit the action to a low level class then you have to pass more information in that class. Or the other way is get more information in smaller pieces using getters.
This refactoring has been a lot easier than I thought, mainly because Tile class was already there and the "only" thing to change is simply add terrain object to Tile instead of int type. Of course it's not that simple if you want to make bigger changes in the concept of terrain as just another object type.
There is also a kind of struggle with other game objects. At the moment objects are stored in lists, but they could also be owned by the Tile itself as the terrain object is now. Tile is using only object pointers for easier access to object in that tile, but it could also own the objects, now that terrain is owned by it.
The call hierarchy to the actual terrain object is in most cases Level - Level_Map - Tile - U_Terrain (the last class is the terrain object instance). Not only that, the U_Terrain also includes the static data class for terrain, named K_Terrain_Type. In most cases Tile is using most of static data information so to avoid some wrapper functions I made U_Terrain the friend of Tile in which case getting information from static data looks like this:
bool w=terrain->type.Is_Wall();
It's always a problem in class programming to decide the structure of functions that handle something. In ideal case you can avoid simple getters, but in real life.. well, they do happen once a while. I think it's important not to care too much about "bad" structure, rather than concentrate on making things that work in gameplay level. No one cares how bad the source code is if the game is great. Also, I think in most cases it's a matter of preference where the action happens. If you want to limit the action to a low level class then you have to pass more information in that class. Or the other way is get more information in smaller pieces using getters.
This refactoring has been a lot easier than I thought, mainly because Tile class was already there and the "only" thing to change is simply add terrain object to Tile instead of int type. Of course it's not that simple if you want to make bigger changes in the concept of terrain as just another object type.
There is also a kind of struggle with other game objects. At the moment objects are stored in lists, but they could also be owned by the Tile itself as the terrain object is now. Tile is using only object pointers for easier access to object in that tile, but it could also own the objects, now that terrain is owned by it.
Wednesday, 14 October 2015
Terrain tiles as objects
When refactoring message routines I realized that terrain tiles are not game objects. It makes rather difficult to handle messages since it's clearly designed for object handles. I could have added special cases to message routine to get stuff like direct char pointer to terrain's name.
Changing terrain tiles from a simple int in map data to actual game object is difficult, sure. But it would not only solve this message thing, but many other problems related to terrain. For example when terrain tiles are objects they can have individual data for stuff like damage and so on.
This question of terrain tiles as objects has been kind of "debate" in roguelike development for a long time. They certainly spend more memory than simple tile maps, but in modern computers it's not a problem anymore. And it's about the only downside in them. My advice for developers who are thinking this question is that make them objects. You wont regret it later when more advanced terrain operations are needed.
What this means as a refactoring work is.. well.. I don't actually know the exact answer. The map system is already changed so that there is Tile object for each map tile, where the terrain tile is. Since the Tile is the owner of the terrain it becomes important not to override the existing terrain object, but that's quite easy to do. Most refactoring is spent in replacing the current system where "regular" game objects and the terrain is handled with different routines and style. When terrain becomes a game object it's possible to handle them using same routines as with other objects.
This change has been long overdue, because I knew the problem about the terrain much earlier, but was still reluctant to start the refactoring since it was working for the purpose at the time.
Changing terrain tiles from a simple int in map data to actual game object is difficult, sure. But it would not only solve this message thing, but many other problems related to terrain. For example when terrain tiles are objects they can have individual data for stuff like damage and so on.
This question of terrain tiles as objects has been kind of "debate" in roguelike development for a long time. They certainly spend more memory than simple tile maps, but in modern computers it's not a problem anymore. And it's about the only downside in them. My advice for developers who are thinking this question is that make them objects. You wont regret it later when more advanced terrain operations are needed.
What this means as a refactoring work is.. well.. I don't actually know the exact answer. The map system is already changed so that there is Tile object for each map tile, where the terrain tile is. Since the Tile is the owner of the terrain it becomes important not to override the existing terrain object, but that's quite easy to do. Most refactoring is spent in replacing the current system where "regular" game objects and the terrain is handled with different routines and style. When terrain becomes a game object it's possible to handle them using same routines as with other objects.
This change has been long overdue, because I knew the problem about the terrain much earlier, but was still reluctant to start the refactoring since it was working for the purpose at the time.
Sunday, 11 October 2015
Actor message model
There is a similar kind of refactoring need for messages as in Teemu. I'm still wondering why it took this long to realize how the messages should be handled, but anyway... This time however I'm going to build a new message system on top of the existing one and rewrite everything with small steps. That way I can check if everything is working properly.
The new message system is not just replacing the old, it's more than that. The new style hopefully requires less inheritance in the game object classes and maybe even more dramatic change is moving the "action" closer to data (in data type classes). It's good I think, because then the data and messages (and actions) are more modular than before.
It's lot of work, but has to be done and it means moving on to the next level in this project.
The new message system is not just replacing the old, it's more than that. The new style hopefully requires less inheritance in the game object classes and maybe even more dramatic change is moving the "action" closer to data (in data type classes). It's good I think, because then the data and messages (and actions) are more modular than before.
It's lot of work, but has to be done and it means moving on to the next level in this project.
Wednesday, 7 October 2015
Themes for GUI elements
Windows and menus have now color themes which are versions of graphics replaced by color of that theme. It's such a simple idea, but something I should have done much earlier. The nice thing about it is not only that you can adjust colors to match them better with other graphics etc. but the way things like highlight bars and background erasing is using colors of the theme. When it's automatic you don't have to set up those colors somewhere else, just to notice when you change the color of window you have to change those colors as well.
Font colors are not defined in the theme (at least not yet) except for title fonts which now also have theme colors. Usually the text is simply displayed over the window graphics, it's not a part of the window, but in menus the text is in a list of items and in that color could be used for text as well. I'm probably not going to create a rigid theme based font colors, because it's easy enough to do that manually and also you are not limited to color set of the theme which may be a good thing sometimes.
Lately I've been working quite long days which is quite different than it used to be. I don't know what happened to me, but now I have to limit the amount of time for programming, because it may be too much, at least in the long run.
Font colors are not defined in the theme (at least not yet) except for title fonts which now also have theme colors. Usually the text is simply displayed over the window graphics, it's not a part of the window, but in menus the text is in a list of items and in that color could be used for text as well. I'm probably not going to create a rigid theme based font colors, because it's easy enough to do that manually and also you are not limited to color set of the theme which may be a good thing sometimes.
Lately I've been working quite long days which is quite different than it used to be. I don't know what happened to me, but now I have to limit the amount of time for programming, because it may be too much, at least in the long run.
Sunday, 4 October 2015
Procedural GUI graphics
I'm planning to create some kind of "procedural" system for GUI graphics which in Kaduria's case are mainly window and gameview graphics. There isn't many graphical elements which is fine, because I try to change them to procedural versions rather than loading them from image data.
There are two ways to do this, easy and hard. In easy version you have some kind of graphical template which has colors you then replace with the actual color palette. In hard version you create the graphics by programming it.
It's possible to use both styles and that's something I'm probably going to do. For windows it could be easy to use the existing glyph data as a template and only create new versions for each color. If there were different kind of fonts then it would be better to create windows graphics that can scale to the font size, but in Kaduria the font is (hopefully) going to stay the same size to the release.
The procedural part in this case is mainly color. It's then easy to adjust colors to create better looking graphics, because color is important especially in GUI. Later it can be also possible to create different kind of color themes and even give the players an option to change colors as they wish.
I think my main goal for this month could be the GUI, because some things are still unfinished and when you have the GUI ready it's one less thing to worry about.
There are two ways to do this, easy and hard. In easy version you have some kind of graphical template which has colors you then replace with the actual color palette. In hard version you create the graphics by programming it.
It's possible to use both styles and that's something I'm probably going to do. For windows it could be easy to use the existing glyph data as a template and only create new versions for each color. If there were different kind of fonts then it would be better to create windows graphics that can scale to the font size, but in Kaduria the font is (hopefully) going to stay the same size to the release.
The procedural part in this case is mainly color. It's then easy to adjust colors to create better looking graphics, because color is important especially in GUI. Later it can be also possible to create different kind of color themes and even give the players an option to change colors as they wish.
I think my main goal for this month could be the GUI, because some things are still unfinished and when you have the GUI ready it's one less thing to worry about.
Sunday, 6 September 2015
New Message
Yesterday I realized what to do with the Message class and messages. Previously I had passed AI id for messages, but replaced that with game object handle. That way the game object always triggers the message and selects the proper message pool with different versions of messages. Also, all visibility and other checks are in the Message class, so there is no need to check for example if the player is blind in other routines. Later messages can become more detailed depending on how far the action happens etc. but it requires more message pools.
For message pools I wrote a new class, not surprisingly named Message_Pool. It's another good example why you need to handle raw style data in a dedicated class rather than directly, because with class you can input as many similar sources as possible and then select them without using ifs or switch-case structures.
There were problems of course. I already knew I had to solve the passing of nouns and verbs to Message, because it was done for each actor first, before displaying the message. It works, but makes the game of course slower. To fix that I'm replacing direct calls with new functions that take the message id and the noun or whatever as parameters, then first check if the message itself exists and other visibility issues before copying and displaying the message. There is certainly some work to do before everything is fixed, but I had a good start in that.
The main message pool needs a clean up and the message data arranged better. It doesn't matter in what order the messages are so that's why "magic" id numbers for messages work here, they are not replaced etc.
It's not yet perfect and I'm anticipating some problems later. One of them is how individual npc names are displayed. The message data can have something like "The # hits you." but if the npc is someone you know then "The" has to be removed. It may be something simple like using another pool for "known" npcs with message data changed to "# hits you." The pool can be selected in the Message class using any kind of rule or condition, that's the nice thing about it.
For message pools I wrote a new class, not surprisingly named Message_Pool. It's another good example why you need to handle raw style data in a dedicated class rather than directly, because with class you can input as many similar sources as possible and then select them without using ifs or switch-case structures.
There were problems of course. I already knew I had to solve the passing of nouns and verbs to Message, because it was done for each actor first, before displaying the message. It works, but makes the game of course slower. To fix that I'm replacing direct calls with new functions that take the message id and the noun or whatever as parameters, then first check if the message itself exists and other visibility issues before copying and displaying the message. There is certainly some work to do before everything is fixed, but I had a good start in that.
The main message pool needs a clean up and the message data arranged better. It doesn't matter in what order the messages are so that's why "magic" id numbers for messages work here, they are not replaced etc.
It's not yet perfect and I'm anticipating some problems later. One of them is how individual npc names are displayed. The message data can have something like "The # hits you." but if the npc is someone you know then "The" has to be removed. It may be something simple like using another pool for "known" npcs with message data changed to "# hits you." The pool can be selected in the Message class using any kind of rule or condition, that's the nice thing about it.
Saturday, 5 September 2015
Messages
The message system of Kaduria is using a ID for each message that points to proper message buffer with versions for situations like blindness and also for other than player's messages. The message can be something like "%100The # is burnt out." where # is replaced by noun, in this case "torch" for example. This kind of system is quite nice, because it removes checks for blindess etc. in the routines that are calling messages.
It's not difficult to track messages IDs even it feels like a dumb idea to call Message(100); to display that message. The real problem with this approach is that the message list becomes large and more importantly the message data is detached from the "data type" classes. In this example I have I_Light_Item class just for items that emit light, like torches, lamps etc. This class has information about light items such as can it be re-filled with lamp oil. But it would be really useful to have also message data included in the class.
The problem at least for now is that message routines become "dumb", they need external data to determine if the message was triggered by the player and also information about blindness etc. This could be solved by some kind of generic routine that handles raw data, possibly even similar type of data to what the main message routine has.
Whatever the solution is I find messages one of the annoying parts of roguelike programming, as if there weren't plenty of them already.
It's not difficult to track messages IDs even it feels like a dumb idea to call Message(100); to display that message. The real problem with this approach is that the message list becomes large and more importantly the message data is detached from the "data type" classes. In this example I have I_Light_Item class just for items that emit light, like torches, lamps etc. This class has information about light items such as can it be re-filled with lamp oil. But it would be really useful to have also message data included in the class.
The problem at least for now is that message routines become "dumb", they need external data to determine if the message was triggered by the player and also information about blindness etc. This could be solved by some kind of generic routine that handles raw data, possibly even similar type of data to what the main message routine has.
Whatever the solution is I find messages one of the annoying parts of roguelike programming, as if there weren't plenty of them already.
Friday, 21 August 2015
Identification
After I tried to write an ascii gui or engine (called "Knights") I started to have more motivation for Kaduria again. At least it seems to work for me. I realized that even Kaduria's source code is quite messy, it still has lot of stuff ready or almost ready while programming Knights I got a feeling that "here we go again..."
Item identification is one of features not yet present, because the current implementation of frame displaying (frame is static data) makes it difficult to do, yet not impossible. The main problem is the decision to use identification in first place. It's not mandatory in a roguelike game, but at least for some item groups it could be nice.
And by nice I mean annoying. I think magic items could benefit from identification, because then they would include an extra risk when using them, before they have been identified. There absolutely will not be cursed items in Kaduria and weapons will probably not have any magical properties. That way there would be a clear distinction between regular and magic objects.
Item identification is one of features not yet present, because the current implementation of frame displaying (frame is static data) makes it difficult to do, yet not impossible. The main problem is the decision to use identification in first place. It's not mandatory in a roguelike game, but at least for some item groups it could be nice.
And by nice I mean annoying. I think magic items could benefit from identification, because then they would include an extra risk when using them, before they have been identified. There absolutely will not be cursed items in Kaduria and weapons will probably not have any magical properties. That way there would be a clear distinction between regular and magic objects.
Thursday, 23 July 2015
Evolution of diggers
In still unfinished Teemu 1.3 I was experimenting with so called 'diggers' which are corridor creating "robots" that can create clones of themselves which simply are the branching corridors of a labyrinth. I realized that diggers can be evolved to do much more than just labyrinths if you create a set of rules for them.
Currently I need diggers to create corridor systems for a 'catacomb' theme. They can be as simple as a straight corridor with branching corridors to both sides of the main corridor. This can be expressed in rules of having zero curvature, more than one branching rate and 100 percent double clone probability.
If you want regular labyrinths it's simple to give more curvature for both original digger and clones. The amount of curvature and changes in other data can be used to create different kind of labyrinth styles and I like the idea of just having extra corridor systems with more or less curvature. Those can be created to otherwise unoccupied areas of the level after the main structure creation has been done.
While this is all exciting I've had trouble implementing the new digger system, because there is a strange bug with searching of so called tile masks. When searching an entry point for diggers one way to do it is find mask values of tiles. So I can for example find water areas and start diggers from there. But for some reason the routine doesn't find room walls, even they do exist and I can even confirm the proper mask values are there by looking at the automap in debug mode.
So I guess I'll spend this day searching for that bug.
ps. Well, that was quick. The bug happened, because 'small rooms' were created after the level theme creation in where I was calling the digger routine, so those rooms weren't even there at the moment the digger routine was called. That also seems to be true for some other routines, because I get some debug error messages of the search routine trying to look for parts of rooms.
Currently I need diggers to create corridor systems for a 'catacomb' theme. They can be as simple as a straight corridor with branching corridors to both sides of the main corridor. This can be expressed in rules of having zero curvature, more than one branching rate and 100 percent double clone probability.
If you want regular labyrinths it's simple to give more curvature for both original digger and clones. The amount of curvature and changes in other data can be used to create different kind of labyrinth styles and I like the idea of just having extra corridor systems with more or less curvature. Those can be created to otherwise unoccupied areas of the level after the main structure creation has been done.
While this is all exciting I've had trouble implementing the new digger system, because there is a strange bug with searching of so called tile masks. When searching an entry point for diggers one way to do it is find mask values of tiles. So I can for example find water areas and start diggers from there. But for some reason the routine doesn't find room walls, even they do exist and I can even confirm the proper mask values are there by looking at the automap in debug mode.
So I guess I'll spend this day searching for that bug.
ps. Well, that was quick. The bug happened, because 'small rooms' were created after the level theme creation in where I was calling the digger routine, so those rooms weren't even there at the moment the digger routine was called. That also seems to be true for some other routines, because I get some debug error messages of the search routine trying to look for parts of rooms.
Saturday, 4 July 2015
Realistic gameplay and torches
The current equipment has a slot for light sources. It's kind of "third" hand to hold the torch or whatever. You still have left and right hand slots where you can equip weapons and shields.
However if you want to be realistic you should have only two hands to hold things. But is it worth it? If you need one hand for the light source you would not be able to hold a shield when fighting in poor lighted places, not to mention two-handed weapons. You could always drop the light source on ground (in Kaduria it's possible, the item will still work as a light source) before fighting, but it would be quite annoying I guess.
The way to make it less annoying would be lot of lights around the dungeon in most places. This is actually what I'm planning to do anyway and it could be a nice way to reduce the need for a personal light source. But then again, dungeon wall torches are the great role-playing example of unrealistic light sources, because they never go out. If they did, they would be always burnt out, unless there is an army of goblins replacing them all the time.
I like the idea of "more" realistic gameplay, but you have to be really careful or it will create some tedious tasks for the player who start to hate it after a while. I know I would.
However if you want to be realistic you should have only two hands to hold things. But is it worth it? If you need one hand for the light source you would not be able to hold a shield when fighting in poor lighted places, not to mention two-handed weapons. You could always drop the light source on ground (in Kaduria it's possible, the item will still work as a light source) before fighting, but it would be quite annoying I guess.
The way to make it less annoying would be lot of lights around the dungeon in most places. This is actually what I'm planning to do anyway and it could be a nice way to reduce the need for a personal light source. But then again, dungeon wall torches are the great role-playing example of unrealistic light sources, because they never go out. If they did, they would be always burnt out, unless there is an army of goblins replacing them all the time.
I like the idea of "more" realistic gameplay, but you have to be really careful or it will create some tedious tasks for the player who start to hate it after a while. I know I would.
Friday, 26 June 2015
Refactoring - that was it
I had to refactor the Spawner class. It's creating lists of items (or any object types) for later creation, because you need somehow determine which items are created in various places. The hard work is done in the initialization where lists are created, by going through object data for each object type.
The way I programmed Spawner class was somewhat dumb, because I used raw std::vectors to hold items. Nothing wrong with that, but it makes internal bookkeeping impossible, since there is no way to know what are actually stored in those lists.
Refactoring was quite simple. I made a Spawner_Item class which holds that std::vector with the name of the list. For some reason I thought it was a good idea to create a function for each item type, such as Spawner::Get_Land_Trap() which then returned a trap that can be created on dungeon floor. The problem is that after a while the number of functions increase. So in the refactored version there is one function to get a random item from a pool, in this case Get_Random_Item(spaw::Land_Traps) where spaw is the namespace for spawning applications.
There are quite lot of functions to replace with new implementation, but I was able to rewrite the new one on top of the old one so they are working at the same time. It's what you always hope that happens when you have to refactor something, that way you can still run the game without problems and slowly replace the old implementation.
The bookkeeping feature was useful right away when I noticed there were no traps for containers. They didn't exist so the spawner list was empty for them. Later it's also possible to write a debug function to watch the list of items, not just the amount of items per list and you can check out if somehow the list contains something it should not have.
Now, as I said something has changed in the development and I think it may be refactoring (or rewriting, it's the same thing). When I was rewriting Spawner class I had a funny feeling it was something I had been doing all these years and only recently I've been programming new stuff as well.
The way I programmed Spawner class was somewhat dumb, because I used raw std::vectors to hold items. Nothing wrong with that, but it makes internal bookkeeping impossible, since there is no way to know what are actually stored in those lists.
Refactoring was quite simple. I made a Spawner_Item class which holds that std::vector with the name of the list. For some reason I thought it was a good idea to create a function for each item type, such as Spawner::Get_Land_Trap() which then returned a trap that can be created on dungeon floor. The problem is that after a while the number of functions increase. So in the refactored version there is one function to get a random item from a pool, in this case Get_Random_Item(spaw::Land_Traps) where spaw is the namespace for spawning applications.
There are quite lot of functions to replace with new implementation, but I was able to rewrite the new one on top of the old one so they are working at the same time. It's what you always hope that happens when you have to refactor something, that way you can still run the game without problems and slowly replace the old implementation.
The bookkeeping feature was useful right away when I noticed there were no traps for containers. They didn't exist so the spawner list was empty for them. Later it's also possible to write a debug function to watch the list of items, not just the amount of items per list and you can check out if somehow the list contains something it should not have.
Now, as I said something has changed in the development and I think it may be refactoring (or rewriting, it's the same thing). When I was rewriting Spawner class I had a funny feeling it was something I had been doing all these years and only recently I've been programming new stuff as well.
Sunday, 21 June 2015
New style
Back a while I was talking about how non-monospace fonts are really cool for editor fonts, but I've since then moved back to monospace. I have also moved the output window to left side of the screen and class browser to right side. That way there is no window at the bottom and the code window can be as tall as possible with more lines of code. I guess power users would use two monitors, but I've never felt it was the solution for me and also I don't even have space for that in my small desk. First world problems!
Then I changed colors to dark background theme with dark grey background and some colors for different stuff like keywords, strings, etc. I've used light (white) background theme for a long time. Somehow I feel the new style is doing something, if nothing else it's just good to see something different when you spend days, months and years programming.
ps. While watching more closely that function I realized it doesn't need that Coords parameter and it's also shadowed in the routine. It's already fixed so I don't need to be embarrassed about it.
Then I changed colors to dark background theme with dark grey background and some colors for different stuff like keywords, strings, etc. I've used light (white) background theme for a long time. Somehow I feel the new style is doing something, if nothing else it's just good to see something different when you spend days, months and years programming.
ps. While watching more closely that function I realized it doesn't need that Coords parameter and it's also shadowed in the routine. It's already fixed so I don't need to be embarrassed about it.
Tuesday, 16 June 2015
The Mountain of Doom
I have a clever and original analogy for creating a roguelike which is climbing a mountain, or maybe more like building a mountain. When you start the project there is lot of stuff to create at the base of the mountain and it's quite easy to add that stuff, but as you climb higher it becomes harder even the amount of features you still need are few. What makes the mountain steeper near the top is the realization that you need more details for some things than you expected when you started the project.
I want to convince myself that I'm now climbing at the steep part of the mountain, because I can feel a change in the way I'm programming the project. Each feature I'm able to remove from the todo list feels like one step closer to the top. But as I said the mountain is becoming steeper when I think of new ways to add more complexity to the gameplay. The top of the mountain is covered in clouds so it's impossible to see it from where I am now.
I want to convince myself that I'm now climbing at the steep part of the mountain, because I can feel a change in the way I'm programming the project. Each feature I'm able to remove from the todo list feels like one step closer to the top. But as I said the mountain is becoming steeper when I think of new ways to add more complexity to the gameplay. The top of the mountain is covered in clouds so it's impossible to see it from where I am now.
Wednesday, 20 May 2015
Level map save
As usual the save/load routine has involved more work than I thought. I've reduced it to the hardest part which is saving the level map. The old map with individual 'byte' maps for each layer was easy to save, because the byte map had a built in RLE (run-length encoding) packing. The estimation for 50 levels each average size of 100x100 tiles is 3,5Mb of space unpacked. How much is it compared to modern save files I don't know (I don't play PC games (other than roguelikes)), but it would be much less when compressed.
As expected the compression routine must be custom created to be compatible for both the save file format and map format which contains four mandatory variables to be saved: the tile itself (terrain), fov value (known tiles), mask and room id. These four variables can't be reproduced from any other data. The mask value is mostly used in the level's creation process, but it might just be used during the game in pathfinding situations.
RLE in theory is easy to implement, but the custom data structure and save format makes it somewhat more complicated. RLE also works quite nicely with typical dungeon levels of rooms and other areas with mostly 'empty' space (walls) between them.
As expected the compression routine must be custom created to be compatible for both the save file format and map format which contains four mandatory variables to be saved: the tile itself (terrain), fov value (known tiles), mask and room id. These four variables can't be reproduced from any other data. The mask value is mostly used in the level's creation process, but it might just be used during the game in pathfinding situations.
RLE in theory is easy to implement, but the custom data structure and save format makes it somewhat more complicated. RLE also works quite nicely with typical dungeon levels of rooms and other areas with mostly 'empty' space (walls) between them.
Tuesday, 12 May 2015
Double dragon
I've divided todo items to RPG and "engine" lists. The list for engine items is interestingly short and I'm working on it. Currently I'm writing a new save and load game which is bit of a complex thing, yet easy compared to the beast of RPG system.
When you add or remove something from a class that has to be saved you should add it to save/load routines. Guess who didn't do that? Well I think it's good to go through everything anyway to make sure absolutely everything is saved. Of course there are still some difficult parts, in particular the new level map class that replaced the old implementation.
A minor refactoring is going on with the level map vs. level, because I noticed the Level class has a double data of width and height which also the Level_Map has. Now.. I know, this doesn't sound like a big issue, but for me it is. I have always tried to remove double data as soon as I notice it exists. It's just something I hate even often it doesn't make the source code that much worse. Still it's always risky if there are doubles of some data, because you need to synchronize it.
When I get save/load ready it's an important step, because I can then start to test it in a way where the current situation is always loaded when I'm running the game. In the debug mode it's impossible to die so it makes long term testing of save/load possible.
When you add or remove something from a class that has to be saved you should add it to save/load routines. Guess who didn't do that? Well I think it's good to go through everything anyway to make sure absolutely everything is saved. Of course there are still some difficult parts, in particular the new level map class that replaced the old implementation.
A minor refactoring is going on with the level map vs. level, because I noticed the Level class has a double data of width and height which also the Level_Map has. Now.. I know, this doesn't sound like a big issue, but for me it is. I have always tried to remove double data as soon as I notice it exists. It's just something I hate even often it doesn't make the source code that much worse. Still it's always risky if there are doubles of some data, because you need to synchronize it.
When I get save/load ready it's an important step, because I can then start to test it in a way where the current situation is always loaded when I'm running the game. In the debug mode it's impossible to die so it makes long term testing of save/load possible.
Tuesday, 28 April 2015
Engine programming
Another three weeks off, but now back in the saddle. I have now a better idea how to proceed thanks to the master todo list I did earlier. First I have to finish some parts of the engine, which at the moment is the new save/load game scheme with the idea of keeping everything in memory rather than saving temp level files. I actually don't know how much the game will spend memory once every level is constructed, but I guess it can be monitored with a crude debug routine telling how much one level requires memory.
I'm also changing the "old school" way of loading game when you enter the character name and replace that with slots for save games. There is a limit for slots, but I doubt people will run out of slots, because usually there are only few open games.
The new save and load is actually going to be quite easy to do, because the "level node" structure is already stored in the world class. It may be as easy as adding a level handle to each node and when that node is entered the level is created. Each class can more or less save and load itself so that wont be a problem.
I'm also changing the "old school" way of loading game when you enter the character name and replace that with slots for save games. There is a limit for slots, but I doubt people will run out of slots, because usually there are only few open games.
The new save and load is actually going to be quite easy to do, because the "level node" structure is already stored in the world class. It may be as easy as adding a level handle to each node and when that node is entered the level is created. Each class can more or less save and load itself so that wont be a problem.
Tuesday, 7 April 2015
Graves & Tombs
Let's make this clear. Grave is a game object that contains buried grave items. It's either mound type or a tomb. Sign class can be a sign, but it can also contain a Grave_Stone class which has extra information about the grave in a form of cross or tombstone and it's a separate object created next to grave. When Sign class is a plain sign, it has a Scroll class data. And finally Item class can have a Scroll component if the item is a readable one.
Now the only (hopefully) thing left is how to determine the grave type. I think it could be easier to do by using monster type as the main data and determine grave and gravestone styles from that information. Then you can create graves using monster type as a parameter and everything else will be determined from that. Only that there may be problems with so called ancient graves where the monster type can be something strange, but maybe that monster type could be actually created as a monster never seen in the gameplay.
It's possible to go detailed about graves and what items there are buried, but I try to avoid that in the first version and try to keep things simple.
Now the only (hopefully) thing left is how to determine the grave type. I think it could be easier to do by using monster type as the main data and determine grave and gravestone styles from that information. Then you can create graves using monster type as a parameter and everything else will be determined from that. Only that there may be problems with so called ancient graves where the monster type can be something strange, but maybe that monster type could be actually created as a monster never seen in the gameplay.
It's possible to go detailed about graves and what items there are buried, but I try to avoid that in the first version and try to keep things simple.
Saturday, 4 April 2015
Scroll in the grave
Grave texts were earlier in a Scroll class. It's not that confusing, because texts of scrolls and graves work pretty much the same way, they only have a different kind of graphics background. What I wanted to do is get rid of extra data for graves in the Scroll class, since scrolls only have relatively simple text in them.
When I was refactoring I realized it would be useful to have a basic class for handling text pieces needed in scrolls, graves etc. with several display options and parsing routines depending on the data.
I guess it was the only good thing that followed this refactoring, because in the end I realized that I had only shifted the problem of gravestones from Scroll to Sign class. Signs on the other hand have also simple text data as scrolls, but they also include graves. Of course, I could create a new class for gravestones only, but adding a new game object type is anything else than trivial. The game object system is quite unwieldy and requires another set of features in Level class. I doubt it will be worth the trouble.
The solution is include gravestone data as an extra member of Sign class, just as it was in Scroll class. I guess it's anyway better than gravestones being 'scrolls' as they were before. Signs and gravestones are similar enough that they can share the same game object type, but it's a bit annoying to have that extra member which is 'empty' when the sign is not a gravestone type. I don't want to think about a tomb which is a Grave object type, but also a Sign, or rather gravestone. Or is it just a grave?
When I was refactoring I realized it would be useful to have a basic class for handling text pieces needed in scrolls, graves etc. with several display options and parsing routines depending on the data.
I guess it was the only good thing that followed this refactoring, because in the end I realized that I had only shifted the problem of gravestones from Scroll to Sign class. Signs on the other hand have also simple text data as scrolls, but they also include graves. Of course, I could create a new class for gravestones only, but adding a new game object type is anything else than trivial. The game object system is quite unwieldy and requires another set of features in Level class. I doubt it will be worth the trouble.
The solution is include gravestone data as an extra member of Sign class, just as it was in Scroll class. I guess it's anyway better than gravestones being 'scrolls' as they were before. Signs and gravestones are similar enough that they can share the same game object type, but it's a bit annoying to have that extra member which is 'empty' when the sign is not a gravestone type. I don't want to think about a tomb which is a Grave object type, but also a Sign, or rather gravestone. Or is it just a grave?
Thursday, 2 April 2015
The curious case of a feature
I've fixed couple of features and it's as awful as I assumed.
Yesterday I was able to partially rewrite a new lighting routine for
static lights (that don't move). The light falloff is linear which can
be fixed later, but the main routine for lights is ok I guess.
Sometimes fixing a feature will introduce new features to fix which in this case is a peculiar problem related to facing of walls. The lighting routine can lit the wall from the "wrong" direction (depending on where the player is), making it lit without visible evidence of a light source. This is somewhat common problem in tile-based games with more sophisticated lighting scheme and I have to find some kind of solution for it.
The plan is to stay with technical features and when they are done everything that is left is the RPG system.
Sometimes fixing a feature will introduce new features to fix which in this case is a peculiar problem related to facing of walls. The lighting routine can lit the wall from the "wrong" direction (depending on where the player is), making it lit without visible evidence of a light source. This is somewhat common problem in tile-based games with more sophisticated lighting scheme and I have to find some kind of solution for it.
The plan is to stay with technical features and when they are done everything that is left is the RPG system.
Monday, 30 March 2015
Project management goal reached
Source code comments with "note:" or "todo:" are now in a text file list of todo features. They are listed per class. Someone might ask what is the difference? I think it helps focusing on fixing features in certain order and it also gives some kind of idea of how much work there is.
The list has around 100 features which needs to be fixed. Some features are stuff like moving source code from other parts of the project to a specific data type class. Harder features are those which contain lots of data or they are part of the RPG system. If you think you can fix a feature per day it may give a good idea about how much time you need, but it's highly theoretic, because some features will take more than one day to fix.
In reality it's worse than that, because these features cover only some of the game content which is still a big unknown. Not only that, but I still have to do a complete check through source files to find all unfinished features. These ones were marked so I could find them easily.
It's possible to crunch away a number of features at a time, but it may become hard to maintain your mental stability. Yet I hope it's going to be lot faster than one feature per day, because fixing these features is surely going to be an important step closer to alpha demo v0.001.
The list has around 100 features which needs to be fixed. Some features are stuff like moving source code from other parts of the project to a specific data type class. Harder features are those which contain lots of data or they are part of the RPG system. If you think you can fix a feature per day it may give a good idea about how much time you need, but it's highly theoretic, because some features will take more than one day to fix.
In reality it's worse than that, because these features cover only some of the game content which is still a big unknown. Not only that, but I still have to do a complete check through source files to find all unfinished features. These ones were marked so I could find them easily.
It's possible to crunch away a number of features at a time, but it may become hard to maintain your mental stability. Yet I hope it's going to be lot faster than one feature per day, because fixing these features is surely going to be an important step closer to alpha demo v0.001.
Wednesday, 25 March 2015
Cowshed
I've been working quite seriously on problems of Kaduria, or features as some may call them. The main focus at the moment is in the dungeon generation which is in pretty good shape, but requires extra things for special level themes, some room types etc.
Cowshed (or is it cowhouse?) is one of those special room types constructed using small repeating building blocks. I think they are going to be blueprints which is a building block type of class I first designed for Teemu. Blueprints are simply static pieces of dungeon features rather than dynamic shapes like room walls. Using small shapes of various type you can actually get quite nice results that look deceivingly random.
I've started to use namespaces rather than notations for enums. The namespace for cowshed (and stables) subtypes is called 'navetta'. I think it serves two purposes to name namespaces like that, first it's surely annoying if anyone other than finnish speaking person ever sees the source code of Kaduria, and as secondary point it's also quite useful as that way namespace names don't easily get mixed to anything else.
Working on dungeon generation is kind of nice. It's the easiest part of the project I think, because it's a "linear" problem compared to other features of a roguelike game.
Cowshed (or is it cowhouse?) is one of those special room types constructed using small repeating building blocks. I think they are going to be blueprints which is a building block type of class I first designed for Teemu. Blueprints are simply static pieces of dungeon features rather than dynamic shapes like room walls. Using small shapes of various type you can actually get quite nice results that look deceivingly random.
I've started to use namespaces rather than notations for enums. The namespace for cowshed (and stables) subtypes is called 'navetta'. I think it serves two purposes to name namespaces like that, first it's surely annoying if anyone other than finnish speaking person ever sees the source code of Kaduria, and as secondary point it's also quite useful as that way namespace names don't easily get mixed to anything else.
Working on dungeon generation is kind of nice. It's the easiest part of the project I think, because it's a "linear" problem compared to other features of a roguelike game.
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)