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.