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.
Friday, 26 June 2015
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.
Subscribe to:
Posts (Atom)