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.