In today’s gaming landscape, indies are often limiting their scope and their development timelines to survive in the unstable market. Without the proper foresight, these timelines often stretch out into the unknown and the studios behind them run out of money or motivation. Luckily, if you plan right from the start, you can avoid these pitfalls!
My name is Daniel, and I’m the lead programmer at Skipping Stones. Our current project, Ripple and Frawg: The Seasonal Song is a co-op puzzle platformer where you, and typically a friend, play as Ripple the Stoat and Frawg the Frog, traveling through the forest and advancing the seasons with each character’s magical instrument.
We’ve been working on the game part-time for around 7 months, and in that time, we’ve finished around 60-70% of the total planned content and created around 45 minutes of gameplay. This experience, along with an array of past game development projects, has given me a robust set of guidelines and practices that keep development running efficiently and effectively!
So, I’ve compiled a couple tips that will help you and your team develop faster. I also tried to go beyond cliché advice I commonly see, so hopefully these are novel to you.
#1: Make your level objects like tools
I’m specifically talking about level objects that must be placed into your world by someone on your team and usually manually configured in some other way. I suggest you develop these like tools, something easy to use and accessible to all team members.
In our Forest Level, we have trees that grow Fruits or Pinecones (depending on the season) for the player. When I was making the asset, I added a sphere on the tree (invisible in-game) that shows the exact position where the object will grow. This can be repositioned to any location or orientation and the spawned object will match it. By thinking of the tree as a tool, we had the foresight to use a visual representation that was incredibly easy to tweak, speeding up dev time and level iteration speed. The takeaway? Visualize whenever possible and expose as much information as possible for easier editing down the line.
Throughout our game, we have a lot of spawn points. From the start we knew making something that could be easily dragged and dropped into the scene was a must. For each spawn point, we have 2 colored spheres, one representing each player, and a box collider that detects players. The players will always try to respawn in their sphere. When placing the object, it’s easy to visualize where players will spawn and where they need to be to activate the checkpoint. On top of that, I built these checkpoints to handle a lot of edge cases. If the spawn point is accidentally placed too far into the floor, the player will spawn above the blocking object. If that’s not an option, the player will be respawned at the other player’s spawn point. When making these level objects, make them resilient to mistakes wherever possible.
#2: Make testing easy
Any successful game requires a lot of testing, so why make it hard for yourself? Automated testing can help a lot with this, but when working with a small development timeline you often don’t have time to make a robust test suite. Build in ways to help yourself test and you will do it far more often.
When doing manual QA for Ripple and Frawg, we found it annoying to run through a whole level just to test a specific part. Because of this, I made a short console command that teleports players to a location in the level that they specify. By using our existing respawn points and camera change areas in the level, we could easily create or modify spawn points in a matter of seconds. Sometimes it only takes a couple minutes to save hours of time, so do it early and keep it simple!
Since our game is two-player, I also implemented a player swap so we wouldn’t need two controllers to playtest. I even added a feature where holding down the swap button controls both characters at once. This eventually became a feature in the game and let us support single-player in a 2-player game. If you put in the time to improve development, you may find a way to add user value as well.
#3: Polish and juice early but carefully
Polish elements like screen shake, controller rumble, particles, sound effects, and more are sometimes put off until later stages of development. While this may make sense in certain cases, I’d recommend adding your juice early on! For me, adding juice keeps me motivated because it helps me better picture the final product. Even if a lot of the game is missing, it makes a prototype feel more like vertical slice.
In Ripple and Frawg, we were having issues with players not understanding that Ripple gets a small jump when he exits his dig. At the time I was also implementing a jump animation for both players that activates when they aren’t touching the ground. We realized that when the animation was implemented, it would play for a second when Ripple exits the dig – and our communication issue vanished. These touches add a lot to game feel and can provide many knock-on effects.
Another example is that when Ripple and Frawg use their instruments, we wanted the controller to vibrate to “sell” the action. This was added very early on in development, more as an experiment into how rumble works in UE5 than because we needed it. I’m glad we did, though, because we ran into lots of rumble issues throughout development that we were then able to solve when they arose. This also gave us extra time to respond to player feedback when we learned the rumble was way too intense and needed to use different strengths for each associated action. Polish and game feel are incredibly important to a great feeling game, so implement early and iterate more.
I hope these tips help you develop your small game quickly and effectively! If you liked the blog post feel free to check out more on our website and wishlist the game on Steam. If you’d like to know more about me feel free to connect and shoot me a message on LinkedIn or check out my portfolio!
Comments