A mobile AR game that pits you against a virtual opponent.
A mobile AR game that pits you against a virtual opponent.
A mobile AR game that pits you against a virtual opponent.
A mobile AR game that pits you against a virtual opponent.
Grabage
Grabage is the title I've been developing over the last year and a half with my team at CozyBara games! In it, you play as a raccoon in a free-for-all frenzy against up to three other players, in a gambit to grab the most trash.
In starting up CozyBara games and developing Grabage, we've been partnered with the Falmouth University Incubator program, where they've guided and helped us in many ways, such as making the perfect pitch deck to send to publishers, creating a product that's marketable and profitable while still being able to scratch our creative itch, and registering as an official company.
Play Grabage here! https://cozybaragames.itch.io/grabage
I've learned and grown enormously as a programmer and designer while creating Grabage; this has been my first major design role after all, and my debut in level design. My coding skills have significantly sharpened too, thanks to being the sole programmer of the project, leading to me coding all kinds of systems and mechanics I've never done before.
Design:
Creating my first playable level was a challenge, but some of the most fun I've had with game development thus far.
In Grabage, the player's movement is created to take advantage of momentum - meaning you can gain speed from rolling downhill, and fling yourself high when you jump up a ramp.
Our current multiplayer stage, the Mushroom Forest, went through countless iterations to best utilise and exemplify the player's movement options.
Initial sketches were designed in a figure-8 shape, with half-pipes and booster pads around the edges to have the player fly around the arena, and launch with great speed at any point they like. As players flung themselves around the map's edges, they would repeatedly meet its centre - knowing this, we wanted to make the middle of the stage a good launching point - so we decided to make it a bowl shape, meaning players could gain speed and fling themselves from this one point.
​
Upon playtesting this, we discovered that while using halfpipes as the core method of gaining speed wasn't effective thanks to the stage's size, and the concept being limiting overall, we found that the bowl-shaped centre of the stage was highly effective.
​
To expand on this, we brainstormed different obstacles and stage elements where the player could gain speed in various engaging ways, and for their endpoint to ultimately fling the player to the middle of the map, where they could continue their speed and fling themselves to higher areas.
Overall, this experience has taught me the importance of identifying what works and what doesn't for a level, and how to effectively expand on concepts that move the experience in a more fun direction.
I've also learned about the value of experimentation - the first idea for half-pipes didn't work, and many others didn't either - but after reshaping these ideas I've transformed them into fun and exciting stage elements. My favourite thing in the Mushroom Forest - this log filled with mushrooms that bounce you around like a pinball machine - started life as one of our scrapped half-pipes.
Programming:
Grabage's movement system was probably my favourite thing to program - using my pre-sharpened skills in movement-making was a joy thanks to working on Dr. Bounce. I was able to use the knowledge I had previously gained, and experiment with new things, to create my best movement system yet - I'm incredibly proud of how Grabage plays.
However, I grew the most from this project by tackling the things I had never encountered before. My greatest challenge during Grabage's creation was making its decoration system, and figuring out the correct behaviour for the game's cursor.
The cursor itself is a trick I'm rather proud of; its position is the hit point of a raycast fired from the camera, directed at the location of the player. During decoration mode, the player is made a child of the camera and is always a set distance away from it. Moving the mouse moves where the player sits in the camera's view, allowing the projection of the cursor to hit wherever the player moves their mouse.
This technique also allows for an easy way to change the cursor's sensitivity, simply by changing how far away the player is placed from the camera.
Keeping the cursor in-bounds of the house at all times was the most difficult part of creating this system, and was a big problem-solving challenge for me.
I initially tried getting the highest and lowest points of the room and clamping the cursor's position, by getting the bounds of the room and finding the closest points on it to 2 vectors created directly above and below the camera.
While this code worked, it didn't have the desired effect. The player was bound to the top and bottom of the room, but naturally in a square shape, meaning the player could escape the house's bounds by moving the cursor to the corners of this bounding square.
Though this didn't work, I knew that utilising the bounds of the room and the ability to get the closest point of something to these bounds would be vital.
Next, I tried using the cursor's position, and if it moved out of bounds, moving it back to the closest point in the bounds of the room. But that still wasn't right - the closest point was based on where the cursor was hitting out of bounds, which didn't always align with what looked like the nearest point to the camera.
For code like this to work properly, the space that's hit out of bounds would need to be a continuation of the closest point in the room. Which is exactly what I made to fix it!
Upon entering decoration mode, an invisible clone of the room is made - each surface occupies the same position but is 100x larger. Meaning whenever the cursor goes out of the room's bounds, its controlling raycast would hit the larger clone room, and an accurate closest point from the cursor to the room could be generated, allowing the cursor to seamlessly return to that position as if it were clamped to the room's bounds.
Pitching:
Our main goal with Grabage is for it to grab the attention of a publisher, who will fund its continued development so we can get the whole game completed and CozyBara Games completely off the ground.
The best way to achieve this was to make an effective pitch deck - one that illustrates why Grabage is so fun, what players will love about it, and why it's worth publisher's time and money - all in one compact and consise presentation.
We achieved this through constant interation and feedback - we're very lucky to be partnered with Falmouth University's incubator program, where we had Colin Mitchell and Steve Stopps to check out what we'd made every time. They also set us up with industry contacts who heard us pitch and checked out our material. They all gave us invaluable feedback and suggestions, allowing us to make a great pitch deck over time.
Our starting pitch is entirely different from the one we have and use now - you can check out our current pitch deck at:
https://docs.google.com/presentation/d/1pH_p-It8a8wBZZEv2X1ozSvXhq8Euaarg6sBzNSo5Co/
(and hey, if you're a publisher and this looks like something you'd want to fund, send us a message!)
Summary:
As a whole, I've had tons of fun working on Grabage, and have learned by far the most from it than any other project to date. It has expanded my programming knowledge, and allowed me to try new things and grow as a developer in a way I never could have anticipated.
Thanks to the Falmouth Incubator, I've also gained a lot of knowledge about setting up and running a games studio, and pitching to publishers.
I'm extremely proud of how much we've done and how far we've come since starting, and I don't think I'd change much if I were to go back and do it all again!