Posts

If you know me, you’ll know I have a lot of (game) ideas, coupled with a less-than-spectacular attention span. Most of the games that I start would likely take 6-12 months of regular evening work (10-12 hours/week) for even a minimal game, while I usually don’t spend more than 6 weeks on a game before becoming distracted by a new idea. But 6 months of focus is a long time! I could make games that I could finish in 1-2 months, but they aren’t games I want to make. Thus, I have a lot of games that are 5% done.

For accuracy, it’s nice to know how fast a rotating circular (or toroidal) space station would have to be rotating to simulate Earth-like gravity for its occupants. After some searching, I finally dug up a concise and relevant Wikipedia article that helps explain exactly that.

There were five games covered here – Dungeon Keeper, Theme Hospital, Rimworld, Planetbase, and Dwarf Fortress, each with distinct ways of handling rooms. There are quite a number of axes along which to analyze these games, so let’s dig in.

What game list would be complete without mentioning Dwarf Fortress? But seriously, this game actually does belong on here.
Dwarf Fortress is a game where…well, you build a fortress, and you have dwarves. Like Dungeon Keeper, you define the boundaries of your rooms mostly by digging out dirt. Like Rimworld, there isn’t a strong in-game notion of “rooms”, though you can flag areas as being a bedroom or a meeting halls. But it’s not a necessity.

Planetbase is slightly different from the others – you’re in spaaaace! It’s a race to build a base in space before you run out of oxygen and supplies, at least for the first few days (surviving a day is actually an achievement).

Fast forward almost two decades and you have Rimworld. This game is a little different from the Bullfrog games in that the game doesn’t itself have a notion of rooms. It knows about indoor spaces and outdoor spaces, but that’s about it. You can build and place various objects into the world (tables, chairs, etc), but at no point except in the player’s mind do you actually get a room. If you want a kitchen, you throw up some walls and put a stove in there. Dining room? Place some tables together with adjacent chairs. Bedrooms are just beds that happen to have beds in them.

Amusingly, released by the same company in the same year, comes Theme Hospital, a game that also has rooms, but they couldn’t be more different. In this game, you’re, well, running a (ridiculous) hospital. You’re given some buildings and capital, and have to solve the silly ailments of the community (while generating a healthy profit, of course).

In construction and management simulation games in which you essentially construct buildings and structures, you often have to build rooms within those structures. People (or creatures) in the game will then enter and interact with these rooms and stuff placed in these rooms; however, the implementations of rooms in games have seen an impressive amount of variety. How are rooms placed? Can you put items in the rooms? How are the walls handled?
I’m going to talk about some of the various room designs I’ve observed in games I’ve played in a six-part series, starting right now.

You’re working on your Android application and realize you have a nice piece of reusable encapsulated logic you’d like to factor out into a library. You still want to be able to develop this library and your application in parallel, so they should be on disk together and somehow linked. So what’s the best way to accomplish this?

As a newcomer to Android, one of the things that’s surprisingly tricky is communicating with a Service (an application component for long-running operations) from other parts of your application. You can’t simply call methods on it – you have to come up with a way to broadcast messages.