I made a freaking game! It’s a spooky, horror/sci-fi themed romhack for Super Mario 64 that came out a few weeks ago and Simpleflips already played it! It was made in collaboration with a friend of mine, Benjamin Wolf, and it took us about a month to complete. I’ve come to grips with the initial buzz for the game waning down to a slow trickle of interest compared to the attention it received in the first week of release. Now it’s time to look back on what I can take away from this experience to foster prosperity with future projects.
Given that this was my first game I’ve ever actually developed, I was pretty clueless in a lot of areas going into it. I had done my research and actively studied the games industry for over ten years. None the less, I was still surprised by how many design concepts sound simple on paper but in practice require more finessing than ever imaginable.
So for this list, I wanted to share the concepts I learned during development that I never want to forget! There’s 19 of ’em which is kind of a lot but I after reading, rereading and editing the list, I really don’t think I would be happy leaving any of them out.
Anyways, let’s dive in! No particular order but maybe leaning towards usefulness in beginning, middle and end stages of development.
1. At first, people around me aren’t going to care about the project as much as I do.
This one was actually kind of weird but also quite obvious. Nobody feels the same way as you about a project and you really have to accept that hearing, ‘I’m happy for you, keep it up!’ is most people’s 100%. Discord was such a great place to socialize with other designers during this whole process. I got to meet and chat with many different people who brought a bunch of new ideas to conversations.
I can talk design to a friend about as well as he can talk to me about raising his child. Neither of us really get it but we show support that’s really enough.
2. The more pre-planning the better.
My first draft of Super Event Horizon was about 80% different from the finished product. Initial plans fell victim to an unreasonable project scope while also lacking detail on how levels were going to look and function. The story was basically none existent until the day before our deadline, Ben added some Toads and wrote frightening dialogue for each one.
Designing without a true story in mind lead to thematic differences across many levels. Alterations were constant and there were even a few scrapped areas. This isn’t even including object placement, music, SFX; factors that make a HUGE difference in how a player interprets the experience provided to them.
Thankfully, every asset besides the levels, text and music we were able to lift from the core game — shouts to rom hacking. I’m very thankful we shipped a product that was met with praise because towards the end I was really starting to feel how carelessly pre-production was handled.
3. Romhacking’s accessibility exists solely because of the work of many smart, passionate programmers.
SM64 romhacking is pretty sophisticated these days. A lot of new tools have been developed in recent years that enable just about anyone with some time and effort make their own game. Tools like Rom Manager (thank you Pilzinsel64,) Seq64 (thank you Sauraen,) Cake Eater (thank you DeltaJordan,) and Flips (thank you Alcaro) were all critical in developing my romhack. These tools weren’t made by a company but bedroom coders who just wanted to see a specific program exist; I think that’s super rad.
I literally couldn’t have made my game without the people who made them. Thank you to everyone who’s ever been interested in the research and development of an old game like SM64.
4. Asking for help is often times the most efficient way to solve a problem.
At all stages in development, I faced errors that were very difficult to describe. Thankfully, the SM64 rom hacking community is super supportive and didn’t mind me asking vague, unclear questions. In the moments where Google couldn’t even point me in the right direction, there were real people on Discord to help.
Reaching out to people smarter than me has been my strongest tool when trying to learn/debug most things. No matter, there’s always going to be someone smarter than me and I love that. Be honest with your needs and trust the people you meet; I promise you won’t regret it.
5. Realizing that ‘someone is really going to have to make all of it.‘
By about the third, 14-hour day of mapping the first level of Hell, I realized that I was slow. So slow that at my current pace, I wouldn’t reach my deadline even if I never took a single day off development. It was only then that I realized setting the scope of a project shouldn’t be determined by one’s optimism but by their ability.
I think I cut 33% of the game’s content at that point, marketed up my calendar with minestones relative to the new projects and tried to make maps half the size of the one. Hell Grove took me close to 40-hours to complete which is it has 6 stars and is much bigger compared to other maps. I’m quite proud of Hell Grove and only regret that I didn’t polish it more! However, I chose to finish my game over adding more content. Super Event Horizon ended up still being massive, sitting at 30 stars exactly, so no worries.
6. Collaborating on even the simplest things needs great communication.
Ben has been a friend of mine for the last four years! He’s incredibly smart and self motivated. Despite him being very easy to talk to, I found it difficult to articulate my needs as a project leader for a variety of reasons.
At the core of this problem, I think I wasn’t prepared for the quality and quantity of leadership skills I needed to direct him in a manner that left both of us satisfied. He contributed the story and a couple levels but through out most of the development time, I felt like we were two Lego guys trying to piece together our ideas rather than sculpting them together.
Pre-production is probably another culprit here. Neither of us were too terribly sure what were solo bits or collaborative bits.
The last day before deadline we rocked out and got a bunch of stuff done as a team! Nervous energy brought direction to us but it would have been nice to harness that earlier on. All in all though, we were both pleased with the games launch and that was really our initial goal.
7. You don’t need gimmicks to stand out; solid fundamentals are more than enough.
So when drafting ideas for Super Event Horizon, my initial thoughts were to be flashy and use existing mechanics in tricky ways. Most gimmicky ideas than emphasized individual moments of play were what I wrote down so of course when it was time to construct the maps, I was mostly winging it.
For example: I originally pictured Mario hopping through space and a wrecked ship to grab a fuse (star) that’d open up a door to the portal room. The player would backtrack through an alternate route — Metroid Prime style — to return to the door AND… what I wrote right there was about all my notes said too. I had snapshots in my mind of this event but nothing tangible to use as reference.
We ended up scrapping this idea all together to focus on a fun and scary time inside the ship. I miss that fuse grab segment because I thought it’d be really exciting but I’m happy we focused on immediate player experience instead.
Later, we switched to a linear design with many medium-difficulty stars. Those few fancy tricks were turned into optional stars and that worked just fine. We left gimmicks on the table for work after the game was completed because creating a fun baseline experience was hard enough to as is! Many ideas were left out ultimately but our game has a begging middle and end… That matters most.
8. Even the simplest parts of a game have to follow logic that a designer must dictate.
If you want to warp out of a level, you have to set a warp point. That warp needs a radius that fills the desired warp floor and you’re also need a warp point for your destination. Don’t forget the logic that tells the game’s levels that these two warps need to communicate and don’t forget to rest the destination warp of a level success/failure. Each warp needs an ID and these can’t overlap, be sure to organize them on a spreadsheet or something aaaand… this is all getting a little confusing, huh?
Since rom hacking is limited by a available tools and documentation, I kind of felt like I was always at the mercy of who ever didn’t mind answering my questions. Thankfully, nothing about rom manager is as arbitrary as it first seems and a bunch of custom code is just a box check away. Most distinguished objects aren’t as simple as drag and drop but they usually only have a few behavior parameters to be mindful of.
Once you get doing a little of work for a simple but crucial element of gameplay, it gets easier to learn the nuance of poorly documented systems.
9. Levels can never be perfect but they can be memorable.
When starting a new map, I’d often ponder what qualities it needed to be considered ‘good’. When ever I’d copy/paste and section or make it a recognizable shape, it’s stick out poorly and I wouldn’t always know what to replace it with. Thankfully, SketchUp is a really great tool for freestyling concepts. Testing multiple designs was something I got comfy with fast and I noticed that I would always associate unique, uncopied stuctures with this feeling of… ‘good.’
Asymmetrical designs take a little bit more effort to model but they really look great. Environments with less duplicated section or mirrored elements were also easier for new players to navigate during play testing. This philosophy helped the most in my not-so-linear levels like Hell Grove and Castle grounds. Players could always use landmarks to tell if they’d visited that area yet.
10. Scheduling your time — even just a few days in advance — is incredibly important.
I was super happy working 14-hour days on this romhack. Hours like that can make it pretty ambiguous as to when I should break to eat or just keep working tho since my hungry waves stopped lining up with the time of day. I often had plenty of food in the fridge but that all needed upwards of an hour to prep, cook, eat and clean. I’d find myself working to the point of feeling starved then just lack the motivation to cook and would go hit a drive-thru instead. This has been the quickest way for me to get side tracked and upset, as often times I didn’t like the food I ate then wouldn’t want to go back to work right away.
Plus, I’ve got friends and a girlfriend I wanted to make time make time for. Poor scheduling had me cancelling plans with them; that sucks. The last two weeks of development, I reluctantly told everyone I just wasn’t going to do anything with them until the game was done. I can’t be mad at this, it was my fault in the first place! I didn’t plan around life circumstances early enough and ended up forcing myself to work super mega crunch time.
If you’re looking to start a project that’s going to take more effort than what you can give in your spare time, I seriously seriously encourage you to have your meal planned, your errands ran and your friends informed. Self care is super important when you’re working your body like a machine.