Between adding features and making other changes visible to the players, I spend quite a bit of time working on the code architecture in KeeperRL. It pays off given the long term nature of the project, and also because working with well designed code simply makes me a happier programmer.
There is a particular bastion of bad design that goes back to the days when KeeperRL was a simple ascii roguelike. All non-moving objects in the game are described by one type of entity, called a square (because each one occupies one square on the grid). There may be only one square at a given position, so when, for example, a chest is placed on a floor, it replaces the floor square. A square is also responsible for tracking any creature that enters its grid cell, and any items that are dropped on it.
When I added the dungeon management features, building and digging was as simple as replacing one square with another. Even cutting trees meant replacing a tree with a tree trunk. When I added graphics to the game (about 10 months into development), the squares had to remember what they replaced and draw that as a background, so you could see the grass under a tree (with ascii you don’t have this problem, as each position is always rendered as one character).
As I was adding features to the game, more logic piled up on top of this design, and it stopped being pretty. The right way to do it was to have another type of entity represent all the objects that can be built, replaced, etc. It would also take care of all interactions between the static object and a creature. The change is not simple though, as a lot of things would be influenced: pathfinding, building, lighting, spreading of fire, etc. On the other hand, there was a solid reason against it: the existing code was already well tested and working.
Until a few weeks ago, when I started implementing manual placement of floors. I wanted to allow replacing the floor under an already existing object, like a door, but the existing design couldn’t handle it. This was the straw that broke the camel’s back, and I went and added the new type of entity, temporarily called “furniture”, although it includes other things, like trees, walls, etc. These existing objects and their functionality needed to be translated to “furniture”, which caused a chain reaction of other necessary changes deep in the game’s internals. The resulting design will be much better, but it will need a lot of testing before it’s released to the public.
Anyway, this is what I’ve been doing in the past week. It’s just an example of what I work on, when I’m not adding new features. If some updates seem to take too long, it’s because I have to embark on this kind of adventures. 🙂
Hi everyone,I wanted to leave you all with a little Christmas gift before the holidays. This year KeeperRL finally went 1.0 and you’ve all shown such incredible support for... more
1.1.1 Golden prayer bench training limit is increased to 99.Added missing church tech descriptions.Fixed courtesan and gigolo minions not appearing in the minions... more
The KeeperRL team wishes to entertain you this Halloween by releasing a new playable faction called the "Corrupted Church". Playing either as a Bishop or a Mother Superior,... more
A few months ago, I was contacted by a company called Elda Entertainment about a possible collaboration on KeeperRL. Elda is a small publisher based in Sweden, comprised of... more
I'm very proud to announce that KeeperRL v1.0 is out! In addition to being the most important milestone for the game, this is also a huge update with major gameplay additions.... more
Home › Forums › The joy of cleaning up old code