Office Simulator: The Concept

We're creating an office life simulation game from scratch. Learn how to transform an abstract game idea into a better documented plan. Follow along as we start the development process.

The Concept

So we've had an idea for a while now about making a game that simulates and mocks office life, and I wanted to write a blog post to hopefully kick it off in a more earnest way. There have been some Office Space style jokes about the bullshit of corporate life making for a great setting that I think would be super fun to explore as a game concept. I'm a really big fan of casual games where you start small, repeat some fairly basic mechanics, and eventually grow big. I also love games that are easy to start and stop with whatever time you have handy. Think something like Cities Skylines or Stardew Valley for the inspiration on mechanics here. But rather than a city or a farm, I want the player to be in the position of starting a small business and growing it into a big ridiculous corporation complete with cubicles and an HR department.

We already have a repository over on GitHub where I started dinking around a little bit. The "game" has also been uploaded here on Final Parsec's website more so as a proof of concept of our Unity web hosting feature of the site. So far, it doesn't do much... there's a rough concept of hiring employees with a button. Those employees spawn between working hours and make widgets which are objects in the game world. My thought for the next step was probably some customers to go buy the widgets that are just sitting around.

While I believe so strongly in just getting started and making incremental improvement, there does probably need to be a little bit of guiding direction for something like this. I also think it'd be a lot of fun to document everything along the way. Some of our most viewed content are the various series we've made about making our own games, so I should probably take that as a sign to do more of it. Ok, so we know we want to make an office simulator type game and then publish the steps so people can follow along on the internet. Let's go!

How do I make my idea for a game real?

Let's assume you're like me and you have an abstract idea for a game, but not much concrete so far. Usually the best first step is putting together a game design document or something similar. It doesn't have to be too formal, but it's very helpful to have a place to centralize your thoughts.

Here at a Final Parsec, we have a game design document template which has this general structure:

  • Game Design
    • Summary
    • Gameplay
    • Mindset
  • Technical
    • Screens
    • Controls
    • Mechanics
  • Level Design
    • Themes
    • Flows
  • Development
  • Graphics
  • Sounds / Music
  • Schedule

We usually write all this up in a Google Doc, but I'm going to use this blog post since the goal here is to develop this game with complete transparency if anyone ever wants to follow along. Feel free to take this as a starting point, but adjust it for your needs. Add sections that make sense or ignore sections if you don't like them. The real goal here is just to get you thinking through the big guiding vision for your game.

Game Design


The player assumes the role of an aspiring entrepreneur starting a business selling an ambiguous product: widgets. The business starts with humble beginnings in a garage with a loan from a family member and eventually can grow to the scale of something like a Fortune 500 company.


The player controls only the founder directly, and all others actors in the game are controlled by an AI. The game operates as a simulation where all actors have their own independent motivations and goals. These autonomous actors in the world will be the employees and customers of the business, and the gameplay will largely consist of the player attempting to motivate them to increase the scale of their business.

Gameplay will consist of running around the business premises to observe employees and customers interacting. The player should be able to talk to the actors in the simulation and should also be able to perform many of the same actions the actors can. They will occupy themselves with attempting to implement, automate, and hire out the various aspects of their business: manufacturing, sales, marketing, research & development, etc.


Super casual, cozy game. Players should feel like they can take whatever pace they want without pressure to pursue goals with time constraints. Goals will be periodically presented to the player as something to guide them to work toward. Examples of these might be manufacturing their first widget, getting their first 10 sales, or moving into their first office space.



The default screen will be a third person view of the protagonist walking around the places of operation for the business.

The game is likely to be GUI heavy. Players will need a variety of stats or summary pages where they can review the performance of their business, market conditions, profiles of their employees, and so on. This will probably be explained and represented visually as the protagonist having a laptop or tablet computer they are looking at.


Meant to be played with a keyboard and mouse in a web browser. WASD for movement. Mouse for interaction with environment or for utilizing GUI.


The player assumes the role of the business founder and the core mechanic they will be focused on will be the production and sale of widgets at increasingly larger scales. They will be able to slowly craft widgets themselves at the beginning of the game but can eventually progress to having employees manufacturing large volumes of widgets on their behalf in plants by the end game.

I want to explore mechanics which play off the silly assumptions about how businesses operate and how people perform in their jobs. Some examples might be:

  • A slacking system - actors will work harder when observed; thus you will need managers
  • Burnout - something to prevent the player from operating 24 hours a day
  • Coffee - caffeine will boost an actor's productivity for a short period of time
  • Meal breaks and bathroom break policies which affect morale and productivity
  • PTO policy with real ramifications on employees showing up or not
  • Relationships between employees which can hurt or help their productivity
  • Optimizing environments by giving employees quiet offices, desks, and better equipment
  • Workplace injuries when investment in safety training is skipped

Level Design

Grid / tile map based game environments. This is something we've done before, and hopefully something comfortable to build again.

The levels of the game will be the various places where the business is run.

Potential levels could include:

  • garage where the player makes the first widget.
  • leased class C office space.
  • manufacturing plant.
  • retail store front for direct to customer sales.
  • skyscraper for corporate operations.


The themes of the levels will follow the rags to riches story the player is experiencing. They'll start with a family member's garage they're able to use for free which will look dirty and grungy. Eventually they'll move on to leasing an office space elsewhere. Finally they'll move on to the business having multiple specialized locations they can travel between: a corporate campus, a manufacturing facility, and retail stores.


Travel between levels will likely just be an animation / loading screen. In-game time will elapse to make the player experience a "commute". The player will have the flexibility to move between any of the leased or owned spaces where the business is currently operating. Unlocking new levels / locations will occur when the player commits the business to paying for it; they'll be able to browse available spaces like they are real estate listings.


The target platform here is to have the game playable in a web browser, so WebGL is going to be the obvious choice. Usually we're pretty fond of developing games with Unity here at Final Parsec and making WebGL builds you can host online is pretty straightforward. This time, however, I'd like to leave the engine behind and take the project as an opportunity to learn about doing all the lower-level things myself and possibly re-implementing some of the conveniences afforded by a game engine. This will have me writing the game using JavaScript. Making a WebGL game without using a game engine makes some sense in this case. The game will only have 2D graphics, won't really need much in the way of collisions or physics, and it's a hobby (meaning I can afford to move a little slower). So I'm, maybe naively, hoping the game will have a simplicity that makes this easier, and I'm also not too stressed about having a learning curve.

I know so far that I want to implement the levels utilizing 2D tile maps. This is a fairly common approach to building the setting for 2D games and something we've done in the past for a number of our games (we even have a tutorial making a grid for the world in a tower defense game!). The elements of the game will fit into these uniform cells. Pathfinding on a 2D grid like this is also fairly straightforward and something we've done before, so getting the simulated employees walking around the environment can be an early and easy task.

In the tinkering I've done so far (which you can see over on GitHub), I've established a pattern where all the actors in the game (customers and employees) are called to act once per "minute" in the simulation. This pattern should set us up well for each actor having its own understanding of the world, its own motivations, and so on.

As the game matures, I'd like to add features like saving game state and associating that with your Final Parsec account. That way you can hop between computers and keep all your progress. I'm hoping to make an API for this that will become available to other developers looking to host their games on our platform.

All the development for this game will be open source in that repo I've already linked and documented here on Final Parsec's blog. It's my hope that people can follow along if they're hoping to make a game of their own.


Everything top-down 2D perspective and probably done as simple vector art.

We'll likely need the following at a minimum:

  • Characters (idle, walking)
    • Protagonist
    • Actor - something that can be used for employees and customers and re-colored to give the appearance of uniqueness
  • Environment
    • Floor tiles - a variety
    • Walls to represent building boundaries
  • Widget - the product everyone is striving to build
  • GUI
    • Icons - a variety
    • Borders
    • Background for modals

Sounds / Music

Nothing too out of the ordinary here... footsteps, clicks & thuds for GUI interactions, cha-chings when you make money, hammers & sawing while people build widgets, and those types of things. I think it'd be fun to try recording most of these things myself, so I'll try to do that when I can. Matt making the sound effect of a crashing helicopter by chomping down on a rice cake is one of my favorites, and I want to keep that spirit alive as we make new games.

I'm probably not going to bother with any music. If you want to listen to music while you play the game, you're on your own. It's a game, not a dang iPod.


This is the section of the game design doc where you can outline a timeframe or versions of the game you're hoping to build. When you are making this for yourself, feel free to set unrealistic expectations so that you're starting off in crunch time.

Since this game won't really be targeting a release date, I'm not going to bother getting very detailed here. One of the earliest tasks for this game will be to set up a continuous delivery pipeline so it's just automatically deployed here on the Final Parsec website. From that point on, I'll just iteratively make progress on the game and have those changes immediately available for anyone to play.

Recommended posts

We have similar articles. Keep reading!

Getting Started with WebGL

Making a simple webpage for your game, hosting it locally, and getting a canvas to render a basic 2D object using the WebGL API.

Caching and Apache

Quick tutorial covering how HTTP headers affect browser caching and configuring Apache for your needs.

Ship Movement Tutorial

Video tutorial about ship and camera movement in a rail shooter built with Unity3d.

A* Pathfinding Tutorial

Technical talk from Matt Bauer about A* pathfinding in Nauticus Act III.


Log in or sign up to leave a comment.