Jump to content
  • entry
  • comments
  • views

Unreal Engine - Pong

Sign in to follow this  


It's been a quite long time since I previously used Unreal Engine to build games. If I remember correctly, the previous game was some kind of first person horror adventure game where the player was exploring the darkness in some kind of mansion or such. This mansion contained faceless doll creatures that would attack the player when certain conditions were met. Game had no weapons and player was only equipped with a small flashlight that allowed him/her to explore the mysterious rooms of the mansion. This project was a school project we created with my three classmates when I was studying my bachelor's degree in Turku University of Applied Sciences. So it's been around seven years since I previously touched Unreal Engine. And now, I decided that it's a time to dive back into the world of Unreal Engine and create something super cool... like an another Pong clone!

Installation of Unreal Engine

The installation process for Unreal Engine is quite interesting. Before the installation package could be downloaded, I needed to create an Epic Account. This account was then used to download the Epic Game Launcher application which was then used to install the actual Unreal Engine. I'm not sure why the installation needs to have so many steps, but perhaps Epic has good reasons behind it.

Installation was now complete, and it was a time to start the engine. During the startup it started to compile shaders, which took a while. I also had some problems with the Visual Studio linkage as the engine throw some errors about how it failed to compile sources for the project. After some googling I found out that I needed to install "Game development with C++"-module to my Visual Studio to get this link to work correctly. After installing the module, I was able to start a new project without errors and now I was ready to start my journey with the engine.


As with my previous implementations, I decided to use three different scenes. One scene for the main menu, one for the in-game court and one for the results screen shown after the match has ended. This kind of scene set requires only the following three transitions.

  • main-menu --> court, after the player has selected the "Start Game" menu option.
  • court --> end-game, after either player has reached the score limit.
  • end-game --> main-menu, after the enter key has been pressed.

In addition, we also have a special transition, which starts from the main-menu and exists the application after the user selects the "Exit" menu option.

If I haven't understood completely wrong, it seems that Unreal Engine calls scenes as levels. This makes my scene split quite interesting, as now I have a main-menu level and end-game level in my implementation. Somehow I feel that I've done something in a bit odd or wrong way.... But it works!


I decided to follow the same main menu structure what I used with my other Pong implementations. This view contains only four different components that should be shown on a top of each other. One label for the game title, another for the menu usage instructions and two buttons which are used to start or exit the game. This kind of simple structure would provide a nice way to get known with the basics of the user interface system in Unreal Engine.

Unreal Engine seems to have a support for basic and even complex user interface constructions via the Unreal Motion Graphics (UMG). After watching a couple videos, some tutorials and documentation, I managed to implement a simple user interface for the main menu. See the following images.



Thanks to blueprints, this was super easy to do. I only needed to add couple click-listeners and wire them with some simple navigation commands to get the transitions to work. Blueprints are actually reminding me of the old Kismet(?) system that was available in some version of the engine. I have to admit that I usually prefer doing all logic by coding it line-by-line. Still, creating the graphical user interface logic with a graphical tool felt natural. Perhaps it's a psychological thing or such.

To get the main-menu "level" working, I also needed to modify the level blueprints so the level would create and attach the main menu widget to viewport when the game starts. See the following image of the blueprints that were used as the level blueprints when the main menu was created.


This blueprint contains the same kind of logic that is actually used in quite many tutorials. And it works! At least for this kind of small game.


Now it was a time to move on to implement the court scene. For this scene, it was quite clear for me to follow the same kind of structure that I used with my previous Pong implementations. This structure contains two movable paddles, one moving ball, two collideable walls, two invisible goal areas, two non-collideable score markers and a one non-collideable vertical center-line at the center of the screen. This structure can be seen from the following image.


The previous image contains flags on each entity to mark the behavioral role of the entity. C is for collideable entities, which may interact with other entities. V is for visible entities that are rendered i.e. can be seen by the users. M is for moving entities that can move around the scene and P is for entities that are acting as player avatars i.e. can be controlled by the players. This kind of notation helps (at least me) to implement all items for the scene.

With my previous Pong implementations (i.e. JavaFX, JavaScript, SDL2 and Unity) I used geometry generation support to create graphics for the entities. This time, I decided to use the Unreal Engine's Paper2D sprite support to create visuals for the entities. I managed to use GIMP to write the following kind of sprite sheet for the court scene.


Well... I'm quite sure that my sheet does not follow the "industry" standards how sheets should be created but it works! There's some redundancy on some elements and such, but I wanted to e.g. keep paddle and number one as a separate element in the sheet and also to keep the ball separated from the middle line sprite section. The sheet used in the game differs from the image shown here as it has a transparent background. I also decided to use TGA as I heard and read about some transparency problems with the PNG, which made this as the first time I used TGA in any of my games.

Now it was a time to start creating some logic for the game entities. I first started with the C++ API but found that there were too many C++ monsters along this road. One of the monsters was that there were strange communication problems between the Unreal Engine and Visual Studio which made my source files to be opened multiple times. I even faced a a monster which did completely collapse my project so I couldn't event re-open it before I manually deleted some of my "invalid" code structures from the project. I'm quite sure that the C++ API is great when studied thoughtfully but I decided to take a shortcut and leave the huge C++ API aside and take the Blueprints path.

I had a bit confusion about where to store the actual game logic as there seems to be multiple suitable layers. I also found out that there is no actually a "right place" to put it as people seemed to put it in different places depending on the size and the features of the game. I decided to scatter my game logic into multiple places, where the level blueprint was acting as a centralized router for global events. I think that this worked quite well as the level blueprint has a good ability to directly refer to all actors available in the current level. After I did some study about how the event passing mechanism works, the communication between the game entities was quite easy to implement. 

I also had a requirement where the game results needed to be passed to end-game scene where they could be shown to players. I first thought that it would be quite trivial to implement this in a elegant way. However, I found out that my game results were attached to a wrong place as I needed a storage which would persist across the scene changes. I googled a bit and found out a solution to use a custom Game Instance to store this kind of data.

And then I finally managed to get all logical pieces gathered into a working solution.... 



I must admit that Unreal Engine is huge! It has lots of cool features and a support for many platforms and things that I haven't ever heard of. Those things that I learned about the Unreal Engine C++ API and Blueprints were only a tiny scratch of the whole set of functionality that awaits within. It's not a surprise that Unreal Engine is a globally popular game engine in game studios. I also think I managed to get a quite well working implementation for my game and perhaps I'm going to dig deeper (and even try the C++ API once more) with some later project.

Thanks for reading!

Game source in GitHub: https://github.com/toivjon/ue4-pong

Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By alien-project
      About me:
      Hi, my name is Christian and I am an enthusiast for games and simulations in the field of artificial life. I am an applied mathematician and have worked in my past for several years as a researcher on mathematical problems for damage mechanics. Currently I am employed as a software engineer.
      Physics engine:
      What I want to announce here is a 2D physics engine for damageable and glueable rigid bodys. Temperature effects such as radiation and heat conduction are also simulated via certain particles and internal energy distributions. The building blocks (nodes) of the bodys can be programmed by a simple assembler-like language enriched with physical actions, communication, sensoring and procreation functions. Portions of code is stored in each node as machine code and also potentially subject to changes. The code is processed by tokens moving/forking on a directed graph which constitutes the body. To get an impression of how the engine looks like in practice I attach some screencasts showing different examples. The engine performs multithreaded computations and is encapsulated in a C++-framework. I think it could be used to create realistic effects for space games. I am very interested in your ideas, opinions and constructive criticism.
      With the current implementation one could simulate rougly 50k - 100k building blocks with 30 fps using 8 CPU threads (measured on Core i7-6700). There is still no finished GPU implementation but after experimenting with CUDA I would estimate that 300k can be simulated
      on my GPU (GeForce 960 GTX). To get an idea of of the computational effort please think that every building block in the scene (size of a pixel in the video) can be glued or detached to/from a body and performs calculations or other physical actions. The high degree of dynamics in simulation (damage and coalescence, function of nodes can change) was one the biggest challenge in the development.
      For broader applications it would be quite nice to port this engine to Unity. But I fear that the performance would then decrease substantially.
      In order to demostrate the engine I had developed an editor/simulator named alien. It allows to create and modify simulations filled with bodys. alien provides a pixel view as well as a graph and code editor for designing and visualizing every detail in a scene. As an demonstrating example I have designed a replicating machines that consumes nearby materials (see video below). More complex machines with sensoring, communication and attacking skills are also conceivable. Thus the material in the simulated world could be equipped with life-like or even intelligent behavior.

      More information and download:
      alien-project.org (it's opensource)
    • By triplewoofer
      Hello friends!
      I've been working on some pretty simplistic pixel art lately, so I put together a picture of the parts of a tile set I'm making. In the picture, you can see grass (one patch with a lighter shade), a stone path, and some cliffs/hills. I've uploaded it to the post.
      I'm hoping to get a little bit of feedback on it - is it too simplistic that it doesn't do a good job of portraying what it's supposed to be? Is there anything you would recommend changing to make it look a little more realistic?
      Thanks so much, have a great rest of your day!

    • By sausagejohnson
      Last week, support was added to Orx for gamepad controller mapping as well as half-axes, analog thresholds and stick/button/trigger controls remapping.
      This is made possible by utilizing the SDL Game Controller Database initiative in order to standardize controller sticks and buttons.
      What this means for games is that no matter what type of controller you plug in, JOY_LX_1 means the X axis on the Left Stick of the first controller. This is much better than the previous JOY_X_1 which meant the same thing, but no guarantee which stick on your controller this would be. This greatly removes the need for creating a re-mapper screen to your games (though still good for convenience).
      An example of use would look like the following. Firstly the config:
      [MainInput] JOY_LX_1 = LeftRight Then in code:
      if (orxInput_IsActive("LeftRight")) {     orxFLOAT x = orxInput_GetValue("LeftRight");     //do something } There are a number of joystick tutorials that cover the new features.
    • By Masterbuiler64
      Good Morning, Afternoon, or Evening,
      My name is Dalton Potter and I am a budding game developer looking to learn skills and develop a beautiful project me and my friend came up with a year ago or so and have refined ever since. The idea is a basically a mix of Final Fantasy and Zelda in terms of exploration and battle, but will throw in its own unique features to switch things up a bit. What we have in place so far is the main story and many connecting character back stories, a map of the over world (still not 100% confirmed however), how some of the main characters look (also not 100% confirmed), a few battle and puzzle mechanic ideas, general story progression, locations, a few beta music tracks, and lore. What we lack however is any solid assets or work done on it as neither of us have any expertise in game development, but have both unanimously agreed that this idea is too good to forget and pass up.
      We are currently looking for people to help us work on the project as time goes on and maybe, just maybe, it may grow into a full blown team of people working on a game and eventually sell it on Steam or other client services. Any replies to this topic will be read as soon as possible depending on my schedule. I have also attached a couple photos and sound files of some design concepts we have. I also have a Pastebin made of the entire story and main character back stories, as well as history into how the idea came to be, though I'll let the Pastebin be requested as needed in the future.
      Hopefully this project turns from being just an idea into something amazingly beautiful and playable......it just needs to be created that's all.....
      Thank you in advance,
      Dalton Potter
      P.S. The sound file, "Power and Prestige" is a song that sounds as though it could be used as a trailer theme, and "Curiosity" sounds as though it could be used on a farm at sunrise.
      Source of music was from YouTube, but the groups official site is as follows: http://floatingcloud.net/
      EDIT: I am adding in a link to the pastebin so those that view this can get look at the story for the game. Link: https://pastebin.com/U7dKp8PS

      Floating Cloud - Power and Prestige.mp3

      Floating Cloud - Curiosity.mp3

    • By BlackSpoon
      Hi guys, let me introduce my new project - Just Smash It! It's all about destruction! Break your way smashing objects with aimed shots!
      * Realistic physics of destruction
      * Smooth game flow
      * Pleasant graphic and sound design
      * Infinite mode after passing the basic set of levels
      * Small size, great time-killer!
      Play Market: https://play.google.com/store/apps/details?id=com.blackspoongames.smashworld
      Feedback are welcome!

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!