Jump to content
  • Advertisement

Baron Bale-Out

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Baron Bale-Out

  • Rank
    Newbie

Personal Information

  • Interests
    Design
    Education
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Baron Bale-Out

    Cyber Warfare Game continued 3

    Testing of my cyber warfare game highlighted a number of issues with the game. Firstly, players complained that there was a lack of information to utilise when try to identify the player that was the aggressor. To make matters worse, the lack of information was made a moot point when it was discovered that the events list did allowed all players to easily detect who the aggressor was. This was because if a player performed an attack, then their name would not be displayed on the events list, making it obvious that they were the aggressor. To tackle these problems, I changed some of the events in the events widget so that the text displayed was just three dots and so didn’t name anyone that wasn’t being active on their turn. This hid actions quite well. To give the players a bit more information to go on, I added an info widget to the bottom left of the HUD. With this, the players can cycle through all nations to see their stability and infrastructure stats, but not political power stats. This helped with attribution (identification), although on testing a second time it significantly increased the number of successful identifications. Attribution of cyber-attacks is supposed to be difficult. It may be because there are only four actors at play that an identification can be made. Expanding the number of actors involved in the game, and giving each a set of objectives would greatly increase the margin for error, but would also make the game more complex and time consuming. This would not be good for a game meant to be used in a classroom. Another issue players experienced was poor turn management. There was no way of indicating which turn the players were on. It was difficult to notice when it was a new turn because sometimes stats would not increase or events would be the same as the previous turn. Thus, I added a turn counter so the players could see when the turn had changed. I also added a ready list so that players could moan at the person who was dawdling at pressing the ready button. These changes were welcomed and the second testing session saw the players stick around for more runs of the game than the previous one. I adjusted values as well in an attempt to achieve a better balance. Normistan is still the worst nation to play as, because political power accumulates slowly for them at the start of the game. The base value for accumulating political power was doubled, and I reduced the costs of some actions so that they could be used before the game was over. As it stands, the project needs to have a lot of changes made to it for it to be a practical educational tool. Ideas and principles about cyber warfare that I have attempted to convey through this game, have been warped by the results of the games. Again, I believe this is because the game has so few players. Other problems include only two objective types. The fact that there is one aggressor and three players out to get him means that the attacker, who is supposed to be the powerful one in the scenario, is in fact watching his back as his efforts to complete his objectives will be noticed very quickly; unless everyone spends ten turns doing nothing which did happen a couple of times. That being said, I do believe that the project has potential and that further study and effort on it will produce a much more accurate and informative experience. Had I started testing a lot earlier, many of the kinks in the design could have been addressed to a higher standard. Nonetheless, players were actually having fun with the game (during the second testing session when I had improved it somewhat) despite the game being lots of button presses. Phrases passed around like ‘I’m going full detective’ as players really began to try to identify the aggressor. This project has also allowed me to develop my UE4 skills and shown me that my time management skills are in dire need of improvement. But at least now I know how to set up projects to network via the internet using the Steam plugin. That proved to be quite useful for testing. I believe if I had not made the effort to set up internet multiplayer, I would not have had any data for my paper on designing the cyber warfare game. https://drive.google.com/open?id=15DZ3uJnC4m36FysTLpnq3tG1muvGwuOk Use this link to download the game and have a play around. It needs 4 players and it uses steam
  2. Baron Bale-Out

    Cyber Warfare Game continued 2

    I have not yet been able to implement the information system into the the cyber warfare game. This was due to having to fix outstanding issues with the player actions. These actions now work correctly. The problem I had was replicating the appropriate variables to client players. I found that some variables were being replicated while others weren't and I lost many, many hours over the past two weeks trying to find a solution to the problem. Initially, I believed that the new blueprints I had added were missing connections between pins or that I had forgotten to add a particular node. Instead, the problem was incredibly mundane in that I had not taken into account that pawn and character blueprints are replicated by default whereas actors are not. As such, I could have saved myself a considerable amount of time when creating the effects system which manipulates each player's stats as I ended up passing information to the game mode in the server to apply effects from actor blueprints. If I had just noticed that damned check box I could have completed that system in much less time. The next two images show how much easier it is to make things work when you remember to click on a check box. The information I wanted form the objective actor for use in the player HUD was not accessible until the spawned objective actors were replicated from the server to clients. Of course, now that the players can interact with each other, an information system is urgently required so that players can determine who may be attempting to attack them.
  3. Baron Bale-Out

    Cyber Warfare Game continued

    The cyber warfare game I am creating is an attempt to demonstrate abstract principles of cyber warfare. The game involves players taking actions in a series of turns in order to fulfil objectives that are ‘cyber-based’. These actions are based on real-world applications of cyber operations, including: · Destruction of physical assets · Information gathering · Denial of Service · Cyber security Again, the game is an abstract representation and so these operations are not simulated at a tactical level. The capabilities of cyber operations are too vast and focusing on any one would diminish the effectiveness of the game to instruct players in the principles behind these operations. The aspect of cyber warfare that I am having the game focus on is that of Attribution. The ubiquitous nature of cyber operations means that the likelihood of determining the origin of a cyber-attack is infinitesimal. This also means that providing concrete evidence that the perpetrator of such an attack is from a particular organisation is also unlikely. Therefore, Attribution is more important in determining the identity of an attacker and how to prevent repeated attacks than clear evidence. Intelligence analysts would attempt to determine the identity of an attacker by examining the method of attack and who can produce the software and/or hardware for the attack. Of course, the attacker will attempt to deceive the analysts by using encryption or programming methods of another party. Thus, the analyst must consider the motives and capacities of all potential aggressors. This makes attribution somewhat challenging. Although principles of cyber warfare are the focus of this game, these principles are situated within existing and well-established theory. As I am covering in my paper, the current ideas about the nature of cyber warfare draw heavily from On War by Major-General Carl von Clausewitz and The Art of War by Sun Tzu. Therefore, any cyber warfare game should make considerations to the fundamental ideas as taught by the likes of Clausewitz and Sun Tzu. I began constructing the game with Clausewitz in mind and so I am having players consider and manage the political, social and military effects on the nations or organisations they are playing as. The game is played in turns. Each player chooses a target and an action to take against that target. The player will be able to affect an opponent’s national stability, information infrastructure or any of their physical or non-physical assets (as specified in the game). Taking actions produces intelligence which each player can use to determine which player is attempting to prevent him from completing his political or military objectives. To help refine the game, I have been researching Hearts of Iron IV. The game was built using the Clausewitz engine and I have been studying how the political, social and military aspects of Clausewitz’s theory have been gamified. Normally, players resort to the use of the military to deny other players from completing objectives. However, players will sometimes have focuses that when completed will deny another player from performing one of his own focuses. The recent update of the event system means that players now have another method of gaining resources or a strategic advantage or of incapacitating another player by attack his society instead of his military. Currently, players have simple actions to perform against each other that modify variables. I am now working on an information system that allows players to build a profile of the other players to determine who is attempting to stop them.
  4. Baron Bale-Out

    Dungeon Crawler Level

    Level Design The texts I analyzed for my literature review offered useful insight into design principles that I have attempted to follow. Ultimately, level design should enhance the existing core gameplay to prevent it becoming stale. However, this requires attention being given to several different elements that must be balanced. One of these elements is pacing. One of the more obvious methods of controlling pace in levels is through enemies. Positions, number type should be considered to control the pace. This is noticeable in dungeon crawlers such as Lara Croft, Diablo 3 and Gauntlet. Typically, the player will only face one or two enemies in his first few encounters. These enemies will also be terrible and of little threat. Thus, I have made the first few encounters in my own game against one or two enemies that only have melee attacks. Throughout the level, the player is subject to more difficult situations. I have achieved this by spawning increasing number of enemies in encounters. I also vary the scenarios by having the player be attacked from the front, behind and from multiple direction. Of course, the level should be fun to play. The enemy encounters throughout the level, despite the variety in circumstances regarding positioning and numbers, still can be quite repetitive as the standard enemies in the level do not change. No variants of this enemy or other type of grunt is introduced to force players to possibly avoid multiple attack types. The boss at the end of the level is the only change in enemy type and makes for a much more rewarding finish to the level, rather than simply fighting even more enemies with axes. Attention should be paid to ergonomics as well. The design should avoid presenting the players with scenarios or bugs that they will find frustrating. One of the problems that was identified in my level, by players inside and outside of the peer group, is that the environment itself lacks clarity or hints. Almost every player required direction from myself as it became unclear where to go. One such actor that cause this problem was the lift to the room before the boss fight. The lift platform was at the bottom, out of camera shot, so it was easily missed. Therefore, I changed the way lift worked by changing it from a pressure pad activation to simply overlapping the actor when stepping onto it. Other switches were also moved to be easier to spot as some were hidden at the camera’s edge. Originally, I put in a scenario to demonstrate that flaming statues could be ignited using projectiles as a hint for the door puzzle. Unfortunately, this could be broken and the hint lost if the player accidentally ran into the dart before it struck the statue. Again, this happened to almost every player and then the players would run around looking for a key that doesn’t exist. I removed this scenario and now an NPC appears to give the player helpful tips and sometimes state explicitly what to do. This explicitness is okay as the level design is supposed to be the game’s first level, where such direction can be expected. Another hint I intended the player to act upon was the use of pressure pads to activate the dart launchers. As well as identifying traps, the player can see dart launchers positioned in the boss arena to assist them with the fight. These launchers act just like the rest of the launchers in the level and as such can only be used once when activated. This caused problems for about half of the players as they discovered their usefulness and then set all of them off before the boss could be hit by them. The pressure pad system presented its own problem as players thought the pressure pad for the door puzzle, and the lift before I changed it, also activated traps and so initially avoided them. Overall, players found the layout of the level to be quite good. They appreciated the changes in altitude and direction that give the world depth as this is better than running along a flat, repetitive level. Trap placement was also like, as the traps offered opportunities to do extra damage to enemies, as well as offering risk versus reward scenarios, such as picking up the key on the pressure pad. The general concerns were the need for more clarity and a bit more variety in traps and enemies. Playability Players responded well to the combat mechanics as they find it fun shooting hordes of enemies that have inferior weapons. However, my concern is that the limited abilities of the player character will destroy and replay-ability as the combat gameplay will get old quickly. Suggestions for improvements included secondary weapons and some kind of special ability like throwing grenades. Combat has been improved though. The fire rate of the gun has been tripled, letting the player dispatch enemies quicker, and preventing them from being overrun by just a couple of enemies. It even makes the larger horde encounter much more fun as they can mow down enemies rather than run around like Benny Hill. The bullets also have nice, bright golf-ball-sized tracers to clearly show the player where they are firing. This is helped further by the player character having an idle aiming animation. Whilst there is more clarity, particularly in the level itself, than there was in previous versions, there is still room to improve when it comes to gameplay. I have used sounds and some particles to indicate to the player when something has happened, however some of these sounds are ambiguous and even fail to play properly. One example is when enemies spawn in. The sound only seems to play half of the time and there is no visual cue for the player to show that an enemy is about to spawn. More particle effects and visual cues would therefore not be amiss. This lack of visual and audio feedback makes it more difficult for players to keep track of new enemies, especially if more enemies spawn off camera. I have improved the AI. The boss can now switch to melee attack if the player tries to hide between his legs. The boss’s weapon ranges have also been adjusted to stop him from continuously swinging his sword at the air when the player has moved away from him. However, there is still a problem when the boss is stunned as he seems incapable of reacquiring the player as a target after the stun wears off. The player must run around the boss over and over until he realizes there’s a target. Obviously, no one does this as it’s easier to just shoot him and so take advantage of the exploit. There is also no particle effect to show he has been stunned and then the stun wearing off. Standard enemies are also more likely to connect with their axe swings now and be somewhat of a threat. Although this can be done in some encounters where their spawning positions means that they will quickly form a queue to be slaughtered. Adding an offset to their target location has helped but they can still be lured into queueing for death. These enemies, by design, are not supposed to be particularly threatening but this does make them completely ineffective. The gamepad controls were also received well. While the aiming system is a little complex as the player has to aim first, then change direction and then pull the trigger, the controls are simple enough and much more suited to casually running around shooting pathetic enemies. Some UI prompts would probably have been better for showing the controls to the player, instead of simply telling the player the buttons in the dialogue which is what I currently have. The player can also see what is going on a lot better as the camera is now at a higher angle above the world and the player moves and aims in the direction relative to the player’s perspective, rather than the world. Despite these improvements, the level (and game as a whole) still has a number of bugs and issues that could prevent it from being playable as players will no doubt find them by exploring. It is possible to skip past objectives, meaning the UI is not updated and so the player will be at a loss for what they are supposed to be doing. Players can also run around on the rocks in they run in certain places. There are also problems aesthetically that makes the game unclear and not particularly pretty to look at. But ultimately, the real problem is a lack of gameplay mechanics combined with a lack of variety in the manner in which they are implemented in the level. This is certainly a long way from being a playable game and more time and effort put into it would have been apt. Playable Build: https://drive.google.com/open?id=1cYhvARNe6g4HXDsV-fgms2qtIpfK4ZAD
  5. Baron Bale-Out

    Dungeon Crawler Level

    During the last two weeks, I have been attempting to rectify bugs and design errors within my level. I have overhauled the layout of the level to give it a greater sense of depth. I was unhappy with my previous layout as it seemed to be a long, linear path that occasionally ascended a little. The new level allows the player to gain and lose altitude and travel into corridors, rooms and larger open areas. The players can now make use of a lift as well as the stairs in the level, to give them a little variety. While the BSP is laid out in a manner that prevents the player from falling through the world and the characters are set to not be able to walk off ledges, some refinement of the BSP is required as players can avoid the door puzzle by walking along the edge of the path and bypassing the wall. The enemies are unable to follow them. It has been suggested to me that I use blocking volumes to stop the player walking off edges as they Can Walk Off Ledge Boolean cause them to hover in mid-air. The sense of depth in the level has been well-received during testing. Testers liked the feel of the world and complimented the ‘clear, concise level design’. Although the level is fairly short, the depth makes it seem bigger than it is. Of course, the depth is not without its problems. In certain spots, the player character was lost behind a wall or floor as the camera’s spring arm does not allow for collisions with objects. When this option is turned however, the camera snaps towards the player every time he walks through a door. This could break the player’s immersion as it is being pervasive. When interacting with the world, players feel that the world objects could use some more variety. I currently only have one trap (the dart launcher) that doesn’t involve ambushing the player by spawning enemies. This can be especially punishing to the player for no reason. I added sound effects to spawning enemies but since some of the spawns are happening off camera, the player does not know he is in peril until it is too late. I have begun to adjust spawn points for enemies but some still require optimising. The dart launchers are also inconsistent with the number of darts they fire. I did this to present the player with varying scenarios using the same mechanic to stave off repetitiveness. However, some of the players found the inconsistency to be annoying rather than challenging. This may be an apt position as the idea of this level is to be an early, or the beginning, level of the game. Doors also presented an issue, as I have yet to add features that would allow a player to distinguish between a locked, unlocked or switch-dependent door. The most obvious switch doors are those with flame statues next to them. Even so, players would still be puzzled (this is bad as not all the doors are supposed to be puzzling as they are unlocked) and this was not helped by the first encounter with a switch door being ruined when the player is hit by the trap that is supposed to open the door. Instead of witnessing a projectile hit the switch, the player is hit by the dart and then stands around not knowing what to do about the door. Frustrating. Also, being able to use switches universally for different actors in the world seemed like a good idea. But, using floor switches for both traps and doors often left players unable to progress because they did not want to stand on the switch that up until that point had tried to smite them. Interactions between the player and enemies are also of concern. Initially, the combat between the player and the enemies looked like a ‘Benny Hill sketch’ as the player could not fire the weapon fast enough (projectiles were also very slow) to kill more than one of the enemies before their position was overrun. In some cases, players retraced nearly the whole level to avoid enemies. Enemies would also spawn and become a large group quickly. Since this is the starting level, I am going to reduce the number of enemies in the ambush encounters and delay their spawning more significantly. The player should not be overwhelmed right away as it might put them off. I am still going to try it this way even though I have changed the rate of fire for the player. The response to combat after this change was very positive. Players enjoyed mowing down enemies as they did not have to keep running away to avoid being swarmed. The enemies were dispatched at a quicker rate, but not so quick as to be non-threatening. One or two enemies might make it to the player’s location and make them think about having to avoid the threat. The boss, while challenging and not frustrating, is easily exploited with some Dark Souls tactics by standing as close to his behind as possible. The boss is also prone to losing track of the player, even if he is looking directly at them. He can also continue to attack while he is stunned. However, players ignorant of these exploits will engage the boss as I planned and are kept on their toes by having to avoid the ranged attacks and then being chased down after doing so much damage. Players would figure out that the traps at the edge of the area could be used to harm the boss but each cannon has one shot. These shots were often all wasted as the player discovered he could in fact set them off. I will change this so that the cannons may be fired again after a period. Until this is changed, the reward for the player is immediately removed and it removes the experience they should have had of blasting the boss in the face with some big guns. When tested by my peers, the controls were generally liked. The Resident Evil vibe seemed to be a hit. Having to stand still while firing added a little extra challenge to combat situations that was received well. The inputs for the controls were not an issue. However, testing outside my peer group showed how the controls could be unintuitive to the average player. One player (Dad), could not grasp having to manipulate the left trigger, right thumbstick and right trigger for firing for some time and paid a lot of health for it. He also suggested that the camera should be at a greater angle to make the game more top down. Currently it is at its default setting. He would also have preferred a lock-on system to having to aim manually. All players, including myself, have trouble aiming even when the particle systems on the projectiles give an indication of where the rounds are travelling. This sounds extremely negative; however, my level was generally liked and the ability to shoot axe-wielding vampires was also somewhat satisfying to everyone. The remaining criticisms I am going to address soon when I begin to polish areas of my level. This includes elements such as: particle effects, sounds, visual clues and meshes. This will certainly help the player receive feedback from the world as they venture through it. I will also have to adjust the positions and activation of existing systems so that the players are not afraid of every door, and can actually observe a flame statue being activated by a projectile so they do not get stumped straight away.
  6. Baron Bale-Out

    Dungeon Crawler Level

    As part of my environment design module, I have been tinkering with simple trap and puzzle ideas and have tested out some ideas in Unreal Engine 4. These traps and puzzles will hopefully be applicable in my dungeon crawler level designs. Trap For my first trap, I have decided to create a version of a classic trap: the dart launcher. This is the first trap encountered in the original Tomb Raider that is not an enemy. This trap is usually intended to damage the player a certain amount per hit without outright killing the player. Darts can also be modified to apply different effects on the player such as poison, stun and sleep; just like real darts! For my own darts, I have created a dart launcher that can be edited by designers to fire standard darts or poison darts. The darts can also be given different life spans so they do not enter areas they shouldn't. The rate at which darts are fired can also be modified as well as how much damage the dart can do in one attack or over different lengths of time. Players know if they have been struck by a dart via sound effects. For poison darts, the player hears the dart hit them, then another sound effect combined with a particle system to show that the player is taking damage over time. The poison will eventually run out and the effects will disappear. The variables in the dart and the dart launcher could have been placed in structures to make the blueprints tidier. I could have also added the ability to edit the velocity of darts to add a new dimension to trap layouts. As for hinting to the player that these flying objects are dangerous, I could have indicated the danger beforehand by having a dart strike an unwitting NPC and kill them. This would alert the player about the potential danger before being put in a position to be hit by one. Currently, the only hint of the presence of darts is the sound of the cannon (standing in for a crossbow or some other dart throwing weapon) firing. Puzzle The puzzle is a simple pressure plate that controls the lowering of a door. To make the puzzle more interesting I have added functionality that requires the player to lock the door in the lowered position. This must be done by remaining on the pressure plate to keep the door lowered and firing a dart at the switch beyond the door. The switch cannot be hit without lowering the door. To hint that the switch, represented by a statue with a torch on it, is interactable, I have added a lone version of the switch to the start of the level. This allows the player to observe the switch being struck by a dart and causing an effect. On reflection, it would have been more useful for the switch to be linked to a door or some other object in the wold to show that these can be connected to moveable objects. The switch’s presence is also not immediately obvious to the player on approaching the door and requires the player to advance right up to the door to see it. This may make it less obvious as the solution. I would appreciate any feedback on parts I could improve or have missed.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!