Software Inc. Review (Narnach)
I played 27 hours in the first 3 days, 2 of which were working day evenings. That should say enough about how compelling this game is.
This game simulates a LOT more than most games, and keeps adding interesting layers and mechanics to play with as you advance through in-game time. As a consultant/programmer who enjoys simulations and economy games, it ticks a LOT of boxes for me.
There are ways to do things manually, and to automate them once you scale up or just don't want to bother with them anymore. It's like real life in this way.
There are so many different ways to earn money in-game that I think it allows for multiple very different playthrough focuses:
- Typical garage startup with one product snowballing into a conglomerate that owns the market for various related tools
- How far can you get with just your founder(s) living the solo indie dream?
- How long can you sustain one hyper-polished product? How "Wube" can you be?
- How much cheap garbage can you churn out for close to zero cost? Think cheap outsourcing.
- Play as an agency: only do contracting work, and never develop your own products
- How far can you go via buying shares instead of developing software? Can you live off dividends until one of your investments collapses and you take over their business? Or start with a big bag of money and buy an existing company to bootstrap your software?
- Focus on publishing, marketing and support for others
- Focus on hardware (I've yet to try this)
- Focus on software that earns its money via licenses vs units sold directly: play the long game with eternal support and ports
- Run a digital distribution platform, and try to grow it via exclusive deals
- Challenge: is it viable to run a dedicated R&D lab from the start?
- Challenge: can you fulfill all available deals? (I'm cornering the market on hosting/support/marketing in my current playthrough, but dev/design would require a LOT more staff to handle)
Gameplay has a bunch of ways in which you can control trade-offs. For example, these are choices you _can_ make (but don't have to) when designing new software:
- How many features do you put into new software? Complexity and domains determine skill of designers/programmers needed to design/develop/support it later on, and how expensive your people will be.
- Do you create or (re)use a framework?
- Is this a sequel to earlier software, or something new?
- Do you have access to research, patents or other advantages?
- Do you target one OS, multiple, or all of them? Do you want OS-exclusive deals? More OSes take more time, but increase market reach at launch. Porting them in later expands reach, but you'll be low on hype.
- How do you position this in the feature pyramid, and how much demand/excess saturation do you want? This impacts marketing reach/effort down the line.
- Who is your lead designer, how creative are they and how experienced are they in this software type?
- Do you use a publisher for funding/marketing/distribution or do you choose to do it all yourself?
- How many design iterations do you take the software through?
- How often do you review + iterate on the alpha version of your software?
- How long do you fix bugs in beta?
- Pre-launch marketing: how many press releases, when, and with how much detail? Do you send demos to the press, and do hyping?
- Post-launch marketing: how much money do you spend to blast it everywhere? (I wonder if future updates could do segmentation and different media types to make it more than "spend money")
- Distribution: physical vs digital (when do you stop physical?), how many copies do you print yourself or order from a supplier?
- Do you make the software exclusive to a particular distribution platform, such as your own?
- Support: do you have enough people turning complaints into verified bugs?
- How often do you patch bugs?
- How often do you apply technology updates to existing titles to keep them relevant vs new competitors?
- Do you want to developer add-on content packs, or just focus on main titles?
- At what point do you stop supporting/selling/marketing/updating/porting of existing titles?
- How many teams work on each of these aspects, and are these primary or secondary tasks? How do you balance tasks relative to each other?
There's a bunch of things I haven't even touched:
- Hardware design, production lines
- Physical printing of software vs just ordering copies
- Project management and HR automation (though now that I'm scaling from 9 to 12 teams that rotate 24/7 my next step is to dig into this)
- Building an office. I went from garage to office building, and haven't filled this one up yet
Nothing is perfect, so these are things that could do with improvement / expansion:
- Picking what to educate an employee on next often depends on which skills are least trained in their team, but you need to manually open the teams window to get the comparison
- If your publisher bails on you, you can't find a new one to do it for you
- You can pick up deals to perform any aspect of the software life cycle for others, but you can't create deals or contracts to ask others to do the same
- A distribution platform behaves a lot like software, but lacks some of the feature comparison and growth metrics that you can get for regular software
- Marketing is pretty simple right now: just throw money at the problem. I wonder if this could be expanded with market research, to increase conversion by optimizing targeting, or to have different channels to reach different market segments.
I bought the game after seeing Quill18 play it. I played 25h after his first 3 episodes. There's aspects of the game he completely overlooks or neglects, which I micro-manage myself, and things still work fine for him. Typical big picture vs detail focus things. It's a testament to the range of viable options and play styles you have while playing and can still succeed with. I love his idea of running 3 teams in the same office in a day/evening/night shift schedule, it keeps the need for space much lower than if you only use a daytime shift. Starting work on marketing at midnight, when the budget resets, also means you have the rest of the day to focus on it, or have other teams work on it as a secondary task.