The road to our second game, part 1

"Having an idea for a game is easy, but making the game is hard" is a phrase that I have heard many times from other game developers.
I don't think that's entirely true. For me, I find the "having an idea" part is hard as well - or at least having a good idea is.
Making a game can take many years. I want to work on games that excite myself, and that keep me excited for all these years. We're working on our games as a team, so everyone else needs to be excited to work on it too!
Also, you need to eventually sell the game, so it should be something that gets players excited as well! To do that it probably helps to be something somewhat unique that stands out from other games, maybe with a cool art style or a unique setting or some clever gameplay ideas.
Oh and it also helps to somewhat predict what the market is like when your game finally releases. Maybe everyone is super into deck builder farming games with puzzle mechanics now, but what about in a few years?

So, that's all a bit overwhelming, but you need to start somewhere, and we do that by building prototypes.
A prototype is a small, fairly unpolished slice of what could eventually become a game that is supposed to give you some ideas about what does and doesn't work. We only want to invest as much time into them as necessary.
It could be for testing many things, like the gameplay loop, or a single game mechanic, or a technical detail.

Once Parkitect 1.0 was released we started working on a few different prototypes in parallel to working on the Parkitect DLCs and multiplayer update.

They aren't pretty, but I thought it would be interesting to take a look at them!
Here's the first one, and we'll show others in future posts.

Town Builder

I really love games with lots of tiny people running around and doing their thing in the environment you've created for them.
I also enjoy working on games that have lots of simulations and systems interacting with each other in some way.

So naturally it made sense to give another management simulation game a try, and I thought a town builder would be a good idea - I've always wanted to make one and had prototyped 2-3 different ones before. They never got very far, but maybe this time things would work out :P

There was no clear idea for what the game would be, other than a town builder - so there was no setting or theme or gameplay mechanics. The goal of the prototype would be to figure out what we like and dislike in a town building game, and hopefully along the way it'd give us some inspiration for answering all these other questions.

It was pretty much a very basic version of Settlers III, with stacks of resources, buildings that create and request resources, and people running all over the place transporting the resources around.
Obviously it would have been fleshed out eventually to turn into something more unique, but the goal for this was to figure out whether this alone is interesting and fun, and what the technical challenges would be.
To learn some more new things that we didn't already know from Parkitect, there was no grid in this prototype, buildings could be placed and rotated freely however you wanted, and we wanted to have a large, smooth terrain.

What we learned

  • distributing resources between buildings in a way that makes sense is quite challenging because there's so many things to consider! You don't want workers to walk from one end of the world to the other just to deliver something. Ideally a resource should get picked up by a worker who is fairly nearby, and get delivered somewhere that isn't crazy far away. At the same time though this could cause some buildings to never receive resources, which feels wrong. Also, maybe some buildings are more important than others because they produce something essential, so probably there also needs to be some priorities for that?
  • having a large, relatively complex area to pathfind across seemed challenging but there are already some good solutions for it that work well (i.e. Navmeshes)
  • simply plopping down buildings everywhere if you have unlimited space and can place them freely however you want is not very interesting. It gives a lot of freedom in how you design your town but if you always have room to squeeze in a building pretty much wherever you want it feels like you don't have to put a lot of thought into placement

Five years of Parkitect!

Parkitect 1.0 was released on November 29th 2018, which as it turns out is 5 years ago tomorrow!
It's a bit scary to think about because it doesn't feel that long ago, but it's also a good opportunity to celebrate a bit.

We'll host a livestream on Twitch and Steam where we'll play the game for some time. If you want to come hang out a bit with us that'd be fun!

Parkitect 5th Birthday Stream


We'll also do a reddit AMA. If you ever had a question about Parkitect or game development we'll try our best to answer it!

reddit AMA


New logo, new website!


You haven't heard much from us for quite some time now.
One part of the reason is that we simply didn't have a good place where we could share what we're working on. It didn't feel right to post non-Parkitect things to the old Parkitect Tumblr devlog.
So, to fix that we now have as a hub to Parkitect and any future projects.
The old Parkitect website was in desperate need of a refresh anyways, so we took care of overhauling that at the same time.
If you've been with us for some time, you'll remember the Parkitect devlog as well. We've copied it all over from our old blog so you can still read the old entries and take a look behind the scenes.

Another reason is that there simply wasn't too much to share, but that's slowly changing now as well.
After completing the two Parkitect DLCs and the Multiplayer update we started working on a couple of prototypes for different games, until eventually arriving at one idea that worked and that we liked. We've been working on that one for about two years now and there's still a long way ahead of us to get it finished, but it's making good progress and we're super excited to show you what it is sometime next year.
I really enjoyed doing the devlogs for Parkitect and think the feedback all of you gave us throughout development contributed tremendously towards making it a better game. I would love to do the same for our new game once it has been properly revealed what it is, even if we didn't document its development from the very beginning like we did with Parkitect.

Since we don't really have any other good place for discussions currently this new site has a comments system for the blog. It's sort-of experimental. Hopefully the login requirement will keep it friendly and the spam away. We'll see! We are keeping an close eye on them in any case, so anything posted there is guaranteed to be seen by us.

Figuring out what our next project should be after Parkitect was surprisingly difficult!
Over the next few months I want to write some posts that'll give a look at the prototypes we made, and what did or didn't work in them.

New Texel Raptor logo

Finally, it was time to give our logo an update! It looks like this now:

It was designed by Colby Nichols (can't recommend him enough, he's awesome!)

We had a bit of fun with creating an animated version of it as a new loading screen for Parkitect. It'll be in the next patch update.

Parkitect development in numbers

I always find statistics posts about projects interesting…
We’ve been working on this for almost 7 years now, so here’s a bunch of numbers about Parkitect!


Engine: Unity
Programming language: C#

Asset folder (the actual “content” of the game):
3.93 GB
Files: 35,944
Folders: 1,322

Total project folder (this includes Unity cache files etc):
Size: 21.6 GB
Files: 364,258
Folders: 2,837

Build duration (all supported platforms together): ~20 minutes (incremental build; a clean build would take 1-2 hours)


Type: Git
Size: 3.5 GB
Branches: 90
Commits: 13,778 (a “commit” is a change to the game, like for example the addition of a new feature or a bug fix. It can be anything from a single number being changed in the code to the addition of hundreds of new sound files in one go)

Here’s a visualization of all the file changes made during development.
Every dot represents a file in the project. A file getting zapped represents a change to that file. Every branch represents a folder in the project (with the folder name being shown as text).
The legend on the left side explains what the colors mean, and how many files of a certain type there are in the project.
The most important file types are:

cs: C# source code file
prefab/asset: Unity data files
fbx: 3D model
wav/ogg: Audio files

We moved the repository in 2017 which messes up the visualization a bit.

File changes by release:
Multiplayer: 7,230
Taste of Adventure: 6,404
Booms & Blooms: 5,117


This only includes our own code, not engine or other third-party code

Size: 7.44 MB
Files: 2,112
Folders: 138
Lines: 241,156

Biggest files (Top 5):
Park.cs (3,737 Lines, contains a bunch of data + methods related to stuff belonging to the park)
2.: MultiplayerController.cs (2,946 Lines, base class for multiplayer related code)
3.: TrackBuilder.cs (2,461 Lines, handles most of the track building UI)
4.: TrackSegment.cs (2,335 Lines, contains methods for positioning trains and connecting multiple segments to a full track)
5.: Attraction.cs (2,192 Lines, base class for handling user interactions when building things in the game)

Lines of code by topic (Top 4):
1.: Attractions (40,828 Lines)
2.: UI (35,915 Lines)
3.: People AI (13,607 Lines)
4.: Multiplayer (11,123 Lines)


3D models:
Size: 221.49 MB
Files: 2,276

Size: 227.07 MB
Files: 961


Sound files:
Size: 2.52 GB
Files: 4,789


Updates released on Steam: 533 (in addition to the regular monthly updates we like to patch immediately if there’s anything that might be inconvenient for players. There’s also many non-public updates though for testers)