Did you really think I was going to miss weekly update? Well… technically I did, so I hope you’re happy. But it certainly wasn’t due to a lack of progress. Last week I wrapped up my first pass of the investment system, but the majority of my time was spent on the two areas: representing bugs in the game, and the shopping store:
Modelling bugs is quite a crucial one in this game as it’s an important reality for any software (or really, any product) startup. It also provides an important measure of balance in the game by stopping the player from simply pumping out features without any consequence. Here is what my current implementation entails:
- Bugs are introduced when developers spend effort on any task (features, infrastructure, etc).
- The rate of incoming bugs is currently only dependent on the player’s skill level, the same number that represents the developers output level in each sprint. This means that as a percentage, a higher skilled developer will introduce fewer bugs in a given sprint. Being a software developer myself I understand that this is a little too simplistic, but I think it’s the right level of abstraction for the game. The side effect of this is that although early on in the game you can hire a lot of cheaper, lower skilled developers to churn our features, it will grown your backlog of bugs more quickly.
- The “Bug Task” is treated like any other game task as described in the last part of this post. The only difference is that while other tasks “Level Up” as effort is spent on them, the bug task level is the actual number of bugs, and spending effort on it reduces this number. My goal here is to have a unified system of expressing work in product / sprint backlog. I think more play testing will show if a specialized UI is needed for bugs.
- Like any other task the bug level will affect sales and user churn and is also dependent on market sensitivity to bugs (e.g. a consumer product in social networking market might be less sensitive to bugs than a B2B product in the software security market).
- In the future I also want to introduce the concept of a “Critical Bug”…something that happens very occasionally but completely brings the operation down to a halt and costs users.
I had already made some headway with the in-game store. Last week I focused on two areas
Certain items in the store, such as workstation, need the ability to be automatically upgraded. For example buying new screens should automatically upgrade it for all existing employee’s, as well as any newcomers. This turned out to be a little tricky, especially as I tried to adhere to certain guidelines I have setup for myself as explained here. I really like how it’s come together now though.
Placement of Items:
For now, I have settled for two types of item positioning. Some items, specifically the workstations, are automatically placed on the level using fixed anchor points (see image below). There are a couple of reasons for this: firstly I think it avoids some unnecessary micromanagement (I have said before that I don’t want this game to be a “office building sim”). It also allows me to have fixed employee capacity for each office.
For other items though I want to allow a certain level customization. My initial idea was to again use fixed anchor points but give the user one of several points to choose from. So for example if you bought a painting, you could hang it from any one of 10 spots. I started implementing this but quickly realized it’s going to be too limiting for the player, and a pain to create levels for because I’d have tons of anchor points lying around.
I came up with an alternative, which is to have anchor “lines”. Since most (if not all items), will either sit on the floor, or on the wall, I can create line segments and allow the player to put the item at any point along them. This is working quite nicely so far.
Some things to note about these anchor lines:
- Al objects on the map exist at 4 different planes currently (more might be added later): Back, which is where most objects like fridges, TVs, painting and decorations will be. Middle, which is where the player desks currently reside, Employee, which is in front of desks and is where characters will be drawn, and finally Front, which is where the employee chairs are. These layers simplify the rendering process
- Objects on the same layer cannot overlap (except for employees who will be able to walk past each other)
- Each anchor (including line anchors) has a type associated with it which stop the player from placing a fridge, for example, on the wall.
Coming up next
I’m still searching for that 15 minutes of game play. I should probably set an “Alpha” deadline for myself and work towards something I can send out to people for play-testing. I have also been searching quite a bit of art styles and trying to figure out what look and feel might work best for the game. Here are a couple of examples of what I have liked so far:
The quality I’m looking for will require spending several thousands of dollars and that is not an endeavor taken lightly. Hmmmm…