Menu class itself was surprisingly easy to change from raw text data to std::list. Item menu was rewritten earlier so I skipped checking it and moved on to refactor "regular" menus with simple text as items. It took a day to change all menus, because the constructor parameters changed and now you didn't pass a text buffer to menu but items one by one as const char data.
The data for menu items was available in data structures of most data-driven stuff so it made the source code better, because all those temporary text buffers were removed. The game doesn't actually have a lot of menus and most of them were mainly in debug routines.
I had a good feeling when I programmed today and hope it continues. I also think the best way for me to manage this project is to make a focused plan of something and then try to concentrate on it hard. It gives good results fast when I know what to do.
Sunday, 27 October 2013
Thursday, 10 October 2013
Refactoring Window class
As a part of quite important menu refactoring Windows class had to be refactored. There were two classes, with regular and small fonts. They were merged into one. The resulted class was easy to refactor per se, but several windows initializations had to be refactored.
It's done, but something went wrong (as usual):
The window displaying help of option went bananas. I'm sure it's quite easy to fix.
The important refactoring is in the Menu class. It's going to be harder than this, but it has to be done. You would think there can't be anything left to refactor in a project like this, but you are wrong. The current Menu class is using simple text data with hard-set amount of items and a pointer to char* buffer. It's bad in several ways. What I need is ability to display each line of text in different colors (sometimes) and to do that you need a list of objects with text data and font color.
Fortunately I already have it, the Display_Message class that Message is now using to show a message. It's not designed for this, but later it can be replaced with any other class of same type.
Sometimes the menu list is changed, for example if you drop an item from inventory and that also is improved with list where only the selected item can be removed. With static char* buffer you need a complete re-build when the list is changed.
Later it could be also possible to create direct item menus (simply a list of items) without using a text based copy.
Let's hope I get it right this time...
It's done, but something went wrong (as usual):
The window displaying help of option went bananas. I'm sure it's quite easy to fix.
The important refactoring is in the Menu class. It's going to be harder than this, but it has to be done. You would think there can't be anything left to refactor in a project like this, but you are wrong. The current Menu class is using simple text data with hard-set amount of items and a pointer to char* buffer. It's bad in several ways. What I need is ability to display each line of text in different colors (sometimes) and to do that you need a list of objects with text data and font color.
Fortunately I already have it, the Display_Message class that Message is now using to show a message. It's not designed for this, but later it can be replaced with any other class of same type.
Sometimes the menu list is changed, for example if you drop an item from inventory and that also is improved with list where only the selected item can be removed. With static char* buffer you need a complete re-build when the list is changed.
Later it could be also possible to create direct item menus (simply a list of items) without using a text based copy.
Let's hope I get it right this time...
Saturday, 5 October 2013
That pesky content - part 2
There has been a subtle but important change from engine programming to content creation in this project. A common misconception is that roguelikes don't require that much content, because they are random(ly generated). It's not that simple. Sometimes they do require a lot of content and randomness is only an extra layer on top of it.
An example is creating equipment for creatures. Today I started with helmets or headgear. For them the race and profession both determine the type of headgear. It's mostly the profession. Fighters and knights could wear a metal helmet, but wizards should wear a pointy hat. But if you always have the same decisions the gameplay becomes dull and predictable. There should be some kind of random variation, but in some kind of context. A knight could be wearing a crude helmet if he has lost his metal helmet and a wizard could be wearing a studded leather helmet. Helmets itself could have an importance value what comes to the decision how often they are created, because they were in reality the most important piece of armour.
The details of decisions can be complex and decisions or their "engine" itself are hand-picked content. More intelligent races and professions means more decisions. I already regret I made goblins an intelligent race like dwarves. Maybe they are removed or the amount of professions reduced.
An example is creating equipment for creatures. Today I started with helmets or headgear. For them the race and profession both determine the type of headgear. It's mostly the profession. Fighters and knights could wear a metal helmet, but wizards should wear a pointy hat. But if you always have the same decisions the gameplay becomes dull and predictable. There should be some kind of random variation, but in some kind of context. A knight could be wearing a crude helmet if he has lost his metal helmet and a wizard could be wearing a studded leather helmet. Helmets itself could have an importance value what comes to the decision how often they are created, because they were in reality the most important piece of armour.
The details of decisions can be complex and decisions or their "engine" itself are hand-picked content. More intelligent races and professions means more decisions. I already regret I made goblins an intelligent race like dwarves. Maybe they are removed or the amount of professions reduced.
Subscribe to:
Posts (Atom)