In the current games landscape, small teams are often inclined to use experimental mechanics and themes, sometimes resorting to procedural systems. These systems allow for generation and creation of content based on a designed set of rules. Endless survival games and other games with repeatable gameplay loops often emphasize systems like these to express the infinite replayability and randomized or sometimes surprising content.

From a development perspective, procedural content versus 'handcrafted' or designed content is an important spectrum to look at. With teams getting smaller and gamers getting hungrier, it's important to assess and appreciate what procedural generation can do for your game.

For Pine, we've heard our gamer audience use the word 'procedural' rather often - procedural world, procedural evolution, procedural crafting. In light of the controversial releases of recent games with procedural content, of which the recent No Man's Sky is a good example, we want to share more information about Pine's "procedural" or generative systems. What exactly is the procedural aspect of Pine?

Systemic content in Pine

In part, we are using procedural systems in Pine to help us develop more efficiently. These are systems that go through algorithmic procedures based on a set of rules to define the content. We use this to easily create assets during development, but we do not generate any content in Pine (in realtime). Our procedures are based on something we’ve created first - in the case of the island, it’s based on a pre-defined height map.


We created a heightmap first, a black-and-white image that can be read by our terrain system.


We then generate a mesh / terrain purely out of that heightmap. This is a procedural system, but without the randomness that’s often proposed in ‘classic’ procedural generation. We do this during development, so there is only one island.

Therefore, it’s good to steer away from the classic term procedural generation right away - instead, we often talk about systemic content.

It’s very important to stress that we don’t ever let our code create content that we haven’t defined ourselves. We design systems, and we let these play out and sort themselves out using the procedures we design.

However, our evolution system is far from a fully designed experience. We don’t dictate that the game develops into a certain direction after a specific amount of time, for example. So what is it exactly?

A simple box model

We often visualize it using a simple box - the game can ‘think for itself’ anywhere inside the box, but we design that area. We can easily look at it as a box with padding and margins (like in CSS):

• Core design: Creatures have a default, designed behavior, set up to be interesting within the combat we provide. We design a ‘critical path’ through the game, as being a ‘default’ experience.


• Design padding: Instead of defining that a species has 20 HP and 3 STR, we define that it can have 18-22 HP and 2-4 STR. This way, the starting situation can provide players with slightly different species, allowing for them to adapt to the ones the player is weak against.


• Possibility margin: Then, throughout the entire playthrough, these species and organisms evolve in different directions - we give them the minimum and maximum values so that they stay within the box.

For players, this means each individual organism within a species can look and act different, while all sharing the same basic behavior and culture. We set all of them up to do slightly different things and look different, based on individual personality and genes.

This model applies to everything we make - we always allow for change and adaptation, but define all the borders. This way we get a strongly designed experience that simply won’t break (never say never, but that’s the goal).





In other words, we design all of Pine - but rather than designing a static version of an enemy, we design a dynamic enemy. This way, we can populate Pine's island with dynamic species rather than the same enemy over and over again. It fits in completely with the adapting combat.

The ecological hierarchy

Players can therefore be better or worse against a certain genetic group within a species: if the more defensive personalities among organisms have a higher success rate against you, these will thrive and survive, based on natural selection. Visually, a certain color of organism might (coincidentally) be best against you, coloring their entire species more towards that hue.

This, in the end, leads to the ecological hierarchy in our game world. Players shape the populations on the island by empowering certain species and make others weaker. Species that are stronger against the player will appear more, while 'easy' species drop down, possibly even into extinction.

We visualize this in a few different ways, including their outfits. On the island, you will mostly see it in their ‘housing’. Instead of designing static locations for their living facilities, we place home sockets - points that can be filled in with any species’ home.



We can decide what type of house can stand where, so that it always looks good and handcrafted. Using rules and quota, we define how many are placed and in what combinations. Endless variety is possible, while it will always look right.



Again, we don’t generate content or procedurally create houses, but we procedurally (or systematically) place them based on a designed layout. Systemic content!

Producing a 'full' organism

For the production of our content this all means we start out with the outer box, including the padding and margin. We ask ourselves: what does a fully evolved species look like?



This is done for mostly animation and design purposes. Lukas, our animator, needs to animate for the most extreme of circumstances, so that no part of an organism's outfit clips with anything else. Design-wise, the species needs to work best when all their moves are fully 'unleashed' - because if the species has reached a high level in the ecology and thus appears more, gameplay with them should be perfectly balanced and extremely fun.

The key here is generalization. Instead of designing all these species from scratch, we spent a lot of time defining their absolute core, so that we could systematically figure out what we needed for each. We can make 12 completely different species, but first we boiled them down to their core.

Conclusion

So, rather than using procedurality to generate, we use it to amend. We believe strong content comes from well-thought out design, and if we would build a large framework that we could never test, being the small team we are, the results can be unpredictable and messy.

Our goal from the start was to design a solid base structure that could then be systemically amended and adapted to players. Even if players would do nothing or play exactly the same every time, the game should not break - because the game has a 'default' response for everything. But on top of that is a layer of content adaptation that is dynamic towards what players do, to make Pine listen to players as best as possible.

By not procedurally generating anything, we also keep full control over everything. The vision is to make Pine fantastic through memorable moments that emerge from systematic content.

After a few months of working seperately, as we discussed in a previous blogpost, we've now finally moved into a new office! It has room for the six of us and we're excited to be able to discuss Pine all day. Here's a picture!



We're still missing the mandatory whiteboards and hundreds of post-its, and we agree that it's a bit of a mess still, but it's a start!

We're working on a few things:

• Something big we'll announce soon! It involves a lot of prototypes, ideas and pretty assets.


• The Mountain Demo - we're perfecting the combat, adding a few new features and tweaking the overall experience based on the amazing playthroughs we observed at Indievelopment. It's taking some time, mainly because we're re-generalizing some of the systems, but it's bound to be better than ever.

Stay tuned!

Time for a little update: it is now July, and after having all graduated, it's time to go full-steam on Pine's bigger picture! A lot has happened online lately, so here's a little recap:

• A front-page featured article on Gamasutra about our findings from making the first Pine prototypes


• A nice in-depth interview on Pine with OnlySinglePlayer. The core ideas and general direction for the future are discussed! We also got the chance to talk about managing expectations and explain how we use the adaptation, as we've noticed some people think we have a fully, procedurally evolving ecosystem - which is not the case.


• We've been cross-posting the Pine blog on the MadeWithUnity website! This is the latest entry, which is slightly adapted to their website format. The MadeWithUnity team is ever so kind to share all of our posts and hopefully the blogs are at least a bit helpful to aspiring developers.


• We made a trailer for the upcoming playable build, The Mountain Demo:

Our current focus is heavily on making that demo better than ever. We want the adaptation to be more obvious and slightly deepen the combat with a few extra moves. The interesting part here is that it still remains a tech-demo: it does not outline the full game in any way. This demo is extremely linear and we encourage players to fight everything along the way, which is different from the more open approach we are bound to take with Pine later.

The demo will go out to all 2100 registered testers, and once we get all the feedback we'll polish the demo up even more - which we then use to make our future dreams a reality. We're talking with a few interested parties and some really interesting opportunities are arising! For this, we're completely fleshing out the game in terms of scope, story and mechanics, and we're getting some amazing new ideas in doing so.

On top of that, we'll be moving into an office starting in August: finally we'll be in the same room! Pictures soon.

Stay tuned, thanks for reading.

As a small team of five, tasked with proving something experimental when it comes to game development, we set out about three months ago to build a demo that would show Pine's USP in any form. This monday was the deadline for said demo, which we showcased at Indievelopment 2016 in Jaarbeurs, Utrecht, The Netherlands. Exciting times! For the first time ever, actual gamers we didn't know would get their hands on a full Pine experience that lasts between 10 and 25 minutes.



The day went way better than expected - we took home the Unity award for best Unity game and we've gathered a large batch of data to work with in the upcoming weeks. In this small blog we'd like to give a few bullet points of things that helped us create a demo like this while we were almost never in the same room during development.

• Weekly reviews: Probably our saving buoy during the asynchronous, hasty and individual development of parts of pine, were the weekly meetings of about 2-3 hours we did. It's very common in normal Agile game development, but as we didn't utilize a physical scrum it was quite difficult to maintain the tasks sometimes. However, once a week we would meet up and show each other what we did and what we were going to do. As we don't have an office, these hours were also good to just check how everyone's doing and if we're all still on the same line.


• Tight online planning using Google Docs and Sheets: In order to never forget anything, we decided we should write down everything, always, inside Google docs and sheets. Then, during reviews or Skype/Hangout sessions, we could discuss them. It may sound trivial, but it's insane how much information gets lost when you're not sitting next to each other.


• Work on the bigger and smaller picture in parallel: We were always building a smaller demo case next to the bigger demo to be showcased later. This allowed us to test things in small scenes (programmer Marc has a scene called the Lab in which he starts the creation of mechanics/species), while always keeping an eye on the demo that was to be showcased for an audience. Our environment artist would work a lot in the bigger scene while the others nailed the basics in smaller scenes. Quite effective!


• Quick decisions, quick iteration: We have a mantra that we really stuck to during these three months - iterating is easier than creating. Our goal is to quickly make SOMETHING, anything (within what we're trying to achieve of course), and collectively see what can be improved later. Again, sounds trivial, but too often someone gets stuck on a task because she or he wants to deliver it pitch-perfectly the first time around. That's not gonna happen, so put something in the game and we'll see what we can do to improve it as fast as possible.


• Make tools, not content: By building simple triggers immediately, Marc didn't have to be bothered with building events or hardcoding things into the game later. While he was working on small demo scenes with new mechanics, others could quickly iterate and make gameplay chunks using generalized tools/objects rather than scripted events (such as a simple activation trigger to turn on/off GameObjects). Think about this early (which ones you need, for example), it can save a bunch of time later.

To end this with something more visual, we share a video of the development process with you. Although we started out with gifs, making the video a bit wonky, it's fun for us to see the improvement over time. The video ends with parts of a walkthrough of the demo!