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.

Monday, 21 August 2017

FOV hardships

I have found a somewhat nice FOV from Roguebasin which I'm trying out. The algorithm is not something that I actually understand, but I guess it's not obligatory. With FOV I'm also programming lighting which is an essential part of the gameview. It has taken quite lot of time trying to solve all problems related to those two features.

Lighting does have an "interesting" problem in 2D map, because you can have a lightsource at the other side of the wall, but it's still lighting the wall on this side. I don't yet know if there is a solution to that or should there be. It's not the worst kind of problem after all, it just may look funny.

What is also funny is how long it has actually taken to come up with a solution to both of these seemingly simple features. Sometimes it can be depressing to think about it and when you don't focus on a particular feature you can delay the depression for quite a while. But this time I have decided to finish one feature at a time and not let it wait any longer. I'm going to stick to this problem as long as it takes and not do anything else.

So while trying to solve this I have already decided the next feature which is the way objects are reacting to terrain. I know, even that is not yet done properly, but it also will be more complex than usual.

Friday, 11 August 2017

Alpha release model

Since it's going to take years to finish this game I have a plan to "start small" with exclusion of data for alpha releases. It means there will be only those features which are considered to be finished and the size of game world is reduced and so on. This could actually be one of the best ideas I've had for a long time, because in my opinion there are many good things about this and only few less good.

From development perspective it's easier to concentrate on finishing features when you don't have to work with a large amount of data. The data is mostly there, but it's not yet functional or fine tuned. The way it works mainly is excluding commands, because it's mainly commands which are also features and you handle the data through them. The second part is limiting the number of object types available. For example in the first release I'm planning to have only one playable character class so it gives an idea what it will be like.

This model also forces to finish those "simple" features which are often overlooked and left unfinished, because they are supposed to be done "fast" before the release.

The early release is probably going to be a positive experience mainly, because then it's possible to fix things that developers can't often figure out. Not only bugs, but some annoying features etc. I'm not worried about bugs, but I guess there will be some people who don't get it and they could complain why isn't the game finished yet. Also, I'm almost sure there will be "ideas" people, you know those annoying guys who throw in their ideas. They don't realize that developers are often creative enough to have their own ideas.

This plan is already in motion. The first part has been easy, because in data-driven engine it's quite easy to exclude features. Some features are excluded by commenting out source code, but it has been also quite easy. When the first release happens is not that easy to predict, but we'll see eventually how this idea works.