In 2017 I was taking a class on project management, studying software development after three years of bouncing between music, international relations, and computer science majors, when I decided to try my hand at making my first game. I should say our hand at making our first game. I wasn’t alone, I had a team of two other classmates. We all knew we wanted to make a video game, everyone on the team were video games lovers, and each had their own tastes. Big ideas were tossed around from an RPG, to a simple shooter, but ultimately we landed on something simple and straightforward. We decided to create our own version of Pong. Why Pong? It was important to us that whatever we were going to create could be made within our course deadline. The course was only five weeks (accelerated summer classes are killer), and being a project management class making the game was one part creative endeavor, one part exercise in seeing a project to its conclusion with a finished product at the end. Pong was something simple we all understood, were confident we could recreate, and could iterate on if time allowed. Having selected the game we were going to make, and determining our roles, the project got underway.
Docs Docs Docs
In addition to being the lead developer I had also been elected as project manager, and I quickly learned the game development process starts much earlier than writing code. My first task was creating a series of documents (remember this was a class, so everything was regimented). There was the project charter, the scoping statement, the team contract, the business case, shall I go on? I was surprised at the number of documents I was generating before we had done any content creation for the game. At times I’d get frustrated, “I just want to make and play this thing!”, but I did find value in the process. Creating the documents helped our team to clarify our vision for the game we wanted to make, it helped us to understand our limitations, and set our expectations. Most importantly, the documents gave us a shared understanding, a common point of reference we could use while collaborating. Considering we were taking the class online and working remotely, having a shared understanding and clarity of purpose was critical. Of course, some of our documents changed and evolved as we got into the actual development process, but having that shared reference never stopped being useful. Almost as useful as the model we were using to develop our project.
Scrum Fun
As this particular project management class was targeting software development students, we were expected to abide by a common dev model: SCRUM. I was elected our Scrum Master, which, if you’re not familiar with the phrase, means I was kind of a schedule, task, and meeting referee. I wasn’t the boss, I didn’t give orders, it was my role to make sure we stuck to SCRUM principles. We held weekly SCRUMs where we would take stock of what he had done, what we were struggling with, what we needed to complete our current tasks, and what was next. As I was also the project manager I’d spend time creating and organizing backlog items, updating our tracking tool (we used Trello), following up with my teammates for status updates, and adjusting as needed. I’m not sure how many project managers have also served as SCRUM masters, but it certainly kept me busy with administrative tasks in addition the programming I was doing for the game. Speaking of the programming let me get into the details of our little pong clone which we initially creatively called “Pong [working title]”.
Choosing an Engine
Before we had even started developing the game on paper the creation of our business case required we specify the game engine we were using. We wanted an industry standard engine that supported deployment on windows and linux, was designed for 3D development, and had a visual scripting language as not all of our team members had traditional coding experience. I recommended Unreal Engine 4 as I had experience working with it during an internship (that’s another story!), and it seemed to meet all of our criteria. With our engine chosen we started designing our pong clone, and since we’d taken on the team moniker “Jedi Masters” (can you tell we liked star wars?) our game needed a new name: “JM Pong”.
Designing JM Pong
Now, I’ll be honest here, we didn’t create any documents to outline what the basic loop of pong would be. Since the team was small, only three people, and we all had a clear understanding of what basic pong was, creating a fully blown design document seemed superfluous. We also took a fly-by-the-seat of our pants approach with our game menus, which in retrospect wasn’t the best choice but it certainly was an educational one. What we did take time to design were some alternate game modes. We designed these to be stretch goals in case we finished our main requirements early. Five alternate game modes were designed, totally six in all: normal, handball, football, hockey, squash, and quidditch. You can read about all the game modes later, but I’ll highlight two of my favorites here:
Football
A multiplayer mode model loosely after football. Player 1’s paddle is positioned on the left side of the screen, player 2’s paddle is positioned on the right. In the center of the screen are a series of ‘lineman’, non player paddles that move up and down a set distance. Each time the ball passes a player paddle their opponent scores three points. The goal is to reach 9 points.
Quidditch
A two player mode model loosely on the fictional sport Quidditch from the Harry Potter series. Each player controls three paddles, in a triangular formation. Near the horizontal limits of the screen are three goals. The object of the game is to strike the goal with the ball. Each time the goal is struck the match is reset.
(for some reason I couldn’t find the diagram I had made back in 2017, I guess it has been lost to the ages…)
With our concepts done we started getting our hands dirty with the Unreal Engine building our pong clone. Our first milestone was simple: create the components necessary for the basic loop of pong. For us that meant creating:
- Two player controlled paddles, one on the left side of the screen one on the right,
- The ball,
- Rigging up the necessary controls for player one (WASD), and player two(arrow keys),
- Setting up the physics for the ball, paddles, and walls.
- Resetting the ball to center after it left the right or left side of the screen
Building JM Pong
Within about a week of scripting with Unreal Blueprints, and creating some basic 3d assets our first milestone was complete. It was functional, but it lacked a lot of key features. Sound effects, music, score keeping, a win condition, menus, settings, and the ability to reset the game without having to close and re-open the application.
Our second milestone was to add some of those key features, score keeping, win condition, basic start menu:
It was coming together nicely, with each sprint (about one week of work for us) it was looking more and more like a finished product.
Third milestone was adding polish and some quality of life features: music, sound effects, a redesigned main menu, a pause menu with settings options for toggling paddle speed, music, sound effects, and background.
JM Pong, the Final Product
At this point our project could have been submitted, but we had about two weeks left in the course, so we decided to implement our stretch goals, the alternate game modes:
Normal Mode
It’s pong! Two player paddles, first player on the left (using WASD), second player on the right (using arrow keys). The object of the game is to knock the ball past your opponent. First player to 10 points wins.
(No diagram for this one, we didn’t feel the need to remake the wheel here)
Handball Mode
A single player mode to practice skill. The player paddle is positioned on the left hand side of the screen, with a solid wall opposite. Each time the ball strikes the wall opposite the player a point Is scored. If the ball passes the player paddle the game is over. The object is to get as high a score as possible.
Football Mode
A multiplayer mode modeled loosely after football. Player 1’s paddle is positioned on the left side of the screen, player 2’s paddle is positioned on the right. In the center of the screen are a series of ‘lineman’, non player paddles that move up and down a set distance. Each time the ball passes a player paddle their opponent scores three points. The goal is to reach 9 points.
Hockey Mode
A multiplayer mode modeled loosely after hockey. Each player controls three paddles that move in unison, a goalie and two defensemen. The object is to score 10 points in the opponent’s goal.
Squash Mode
A two player mode with a twist. Both player’s paddles are positioned on the left side of the screen. The screen is divided horizontally with player 1 occupying the top half, and player 2 occupying the bottom half. Paddle movement is restricted to the respective player’s region. Opposite the players is a solid wall that bounces the ball back, similar handball. The object of the game is to score 10 points in your opponent’s goal, but be careful it is easy to score on yourself!
(No diagram to share here, another one lost ☹)
Quidditch Mode
A two player mode model loosely on the fictional sport Quidditch from the Harry Potter series. Each player controls three paddles, in a triangular formation. Near the horizontal limits of the screen are three goals. The object of the game is to strike the goal with the ball. Each time the goal is struck the match is reset.
(Again, no diagram, that’ll teach me to archive better!)
Looking Back
I was incredibly proud when we submitted our final version of the game for the course. Not only had we completed our main objective of recreating basic pong, but we did it with enough time to fit in our stretch goals as well. It was a humble little game, maybe not that fun for anyone who didn’t make it, but my teammates and I poured ourselves into the project. I can’t speak for the others, but I learned a lot about both developing games, and managing a project. I deepened my knowledge of Unreal Engine, got a crash course in SCRUM, and got hands on experience leading a team and managing a project to its conclusion with a finished product at the end. I learned is that making games isn’t as simple as creating the perfect schedule, writing a full-proof set of documents, writing the best code, or creating interesting art and sound assets. Gaming projects, and I guess all projects by extension, require vision, clarity, and constant communication and collaboration. I feel the most valuable thing I did as project manager was to facilitate and encourage our team to keep communicating, stay open minded, be flexible, and never be afraid to ask for help. We were all in it together after all.
Making JM Pong was a great experience, and considering it was my first completed gaming project, I consider myself fortunate. It’s been enjoyable reflecting on JM pong and sharing my experiences with you. I hope you found something useful, or at lest interesting, and I appreciate your time and company in reminiscing. I plan to continue cataloging my development experiences here, not all of them were completed like JM pong, but they all taught me something. Check back soon for another chapter in my game development story.