Devblog #15: Design Philosophy

Hi, it’s TJWhale here.

Thrive has a great team. There’s a lot of talent working on this game and there’s also a lot of commitment, people really care. Recently I have been promoted to Microbe Stage Design Lead, which is a role that used to exist but had lapsed. As a team we decided it is important to have a way to finalise decisions and having a Design Lead for this stage gives us this.

In my life outside Thrive I have strong beliefs about what good engineering discipline is and I want to try to strengthen this team’s way of working. Engineering discipline is a way of thinking about the process of building things which have not been built before, if something is well known then you can just follow the instructions, however when this is not possible you need to be careful.

Firstly it’s important to have a clear vision about what you are trying to do. This means on both a large and small scale. If you are not sure what you are trying to do then it’s hard to do it.

Secondly I believe in starting small and then building outwards in a rapid iteration loop. It’s important to build the minimum viable product and then add to it, making sure that each change you make genuinely improves what you are making. Sometimes it’s possible to make a grand plan and just work through it however if there are a lot of unknowns in what you are doing then this often doesn’t work.

Thirdly it’s important to rely on validated learning. If you have an idea for something which hasn’t been built before then you have no idea how good it will be and what it’s issues and drawbacks will be. It’s important to build it and then test it to really be clear how well it works, this validates what you have learned. This is the power of the rapid iteration loop, the more times you can test the more information you will gather which will lead to more learning.

Fourthly it’s important to review your plan in the light of your new, validated, learning. If you have new information which changes how you see the problem then it’s important to be willing to change direction to take account of it. Exploration in general involves a lot of zig zagging around obstacles, there are no roads in the unknown.

Fifthly you will always have more good ideas than you have time and effort to implement them. This is because having a good idea can take a day, building it could take a year. Because of this it helps to prioritise things in order of their value to the project divided by the effort they will take to make. A feature can be hugely awesome but if it takes huge effort to build it then it’s worth less than something which is decent but quick and cheap to make.

In general good engineering discipline is rare. It’s extremely hard to keep your eyes open and consistently make solid, evidence driven, decisions. It’s easy to just have a crazy idea and rush off after it and end up in a tangled mess, I’ve done that a lot in my life. Working on your engineering discipline is a very noble thing and is very valuable.

Applying this to Thrive means building on the process we have used until now in order to improve it. Our goals are reasonably clear, we want to make a fun and scientifically accurate xenobiology game. More locally we want to build an awesome and fun microbe stage. Even more concretely what we are working on now is 0.4.0.

The goal of 0.4.0 as a release is to work on the core gameplay elements of the game and make Thrive a fun experience. I want to get to the point where someone can sit down and get immersed in Thrive for 2 hours. This is the validated part of the learning, we can measure how long it’s fun to play for. To increase this time we need to figure out how to make the game engaging and immersive. The first steps down this road are to remove some of the painfully broken elements of the game and get the core game loop solid and tested.

You can read more about what we are planning for this release here:

More broadly we have moved to a different pattern of decision making. We are going to have a broad discussion on the dev forums about an issue, once this discussion is mature I will decide what the next small step for this feature is. If there is consensus in the team then I will always respect that. Then we will implement that step, learn from it, get feedback from the community and go back to the discussion stage.

This process is designed so it’s easy to start small, move in small steps, continually check how we are doing and make sure we are going the easiest route. I think this will really help us solidify the game and make sure it’s fun and enjoyable to play as soon as possible. Further it will help attract more excellent people to the team to join the ones we already have and this will ensure a bright future for the project.

In closing I would like to emphasize the importance of Thrive’s broader community. It is extremely helpful in the development process to have people to test the builds we release and give feedback, so thank you to everyone who has done that in the past. Also it’s great when people suggest ideas for the game and offer their thoughts on features we are planning, it enriches the process greatly. We are lucky to have a good community so thanks to everyone who is part of it. Remember to join our community forums so you too can participate:

That’s all from me, remember, having a good method is the first step to getting good results.