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.

 

The Unreal Forest: step 6

Even if progress is made more slowly than we would like, remaking The Endless Forest only becomes more exciting every day. In no small part thanks to the enthusiastic support from the lovely community of players.

We have added and tweaked forest magic, most visibly the ability to pick up flowers from a patch of hyacinths and give them to another deer. This required creating a new system for growing hyacinths, much like the one for creating mushroom circles.

After some searching through our archives, we collected the assets that make up the floor of Phase One of The Endless Forest: meshes and textures. We adapted them to the new tiling system we had created earlier, the system that makes the forest seem endless, and implemented it in Unreal Engine. Back when we had created this floor, shaders barely existed. So we had to come up with all sorts of tricks to get the look we wanted. Since the floor is very big, we needed to tile textures that are much smaller but we wanted to prevent all too visible repetition. And then there’s, of course, the shadows and lights which are also textures. Amusingly, some things that we had set up in the old game but didn’t quite work, now do! The new Endless Forest will not look the same as the old one. But instead of striving to get as close as possible, we will use the new technology (and the old assets) to create something equally beautiful.

Setting up the ground also required the deer to walk over hills and down valleys. We initially set up a system as in the old game that basically checks where the ground is below the deer and then moves the deer there. But then we realized that, as opposed to the old engine, Unreal has a physics simulation built in. So we are now simply using the built-in gravity simulation to keep the deer on the floor. This may break the old bug that allowed some deer to fly. Sorry about that.

We are making maps of the old game to use as a guide for placement of trees, plants and flowers (like the hyacinth patches). We want the forest to feel familiar. But it is virtually impossible to make an exact copy. The systems we used for doing that are integral to the old engine and very opaque. So we’re making an artistic copy rather than an exact one (something like landscape painting). The atmosphere will be the same and things will be more or less where you expect them.

Major features will, of course, be placed exactly where they are now. We found the meshes and textures that make up the church ruin based on the floor plan of the former abbey church in Ename where The Endless Forest was launched. So we created the appropriate materials and implemented it in the remake. It’s good to see it again (although it’s a bit embarrassing to be confronted with the amateurish way it was modeled!).

Remaking things in a new engine is turning out to be a lot more involved than we had anticipated. We have a pretty good system now for retrieving assets. But every element in the game needs to be first researched in the old engine and then rethought for implementation in the new one. Not only does Quest3D work very differently from Unreal Engine, we have also learned a lot about using videogame technology in the past decade. So we want to apply that knowledge. Towards optimizing the game’s performance, for instance (which is the primary requirement for future expansion). Even though I remember struggling over some systems back in the day, sometimes it seems that it takes even more time to re-make them, despite all our experience.

Another reason why progress is slow is that we are also not the young eager game developers that we were back then. We no longer make ourselves sick by working 14 hours a day. We work more efficiently now but that may not make up for raw energy.

And then there are all the other things that we do. We don’t focus on single short-term projects anymore. But instead, we work simultaneously on multiple projects that span many years. One of those is Auriea’s full-time job in the Kunsthochschule in Kassel. Another is Cricoterie, a VR project that will launch in September… until that happens, work on The Endless Forest will be on hold.

In November, on the other hand, there’s a festival in Scotland where The Endless Forest will be featured! It’s organized by some of the people that made the Halloween features in The Endless Forest possible. And this time too, it was they who complete the Second Decade budget. They are interested now in showing both the current game and the remake, in whatever state it will be. We will want to pour some energy into the project to make a good show.

So, expect much excitement in November!

Have a lovely Summer.

―Michaël & Auriea.

Cricoterie: a virtual theater of death

Virtual Reality is bound to die. We don’t believe that the technology can survive in the current sociopolitical context. That’s why it provides a perfect medium for a project inspired by theater of Polish artist Tadeusz Kantor (1915-1990). He referred to his work as Theater of Death. Is there a better way of describing Virtual Reality?

Cricoterie is named after Kantor’s theater company Cricot 2. It does not aim to reproduce any particular play or represent Kantor’s work in some way. But it is inspired by his spirit. And many elements are directly taken from stage props and characters that recur in his plays.

It is especially the license to be completely sincere that excites us. A sincerity that exposes its fragility in the absurd and the ridiculous (“cricot” is the reverse of “it’s a circus” in Polish). Kantor’s work is haunted by death and explores the ambiguity offered by the stage between living actors, static characters and limp mannequins. This haunting was illustrated acutely by the director’s persistent presence on the stage during each play. He seemed to surround himself with spectacles from his memories and dreams, a sort of self torture in an desire for catharsis, perhaps.

In Cricoterie the VR user performs the role of the director. Objects and characters are moved and manipulated by virtual hands to create dramatic scenes on a simulated theater stage. A wardrobe supplies a never ending stream of props. Every time you open its doors, a new element appears. Some of these are inanimate objects, others life-size ball-jointed dolls whose life-like eyes stare directly at you, all inspired by Kantor’s world.

Cricoterie in its current state

In computer simulations such as those presented in Virtual Reality objects are neither alive nor dead. The wooden cross is as alive as the marching soldier. We emphasize this in Cricoterie by driving all animation with physics simulation. The awkwardness of the motions and the many errors this produces greatly intensify the tragedy.

Art residency in Kantor’s former summer residence in southern Poland

The initial prototype for Cricoterie was created during a residency in Kantor’s former summer home in Hucisko, near Krakòw. This VR prototype consisted of a wardrobe on stage from which the user, equipped with VR motion controllers, could grab objects such as a cross, a chair, the bride and a soldier, and move them around on stage. Over the past few weeks, we have added a cage, gallows and a horse skeleton in a wheeled frame (all directly taken from original stage props). A major addition to the interaction in the piece is scaling. By holding a button on the VR controller the scale of the world is increased or reduced. This allows the user to move around with giant steps. And when holding an object while releasing the button, the object retains its relative scale and becomes either tiny or gigantic. The effect is astoundingly dramatic in virtual reality, and almost imperceptible in screenshots.

Tadeusz Kantor: Impossible Monuments (1970)

Cricoterie is an incredibly satisfying project for us. Not only because of the subject matter and the technology but also because of the way we are approaching production. We work more slowly now than we did when we were making videogames (a necessity for our health). This provides a real boost for both motivation and inspiration. We also work “without a script”. Rather than breaking our heads over a grand master plan and then producing many little puzzle pieces towards a glorious end result, we allow the prototype to inspire us and we work in collaboration with the actors and props on the virtual stage. There’s a certain mood that we do strive for, certain rhythms and flows that we want to implement, and long lists of ideas. But we’re not forcing anything. And ideally, for us, this project would never end, and we would just present different stages in its evolution to the public. This permanent state of unfinishedness seems highly appropriate for interactive art, where it is the spectator who creates the spectacle. In this sense, Cricoterie is merely a toolbox, a playset. It’s a stage with props and actors. And you have to make the play.