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.

Friday, 14 July 2017

Remaking level generation

Since the map holds Tile objects it doesn't make a lot of sense to create objects for each map tile, but only those you can see. This idea led to another one when I was thinking level generation from a new perspective. In short you start from a level of null tiles and create open areas first (floors). Things like caves and passages between them, rivers and other natural areas. Walls don't exist yet, in fact they could be created after everything else is done, for rooms too. So the generation scheme would be two stages: first floors (and other tiles that are on floor level) and then walls/obstacles on top and around floors on empty areas. Also, I guess that way you could always make sure that everything is connected, other than areas you would later seal off with obstacles etc.

When digging to an empty area tiles would be generated around that place to avoid the player to reach null tiles. The only downside is that this will take some time... but I think it will be worth it and it's only a kind of minor shift in paradigm from carving stuff out from full rocky level to creating floor areas first on empty void and then building walls later in places they should go.

Sunday, 9 July 2017

Level class structure

After couple of days the final form of level class structure is ready. The difference to my initial plan is that there is one more class. They are:

Gen_Level: This is the base class which contains only the map for tiles and handling simple tasks such as low level get/put tiles.

Shape_Level: This class has routines to create different shapes of terrain tiles. Again, this class is kept very low level.

Object_Level: This is the new class that contains game objects and also room objects. The previous Object_Shed class was copy-pasted into this directly. It also was designed to relieve the amount of lines from that massive Level class that I had, but I realized it can be made a part of the class hierarchy.

Sequence_Level: The dungeon generation class with different parts activated depending on level theme.

Level: Gameplay part of the level structure which has routines that game objects use during the gameplay.

After this there are special themes derived from Level that override some creation procedures. This split seems to work quite nicely and it surely has made the management of code easier already. Level class still has quite few creation related routines which are moved either to Object or Sequence level. When this is ready I can continue working on creation routines of some level themes.

Tuesday, 27 June 2017

Level class management

After about 12 years of C++ programming I had an idea to split the Level class. Actually I did it to downward direction when I derived some level themes from Level class, but now I'm planning to split the level class to four classes with a linear deriving order.

The base level class is going to be a container for tile map and game objects. It also has tile-based functions for things like creating a single tile. Another idea I had is that the tile map pieces will be null unless there is a tile object. Also, the tiles should be created on first priority which means what is created first will not be overwritten by another tiles. Well, other than creating wall tiles on floor tiles which is going to happen anyway.

The second level class will be shapes class with features that create anything from rivers to rooms.

The third level class will be the sequence of creation (which is different for some level themes).

And the fourth class will be the operation class during gameplay which handles actions with game objects and the level.

A nice thing about deriving is that I can simply copy-paste the existing source code from Level class upward in classes without any modifications needed. So it's a big task, because the Level class is huge, but still quite easy one.

Tuesday, 16 May 2017

The role of magic

I've always seen the typical magic in role-playing games too powerful and having too big role. In some cases it's impossible to survive without magic in some form (magic items if the character class can't cast spells). I wanted to avoid the same mistake and for a long time I had difficulties to think about the role of magic in Kaduria.

The big problem is that you want to have "magical" things, like creatures, in the gameplay. Without them everything becomes kind of boring. At some point I decided to remove spells, but it started to seem odd, because the game world has magic in it.

I've been working on bringing spells back, but it's not going to be old school fireballs etc. It's more tricks and illusions rather than spells that simply kill everything. The way magic works in D&D based (almost all role-playing) systems is that it's fixing the balance issue coming from fighting thousands of otherwise tough creatures. Then again the combat system of D&D also has the same flaw, it makes the player eventually a godlike creature that can kill everything.

I feel like I'm now experienced enough to design spells that will work in this game, when in past I would have been only using similar spells that were in every role-playing game.

Friday, 5 May 2017

On success and failure

I think many people understand success as results. Developers release games and possibly get money selling them, which is seen as success. But you could think it another way, success as opposite of failure.

Some roguelike projects fail, because developers not only abandon the project but they sometimes completely end their game programming hobby or career and move on to other things in life. I guess it's ok, but it's an actual failure: you failed in whatever you tried to do. But if you just keep on going and don't give up you can't fail. You will always be successful as a creator, and that can't be measured by achievements or the amount of money you make.

There is something in the way people react to long term projects. They try to ridicule it, but I think secretly they wish they had the same kind of persistent willpower to never give up. In many cases people who do become successful in real life terms (money etc.) have that trait and for them life is all about trying to reach something, some kind of goal that's always around the next corner.

I guess I'm a bad case of that trait, because I never understood people who abandoned their game development life. Why would they do that? What made them stop?

Wednesday, 3 May 2017

Implementing ideas

One of the things in roguelike development is that you should be careful about implementing too many ideas. But what if you did implement all or most ideas you had? I started to think about it and it could be something to try. At least with Kaduria, because I really don't have any kind of pressure to release it any time soon.

One idea I had the other day is a randomized cargo lift. With that it would be possible to move something heavy between levels, like 'movable' objects (barrels etc.) which you can't pick up anyway. The source and destination levels could be more or less random, making it interesting sub-plot to find out which lifts are connected.

I've started to change notation type enums to namespaces the same way I did in Teemu. It's not very important, but makes the source code more manageable I guess.

Sunday, 19 March 2017

Object storage re-design

In the current engine game objects are stored in "raw" lists on Level class, a list per each object type. 2D maps have pointers to these objects. There are other ways to do it, like concentrating everything on a tile which means the tile owns all objects on it. The reason why I have a list for each object type is that when I was designing the system I had difficulties to understand how a base class list would work, but of course it's pretty trivial.

I'm planning to re-design the system with a container class that "hides" the base class list of objects and then has everything needed to work with the list. Then I could create an array of those classes each with a type of game object. I could even try tile-based approach or possibly a mix of both with stationary objects owned by tiles.

I know this is one of the things that people may get right the first time, but I wasn't that lucky. Even so, the re-design is not very big actually, because all it has to do is add and remove objects in the list, with couple of other routines. These days I'm quite careful not to reprogram things just because, but this one seems to be quite important to get rid of the object id confusion I'm having at the moment. If there is anything I have learned about programming it's to break large pieces of code to smaller pieces that then can be managed.

Wednesday, 1 March 2017

Unlimited level size

I've worked on level theme content and kind of frustrated about the rectangular level shape or space that you have to work with. I think it's limiting the way level generation is made, because you have to choose cavern sizes etc. to match the level size, but it should be the other way around. Level size should adapt to whatever is created in the level.

The big question is how to implement that kind of level map, because you still need a 2D grid to contain the level. One idea that could work is create a ridiculously big empty level and when the creation is done then remove areas "outside" the level that don't contain any features. If it's difficult to resize the grid then copy the content to another level that matches the size.

The way level is generated would change a lot, because everything would be created in relation to other features. With this kind of creation it would be possible to start from several "points" and create different kind of content until they meet. This is a problem I have now with themes that have more than one style of features such as a town level surrounded by generic cave-corridor -style. When you create the town you are limited by the outer edges of the level plus those extra caves. Without edges you could create the town of random size, add some caves to extend it and that's it. Not only that, even simple level themes sometimes position caves on the edges of the level which can be seen, because they are cut off by the edges, even the edge routine is including some random tiles to make it less obvious.

I think it's not too late to use an "unlimited" level size when creating the level, because the way levels are created in this game are not limited to any kind of grid. Yet this is not something I want to try now. Not until I have programmed all important features of level generation.

Sunday, 5 February 2017

Graphics design

I'm trying to design the placeholder elements on the main gameview. You would think I had all the time to do that, but "stuff" keeps changing. In my opinion you only have to show the player stats and other things that have some direct meaning to the character's condition. Other stats can be hidden to reach with keyboard command etc.

Drawing is a strange experience to me, because I'm supposed to be a graphic designer, but I'm really not that good as one. Or at least it takes time to do something that looks decent. But my first goal is placeholders which for those who don't know are the location and size of elements on the screen filled with some quickly made sketch.

As usual if I look at the past I made a mistake with tiles, not really knowing that technology would change in the future and I would have to remake tiles again. This time I'm just keeping what I have as it is and when the game is ready only then it's time to think about graphics. I would like to have someone to draw tiles for this game, but then again it would feel weird, because I've been creating this game alone for such a long time.

Other than that I think the project is starting to run out of unfinished parts of source code. Everything seems to be narrowing down to couple of issues, although the largely unfinished RPG system is a complex subject.

Sunday, 8 January 2017


As a new year's resolution I have started to find solutions to difficult problems which are often left to be "done later". One of those was traps that had the trap effect and mechanism in the same class. For a long time I planned to create separate classes for those and currently implementing it.

The new Gadget class is the visible part of the trap, like pressure plate or holes on ground. Gadgets are not always traps, the pressure plate can open a nearby door for example. Traps can be also attached to other items than gadgets. This was the reason I had to move traps from game object system to a composite class. The procedure or refactoring is anything but simple. I don't think there is a nice, clean way to determine which gadgets or target objects can be attached to which traps. It's probably going to be a manual list of traps for each type of game object which simply means I have to forget data-driven approach in this case.

With a gadget or other host mechanism the traps could be changed to more abstract form such as gases, spikes, falling objects etc. so for example you could have a classic water bucket placed on top of a door.