The Unreal Forest: step 13 – it’s Easter!

In this step we implemented a major feature on our way to a full remake of The Endless Forest: database connectivity. And we have released a new pre-alpha build of the remake that includes the appearance perks for the backers of the crowdsourcing campaigns, including the new Tin Deer set. All backers should have received an email with a download link. If you haven’t, please email us.

Oddly, Unreal Engine does not come with a straightforward way to access web-based data. But through a plugin called LE Http Request we could access the Endless Forest database in the same way as we do in the current game. So we started building the options menu of the game with the Network section to log in with username and password. When a login is successful, a code is received from the database that represents the deer name, or pictogram. In Unreal we created a shader to convert this code to a unique pictogram for each player.

Another code received from the database represents the appearance of the deer: antlers, mask, pelt and body. So we added logic to parse this code so that the avatar looks the way it did when its appearance was last saved. Since the new and the old game share the same database, an appearance saved in one can be loaded in the other. So to flaunt your well deserved perks in the current game, you need to acquire the mask, antlers and pelt you would like in the new pre-alpha build of the remake and save your appearance to the database in the Network menu. Then when you log into the current game, your deer should look the same. But first contact us to let us know the account name to which the perks should be applied. Otherwise it won’t work.

Everybody loves the Tin Deer! On Instagram it became our best like post ever.
Everybody loves the Tin Deer! On Instagram it became our best liked post ever.

The Tin Deer was created to celebrate the ten year anniversary of The Endless Forest. Only Indiegogo backers of 10 Euros or more can get the new antlers, mask and pelt. Forest Lovers of 100 Euros or more get access to the Valentine set and Forest Believers of 300 or more can get the Golden Pelt for their deer. The latter two are still available via the fundraising campaign. When saved in the remake, they will show up in the current game too, including the new Tin Deer set.

To facilitate playing together we have also added the display of the pictograms in the border of the game, so you can find each other easily.

The game also saves your login information to disk and logs you in automatically on startup. And we have added a way to shut down the game which also saves your login data before quitting.

We tweaked the color of the ground a bit. There’s no way we can make the game look the same in Unreal as in Quest3D, the old engine. But we want it to look good in and of itself.

And of course there were a million other things that happened. Some tiny things that take days to figure out. Others huge finished in a few minutes.

We have been working hard on the remake of The Endless Forest over the past months. But as you may know, the estimated time budgeted for producing has been exceeded quite a bit. This means that we are funding the remainder of the remake ourselves. Every contribution to the ongoing fundraiser helps, but sadly it’s not enough. So regrettably we need to take a break now and work on some other projects before we can continue remaking The Endless Forest. But don’t worry. We’re getting there!

We hope you enjoy the new “Easter build” of the remake-in-progress. It’s still a bit early for actual bug reporting. So please ignore the many little errors. Just restarting the game solves most issues. If you would run into a serious problem, please send us an email with the steps to take to replicate the issue (we deeply appreciate the time you would put into this).

Thank you all for your support, encouragement and patience.

See you in the Forest!

—Michaël & Auriea.

The Unreal Forest: step 12

The focus of this step has been changing the weather and the time of day in the forest.

To trigger these changes in the forest, the building of the interface for Abiogenesis has begun. Changing the time of day involves changing the color of the lights but also some materials. In the original game the color of almost all materials is changed but in Unreal only a few are needed to achieve the desired effect. Some other things change as well when the time of day changes: instead of butterflies, fireflies appear above flower beds and instead of doves, swarms of bats fly overhead. The sound changes too when night falls, both the general atmosphere and specific sounds of nature are different. All the sound files of the old game were reused.

Changing the colors for the time of day worked out okay with Unreal’s standard atmosphere system. But to approximate the subtlety (and complexity) of the original game when changing the weather, a new system needed to be built that allowed the reuse of specific colors and numbers in the old game. With the colors of sky and lights in place, it was relatively straightforward to implement the particles systems for rain, snow and mist, using the original textures (although the resolution of snow was increased). And to replicate how the sound is affected by weather changes.

When comparing screenshots of the old and new game, it became clear that our camera setup still didn’t match the original game. As it turns out, the field of view in The Endless Forest is exceptionally narrow. I think we chose to do this to reduce perspective distortion of the tree trunks. A more narrow view also means that the camera needs to be further away. This change required all sorts other tweaks to sound, particles systems, and so on.

Implementing time of day and weather took a lot more effort that anticipated. But I’m glad it’s done. And I love how it looks.

Thank you for your support!

— Michaël Samyn.

The Unreal Forest: step 11

January has been a month of steady progress in tiny steps. In preparation of the expansion of the forest, I have fixed a number of bugs, tweaked a few features and added some pleasant details.

Unreal Engine is completely designed for multiplayer (match-based multiplayer, not the server-based multiplayer required for The Endless Forest, although there is a lot of overlap on the client side). As a result it is in fact a little tricky to make things happen only on the individual player’s computer. This is why in the current alpha, the dance music is such a jumble: every player starts a new iteration of the song. I think I have fixed this now, but I haven’t tested it in an online context (which is surprisingly hard to do in Unreal Engine). The video was recorded with two clients on a single computer (so the music still sounds messy).

In the same vein I have set up a system for local effects and added the floating particles to it. And I have implemented the falling leaves (with procedural animation rather than baked), the flying doves, and the scurrying squirrels. All of these happen only on the local player’s computer. For performance reasons and also because it would make quite a mess when many deer gather.

The motion of the deer avatar has been improved, especially when walking towards a destination such as another deer or a tree to rub. But this might need another pass. I have also removed the bug that would allow the deer to try to rub against grass and ferns next to trees. And two deer should find each other now when sniffing.

The flower antler spell casting has been fixed so that you don’t keep the flowers after giving them away. Some hard edges of tree trunks have been smoothed. And the initial camera view doesn’t end up in the floor anymore.

None of this is very spectacular but it all needs to be done. And better now than when the forest gets bigger, multiplying the problems. We will need to step up the pace a bit if we want to achieve our goal of finishing the remake in the fall. Hopefully that will be possible.

Thank you all for your support. Please spread the word about the fundraising. Since this is taking longer than we had estimated, we could use some extra support.

— Michaël Samyn.

I wrote a book!

At the end of 2017 I decided, as a New Year’s resolution, not to tweet in 2018. Instead of posting to my @MeneerSamyn account, I confided my thoughts to the iPad Notes app or to Google Keep. I have now collected and categorized the notes and published them as a book. You can download the PDF here. Or buy a hard copy at Blurb.

I will no doubt continue not using Twitter next year. I didn’t miss it. And I very much enjoyed taking notes without pressure and then reading them later. I hope you enjoy it too.

—Michaël Samyn.

The Unreal Forest: step 10 – it’s Christmas!

We have managed to create a dedicated server for the multiplayer functionality in The Endless Forest. A client to try this out is available to backers of the fundraising campaign (*).

The process of creating a server for a multiplayer game in Unreal Engine is severely complicated by the fact that this requires a C++ version of the project and a custom build from the source of the editor. Here’s the steps that I took to make it work (some arrived at through hours and days of trial and error).

  1. Do the following on a solid-state drive as many of the steps are long processes that involve much read and write activity.
  2. Download and install Microsoft Visual Studio 2015.
  3. Download the Unreal Editor source files from Github.
  4. Compile Unreal Editor in Visual Studio 2015.
  5. In game project’s Config folder, edit DefaultEngine.ini to set “r.PostProcessing.PropagateAlpha” to “0” as the default setting of “false” makes the build fail.
  6. Open a copy of the game project in the newly built Unreal Editor, package the game and resolve errors until the build succeeds.
  7. Apply the same fixes to the original project but don’t build it.
  8. Open the game project in the source editor and add a dummy C++ class of “None”. This will create a bunch of files and end with opening the game project in Visual Studio. Wait until Visual Studio is done parsing and scanning thousands of files.
  9. Close the Unreal Editor. Close Visual Studio.
  10. In the project’s new Source folder, create [game name]Server.Target.cs (**).
  11. Double click [game name].sln to open it in Visual Studio. Wait until it’s fully loaded and done scanning and parsing.
  12. Build the game client in Visual Studio. We will not use it. So maybe this step is redundant.
  13. Run Engine\Binaries\Win64\UnrealFrontend.exe and create and launch the project to create the game server. If UnrealFrontend does not exist, build it after loading UE4.sln in Visual Studio.
  14. Open Unreal Editor (built from source) and create a build package. Make sure all maps are included in the package settings array.
  15. Copy [project folder]/Binaries/Win64/[game name]Server.exe to [builds folder]/[game name]/Binaries/Win64
  16. Make a shortcut to the server and add “/Game/[mapname] -log” to its command line.
  17. Run the server and some clients to test if it all works.
  18. If the server complains about missing files, install the C++ runtime and copy any required DLL files to the server machine.
  19. After all this your 500 MB Blueprint project will have become a 16 GB C++ project. So have a lot of free disk space!

It took us two weeks to build a functioning dedicated server from a project with perfect multiplayer functionality in the regular Unreal Editor. Mostly because many of the operations take a long time and Unreal C++ project folders are huge and contain many files, making everything take long. Since testing within the editor is inconsistent, for each change one has to go through the entire cycle again. Here’s to Epic including server building in the Unreal Editor by the time we start beta-testing!

If you are a backer, thank you, and download and try out the game. We’re curious how it will fare when larger numbers of players use it.

Merry Christmas!
Happy New Year!

— Michaël Samyn.

(*) Send email to The.Endless.Forest at Tale-of-Tales if you are a backer but did not receive the download link. There’s still some major bugs (sometimes the client starts with the camera in the floor and when a player leaves, their deer body might fuse with another’s). Restarting the program usually fixes this. If automatic connection didn’t work or the connection is lost, you can try connecting again by pressing the Enter key.

(**) The text for [game name]Server.Target.cs is

using UnrealBuildTool;
using System.Collections.Generic;

[SupportedPlatforms(UnrealPlatformClass.Server)]
public class [game name]ServerTarget : TargetRules
{
       public [game name]ServerTarget(TargetInfo Target) : base(Target)
       {
        Type = TargetType.Server;
        ExtraModuleNames.Add("[game name]");
       }
}

The Unreal Forest: step 9

We’re making steady progress remaking The Endless Forest in Unreal Engine.

Over the past month we have added the idols, the graves and the mysterious cage to the church ruin area. We have added the ambient forest sounds and sounds and dust to the deer’s running and braking (and sniffing!). And we have increased the running speed to match the current game.

The deer now also jumps over obstacles and can hop either by pressing a button or a key or automatically onto certain objects.
We have added the audio and visual effect when running through trees as well. And poppies can now also be picked up and worn in antlers. And butterflies now appear above flower patches.

The interface was also improved. The cursor now remains visible. The camera zoom path has been tweaked to be more similar to the original. This can now be done with the scroll wheel too. And the action bar can now be scaled. Just like the border where we have added the little icons to point at the directions of landmarks and other players.

And last but not least, we have added the visual effect when deer intersect with each other.

Many of these elements were implemented in a completely different way than in the original engine. But we strive to make them look as similar as possible. And hopefully with improved performance.

With all this Phase One is almost complete. I will be looking into networking over the next weeks.

We hope you will enjoy the upcoming holidays in The Endless Forest. They may be the last in the original game. If all goes well, touching wood.

 

—Michaël.

The Unreal Forest: step 8

In the run-up to the presentation at the NEoN festival in Dundee in Scotland, we have made The Endless Forest extra pretty. Almost all of the vegetation of Phase One has been implemented in the Unreal remake. But not quite in the same way as in the Quest3D original.

In Quest3D we used a feature called Nature Painting to plant trees and flowers in the forest. Unreal Editor has a similar feature but it doesn’t work with the way we have set up the tiling that is required to make the forest endless. So we had to come up with an entirely new strategy.

After retrieving the final versions of all the 3D models and textures from our old archives based on hints to file names left in the old game code,  we carefully examined the layout and distribution of the trees, plants, logs and rocks in the original game. And then we used a combination of deliberate placing and random generation to create a forest in Unreal that feels similar.

By highlighting objects in bright colors and replacing models by simple shapes in the original Quest3D editor, we were able to distinguish where trees and plants are supposed to go.

An interesting side effect of the procedural method used for distributing foliage is that it is very easy to change the density of the forest, even while the game is running.

Not that we want to implement this right away as we are keen on replicating the original game as faithfully as possible. But this does open up new possibilities for the future.

 

Thank you to all the people who have donated to make this remake possible. We’d love it if you could join them since we have sadly grossly underestimated the effort this remake takes. Also thanks to all those who faithfully contribute to the monthly costs of the server.

If you happen to see us in Dundee during the NEoN festival, do come say hello!

If not, see you in The Forest!

 

—Michaël & Auriea.

The Unreal Forest: step 7

Just a small update to let you know that we have added the buttons for Emotions and Activities to the remake of The Endless Forest in Unreal Engine. And of course all the animations that they trigger, including the dancing. The dance music gets a bit mangled in the video because it’s recorded from two client games running on a single machine. But it works!
Also, but hard to see in the video, we have added all the morph animations for blinking, laughing, sticking your tongue out, etc.

The Endless Forest will be featured in the NeON festival in Dundee in the beginning of November. This festival is organized by some of the people that made the addition of our beloved Halloween event possible. We hope to get a lot of work done before then.

Programming freedom

While remaking The Endless Forest I am becoming acutely aware of how much I have learned about programming in the 13 years that have passed. The new Unreal engine is much more conventionally structured than the old Quest3D ever was. So part of the different approach to programming is determined by that. But there’s something incredibly refreshing about the way I programmed The Endless Forest as a complete amateur.

Over the years I have learned what I assume is good programming practice: to categorize problems and reduce the amount of different routines by collapsing similar pieces of logic. One could organize these categories of routines hierarchically so that subroutines can be children with functionality that the parent routine doesn’t have.

When Object Oriented programming was introduced in Quest3D back when working on the original Endless Forest, I had no use for it. Because I didn’t know how to program. Or how to program properly.

But The Endless Forest is a computer program. A multiplayer online game that has been running for twelve years and has been enjoyed by hundreds of thousands of people. It’s supposedly badly made. But does that matter?

The original Endless Forest is programmed in a rather organic way. There are very few shared routines. Everything is an exception. This means that every element in the game can have its own properties. So when we want butterflies on the flowers we just add them. When the candles need to switch on at night, we set that up. When birds should come sit on antlers we just program that in. None of these systems needs to fit anywhere else. Everything is unique.

In my current approach to programming, which I presume is more mature and more conventional (although far from expert level), it is hard to add such details spontaneously. Because everything is a category. It’s a sort of laziness: if I can design a routine that is used for multiple things, I can reduce the amount of routines I need to design. But adding functionality to such routines makes them less “elegant”, less clean. So I hesitate every time. I basically make my code look pretty rather than the game. Or I attempt to structure things so that the amount of bugs and the potential for crashes is reduced and performance and stability are improved. Rather than making the virtual environment richer and more beautiful.

Computers and the software we have to program them aren’t built for the sort of programming in the original Endless Forest. The game has never run very smoothly on anything but a hardcore game computer. But by adapting our designs to how the computer operates, we reduce our creativity. I have always said that computers were too slow for what I really want to create. Over the two decades I have been involved with them, despite euphoric enthusiasm about increasing gigaflops, they have remained too slow. Not only for what I want to create but also for how I want to create.

We will probably never have a programming environment that allows us to paint with code. The realtime visual flowchart interface of Quest3D probably came closest to that. But the program’s development stopped many years ago. And if it hadn’t, it would have probably become more conventional. When I stopped using it that had introduced arrays, object oriented programming and a separate edit mode. Useful, but in the end limiting for my sort of creative mind.

 

—Michaël Samyn.

On errors and objects

On the eve of the premiere of Cricoterie in Warsaw.

Computers have a reputation of being sterile machines that only do what you tell them to do. But anyone who has attempted to program knows that in fact they are wild animals that stubbornly resist taming. Software runs on a computer processor in real time. It does things on its own, such as responding to a user’s input. There is a tendency in computer programming to limit the inherent potential for autonomous behavior of software in favor of streamlining the experiences that its human users have with it. But computers are wild beasts and more often than not computer programs will produce errors or bugs. It is when such errors happen that we feel some of the energy that resembles life in our machines.

Inspired by Tadeusz Kantor’s leveling of the distinctions between props and actors on the theater stage, Auriea and I created a program that attempts to demonstrate this strange form of life that takes place on the computer’s processor. After all, every object in realtime 3D is made from the same material: vertices, edges, faces and textures can take the form of a table, a chair, a machine or a person. And yet I do not think of those objects as representations of objects in the real world. Instead I consider them to be objects in the real world themselves. What happens in the computer is part of the real world that we happen in.

Virtual Reality is a technology that allows us to physically enter the realm of software. As opposed to flat screens, VR does not require any imagination. It puts you right in the middle of the virtual world. You don’t need to imagine how big something is or how far away it is. You can simply see it with your own body as reference and walk towards it.

Cricoterie confronts you with objects derived from Kantor’s theater. The behavior of these objects is subjected to the laws of physics. Or at least to a mathematical simulation of these laws, in and of itself a computer program. As a computer program, this simulation is imperfect. It is similar enough to feel familiar to a human user. But things always go wrong. Objects do not fall correctly, they seem too light or too heavy, they intersect with other objects or start shaking violently. I did not program this to happen. But I embrace these errors precisely because they make the objects seem more alive, even if it is a sort of life that may seem alien to us.

 

I am very proud of Cricoterie. In the way that I might be proud of a pet or a child or a friend. As a creation it approaches more than anything I have made before my feelings about art that uses the computer as its medium. Not for the display of images or the reproduction of sound, or the entertainment of users. But as the creation of a form of life. Or, perhaps, the making visible to humans of the life that exists in cyberspace (akin, perhaps, to how Michelangelo may have felt about a sculpture being contained in a raw block of marble).

All of the environments and characters that Auriea and I have created in our videogames are dear to me. I do not think of them as pictures or symbols that serve the presentation of some concept or story. They are living beings that I am eager to observe and get to know. I delight in the errors that they make, the things they decide to do in spite of my sincere programming attempts to prevent them. To see someone play with Cricoterie is always an adventure. I do not now what is going to happen. And I am immensely curious as to how my creatures will treat the user this time.

This is not to say that there is no vital role to play for the human user. Cricoterie presents objects to you, objects often filled with cultural and social meaning, and lets you manipulate them however you see fit. It is in the confrontation with these objects and specifically in observing your own response to them that the art happens.

 

While I was creating Cricoterie, I was introduced to Object-Oriented Ontology. OOO is a philosophical school of thought that calls itself realist. By this is meant that, as strangely opposed to a lot of philosophy, it holds that objects exist even when humans are not interacting with them. And everything is an object. Thoughts are objects as much as cans of beer and rocks are. Even feelings, relationships and events are objects. Crucial to OOO is the rejection of the possibility to actually know all there is to know about these objects. Since that would reduce them to an existence that depends on human consideration. This stubborn existence of objects beyond our control demands respect.

Encountering these ideas explained a lot to me about how I feel about the software I create and the virtual objects in it. And also about why I consider this attitude a worthy aspect of art making. Apparently my ideas about software can be expanded to include the world outside of the computer as well. I have always considered the virtual and the real to exist in the same universe. But OOO helped my realize that this is not because the virtual resembles the real but in fact because, on closer inspection, the real resembles the virtual. To understand that this is not a degradation (from life to computer simulation) but rather an opening up to a much broader field of experience (somewhat reminding me of my brief encounter with Buddhism earlier this year) has been eye-opening.

The philosophers in the OOO school will probably scoff at this, but I very much enjoy the mystical qualities that even banal objects acquire in my eyes by existing beyond the grasp of humans. There’s a certain spirituality in this stubborn objecthood of things, a certain peace. If only because it allows God himself to return to our existence in the form of an object, next to all the other objects. Hello, God, how have you been?

 

―Michaël Samyn.