Programming

Remote Server

The remote server build and setting up remote multiplayer is working smoothly now, we no longer have to debug server issues and pretty much any iteration of the game build can get copied up to the remote server and played without issues.

Human Tasks

For alpha we wanted to build out the first major task for the human players to interact with. Building the DNA Synthesis minigame layed a lot of foundational deisgn work in terms of understanding the limitations of what we would be doing with our minigames, what is possible using the UI, and the time constraints required to make one of these.

The game is pretty simple – players must match a DNA base pair sequence to its corresponding match. There are three rounds, starting with strings of length 3 going up to 5 characters. Clicking the correct answer progresses you one stage forward, and failing sets you back to the start.

The process of building out the level progressed as such:

1. Program the base functionality of the game (generating the DNA sequences and fake solutions) (approximately 2 hours)

2. Design the prefab, with its corresponding UI elements and planned interface. (approx. 1 hour)

3. Link up the functionality to the UI, filling out the additional features that come along with linking everything up, such as failing back to the beginning, properly updating the UI, etc. (approx 3 hours)

4. Debugging (approx ?? so far another 2 hours) There are still a couple of bugs with the tasks left to iron out, which should hopefully be one time issues that don’t add development time to future tasks, but future games of roughly this level of complexity will likely take about the same amount of time (subtracting time due to increased familiarity, adding time back anyways just because game dev is hard like that) of about 5-7 hours.

Visuals

Level Assets

We added new 3d assets for the level along with some UV mapping for pretty baked global illumination.

Animations

A whole slew of new models and animations were added for the parasite and human player models.

Player Identification

Each player has an assigned color attached to their playermodel so they can be recognized at a glance – they also have usernames over their heads that match the username they chose on the main menu.

UI

This week we also did some 2D design for UI. Based on the game concept, the sci-fi style is the main direction we went for. Also, it should not be too heavy in order to fit our player characters. Geometry shapes, parallel lines and the use of 45 degree angles are the building blocks for the interface. To combine elements into UI, we play with effects like overlay, floating, repeating and transparency. The font for button and titles are futuristic.

Audio

On the audio side, this week was mainly about implementing all of the core SFX and music. Using fmod, there are slight randomizations for each of the core sounds including footsteps, various parasite impacts, and all the sounds that the parasites make when performing actions. By slightly altering the pitch, volume, or sometimes combinations of sounds, the audio of the environment as a whole will hopefully feel more alive and less predictable. We have also added an approximately 2 minute long looping soundtrack for the background of the level. Musically, it should sound mischievous and fun without being threatening. The timbres used are primarily orchestral to evoke a similar feeling to that of old cartoon animations. Synth elements are mixed in to ground these orchestral sounds into our sci-fi environment.

Programming

Bug Fixes

There were a ton of miscellaneous bugs and issues that have been fixed – the parasite jump motion and physics has been made a lot more reliable, and network issues with duplicate objects have finally been ironed out.

Win Conditions

We added a universal game-end state that is activated when all local and global conditions are fulfilled for the current human player. The UI doesn’t exist yet but now we know the system works and can start iterating on interesting tasks.

Basic Tasks – Richard

Designing the tasks for the human player to accomplish while running around the spaceship is key to making sure the player has goals they want to accomplish while they’re in the hot seat – and doing them should give the other players time to potentially hijack the player.

I spent sometime making up some basic wall panels to test that the conditions work for the human player (pardon the lighting): – After making sure that works, I moved on to more design work – the goal is for these games to be instantiable, so they have to be able to dropped into a level and work out of the box. Furthermore, – they should be simple enough that the only necessary RPC’s should be task failure/completion – if the player gets hijacked, they should be interrupted on the spot and the game/task gracefully close – they should varied enough to not get tedious. The current goal is to have a mix of more mundane tasks that might just involve standing in one spot (something like https://www.youtube.com/watch?v=yRCoQgUNTxk) survivor gameplay but for nowhere near as long), and others might be more involved, such as the minigames in Among Us or the lockpicking from the Elder Scolls games. Implementing a game inside of a game presents an interesting challenge to tackle in terms of managing game states inside of another game, but hopefully as long as we keep the games simple it shouldn’t be difficult to implement. I’m making headway into a simple DNA matching game where the player is presented with a short DNA sequence and is told to pick the right match out of 3 options right now to lay the foundation for more games in the future.

Level Components

The level components have been fully integrated into the prefab system – now all we need to do to make the level look nicer is replace the meshes on these components.

Parasite Jump UI

We have a line renderer component in the works which generates an arc which shows the player their exact trajectory they would follow with a jump in a specific direction and specific power.

Sound

Being able to properly iterate on sound has been difficult so far since the fundamental game loop has still been coming together, so this is something that will expand a lot more once we pass alpha and start much more vigorously play testing.

But in the meantime – here’s some cool background music Ian has put together

Art

We’ve integrated the latest parasite model into the game – its quite fun to see it bounce around after the jump – I’m personally really looking forward to getting a proper jumping/falling animation in for it.

Programming

Possession

This week was spent squashing some bugs that were left over from our earlier sprint to get to a playtestable state. The following describes an overview of bugs we tackled in getting possession working:

– Camera wouldn’t update/player wouldn’t move: our current implementation of the human is akin to that of a GTA5 car that the parasite players hop into – once you get in the car, you kick out anyone inside. However, this requires updating a host of parameters, such as disabling/reenabling certain scripts, making sure the camera is properly disabled so we don’t have multiple cameras per client, and reenabling turning on the proper prefab.

– One time possession bug: a bug that took me an embarrassingly long amount of time to fix. Basically, possession would work a single time and then fail – instead of slotting someone new into the mech human, it would delete the human and dump the parasite on the floor. After some misleading errors lead to thinking that it was a nasty race condition between receiving the possession message and deleting the prefab, I did the usual and placed Debug.Log everywhere, and lo and behold: [Image 2 here] We keep a dictionary with the prefab status of our players, and we never actually set the human back into a parasite when performing possession. The actual fix was a single line (the last one).

Up next is getting tasks working for the individual and global objectives. The current aim is to have one global objective and one individual objective per player lead to a win state – this should allow us to build a framework for adding future tasks and objectives, whilst also allowing us to test our win states.

Parasite Controls

We wanted the parasite to be able to walk on walls and ceilings in order to maximize their ability to hide and surprise the human player. We managed to get a system working fairly well that augments the motion of the parasite (when not physically ragdolled) to be in the tangent space of the mesh it is sitting on, letting us slide along all surfaces at all angles.

Art/Characters

Our next big step is finishing up the character models and players

We have a viewmodel (the first person perspective of the baseball bat arms and animations) and a ragdoll model for the parasite in the works, but they aren’t ready to show yet.

Level Design

We’ve added more props to the levels which by next update should let us replace our basic demo level. We have lights, terminals, and more physics props such as phones and desks.

Game Mechanics

We’ve created a generic interaction and “Win Condition” system which lets us arbitrarily place interactable tasks for the human player to complete, as well as an option to make a task “Global” or “Individual” depending on who needs to complete the task in order to win.

Parasite

The parasite controller got a UI makeover to give players feedback on their jump strength, and the network code for their physics and feedback was fully implemented.

Human

The Human also got networking fully implemented, now fully affecting the parasites physically when they hit them, as well as affecting non-player physics objects when they hit them with the bat.

Possession

Possession also need to be networked, which was done this week. The possession is now a global rpc which is triggered when the human’s face collider intersects with a parasite. This is now all hooked in with our GameManager singleton, so we can customize networked effects and announcements when a possession takes place. We have a full UI announcement system in the works to announce to players when global state changes.

Overall, tech moved forward a lot this week, but it was a lot of first drafts. We are now in a state where we can iterate and test and we have a lot of iterating and testing ahead of us.

Level Design

The basic level got a makeover this week, now featuring plug-and-play maze sections that we can use to build whatever level structure we want.

Props

We built a few basic props to place around the level to give it more interesting physics moments and liven up the otherwise blank initial design.

Characters

More progress on 3d modeling the human player, along with some mixamo work to get the rig and animation workflow started.

Design

This week we refined the details of our gameplay and decided on a solid MVP which will likely evolve over the semester.

Basic Gameplay:

The Human player, assigned at random in the beginning, has traditional First Person controls, and wields a baseball bat that they use to defend themselves from the oncoming parasites.

The Human must prevent the parasites from jumping into their broken helmet, if they fail to do so the parasite will swap roles with the Human and thus has the ability to win the game. Only the human can fulfill the win state (currently just getting to a goal position). After a swap the human has some invulnerability.

The parasite has the ability to walk on any surface and can launch themselves forward as a ragdoll in an attempt to land in the helmet.

In-Engine Work

This week we worked a lot on the basic programming structures and library which will manage game state and hopefully set a good foundation for future work and yet-to-be planned mechanics.

Dynamic Lobby

We have finished the dynamic lobby which lets players set their username and join a lobby before starting the game. This involves managing a dynamic list of joined users that is used with the game manager which assigns initial player roles.

Game Manager

The Game Manager is a core object which manages the active game state and handles things like tracking the current Human player, guaranteeing temporarily invulnerability, and deploys necessary messages to all clients.

Mockup Level

A basic mockup level with simple lighting, several spawns, and a ‘goal zone’ at the opposite end.

Human

We have a basic humanoid model and swing animation we pulled from mixamo, as well as a simple raycast which scans where the player “hit” their bat and an effect to show where the contact point is.

Parasite

We have a basic 3rd person parasite controller which enables and disables a rigidbody when they launch so they can roll around, as well as a custom camera controller so that players can maintain a view of their target regardless of their orientation. After a few seconds of little movement (they’ve physically come to rest), the controller resets back to the normal controller.

Audio

We have several basic audio effects built but yet to be implemented, here are a few samples:

Visuals

Some mockups for the final look and feel of the space facility:

A simple hallway in the facility.

Some mockups for character look and feel:

Challenges and Successes

The individual player controllers feel really good, and the basic gameplay vision is coming together.

Networking has made tough work tougher and integrating everything together for a working prototype took much longer and was less successful than expected. Thankfully its just a matter of spending more engineering time on it and so far nothing has been a roadblock.