Thoughts on my "Week of Games" experiment

  • user warning: Table './glorioustrainwrecks/sessions' is marked as crashed and should be repaired query: SELECT COUNT(sid) AS count FROM sessions WHERE timestamp >= 1710638348 AND uid = 0 in /var/www/glorioustrainwrecks/includes/database.mysql.inc on line 175.
  • user warning: Table './glorioustrainwrecks/sessions' is marked as crashed and should be repaired query: SELECT DISTINCT u.uid, u.name, s.timestamp FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.timestamp >= 1710638348 AND s.uid > 0 ORDER BY s.timestamp DESC in /var/www/glorioustrainwrecks/includes/database.mysql.inc on line 175.
spiral's picture

so a little over a week ago, I decided to embark on a experimental (for me) game-making project, in the hopes it would lead me out of the creative funk I've been in for a month. the plan was to make one game a day, with a sheer time limit of one hour per game, for 7 days in a row. of course, I'm not going to pretend this is some kind of new idea I just came up with- incredibly fast paced "trainwreck" games were one of the first ideas behind Glorious Trainwrecks! what is new is getting myself to stick to this one-hour rule.

sticking to a short schedule has always been difficult for me, so I wanted to see if I could re-approach fast paced game design in a rigourous way. over-commitment has been a thorn in my side, as I regularly want to take breaks from large projects by making something short and scrappy, but so often they end up becoming another large, time-consuming project when I keep coming up with more ideas for it without limiting the potential scope. so the result is I either put a prior project on hold, or I effectively cancel something I had suddenly become very passionate about. yowch!

thankfully, my Week of Games experiment was very successful, and I feel like I learned a lot along the way. I'll be spending the rest of this post detailing my process for making each game, my thoughts on how it went, and concluding each with the lessons I've gotten out of it. also, if you got here without seeing the games first, you can find them here!

1) Monday: "Monday"

to kick off the first game, I decided I would write something in Twine 2, to avoid any possible technical issues from a more complicated engine. I didn't want to hesitate while I tried to come up with a subject, I just wanted to immediately start making *something*, which in this case quickly became a simple Choose Your Own Adventure story from the perspective of Garfield the cat. you know, because Garfield hates Mondays! haha, what a silly cat!

since I don't actually like Garfield, I had no personal investment in the material, so if the story ended up being a total flop when time was up, I wouldn't feel bad about it. in the end, I wrote about 10-15 minutes worth of text, which is a great pace for the work of just one hour! it was an easy process, because I made up everything up on the spot. it's a very silly game, but it was fun to make, which is exactly what I wanted to get out of this experiment.

CONCLUSION: writing nonsense works well if the only ending you have in mind is an arbitrary time limit, because that way you don't have to worry about fitting in some kind of arc. it just happens, and then it's over!

2) Tuesday: "Tuesday"

similar to the previous game, for Tuesday I had an immediate association that I then fit the rest of the game around. Underworld's song "Spoonman" has a sample of somebody saying "Tuesday", so I made a minute long re-arrangement of the song focusing on that sample. from there, I had a restraint on what the game itself would be- it would last as long as the music.

continuing the theme of the day, I decided the goal would be finding Tuesday. I put down a random klipart background and spread out copies of it into a 10-by-10 grid, creating the playing field. I started replacing as many grid squares as I could with different klipart backgrounds to create a textured and diverse world. Some of the images were sourced from a calendar, so that finding the square labeled "Tuesday" could be the winning condition.

unfortunately, I planned the scale of the game quite badly. 10-by-10 seemed like a nice size at first, but I eventually realized that it was demanding I gather 100 unique pieces of art to fill it completely! I had to repeatedly redo the grid dimensions until it was a reasonable size. this cost a lot of time, leaving the remaining art choices and all of the coding in a rushed state. most of the tiles are the default I set, and the ending conditions do the exact opposite of what I intended. oh well!

CONCLUSION: planning out an appropiate scale for the scope of your time committment is difficult, but necessary. this was a good lesson to run into for what was supposed to be a very simple game, because one of my biggest problems is how often I plan games that are *way* bigger than they have any need to be!

3) Wednesday: "Cycle The Recycling!"

on Wednesday morning, I helped my mom take all of the recycling we had laying around the basement to a recycling depot. during the ride back, I was thinking about making a game to reflect the experience. after my lesson from yesterday, I knew I had to make something simple. so the plan was to have recyclables randomly fall from the ceiling, leaving it up to the player to drag each item over to the appropiate bin (e.g., plastics, glass). it would be a cute little game, as well as educational!

however, I ended up spending most of my time searching for real life photos to use as graphics! I love the look of the game, and I am glad for the work I put into it, but after implementing basic physics and a scoring method, I didn't have time to actually let the player control what was happening. all you can do is watch the bottles, cans, and broken electronics bounce into each other and fall into the bins. but it's kind of fun to watch, and hope for luck to be on your side and correctly "cycle" the recycling!

CONCLUSION: finding / making a visual aesthetic you like for a game is a considerable task not to be taken lightly. if you don't have assets on hand to use immediately, be prepared for work.

4) Thursday: "Help Nikki Shave"

CONTENT WARNING: discussion of dysphoria

for Thursday, following the reality of yesterday's game, I decided I would follow it up with something more personal- in this case, my difficult experiences with shaving. I used to not mind my facial hair, but when I decided to try out shaving my whole face, I realized that I liked it better that way. more recently, I had to confront the fact that my facial hair causes me dysphoria, which I had been avoiding admitting. it felt good to imagine processing that through a game where the player helps me shave.

unfortunately, the initial result only made me feel worse. my first approach was to use a real photo of myself, and distort my appearance with klipart to prevent it from being *too* real. when the hour was up, I immediately rushed to share it on Twitter, as I had for the previous games. unfortunately, in my excitement with having completed a game, I ignored my own feelings. the way I had made myself look in the game was frankly ugly, which worsened my dysphoria, instead of helping me process it. I deleted the tweet, and said I was putting this game on hold to re-evaluate it. I needed to treat my image with care and self-respect for the game to succeed.

I revisited the game later and redid the art in ms paint. decky, one of my partners, helped with the drawing and art direction, which I'm very grateful for. instead of an exaggeration of physical traits I dislike, the game now shows an abstract but much more comfortable representation of myself and my facial hair. I feel good about it and in the end I'm glad I had this idea, and that I spent extra time making it better for myself.

CONTENT WARNING OVER

CONCLUSION: making a game handling a personal/serious subject is not something to be taken lightly, especially if there is a tight time limit on it. also, taking care of yourself is more important than the performance of sharing something in public.

5) Friday: "A Conversation"

after having been immersed in Clickteam for several days, I wanted to try out a different engine to test out part of an idea I had laying around, an "everything simulator" that lets you type anything and creates a consistent state based off of the keywords you give it. I guess it'd basically be an interactive Inform 7, but whatever! anyhow, I chose to try making A Conversation in Twine 1. I was going to use Twine 2, but it gave me technical challenges for retrieving player input that I didn't want to grapple with for my one hour!

I wanted to make a simple but technically rich simulation of a conversation between two characters of the player's choice, allowing them to have each character speak/think/act out whatever they choose to write. I'm happy with the result and while it demands a lot of creative input from the player to accomplish anything, it was a neat little experiment and I'm pleased I was able to complete it so quickly. that said, I *did* spend some time planning the design of it before I started the timer, and I went beyond the original time limit to properly implement the pronoun selection mechanic. I didn't want to be stressed out by trying to design an engine on the fly, and hey, pronouns are important!

CONCLUSION: in-depth technical design is best handled outside of tight deadlines, as creative foresight is often needed to work around/with limitations.

6) Saturday: "Frogger 2 Advanced: The Greater Quest"

some of you probably know that I am a fan of the Frogger series. I find it fascinating that every game in the series recreates the entire Frogger universe. one of my favourite examples is the dreadful GameBoy Advance port of Frogger: The Great Quest. the GBA version turns the pre-rendered cutscenes into static screenshots with abrupt dialogue snippets. the uninspired 3d platforming gameplay of the original is turned into a banal 2d platformer, while retaining some of the awful collectathon traits. the best part is that if you don't find *all* of the special Ruby Stones or whatever junk, you get a bad ending that they made up just for this port. wow! I can't imagine being that cruel.

anyhow, I had the idea of making a classic "trainwreck platformer", and position it as another GBA port of a sequel to the original Frogger: The Great Quest. hence, my awkward title is meant to turn "Frogger 2: The Greater Quest" into "Frogger 2 _Advanced_: The Greater Quest". another aspect of the joke is that there are about four different, official "Frogger 2" games, and each has almost no familiarity with the game it is apparently a sequel to.

CONCLUSION: through this week's journey, I have finally found myself getting over a flaw (from my perspective) of my game design. specifically, I'm finally capable of making a complete, but absurd to play, trainwreck game in just an hour! woohoo!

7) Sunday: "You Can Only Shy 80 Times"

I probably spent more time on this than all the other 6 combined, but I'm fine with that! after my mostly-positive experiences with making games at a ridiculous pace, I was thinking about ways to turn it into a more regular practice for myself. such as, say, spending one day a week making a new game that I would finish within that day. so I'm going to excuse breaking my only rule of "finish in one hour" with this game, by saying that it's the first attempt at that! not that I need to excuse it in the first place. but anyhow.

I planned out exactly what I wanted the game to be before I opened up the Clickteam editor, which made putting it together a very focused task. the only goal I had was to make a sensible example of the parody title, which is a riff on another game I helped make, "You Can Only Die 80 Times". what does it mean to "shy"? well, that's if somebody says hi and you don't respond! how do you know how many times you've done it? a shyness meter! the rest of the game made itself from there. well, other than the day/night cycle I implemented for some reason.

a lot of my time was spent dealing with a significant technical issue: I wanted the speech bubbles to follow the character who it belongs to, making it clear who is saying what. for some reason, I found this conceptually simple task impossible to implement correctly, which was frustrating. and I was too invested in what I wanted the game to be to let it be unplayably broken! however, when I finally gave up on this one detail, and saw what it was like to have the speech bubbles remain static, I actually preferred it that way. so that was a good save.

also, when I picked out some nice midi music and set it to shift between two different soundfonts based on the day/night cycle, I was so enthused about the result that I made the decision to not put in an abundance pf silly sound effects. while I always enjoy that process, I think it would have only been a distraction from the bliss of the music. going against my typical / initial ideas made for a better experience! as a final aside, the player character (or "PC") is a "player chair"! get it?

CONCLUSION: if you are running into a block, whether technical or creative, try subverting the expectations that are forming the block. maybe it'll be better that way, maybe not! either way, it's good to experiment with going against your own expectations. as they say... "rules are made to be broken" - the matrix

pensive-mosquitoes