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.
4 thoughts on “Programming freedom”
I could perhaps force myself to program in that weird old way again, but I don’t think I can do it in the context of today’s conservative engines that demands categorization and limitation rather than abundance and spontaneity. It’s already hard enough to make these things going with the grain.
Hey M! Great to hear about the game updates.
I was wondering if you were ever thinking about adding a feature to the game that allows the players to pick up flowers with any kind of antlers they have on?
Personally I’ve always liked the idea of carrying the forest flowers with yourself, but it’s a pity that you can’t do it with the non-default antlers in the game.
I have not considered this. Such a feature would require extra flower shapes for each set of antlers. A lot of work that we would have to way against adding other features.
What I decided to hang my hat on in 2010 is a binary file that doesn’t have published source code for it, and even if it did, it would not be more useful than the artifact itself at this stage. It is like a core in the system. And I program my things around it. This is an alien way to go about programming, but I find it is actually very liberating, for a few reasons. One of them is you cannot approach any problem with the mindset of building some monolithic thing, because you can only do anything obliquely. It’s probably like you say, an “exception,” in every case. Serious developers might turn up their noses at the resulting code base, however in my experience, the best way to work is always with a scaffolding, and this is what it provides, and it’s humbling too stay with something that is a reliable hard core, which acts like a foundation. And besides, my experience as a programmer, which I am first-and-foremost, is code should always have a very light touch. That means its roots should be shallow and purpose oriented. Its hierarchies should be flat to nonexistent. What matters more than organization is its intelligibility.
My software is a tool like Quest3D for telling esthetic stories. It’s finally at a place that I myself am willing to apply it to one, at least partly, by preserving an old PlayStation game from 1995 that I want to give a second chance. The project files are backed up here ( https://www.reddit.com/r/KingsField/comments/9kj984/very_early_playable_section_of_kf2_for_windows/ ) and I will be updating the same ZIP file probably sometime in the next month with more content, including perfectly replicating the title’s color and 3-direction lighting. It has PlayStation VR support, and is open source, in case you want to add PlayStation VR to any of your works.