In our Developer Blog Updates we’ll talk about some of the work we’ve completed in the previous two weeks and explain our approaches. Through this you’ll get an understanding of our game development methods and tidbits on the features we’re planning for Dredge!

Sprint 1: 

An understated sprint but a very necessary one. This sprint we did things like project setup, wireframes and control inputs – things that we know will make our lives hell if we don’t do them right at the beginning.

Project Setup

Source control, deciding on which version of the engine to use (and how you’ll go about deciding when to update it) and ensuring all dev team members have access to the correct environments! Not necessarily the type of work you think about when you’re planning on becoming a game developer, but in the interests of making our lives easier down the road we’re starting here.

• Source Control & Engine – We are using Atlassian’s Bitbucket and Unity 2020.2.3f1 (for now).
• Scene Setup – Loading Screens, Menu’s, Inputs. For Dredge we’re supporting keyboard & mouse along with PC and console controllers and so many things that work for a mouse/keyboard combo feel janky with a controller and vice versa, planning for and testing both at the same time is really helpful for us.
• Wireframing – Part of the planning of control inputs for us is wireframing and understanding how the player will interact with the game and inputs, then testing whether our design works.
• Saving & Loading – This was a big item to tick off early on, and the first time we’ve worked with Nintendo as well. We had to decide how we want the player to be able to save (free-form or checkpoint style?), how many save files the player is allowed to have (consideration of how much space the game might take up) and handling conditions for when players do or don’t have save files available. 

QA Mindset

• FPS Counter – Keeping an eye on this little guy means as soon as we implement anything that brings it below 59fps on any of our chosen platforms we’re going to know about it and can address that then and there, rather than have major optimization sprints at the end of our development. Simple but effective.
• Debug Console – This means we’re not only getting more info about what’s going on behind the scenes like errors, we’re also able to tweak the environmental variables which enables easier testing and balancing. For example if we have an event that happens on Day 12 of the game we might want to be able to skip days 1-11. We’ll continually add commands to this as we add more features throughout development and remove the redundant ones.
• Version Number 

Foundational Fun Stuff!

Invisible water! Collidable land! Physics! 

• Camera Controls – Using Cinemachine Virtual Cameras for all camera movement.
• Water & Buoyancy – Using Gerstner Waves, which is a simple math equation for forming some pretty cool waves. In future we’ll be defining areas of the game that have choppy water, so look out for that in a future devlog.
• Boat Movement – Pretty basic for now but it’s something we’ll revisit to make sure it feels good to sail around.
• Boat Collisions & Health
• Day/Night cycle – Most of the game is impacted by this system in some way so it’s important we get this right.
• Secret Feature

And that’s our Sprint 1 wrap-up!