Sunday, 23 September 2018

Being simple

Finally solved the display map synchronization problem I had for a long time. The underlying problem was my inability to think the simplest possible solution. In programming almost always the simplest solution is also the best one, because it's going to reduce the number of places things can go wrong.

I solved this in Teemu where I was adding support for multiple items per tile. The solution was so simple it just came out from nowhere. It's sometimes difficult for a highly creative person like me to think in simple way, but it's something I'm trying to do when programming. I try to be a simple person and it's probably the most difficult thing to do for extremely intelligent people in my experience. Although even harder for me is how to get women. It seems to be impossible for me and sometimes it makes me sad.

I'm also going to import the "flight package" routine from Teemu. It adds flying items into a list and then throws them at the same time, rather than go through each creature and make them throw items one at a time. When items are flying at the same time they could even hit each other. For example you run into an archer who is about to shoot you, but you can throw a large item and intercept the flying arrow.

Friday, 20 July 2018

Modular style

So what I have discovered lately is a sort of modular programming style where classes and functions of same theme are placed in one source file. This doesn't sound like very interesting news, but at least in my experience it may solve some problems resulting from C++ "class per file" rule we have been told to follow.

The problem with "class per file" is the physical size and complexity of the project: the more files it has the more difficult it becomes to maintain. C++ doesn't help, because you have to remember to include headers and also keep track of headers that are no longer needed. With large, over 300+ files project it starts to become a hassle.

Modular style has also other benefits like keeping better track of similar types of classes/routines and possibly making them more generic with inheritance etc. If your classes are in a single file you may actually forget(!) something similar exists. It's easier to find stuff, too, when similar type of code is in one file.

In C++ the downside is naming, sometimes there are issues when some namespace has been opened. But it's quite simple to remedy it by not making your names too generic even it is possible with namespaces, or use nested namespaces when possible. With modules the amount of namespaces seem to drop as well, with logical solution to use namespace per module, possibly even using the same name as the filename to keep things tidy.

For me at least modular programming used to be split to classes in a way, because classes are kind of modules by themselves. But using larger thematic modules may actually prove to be very important in this project and in the way I'm able to maintain and develop it.

Wednesday, 30 May 2018

Object-oriented news

I have a plan to put related classes into one file. This idea came from The Prowler's Datatype module and when I was programming similar type of stuff in Brick Atelier. I noticed that it's somehow easier to manage code and even design inheritance when there are less source files. It's maybe something we were not told to do, but I'm doing it anyway.

It's not a big refactoring which is something I try to avoid these days. It's more like re-arranging code into bigger pieces. This works with small classes, but not so much with bigger classes where actually splitting the class is a better option as mentioned earlier with the Level class saga.

I also try to use more inheritance which sounds quite obvious with a C++ project, but it's something I guess many programmers try to avoid (for no good reason). If you have a class-based code it's almost better use inheritance, because then you are going to remove some similar, repeating code for sure.

With content I try to design level themes from basic terrain topology first and then moving into details. I have some new ideas and tools to create difficult level themes so let's try it and see what happens.

Thursday, 8 February 2018

Plans for 2018

The account problem with VS was fixed, but I've also made a project for new Code::Blocks with virtual folders trying to make some kind of sense to it. The Cornucopia system I made for Teemu is going to be in Kaduria too. I think it will work well in town generation which is a missing piece in dungeon generation algorithms.

Something happened to me during last year, I don't remember I mentioned it before, but I became more aware of problems in my source code and programming style. In a way I became a better programmer almost overnight. It was a strange thing to happen, because it came out from nowhere. Maybe brains sometimes work that way, they get information from a long period of time and then make a decision to step into a new level.

The plan is simple: detect and work on problem areas of this project. There aren't that many left I think and they are mostly fine tuning some system like dungeon generation, in which I'm going to follow my experiences in Teemu and use more or less individual level theme generation for the basic structure of a level theme and then add more generic routines which create objects etc.

Wednesday, 30 August 2017

Switching to Code::Blocks

Visual Studio started to have strange problems with the Microsoft account which made me rage quit and switch to Code::Blocks and gcc. I've made final compiles for Teemu and Brick Atelier with gcc and it was easy to set up Kaduria for it.

Code::Blocks is let's say less good than Visual Studio, but it's not that bad actually. All I had to fix were some missing c headers, because VC is "silently" including them. And fix some missing forward declarations. Then I built the project using some useful warnings and also -Wall. At the end of the day it's quite clean, couple of floating point comparisons left to fix. I did suppress 'write-strings' warning, because it's warning about things like printf("Hello"); not being const. I can get the reason behind it, but it's still one of those impossible warnings you don't need, because there are going to be billions of them.

The debugger of gcc is quite useless, but luckily I almost never need it. Most of the bugs I'm making can be found with static checking and warnings of "dumb" things you can easily write when tired etc.

Code::Blocks is surprisingly stable for open source program which is great, because without it there would be even less options to replace Visual Studio. One thing I didn't yet solve is how to get rid of the console window in SDL2. -mwindows doesn't seem to work.

Monday, 28 August 2017

New gameview design plan

Since I had no luck with FOV I've moved on to next feature which is not in fact terrain effect when moving but the new gameview. Funny thing is that I've had this constantly scrolling "Ultima" style gameview since the beginning of this project, but I'm going to change it anyway. The reason for Ultima view were tiles of course, because in ancient times you couldn't create a large view area with tiles, it had to be small. But it's no longer a problem.

The current view is 17x17 tiles, but since I'm keeping a full hd resolution as "minimum" then there is room for larger view. One possibility could be 30x20 tiles. It's still quite small, but allows push scrolling for the view and it's not too large, because more tiles means slower gameloop. When I was making a sketch of 30x20 tiles to see how it looks it's quite mindblowing to realize that Nethack's gameview is 80x20 something (the level area). It's so wide, but it's harder to get, because often the font is taller than its width. I guess you could say Nethack predicted wide angle screens long before they existed.

Push scrolling is used in many roguelikes so it's not that strange. ADOM has it and also tile versions of roguelikes, including Nethack. It's also quite "easy" to change the gameview to push scroll and I have done it in Teemu so at least it's not going to be a big problem like FOV. But as always we'll see that later. Also the screen size is going to change and it means lots of changes in placing gui components, windows and other stuff like that. However since I'm developing this one feature at a time it's not going to blow up everything at once.

Saturday, 26 August 2017

FOV hardships part 2

Last time I wrote about a routine that seemed to work nicely, but for some reason I could not use light values for that routine. I couldn't figure out how to calculate values or even how to use an array of values to attach to visible tile calculated by it.

Not only that, it's almost as adding "salt to my wounds" (a saying we have in finnish) I received an e-mail from a guy who's identity I wont reveal since he used e-mail. Anyway, I'm calling him "Mr. Man". He wrote me about his game and a FOV routine which not only is a great FOV but also a perfect lighting routine taking account light direction. I wrote last time that I didn't know how to solve "other side of wall light" but in fact I did know that you need four values per tile to lit each side. Just how in practice you implement it is another story.

So Mr. Man was telling me how he solved those problems, but he didn't show any source code. Since everyone knows me they also know that I have difficulties to understand even simple algorithms and math. It felt quite bad to be honest, him mocking me with his perfect routine. It was almost like women mocking me that I can't have sex with them. He could post his routines to Roguebasin or RogueTemple for everyone, but I doubt he would do it. Well I think his game is going to be bad anyway. Or if it's good I'm going to play it. If it's free, of course.

I'm kind of back in square one, but I have solved lighting calculations by realizing that I can use an array of data for lighting values. It's static data and you need an array for each size of light source, but it's not that bad. The problem is still FOV, but I'm not entirely without ideas. The routine I have in Teemu is working, it's just bit slower, because it has special checks for gaps of line-of-sight. But it's not that slow I guess.

The wall facing is a problem, because you could detect creatures walking with a light source from another side of a wall. Yet I think it's not going to be too difficult to implement once I have a working FOV routine.