top of page
Space Smack!

Space Smack!

Play Video

About

Space Smack! is a 1 to 4 player party game exploding with chaos and sabotage. Enter into the vast expanse of space and clash in a variety of minigames. In this controller-only game, cooperate or undermine your friends to become victorious! Features 15 minigames!
Download on
Role:               Lead Programmer
Team Size:      10 (3 Programmers)
Engine:           Unreal Engine 4
Time Frame:   5 Months
Release:         January 2021
Platform:         PC
SteamLogo.png

Roles and Responsibilities

As the lead programmer, I communicated with the Game Designer, Producer, Lead Designer, and Lead Artist to discuss and plan all technical features.

 

Responsibilities

  • Sprint planning with the other leads

  • Managed team of 2 programmers

    • Ensured they knew the direction of the game​

    • Worked with them to break down deliverables into tasks

    • Discussed the design and implementation of gameplay systems

  • Updated Hansoft scrum board

  • Automated Daily builds

  • Performance Optimizations

  • Worked on the Menus and HUD

  • Worked with designers to implement audio

My Contributions

Dynamic Shadows

A problem we had dealt with was depth-of-field. When we would go to pick up objects or drop them, it was hard to gauge how high or low things were and led to constant frustration. Working with the artists, we approached this problem and came up with 3 different solutions that had different results.

  1.  Using dynamics lights

    • An immediate problem that arose is that shadows weren't sharp enough without drastic settings and it would often overexpose the scene​

    • Unreal Engine 4 only has 3 lighting channels and so there would have to be an overlap and objects would start giving off weird shadows

    • Verdict: Needed a better solution so that we don't have weird shadows or lighting problems

  2. Using blob shadows

    • It was difficult to get working, but it worked perfectly when we got it there​

    • The benefit of using the blob shadows is that it cast shadows around the objects perfectly, even if they did any rotating

    • The problem we had here was performance

      • It had a high framerate when it was single player, but dropped by up to 30-40 frames when you added on even 1 extra player​

    • Verdict: Needed a solution that was better on performance

  3. Using a masking object

    • The final solution we decided upon was to create sphere mask that we could draw on the ground below the objects, most notably the hands​

    • No performance issues

    • Did exactly mirror the objects perfectly, but it was passable

    • Verdict: This is the solution we used as it provided the best balance between performance and performing the job we needed it to do

Menus and HUD

With the small size of the team, I created the layout of all menus and most of the UI seen throughout the game. I worked with the Lead artist about what assets I would need and then implemented them.

  • One limitation I had for the UI was that it all had to be navigable by a controller only

  • Main Menu

    • My main goal on the menus was to ensure that any data set in the options or player selection was persistent throughout the game​

  • Join "Menu"

    • The designers were having a hard time trying to find a way to teach players how to play the game that was both useful and didn't involve making veteran players annoyed they had to do the same practice every time they played​

    • The join menu was created as a kind of hub for players to practice before they started playing

    • For players who already knew how to play, they could simply ready-up and wait for the rest of the party before moving on

    • Players also had the option of choosing from a list of preselected names to help them differentiate themselves in game

  • Minigame Hub

    • The minigame hub has 2 modes depending on how many players there are​

    • Single player​​

      • Only has access to single player accessible games in a free play mode​

    • Multiplayer

      • Has the option of either free play mode or tournament mode​

      • Tournament mode was a first-to-3-wins mode where a minigame was selected randomly

  • HUD and Results was a bit different for each game and sometimes was based on how many players there were

    • Single player and multiplayer results showed different data

    • For example, in the minigame Risky Rollers, single players were shown time elapsed and multiplayer was show the percentage each player made towards the goal​​​

Post Mortem

What Went Well

  • The team was able to create a shippable game 

  • I was able to plan deliverables and their due dates with reasonable accuracy

  • Information flow and teamwork among the different teams improved as the project progressed

  • I was able to solve most problems that arose, though I had to take several home and they took a few days to solve

  • Help was offered often to ensure that all tasks were done on time

  • All teammates were working in-person

What Went Wrong

  • There was always a bit communication lost between 2 of the teams each sprint

  • COVID-19 made it hard to get sufficient playtesting feedback due to the game being multiplayer

  • I took on a little too much work and would often take it home to finish so that the other programmers didn't have to worry about it

  • There was bit of disconnect between leads when planning later milestones that caused issues with deliverable dates being met or confusion about what team was waiting for a specific feature

What I Learned

  • On a small team, you can think that you're communicating enough and it still not be enough

  • It's important to discuss with the team if something is unreasonable or there isn't enough time to do it

  • Make sure to disperse work so that one person isn't always having to take work home

  • Planning effectively is important to delivering things on time and making sure that each team has all the tools they need

bottom of page