House Pixel Games - Mowen&Throwin

Mowin and Throwin Store Screenshot 2.jpg

Company: House Pixel Games

My Dev. Time: 2 Years

Genre: Local Multiplayer, Party Game

Technology:

Unreal Engine 4 (UE4)
- Blueprint
- C++
Perforce
Fire Alpaca
Assembla

Platform: PC

My Role: Gameplay Programmer

Game Summary

Players take control of gnomes on separate teams. Their goal is to mow the majority of their lawn before time runs out, while sabotaging the other team. Alternatively, a team can win by completely mowing their lawn before time runs out. Gnomes can cut grass via the lawnmower or by hand. They can also sabotage the other team by throwing items or switch the lawnmower into tank mode and shooting collected grass bags. Mowin' & Throwin' is being developed and produced by House Pixel Games.

I have been developing the throwable selection system, the interfaces for handling player input (both for the game and the UI), the mower tilt, and the death and respawn system. I have also worked closely with other departments (QA, Art, and Design) in order to achieve the vision for the project.

Title Screen

The title screen of Mowin' & Throwin'

Mowin and Throwin Store Screenshot 2

This is a screenshot from the store page, it shows some gameplay from the level "A Lawn Way Down".

Mowin and Throwin Store Screenshot 10

This is the 10th screenshot from the store page, it depicts gameplay from the level "Gnomie-Go-Round"

Title Screen

The title screen of Mowin' & Throwin'

Instantiating Coding Standards & transfering to C++

Personal Contributions

Instantiating Coding Standards, and Transfering to C++

Reasons to create coding standards:
- Lack of coding standards can lead to spaghetti code (especially with UE4's blueprint)
- Tools available at blueprint level for enabling coding standards:
  - Box Comments
    - can be color coded
  - Reroute nodes
    - Good for keeping the lines connecting variables and execution paths neat and orderly
  - New event graphs
    - can separate code into different sets of events
  - Functions
    - makes it possible to pass around variables without having to use reroute nodes for every variable
Reasons to use C++ in UE4:
- If the editor crashes while the game was running, can't use blueprint to debug
- There are some issues with event tick in blueprint that are not present at the C++ level
- General readability of code:
  - Blueprint was made with designers and artists in mind, its intended to help them visualize whats going on
    - Good for small code segments, horrible for the systems the programmers need to create and develop
    - Not intended to be finalized versions of code, only really useful for quick prototyping
- When to start transfering, and best practices:
  - Transfer code down as soon as possible; it will snowball otherwise and turn into a monumental task
  - If compiling, close the editor first:
    - Otherwise UE4 will try to keep a copy of the old versions of compiled files
      - Occurs when the file and all files touching that particular code is read only (not checked out from source control)
    - UE4's editor might crash anyway because it doesn't know what to do with the new and old versions of the C++ code
  - When moving a large blueprint down:
    - Its faster to develop an entirely separate C++ version instead of having a hybrid of a C++ and blueprint file that you slowly trickle down
    - Only time you might want to keep a hybrid is if it was the game instance so as to not break all of the references to it

Lawnmower Tilt System

Idea was to make it to where the mower more challenging to maneuver, while matching the terrain it's on
Lawnmower will tilt itself to match the ground's orientation
Lawnmower will also push itself towards the "down hill" direction
The tilting and shoving is handled by four ray traces downwards
If the wheels of the lawnmower get far enough off a ledge, then the player's controls will lock up and the mower will shove even harder in that direction
- Control locking is handled by four collision boxes.

Lawnmower tilt part 1

This gif shows the lawnmower tilting but with the player recovering from the tilt shoving.

Lawnmower tilt part 2

This video shows the lawnmower tilting and the controls locking (the mower then falling to a watery grave)

Mower tilting with controls locked

This picture depicts the mower when it is tilting and has just barely crossed the threshold to lock controls.

Lawnmower tilt part 1

This gif shows the lawnmower tilting but with the player recovering from the tilt shoving.

Lawmowr Tilt System

Throwable Selection System

The throwable/item selection system is what picks what items to give the teams during a match
- Selecting an item occurs after a care package breaks, and is affected by:
  - The current weighting/chance of an item since last round of selection
  - How many of a particular item is active in the game currently, per side
  - Various other designer defined rules (via a table)
- After an item is selected, the weighting for all items for that teams is updated based:
  - Which item was selected last
  - How much time has passed in the game
  - Rarity adjuster settings (based on game time)
  - Category adjuster settings (based on game time)
  - Various designer defined rules (via a table)
- There are two separate lists for each team; the regular dropping list, and the lose bad dropping list.
  - The lose bad list has a separate set of adjusters and rules from the regular dropping list, but uses the same set of items.
Testing and Debugging the system
- The system has a way to simulate a game for N number of times; this allows designers to have the throwable system spit out a bunch of trial runs of into a series of CSV files
  - Uses console commands to set special variables and also to run the simulations
  - Pro: Allows for multiple quick tests of the system, which allows for verifying that roughly the intended chances for throwables occur
  - Con: Can not simulate all exposed variables of the system by itself (Would require more controls)
- Another test option is to have the system spit out a similar CSV file at the end of each match
  - When the option is turned on, the throwable selection system prints out all data of the current match at the end of the game
  - Pro: All exposed variables for the system are used
  - Con: Requires full matches to be played, thus time consuming

Throwable Selection Spawn Gas Can

This gif depicts a gas can spawning out of a care package

Throwable Selection Spawn Rock

This gif depicts a rock spawning out of a care package

Throwable selection chance chart

This chart depicts the logic behind how a throwable is selected off the list.

Throwable Selection Spawn Gas Can

This gif depicts a gas can spawning out of a care package

Throwable Selection System

Grass Growing and Cutting

Grass is a skeletal mesh
- Bones are hidden or shown based on whether bits of two int32s were marked as cut or never show
- Bit masking and shifting in order to adjust those bits on the fly
- A bit manager actor is used to translated bit masks and index values back and forth as necessary
Two optimizations were applied to this system:
- When a grass piece is cut/grown, the grass marks itself as dirty, and refreshes the appearance of the grass on the next frame
  - This allows for grass int32s to take in all actions that may occur on the same frame between multiple players cutting or growing in the same area
- When a grass piece is cut/grown, it also notifies the game state that it has been dirtied
  - The game state upon being told one piece of grass is dirtied, then gathers up that team's grass and recalculates how much grass has been cut versus uncut
Grass can be cut via the gnome button mashing or else the lawnmower running over it
Grass can be grown by various throwables

Lawnmower cutting grass

This short clip shows the mower cutting the grass as it moves.

Grassbags being used to grow grass

This video depicts lawnmowers shooting grass bags in order to grow grass on the enemy's lawn

Grass and How it Works

This explains how grass works in the game and editor. The reason for the two ints being separated instead of one int is to allow for better readability. Though if necessary, one optimization that could be made would be to combine the two and just add more grass sections as necessary. A grass section = 1 set of collisions, and grass state data.

Lawnmower cutting grass

This short clip shows the mower cutting the grass as it moves.

Grass Growing and Cutting

Player Input with Pawns and Menus

Instead of having the keybindings be directly on the pawns or the menus, the controller has all the inputs bound on itself
- Reason to do this is so the controller can track which buttons are held down or not and handle clearing state data correctly off pawns and menus
When the reference to a menu is valid on the controller, it pumps input actions up to the menu, else it sends it to the pawn
When a menu opens up, all pawns have their widget reference set to the menu that is open
- This is so as menu control can be filtered via either the player that opened it, or everybody depending on player settings
This system also provides some more flexibility for rebinding inputs
- Presently only handles controller inputs in this way, planned to allow for controller presets, though the options are presently unavailable
- Even if the presets are not made into a player setting, they could be made useful if porting to platforms with different controller configurations

Player Input with Pawns and Menus

What Went Well

Implementation of coding standards at blueprint level increased readability, which also greatly increased productivity
Having the controller handle all input events instead of the pawns individually has helped keep the code clean and keeps the states of the pawns/menus easier to maintain
Familiarizing myself with the majority of the code base, and not just what I specifically was tasked to work on, aided immensely with diagnosing a large quantity of bugs

What Went Well

What Were Challenges

Team's desire to stay entirely in blueprint, even with the coding standards, made some of the larger systems difficult to maintain
- This also made eventually transferring the code down to C++ even more of a monumental task than if had been constantly doing it
Some of the experiments made to make other departments lives easier or as an optimization for the game needed to have other departments pulled in sooner so as to make the product more readily useable by the intended department
Making the exposed variables for the throwable selection system be easily understandable to designers (even with appropriate variable names and descriptions) proved difficult as designers did not read descriptions

What Were Challenges

What Was Learned

Push harder to have code base shifted down to C++ sooner, if in UE4
- This will save a lot of headaches later
Before starting on an experiment that is intended to help another department, discuss with a member of that department what they would want out of it first, and pull them in for testing when available
Even with the variable names and descriptions, write a wiki document
- Having the ability to pair those names, and descriptions with step by step instructions as well as pictures will greatly aid any department looking to better grasp a new system

What Was Learned

Gameplay Programmer

Table of Contents

Game Summary

Personal Contributions

Instantiating Coding Standards, and Transfering to C++

Lawnmower Tilt System

Throwable Selection System

Grass Growing and Cutting

Player Input with Pawns and Menus

What Went Well

What Were Challenges

What Was Learned