Gameplay Programmer
Technology
-
Visual Studio (2015)
-
C++
-
GLSL (OpenGL)
-
-
Photoshop
Genre Networked, PvP 2D top down shooter
Platform PC
Development Time 2 Months
Resources Used
Table of Contents
Game Summary
In this 2D game, players can host game matches with up to three other players. The objective is to kill the other players with fireballs. There is no real score tracking, or anything like that. In order to connect with one another, an IP address has to be already set aside for the host, and the client has to connect to that port once the game has begun to be hosted. Players can shoot fireballs in one of 8 directions from themselves, or lay a fireball on the ground instead which will eventually time out. All players have three hit points.
The Intended Goal of this Project
Summarized Bullet Points:
-
Primary point of this project was to try and create a decent Networking System
-
Have the ability to connect a client to host.
-
Supports three message types:
-
Unreliable (Send and forget)
-
Reliable (Send and listen for if they actually got that packet)
-
In-Order Reliable (Same as previous, but also run commands in order to what they indicate.
-
-
-
Gameplay is notably lack luster
Gameplay in this one is pretty lack luster, that is as the primary focus was put on getting a decent Networking System up and running. This system supports Unreliable messages, Reliable messages, and In-Order Reliable Messages.
StateMachine and Basic Event System
Summarized Bullet Points:
-
Event System:
-
This version requires that the variables allowed in be defined during instantiation.
-
Due to this set up's rigid nature, this Event System is more of a local set up, than a global set up.
-
Can subscribe Function pointers and Method Calls on objects
-
Can unsubscribe Function pointers and Method Calls.
-
-
StateMachine:
-
Uses the above mentioned Event System with it's states.
-
Each state contains 3 events: Start, Update, and Stop.
-
-
StateMachine uses state_ids (aka: unsigned ints) to define what state they currently are in.
-
On the ChangeState call, it does not automatically switch right away to the next state.
-
Instead when the StateMachine's update is called, it calls "Stop" on the current state, and then checks if the state is finished.
-
If state is not finished, then it exits the update.
-
If it is finished, then it changes the current state to the next state.
-
-
-
Event header part 1 of 5. This is the simple version of an Event. It registers/unregisters functions and methods of a defined template set of arguments, and calls them when triggered. This type of Event system is intended for local events, and not world events. Aka: no easy console support.
Event header part 2 of 5
Event header part 1 of 5. This is the simple version of an Event. It registers/unregisters functions and methods of a defined template set of arguments, and calls them when triggered. This type of Event system is intended for local events, and not world events. Aka: no easy console support.
Networking System
Summarized Bullet Points:
-
Networking types supported:
-
Host, Client
-
Peer to Peer
-
-
Supported message types:
-
Unreliable
-
Reliable
-
Reliable In-Order
-
-
A packet is filled with as many messages as possible before being sent.
-
Known bugs:
-
Did not handle wrapping various IDs for reliable or in-order appropriately, eventually the message type will fail to send.
-
Currently does not destroy PacketChannel correctly on ending the networking session without closing the game. This means players can not exit a session then join another without first closing the game.
-
Reliable In-Order message type may not be fully lock up safe yet. (means that the system may lead to being unable to use Reliable In-Order messages.
-
The networking system supports three message types: Unreliable, Reliable, and Reliable In-Order. Unreliable messages are messages that get sent, and then the networking system does not care whether it reaches its intended destination or not. Reliable messages are messages that the networking system keeps track of a connections last highest received reliableID, and if a sent reliable message has not been marked as received, then it resends it after a while. A Reliable In-Order message works similarly to the Reliable message type, except that it does not run the message until the next expected reliable in-order message type has been received, then it runs them all as quickly as possible. Reliable In-Order messages also require an addition ID on top of the reliableID.
Instead of just sending one message at a time to a given connection, as many messages as possible are crammed into a packet, and then that packet is sent off to the connection.