Kickstarting Our Game Vision & Setting Foundations

In week 6 of the semester, our team converged to brainstorm, eventually zeroing in on our game's central theme. We envisioned a hybrid third-person shooter/metroidvania experience where our protagonist, a robot, adapts by interchanging parts to overcome hurdles, all while trying to dodge its destined fate at a junk reprocessing facility. Dive deeper into our concept with our pitch document. Upon cementing our theme, we swiftly finalized our technical framework: Unity's latest LTS version, its native render pipeline, and GitHub for seamless collaboration and versioning. By week 7, our setup was ready, positioning us perfectly to dive into development during the mid-semester break.

Laying the First Bricks 

Our development journey commenced with the integration of tools like Probuilder and an elemental "construction site" asset pack. This foundational step facilitated the design of a rudimentary test level, setting the stage for perfecting our robot's movements.

Josh's attempt at character movement:

One of the questions asked by one of our peers during the project pitch was "How do we plan to make the game fun?", which I thought was a pertinent question given that - although we'd defined the games genre and setting, we hadn't really provided any real details on the actions involved in the core gameplay. At the time I answered something like "I guess we'll have to do a good job on making the movement, shooting gameplay and level design interesting, to make the game fun." With this in mind, I began thinking about 3d games that felt like they had interesting movement mechanics, and some classics that came to mind included Super Mario 64 and Quake 2. As our game has significant shooting elements and the quake 2 source code was made open source by id software, I thought that would be a good place to start, and ended up stumbling across a fairly complete quake 2 unity port by Maciej Szybiak: https://github.com/MaciejSzybiak/q2unity . 

Unfortunately due to the fact that Szybiak's scripts were written to load BSP map files as it's environments and made heavy use of custom raycasting scripts that depended on these BSP's, it wasn't possible to use any of his scripts, but I decided to try to use the basic structure of several functions in one of his player movement scripts as a starting point for our games movement - in an attempt to capture the Quake 2 feel of momentum, and hopefully some of it's quirks.

Over the course of the semester break, I managed to create some somewhat promising movement, though still with a few stubborn bugs, and also created scripts for the 3rd person camera and look controls, and some core state scripts that would help with future features. I also decided to implement control mapping using the newest unity input system. By week 8 Jon had also just about completed the player robot model, so I imported that into the test scene and here is a short video of what we have at this point:

Some unresolved issues include:   - Framerate issues  - Loss of momentum when jumping  - Player getting stuck in walls or falling through floor