This is the first post in a series describing and documenting the development process of a personal project. The process, and the blog posts themselves, might be fairly unorganized, but I will try to build up a Github streak at the very least. No promises about regular blog updates. This is something I’m doing in my free time to have fun, keep my skills sharp, and learn new ones.
That’s a pretty liberating set of constraints. I don’t have to build anything useful; I’m focusing instead on silly and fun. That’s my jam. The idea itself is still in development, but I’ll describe the MVP I’m aiming for in this post. I’ll get more ideas as I work.
I want to be able to boot up my browser and explore a forest. I want to be able to walk through the forest and see what’s in each area. It’ll behave like a lot like text adventure, except for now it won’t have a point. Maybe a bit like Minecraft or Dwarf Fortress.
It’ll be a SPA with routing and all that cool stuff so that I can really get my React chops good.
The architecture is a Rails API back-end with a React + Reflux front-end. I’m currently working on how to create associations between a location and any of a list of objects.
Here are some stretch goals and general concepts: I want the user to be able to zoom in to any given object and get a nice amount of detail. I want that zooming to be what the user wants to do. A tree’s age, how many branches it has, and how it looks. The bugs that live on it. The color of that bug. The fruit. Maybe the forest will go through seasons. It’ll be fairly procedural and random generation, but I’d love to be able to reproduce some of the strange beauty of, for example, Minecraft’s landscapes or Dwarf Fortress’s histories and cultures.
At first, any number of trees or wolves will be able to exist in any given location, but I want to be able to add different kinds of objects to that list easily, without having to set up a has_many association in Location each time. This means using polymorphic relationships in the opposite direction than they are usually used. There might be a better way to implement this but I’m learning a lot by taking this path.
Here’s the Gist I read to flesh out my understanding of these relationships: https://gist.github.com/runemadsen/1242485
It’s complicated enough that I know I’m probably doing something unnecessary, but that’s okay for now. I’ll fix it if it becomes a problem. I’ll learn in the meantime.
Here are some questions I need to answer eventually, and just free form notes:
- How can I make it easy for myself as a developer to add new behavior and content?
- Especially keeping in mind that I want objects to contain other objects to pretty much arbitrary depth. There’s no reason the same kind of bug couldn’t be on a tree or wolf. Or on the ground.
- What will the front-end look like? I need to design and wireframe the UI.
- Will the user be able to destructively interact with objects, or will it be read-only?
- What will the API endpoints look like? Nested resources can quickly become a pain.
- What’s the best scheme for building JSON? Each model having a #to_json method? Keeping that logic somewhere else?
- What should I use to build JSON?
- Probably JBuilder
- What’s the most RESTful route for accessing a location object through its x and y coordinates rather than its ID? Should it be “locations/x/:x/y/:y”? No. What about “locations?x=4&y=5”? Maybe? But that base route is usually the #index method, when this is clearly a show page.
- How do we make this about storytelling later on? How to keep track of each object’s existence?
- Probably logging somehow.
- Gosh I should write tests.
- What will this app look like when it’s deployed?
- Do I want to deploy it, or should I just put it on Github and make it a “run Rails locally and play with it on localhost” type thing? I mean that’s a little lame.
- If it’s public then there will have to be users and multiple accounts, each with their own forests, and ughhh.
- Unless the whole forest is “read only”, then it CAN be deployed publicly! Nice. Fun.
- What’s the best way to have the world continue to “live” even when the user isn’t playing with it? Chron jobs? Separate processes?
- What if every relevant object had a #live! method that triggered it to make decisions on growth, movement, etc. And that #live! method is called on each living object.
- I like that idea.
Well that’s it for now! I should make sure to focus on getting some tiny MVP ready. Goodnight.