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

Gadgets

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.