• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

105 Neutral

About JToiviainen

  • Rank

Personal Information

  • Industry Role
  • Interests


  • Twitter
  • Github
  1. Unreal Engine - Pong

    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. Scenes 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! Main-Menu 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. Court 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.... Afterthoughts 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
  2. Specification

    I've finally managed to write down some initial specifications for the project. There are still plenty to think and reconsider, but at least some parts of the specification should be quite solid. Overview Operation Hillfort is an action shooter game which takes players into a fantasy world with mighty dwarfs and mysterious goblins. Game is based on matches, where each game contains exactly two teams; dwarfs and goblins. Players take control over a single avatar and must manage to help the team to capture or defend capture points within the map. Players The game will support solo and multiplayer gaming. Both types support up to 24 players per match, where each participant can be either human or AI controlled. Players are split into two teams of 12 players each, where both teams may contain human and AI controlled participants. One team will be the attacker trying to take over all capture points while the other will act as the capture point defender trying to defend points against the invasion of the attacking team. These attacker/defender roles also define a map specific race for the team. Maps will be designed in a way, where either dwarfs or goblins act in a role of an attacker. This makes it possible to design maps with a look-n-feel theme where they can take place in a goblin or dwarf territories. While the players play in matches, they can still stay in the same session after a match has been completed. This makes it possible to play next match along with same people (and same team). Game sessions also process an automatic map/role rotation, which tries to ensure that players don't get so easily bored. Look and Feel The view will be a top-down 2D view of a colourful fantasy world with trees, rocks, buildings and other kinds of environmental objects. Camera is locked to follow the player (i.e. the avatar) as it moves around the map. The zoom amount of the camera determines how far the player is able to see. This amount can be related somehow on the selected class or perhaps on some special items (e.g. catapult or ballista). Game visual design is a humorous colorful fantasy world with some special twist. Map locations can be places on above or under the ground, while mixes of these two are also possible. Underground worlds may end up containing lava or underground rivers, while places above the ground may contain beautiful forests etc. Visuals will also contain simple particle effects to improve the visual details and make the game world to come alive. Some graphical colour and humour style reference are Warcraft and Plant vs. Zombies: Garden Warfare games. Some musical and sound references from the both graphical references as well. Interface Players use a combination of keyboard and mouse to control the avatar. Keyboard is used to move the character as well as to change weapon or to select a special skill. Mouse is used to aim, shoot and to activate the selected special skill. The aim location is shown with a crosshair, which can be sized and differently rendered for each race or class amd perhaps also based on the weapon type or a possible blast radius. Interface contains UI items quite similarly as in the Plants vs. Zombies: Garden Warfare. Here are the four major component sections in the view: A health bar at the bottom-left corner of the screen, indicating the avatar's current amount of health. Ammo and special power indicators at the bottom-right corner of the screen. Currently active capture point status at the top-center of the screen. A scrolling invisible point console at the top of the health bar. Players will be guided to the active capture point with an arrow kind of indicator to prevent players to spend time to actually find the point. When a player has a visual sight of the capture point, this indicator can be hidden as the capture point will be clearly highlighted from the terrain. Start Up When a new match is about to begin, all participants will first load the map and then arrive into a class selection scene. Each player selects a class from their race, which defines the movement speed, maximum health, shooting type and special abilities for the avatar. After a player makes a selection, she/he will be transitioned into a in-game scene into a restricted starting area to wait for the go-go timer to launch the game. When the game is launched, players may proceed to either attack or defend the first capture point. Players may also join a public game during the game is in progress. When doing this, the player goes first into the class selection scene. Then she/he will be transitioned into a in-game scene and spawn into the role (attacker/defender) spawn area of the currently active capture point. Objectives Game objectives depend on the current role (attacker/defender) of the team. Both teams actually fight against time, but try to achieve different things: Attackers: Take over all map's capture points before the time runs out. Defenders: Defend any of the capture points until the time runs out. Capture points must be captured in a sequence, where a previous capture point must be captured before the next one can be captured. Each capture point has their own timer, which starts the countdown after players proceed into the corresponding map section. Entities Game contains avatars that are being moved around the game world by the players. These avatars are dynamic entities, which also contain different kinds of animations which may vary depending on the race and class of the player. These avatars are only a subset of the whole repertuar of the available entity types. See the following list of main types of entities in the game. Dynamic entities Avatar characters Projectiles (e.g. arrows, magic and bombs) Other particle effects Destructible world objects (e.g. doors, boxes and barrels) Special items (e.g. siege weapons, walls and traps) Some game user interface objects Static entities Capture point areas Non-destructible world objects (e.g. trees, rocks and most walls) Some game user interface objects The set of possible entities is kept versatile to allow a free-form map design. Key Features Game features will evolve along the process during iteration steps. However, I'll try to describe some initial key features here. Game mode features: Offline, which supports local gaming with a desired amount of AI players. Online, which supports online gaming with a desired amount of AI players and other human players. Match features: Each match supports max. 24 players. Each match divides players into two teams; attackers and defenders Each match has a time limit, which is based on the amount of capture points. Attackers win the match if they take over all capture points before the time runs out. Defenders win the match if they manage to defend any capture point before the time runs out. Idle human players (players not doing anything for 2 min) will be automatically removed from the match. Map is automatically changed after both teams have played the map on both sides. Match specific scores can be shown to users during the match (e.g. when they get killed or use a shortcut to see it). Match specific statistics (e.g. player scores, best player, other titles, etc.) are shown after each match. Game world features: Contains two types of entities; destructible and non-destructible. Contains a humorous, colorful and fancy graphics. Map features: Maps are split from four to six regions. Each region contains a single capture point. Each region contains own spawn areas for attackers and defenders. Regions are opened in an order, where the previous region must be captured by attackers before the next region opens. Avatar features: Players may change their avatar class during the match. Players cannot change their team during the match. Avatar visual appearance is based on; race, class and some minor player customization. Avatars have health, which defines how much damage they can take before they are being killed. Player name is shown at close of the avatar within the in-game view. Avatars can use two kind of attacks: projectiles and melee Race features: Game contains two races; dwarf and goblin. Race is always team specific, where all members of the team belong to same race. Race defines the look of the in-game user interface components. Class features: Game contains four classes for both races; heavy bruiser, projectile shooter, magician and light rogue Defines n-amount of special abilities for the avatar character. Defines the maximum health for the avatar. Defines the type, base damage, range etc. of the primary and secondary attack of the avatar. Defines the speed of the avatar. Attack/shoot features: Attacks have a cool down time, which defines the amount of time before the player may attack/shoot again. Attacks have a damage, which defines how much the attack target will lose health. Projectiles can be either explosive or non-explosive. Projectiles have velocity, which specify how fast the projectile flies. Projectiles have lifetime, which specifies the maximum lifetime of the projectile before it automatically vanishes or explodes. Projectiles move in a straight line. In summary, the game will contain high amount of identical functionality with the Plants vs. Zombies - Garden Warfare game mode Gardens and Graveyards. One of the major differences is that this game is a top-down shooter, while the previously mentioned is a third-person 3D shooter. It will be quite interesting to see how a similar kind of game works in a quite different perspective. I'll try to cover at least some kind of implementation plans in my next post. Thanks for reading!
  3. Idea

    Recently I've been brainstorming a new game which takes players into a fantasy world with dwarfs and goblins. Within this world, dwarfs and goblins have declared a war against each other. Goblins have stolen some ancient dwarf artifacts and in a countermeasure dwarfs have captured the goblin prince as a prisoner. Artifacts give goblins some supernatural crafting skills while the goblin prince provides some dark magic to dwarfs. In summary, both races have a bit of both skills at their sides. The game itself will contain elements where n-amount of players are divided into dwarfs and goblins. These races take turns where they act either in a role of an attacker or defender. Game maps (i.e. game rounds) are divided into areas which must be captures by an attacking team. When other race is attacking, the other acts as a defender. Attackers win the map if they can capture all map areas from the defenders, while defenders may win if they manage to defend any of the areas until n-amount of time has passed. This is quite identical with the idea behind the original Plants vs. Zombies - Garden Warfare. In the game, both of the races would contain n-amount of different classes that can be used to tailor the gameplay experience to fit for the players own play style. There could be slow and heavy bruisers, which could be contrasted with light and fast rogues. I'm not still sure how many different classes I'm willing to take in. Perhaps it would be good to have at least one bruiser, one rogue and at least one class somewhere between those two. Well see as the idea evolves. I've been also thinking that the game would contain some additional material(s) that could be used to build some support systems like siege or extra-defense structures. Each map would contain only x-amount of these special materials so the amount of siege power or the cover from the extra-defenses could be easily controlled. However, their usage would act as minor feature in the game. There are also three major keywords that I'm going to take my bullet points. User friendly Linearity Along with a twist I'll try to open up this idea in a more detail in my next post. Thanks for reading!
  4. That's a good note from Waterlimon. The ball and the controlled (i.e. owned) paddle could be considered as the primary focus points within the scene as they are the only entities which can be directly interacted by the player. This may make player to easily ignore corrections that are applied to the remote paddle positions. It could be avoided by creating a game where the players may interact directly with each other, like with a small FPS or such. However, this is something that is also considered when the results of the testing phase are studied. 
  5. Server online time is now extended to the end of the month.
  6. A bit more about the test implementation...   When a new game session is created, the server assigns a session delay from the 4 available delays (0ms, 25ms, 50ms, 125ms). This delay is used to hold incoming and outgoing messages for the specified time before they are processed. Same delay will affect the whole game session i.e. until all rounds has been played.   Techniques are selected in a random order from the four available techniques (pessimistic-presence, pessimistic-delay, optimistic-presence and optimistic-delay). Optimistic techniques are able to provide instant feedback to users while pessimistic techniques use either event serialization or event delaying before the feedback is provided.   As swiftcoder said, some of these techniques may become quite challenging to play with high latency values. For example, the implemented serialization will move the ball into new direction in a warping manner as the delta time from the previous update iteration may grow quite high. These warps may easily make a real-time simulation game to became a bit annoying if not impossible to play. However, I'll try to post some of the test results here as well when the testing part is over.   It would be great if we could get more people to participate as the current amount of results is still quite low.
  7. I'm writing a master's thesis about the consistency-responsiveness trade-off problems related to multiplayer online games. Thesis has now proceeded into the user testing phase, where potential testers are needed. So I decided to try whether I could reach a good amount testers via this forum.   The test is implemented as a simple ping-pong game, where each player plays 4 rounds.  Each round ends when either the player receives 10 points or the time limit of one minute is reached. Each round uses a different consistency maintenance technique, which typically affect the game somehow. After each round, the user will be queried about how she/he noticed these possible game-play anomalies.   Testing will take approximately eight to ten minutes. Each player may participate the test with their own computers by using their web browsers to navigate into the URL http://cr-tradeoff.cs.hut.fi . No additional software installations should be required. Players may use a keyboard to control their avatar and to provide answers to the queries. It is therefore preferred to use an PC while participating.   Server will be approximately online due to next Wednesday (13.01.2016) and it should be reachable around the clock.There's no need to register for the test and all players may participate anonymously.   Hope that as many of you as possible would take a part of this test! Thanks!   BR, JT    
  • Advertisement