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.