Banana Rogue

[Krice]

Cleaning up the 'object' struct which is item game object is quite tedious. The way items are created is a mess, because the data in 'object' is set in many places and many ways. Some variables in 'object' are problematic, like o_ac which is used in more ways than just the ac of the item. The o_group variable is a mystery, it seems to be given to item stacks, but I'm not sure why. Then there is o_launch which stores the item that is used to shoot that item. For example if the item is arrow then o_launch will be a bow. But there are only three items you can shoot with and for the rest of items o_launch is useless. It would be much easier to write a member function to determine which item you need to shoot those three projectiles. Which I did, but didn't yet remove o_launch. The way this game is using data is primitive, because you don't really need to store that kind of data in the item class, you could use the static data for items to determine that kind of stuff.

 

[Krice]

I have a new kind of strategy for all of my projects actually. There are list of problems (in the source code as note: ... comments) and I try to fix them in order, no matter what the problem is. In this project however problems are connected to output routines so I'm first trying to remove "easier" problems and trying to figure out how to fix the output stuff. It's not that difficult, but it's tedious for sure, because the chaotic C style source code. This project is the easiest, the game is more or less working, only output routines don't work as they should.

 

[Krice]

The problem with the gameview refactoring is that I have no idea what I'm doing. Well, at least not for now. When the refactoring is done you just have to check out everything that had something to do with the gameview, because in some cases the routines are checking for monsters in that location and in some cases only terrain etc. I try to give member functions of Gameview class clear names to check out later what they are supposed to do. In any case, decoupling parts of the gameview and level is much better than how it works now.

 

[Krice]

The tile class has now another "layer" for hidden objects which are doors and traps. This was actually the last missing piece of the gameview logic, but there are still stuff to fix, mainly checks for isalpha() which is the old way to determine if something on the screen is a monster. Monsters also restored some data under them in the old engine, but it's not needed in the new version where everything is in their dedicated "layers" of data, so there is no overlapping. I was able to focus on this for about 2,5 hours today and lots of stuff was fixed. Decoupling and abstracting the gameview will be quite nice, because you can then do stuff like add colors and replace layer data with something else than ascii, freeing some ascii characters for other use.

 

[Krice]

Display routines that has to do with the gameview (level, moving monsters and items etc.) has to be rewritten, but the good news is that there isn't that many places where monsters are moved etc. Level generation is a bit different story, but probably doable. I'm removing all window layers which completely breaks the old curses implementation, but the gui is going to be decoupled so it is possible in theory to re-rewrite it to curses later. Then again, with the new gameview you probably don't even need layers in curses, just a simple drawing routine for everything, because the gameview has nothing to do with the way it's displayed. Even this project doesn't work properly at the moment, at least it compiles and runs, it's always a nice thing to have.

 

[Krice]

Funny thing about curses is that it's actually really easy to compile even on Windows, which I did for Saladir. But now that I have changed so much of the code in this one I can't go back, or it would be quite difficult, I would have to check out so many things from the original source code... not going to happen. Anyway, rather than fixing display stuff I began to rewrite the player's data into a player class (which didn't exist before), because I can't watch player data as global variables and be happy about it. I think it also gives me a good insight about player's data, how it's used in the gameplay. Some data doesn't even belong to the player, like there was char_type that was just an option of your default character class.

 

[Krice]

While I was refactoring the player class I suddenly became aware of the problems with mixing OOP and procedural style and decided to refactor the whole source code to OOP. I need that structure of OOP to make some kind of sense of this. At first it may seem like a lot of work and it will be no doubt, but in this case it will have a dramatic result since the source code has so many repeating blocks. Splitting the functionality to small classes makes the source code easier to read, so it's easier fix pieces that don't yet work.

 

[Krice]

The "structure" of gui is now somewhat clear with gui.h for low level (SDL2 routines), output.h for curses-style routines that basically draw letters on screen, input.h for input routines and display.h for high level display routines that are isolated from low level. The big problem in output routines are that the screen and level were previously the same thing so when you did output something it also changed the level stuff. In the new gui output is just output on screen, it doesn't change the level map. These routines need to be fixed and the next task is to go through all files with output.h included and fix everything. Easy!

 

[Krice]

Moving stuff to Level class has required lots of fixing to function calls, because they are everywhere. Also, sometimes it's not clear if you want the routine to be in the Level class vs. the player's class. This is the "joy" of object-oriented programming. Save/load game has to be fixed for the same reason. Using the project management for this project has revealed that it doesn't have a lot to fix, which should be so, because this is (was) practically a finished game, although there are some unfinished features in overworld generation etc.

 

[Krice]

I keep telling myself I just need to decouple output functions from the game code. However it was extremely coupled so to speak. Everything happened in layers of curses windows in very complex way. If I would have kept the curses code the game would be working right now, but it would stay primitive for the limitations of that system.

 

[banana]

FYI the original developer for Cataclysm and Cataclysm 2 made a I guess wrapper for ncurses that is easier to use called cuss.
https://github.com/Whales/cuss
https://github.com/Whales/Cataclysm
https://github.com/Whales/Cataclysm2

 

[Krice]

Curses is not a problem really, I'm using it in Legend of Saladir as well, works fine. The way this game was using curses was just not that great, so I think it had to be changed. That being said, it's been quite difficult to rewrite the code, because of that complex use of layers.

 

[Krice]

After some break from this project it suddenly looks a lot simpler. There are mainly addch routines combined with old style check for level limits that need to be replaced with gameview routines. I can also move everything to proper places to keep an eye on how they work, like all movement routines to move.cpp etc.

 

[Krice]

Thinking of refactoring this back to curses from SDL2, because I can't understand how SDL2 handles keyboard. I get ' in finnish keyboard, but I want shift+' which is *. You can check if shift is pressed, but I don't know what is the code for ' in SDL2. Curses has also quite wacky keyboard routines, but they work a bit better I think.