Intro

This post is mainly for reflecting on the decisions made during this project to take away lessons that can be used in future projects. For a description of the project and its development, check out EcoSim Timeline.

Lulls in Progress

As a whole, EcoSim took a little bit over a year. My first commit was on 5/22/18 and my last bug fix was yesterday, 6/22/19. So it pretty much took 13 months. Although I wasn’t working the whole time. There were a few things that came up that significantly stalled my progress for weeks at a time.

The first problem I ran into was not a technical one. A combination of me moving apartments and there being a massive heat wave that I had no AC for led to no work being done between 7/10 and 9/4. There are two parts of this that could be mitigated. First, when it came to being randomized by moving, I probably could have maintained progress better if I had been better able to split work into smaller units. While I might not be able to sit down for four hours to do a big feature, if I instead had planned in 30-90 minute units of work it might have been more reasonable to weave in work here in there even when I’m busy with something like moving. On the heat, I don’t think there’s any real planning mitigation there, I’m just gonna buy an air conditioner next time.

The second problem I ran into was related to the dynamic assets of animals. Oxygine was automatically clipping empty space out of art assets, which was messing with my plan to overlay different parts of the dynamic asset. I couldn’t figure out the relative scales and positions. It was made even more annoying by the different parts all being different sizes after clipping. Trying to get that to work got me really frustrated and I ended up not working from 12/4/18 to 1/4/19. A decent amount of that time would have been lost to the holidays anyway but not all of it. Embarrassingly I found a solution in the oxygine docs, a flag that disabled clipping of assets. Besides not reading the docs sooner and more thoroughly, I think my problem here was that I was fixated on a planned solution. It would have been better if I could figure it out with clipped assets, it would have been more efficient. But I wasn’t really thinking through other potential solutions because I had already planned a solution that relied on unclipped assets and I was tunnel visioned on trying to implement my plan.

The last big problem I ran into was when I finally got the simulation running for herbivores eating plants. Although it worked, it was very unstable. Animals would almost immediately eat the plants in their radius to death then die from lack of food. I significantly overestimated the range of values that would lead to a stable simulation and thought I would easily be able to get it to “good enough”. I think this could have been prevented if I was more thoughtful and realistic in the beginning about the amount of design work that would be required to get the simulation stable. Not wanting to deal with this problem led to no work being done between 3/11 and 4/22.

Pivot to Sandbox

I was talking to a friend of mine about my simulation instability problems and he suggested I pivot from trying to make a simulation game to just making a sandbox. Rather than implementing game type systems on top of the simulation, I would implement user facing controls to vary all properties in the simulation. I was hesitant at first because it initially seemed like it would require additional work. But I thought about it and came to the conclusion that the remaining game systems would be more work than making a gui for the simulation properties. This ended up being a great idea. It enabled me to actually finish the project. I don’t know that I could have pushed on with the current plan to do game systems on top of such an unstable simulation. It would have required much more design work in stabilizing the simulation that I was not at all excited to do.

Web Attempt

One of the reasons I chose to use oxygine was because it has a path to cross compile to javascript for web using emscripten. In hindsight, leaving this for the end was a bad idea. The emscripten compiler was different/stricter than what I was using so I had to fix new compile errors for a while. Eventually I got it to compile and launch in browser only for it to hit a javascript exception when starting to run. I worked my way through one or two javascript exception problems until I got to an error about emscripten linking. My ImGui OpenGL binding didn’t play nicely with emscripten and I would have had to change the binding to get web to work. This wouldn’t really be that hard and might not even be that time consuming but I just was not at all interested in doing it. I decided win32 was enough for now, as the goals I set out for the project were already met. In the future if I want a project to be on multiple platforms, I’m going to consider that in the very beginning and have a working web path to test each incremental change with. That being said, I may still revisit EcoSim’s web compatibility in the future as part of a project that ports this to multiple platforms for experience dealing with multi-platform.

Project Takeaways

Thinking about the past year working on this there are a few other conclusions I came to that might be helpful in future projects.

First, it was dumb to expect to be able to hand wave away the design work. I went in knowing there was going to be a decent amount of design work to do for this and that I wasn’t at all interested in doing it. Beyond just underestimating the scope of the work, even if I had been able to do it quickly with just placeholder values, I shouldn’t have started a large project where I had no interest in doing the a large chunk of the work for it. For hobby projects, I can work on whatever I want, so I might as well work on things I actually want to work on.

In that same vein, I don’t think I necessarily need to optimize project plans for potential learning value in the future. I wanted to use something where I could do almost everything myself in C++ because that would be the best practice but that definitely slowed me down. If I want to make a game in the future I’m going to probably just use an engine like construct or unity. Sure, I’d probably get more valuable learning from working directly in c++ again but hobby projects are in my free time so it seems fine to focus on doing things that I’m excited to do over focusing on doing things that will have the most practical/educational value.

Finally, I need to work on much smaller scoped projects in the future. I don’t want to be working on something for 13 months again. In addition, I need to be more agile in my development. Get a prototype or minimum viable product as soon as possible. The mvp of the simulation probably wasn’t done until like month 10. In the future, I’m going to try to work on a game that has a very small base of functionality that can be further built upon. EcoSim had a lot of different units of interdependent functionality which was not great for development.