Redesign of the gameview screen

So I went to doctor and got heavy antibiotics for three weeks plus alpha blocker medicine. It's interesting stuff, supposed to loosen the muscles of pelvic floor, but since I'm special it's affecting to all my muscles, including heart which is of course a muscle. For couple of hours after taking the pill my heart speeds up for quite a bit. It's annoying, but supposedly not very dangerous. However it's working, I'm feeling lot better now.

I've planned the next feature also for some time and now started to implement it. It's the gameview screen (stats, messages, etc. around the gameview) which is going to be modernized to 1.6 aspect ratio. The current resolution is 800x600+ something, but it changed vertically bigger when I added 5 lines of messages. Since displays today are almost all 1.6 ratio it makes sense to change the screen for that size. Even more important it feels like I'm actually planning the screen for the first time, because this far it has only included some of the stats.

The extra space is probably going to have both equipment and inventory as tiles with drag and drop functionality. Yet the UI is kept such that there is no need to use mouse, it's entirely optional and will work at the same time with more traditional keyboard commands.

Stetson-Harrison project management

I was looking at the oldest files in the project and found two classes (four files) from 2009 that were not used anywhere. It's actually a problem in big projects that you can create multiple ways to do something and then some of that code is never used. These days I try to avoid writing anything for "future use", just as happened for those two classes.

It could be really nice to have an option to somehow mark files in the project different way. You know, when you have the list of files in the project you could mark "ready" files with green color (or something like that) and critical files with red, etc. Neither VC2010 or Code::Blocks has that feature. Some time ago I went to ask C::B developers if they could add that feature, but I got the typical "open source answer" to add it myself. No. You add it, you are the fucking developers of that piece of shit.

I've had problems with my health. Nothing major (I guess), but for couple of days I couldn't concentrate on anything. Sucks. I tried to go to doctor, but he is not in the house for thursdays or fridays. Public healthcare, you know. At monday I'm going to try again. I hate going to doctor, but enough is enough.

I try really hard to concentrate on fixing actual gameplay mechanics rather than fiddle around with source code quality (which is important in a way). When I refactored the map routines it broke stuff elsewhere. Funniest one was walk command (similar to 'g' in Nethack), pretty much everything broke in that routine.

Clean-up (x2)

The level generation is working again mostly. Some new bugs, but nothing major. Both FOV and light map routines are off for now until I have the energy to concentrate on them. Maybe it's best this way, I can directly see the topology of the level when creating level themes.

There are more important things to do anyway. Next task is mainly go through level themes and add more things, starting from basic topology and then moving on game object distribution. There is a "trick" involved in the process, an idea I had while working on the new version of Teemu. It's of course a secret.

I guess it's these warm days, but I was upset when I noticed that save game routines for each game object type has to be refactored. Most of them were easy to convert, but couple of them needs more work. When I get upset it sometimes makes me clean up places. It's a woman-like way to react, but who cares.

Tile class - part 6

It took almost two months to refactor multiple maps to a single one. But it's not over yet...

It's annoying that I made mistakes even I should have known better. The bounds check is less reliable now, because it's not built-in like it was before. I don't know what was I thinking. I guess it can be fixed for at least those getters that return a class type, because returning -1 is dumb. It could be possible to create a type for a tile outside level borders that acts like any regular type, but the way that you can't reach or use.

FOV is not working properly. There was a coordinate translation change so it maybe has something to do with that.

The next task is a clean-up to fix bugs.

Tile class - part 5

Mask maps are now mostly included in the Tile class. While refactoring terrain map I realized that Gameview class has to be refactored. It's a class that draws the final 17x17 tiles on screen. Previously it had both static and dynamic light maps copied into a special 35x35 buffer which includes nearby light sources still visible from that 17x17 view.

However I found out that there is no need to copy the light information to the gameview, or anything else, because Tile class can include them. Even dynamic light values can be stored in Tile and recalculated on a specific area around the player to show only light sources that can be visible to the player.

The original Gameview was a result of copying FOV data and then determining how tiles and light would be displayed, but FOV was moved away from Gameview even before I started this refactoring and I didn't figure out how much there was unneccessary copying until now. Another great thing is that the new code will completely remove difficult coordinate transformations. Also, tile graphics are now stored in Gameview which is a wrong place, because they belong to GUI class. Gameview wont become completely useless, because it still has the update map which speeds up displaying of tiles by remembering empty tiles from previous turn and not drawing them at all.

Even now the gameview routine is fast, but it's going to be really fast after this refactoring. Well, I'm going to need that speed to include lights that have FOV routine in them. At the moment lights are just simple spots that don't know anything about walls or other obstacles.

Tile class - part 4

Dungeon (World) class is now cleared from game object maps. Yes, they were there, because object maps are just 'temp' pointers to the object, which are owned by the Level class in a linked list container. The map could also own these objects, but it would need dramatic changes in the way true object handles (vs. generic base class handle) are stored.

At that point I was able to run the game, but it wasn't very pretty to look at. Terrain tiles were missing, because Level::Show is now in Tile_Map class and terrain isn't there yet. The game also crashed a lot which is funny, because the usual code is rock solid. I believe it will sort out itself when everything is moved to their proper locations.

Terrain and masks are the big refactoring thing I'm now programming. It's more tedious than difficult, but some constructions are very different than before. Yet as I thought functions of Tile are shorter and easier to read as source code, because they don't require external gets from different map layers.

Tile class - part 3

The easy stuff like FOV and automap are now in Tile_Map class. There is a class hierarchy confusion with Tile and Tile_Map, because in Tile_Map class sometimes there are simple getters that return Tile information from (x, y) location. It's not always pretty as it happens to be with getters, but I now know better not to spend time trying to create a perfect class hierarchy.

I think the tricky part will be lighting routines, because I'm planning to rewrite them. What I need is a nice line-of-sight routine for lights and a math implementation to light areas. Both can be difficult, at least for a programmer like me. I think I'm not going to use the main FOV routine for lights, but who knows, it may be easy to change it to work with lights. I've been thinking about the wall problem. It's a "bug" where a light source can lit wall from the other side (as if coming through the wall), because walls are usually 1 tile wide. I have some kind of idea how to fix it, but it's too early to tell if it works.

The biggest part will be terrain map routines. I'm trying to avoid Tile_Map becoming a kind of Level class itself and put only low level creation routines in it (things like shape primitives, rooms, etc.).