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.