Log #31: Mar/18/2025
- Chaos Game Jam
- Struggling with Writing
- The Simplest Game
Hello everybody! I apologize for this entry's lateness. This entry is mainly about last week's game jam, dubbed the "chaos" or "mad-lib" game jam. The premise was (extremely) simple: different teams would work on different projects each day, so at the end of the game jam, we should have 5 projects made by everyone.
Naturally, this goal was not accomplished, but it tought everyone who participated in it a lot. As a designer, I made a design document for a game over the weekend, and wished it farewell for the randomly-assembled team that would be first to tackle it on Monday.
Through the week, my role was then project manager, I would get a random project one of us designers made, as well as a random team, and we would try to move the project as far along as we could.
This excercise forced all to work outside of comfort zones: new spontaneous groups, new unfamiliar projects, and in new software. A huge takeaway was that we should make sure a project's information is organzied clearly. Throughout the jam, having to sift in a variety of places to find information on a project was incredilby annoying. I did not even read everything that was written by previous teams. If there had been a nice "roadmap" that told me where to find updates from the previous team, as well as the file organization of the projects themselves, that would have been greatly beneficial.
The second big thing I learned was "resiliance." While that word is nice and flashy, what it means is being able to pull a project together from a bunch of fragmented pieces. When I opened up the design documents on some projects I thought, "this is too ambitious." I greatly reduced complextity in designs so that our team could hope to get something finished. This leads me to my third main takeaway: Build the smallest functional game first.
So many projects (including the design I wrote) had hugely ambitious ideas, and because of that, a playable version of the game was never assembled. Next time I work on a game jam project, I want to push to create a stupidly simple playable version of the project. This lets future teams easily expand on our ideas, and, if all things fall apart, at least we actually have something finished.
So my main takeaways from working on 5 projects on 5 teams: Organize everything and explain your organization, make the project work with what you're given, and start small and expand from there.
From an organizational perspective, the event felt a little messy. I think there may have been a little too much information shared between teams, but generally, things worked out nicely. I liked being able to see all of our teams on the whiteboard each morning. It was annoying that no team specified how its project files were organized, or that there was no agreed upon system for how to make changes to a design, but that is more a fault of the project managers and designers than anyone else.
Overall, it was really great to work on projects with people I otherwise wouldn't work with. Because I had taken the time to get to know everyone beforehand, it was easy to work with the new teams each day. I think it's awesome that we were forced to socialize with each other and immediately start working together.
So there you have it, a chaotic game jam. On the last day, our team did manage to publish something. Unfortunately it isn't really a game, but it does allow you to see the artist's cool stuff. You can check it out at the below link:
blob-guy.itch.io/monster-restaurant
MATH SEGMENT: Geometry (2D Relationships)
One weird problem I ran into during the chaos jam was not understanding the resolution of one project. No screen size was specified, but I had an image that seemed like it was meant to take up the whole screen.
I thought, "great, this will be our resolution for the screen." However, once I looked at the image, I saw that it looked like it had been scaled up multiple times. I ended up counting how big one "pixel" was to find out how many times the image had been scaled up --thankfully it seemed to have been scaled up at nice whole numbers.
After finding that each pixel was really 18x18 pixels, I was able scale the entire image down so that there was no weird sizing happening.
On some projects, I ended up creating the resolution for the game. When documentation was poor, I did what I could to calculate the resolution of our art assets.
One method was to find out how big our character was. Then, using the resolution of the character, decide how much space the characater would take up on-screen to calculate the whole screen's resolution.
For exmaple, a 16x16 character 1/8th of the screen size would give us a 128x128px resolution game.
Working with unfamiliar projecst in a myriad of styles forced us to figure these kinds of things out, almost like puzzles. Keeping a game's assets at a consistent size makes things look nice.
MATH SEGEMENT: Algebra and FunctionsAdded Mar 24
As I touted above, making the simplest form of the game first seems to be an ideal objective for game jams, or really any game's development.
To do this one has to work out the minimum required mechanics, but arrange them so that they can be expanded on later.
For example, if you were to build a platformer game, you might want to set up functionality for player movement, obstacles, and a lose state for the game. But you would also want to have an idea of what features you might add later, so that your player movement is flexible enough that you can add, say, trampolines later on.
When you have a set of features you know you want to implement, this can greatly affect how you plan the game's features. For example, if you know your game's whole world will be spinning, you have to set up the obstalces in that world to respond okay to spinning. Or, you could instead spin only the player, so the world appears to be spinning to the player, and your obstacles might not actually need to move. Different methods of making a game can create identical results, but they dramatically change how a game works, and if done imporperly, could require you to remake features that aren't compatible with your core mechanisms.
At one point during the game jam, we realized that we could not salvage any of the previous' teams code on the project. This meant we had to tiptoe around the code we didn't understand, and build our feature in a different way.
While this is hard to lay out in a mathmatical, abstract way, being able to create the same result with multiple different methods is valuable when you hit roadblocks or have to plan for additional features.
One way to think about it like math is to imagine coding a function that adds two numbers. If you always knew what one number was, you could simply write something like below:
addNumbers(x) : ans = x + 5 return ans
But if you knew you were going to be adding different numbers every time, you would need to build the function in a more flexible way:
addNumbers(x,y) : ans = x + y return ans
Or if you knew you were always adding the same number to itself you could use multiplication instead:
addNumbers(x) : ans = 2 * x return ans
The functionality of video games in only a much more complicated version of this. Setting up your mechanisms so that they allow for your game's features can be complicated and mind bending, but also a lot of fun to work out.
Well, thanks for reading. Have a good one.
-Luke Knotts
