The Story of Ocean Town
Inspiration
As a group, before the event started, we wanted to tackle a social issue. Our first idea was "How can we make a positive impact on women's experiences with medical professionals?" We came up with some really broad ideas before the competition, and that was the winner among us.
When the idea "Reinvent the Wheel" was announced and expanded upon, that changed our direction completely. We still wanted to address a social issue, and we spent the first hour debating topics, finally settling on climate change.
Among our peers at college, climate change and its effects are widely accepted as factual, supported by numerous rigorous studies. However, some people in the United States believe, with certainty, that climate change is not real, and when presented with studies put their heads in the sand, unwilling to budge.
And we decided that, to reinvent the wheel, we needed to come up with a way to start a dialogue with these people, gently introducing them (on a super simplified and broad scale) to how our choices today impact the environment. We tried to abstract the fact that this game is about climate change, so people who play it see first-hand what they are doing to a (virtual) environment. We hope it sparks thoughts and dialogue around these actions through critical thinking. This gives them a safe space to explore what it actually means for climate change to exist without being told to read complicated papers or being told flat out that they are wrong.
We also did our best to research the effects of deforestation and oil mining (for simplicity's sake, we only considered these factors) on air and ocean quality, and how that, in turn, affects the population.
What it does
Ocean Town is a web application game that uses a dialogue system not unlike "The Oregon Trail" from ye olden days. You make a couple of decisions for each unit time (most likely a year), and once those decisions are made, the next year/day approaches, and you see the effects of your choices on your people (their happiness), your deforested area, oil production, and ocean and air quality (which affect happiness).
For the demo, we chose three units of time, but it can easily be expanded to more.
How we built it
We used React and TypeScript front-end to manage the state and animations of the game, making it a light, fluid UI/UX. We then built an SQL database hosted on a Microsoft SQL Server to hold the game data. The backend was a RESTful API built in C# and .NET. React then made async fetch calls to and from the backend to update the game state in the database and run the simulation engine.
We decided, for an extra layer of complexity, to make the simulation engine system agnostic. So, in theory, you can use any set of modeling equations you want and hook up a front end to run the simulation. This was achieved by storing an equation as a string and the variables as parameters in the database. Those are transmitted to the front-end, which digests them, and based on the player's choices, sends back modified numbers for the engine to run. The cycle then repeats ad nauseam.
Challenges we ran into
As always, setting up the environment in which you build your code is the hardest part. Besides that, we had trouble with some of the logic of the engine, supplementing our coding skills with CoPilot to flesh out mathematical ideas we had either not known or forgotten.
On the front-end, we started in JavaScript and transferred to TypeScript, having to convert JS to TS, which some of the members did not have a lot of experience with. The UI/UX design was a challenge, which is always to be expected. There are professionals whose job is to design user interfaces, and we are by no means professionals in that regard.
Accomplishments that we're proud of
We are proud of the UI/UX. A lot of work went into the design and a lot of revisions. The engine did end up being system agnostic, and that was quite the achievement, building a database that can handle the flexibility you throw at it. The one limitation is that right now, it calculates one day at a time, so if you have functions dependent upon one another, and you want to update the game state between each function call, then you need to be careful about function dependencies, as a cycle will break it at this moment. That is easily solved with a little elbow grease, but we didn't need that functionality, so we left it out.
What we learned
We learned about many design principles of both the front and back ends. Architecting projects is an art, which is why managers and seniors run that show. If we were to do it again, I could see us chasing an engine that is not system-agnostic and increasing the complexities in other ways.
What's next for Ocean Town
Ocean Town has many pathways it can take, and one of those is increasing the granularity of what we do with it. Adding jobs and an economy model, other types of pollution, and other beneficial and harmful events to the environment. Extending the game to have more interesting gameplay with characters to interact with would probably be a decent step, too. There are many directions to take it, we just have to decide which is the best path.
Log in or sign up for Devpost to join the conversation.