#xb2178

Goals for specialism

My aim within the industry is to become a narrative designer, a role that combines both gameplay and storytelling, as such I felt a fitting specialist project would be to create my own dialogue system as well as a story, characters and dialogue to go with it, which I felt worked well towards my aim, I was also planning on doing all the modelling for the assignment as well.

For the first part of my specialism I focused on just getting the framework for the dialogue system working, a challenge in itself given the sparse resources on the subject of dialogue based systems, the few that are out there are limited and outdated and inevitably lead to more problems down the road anyway.

However by the end of the first semester I had a solid, if not a little janky, working base to build upon going into my second part of the project, where my goal was to improve upon the system as well as write a story and dialogue with about seven characters to talk to.

Of course not everything goes to plan, in fact it rarely goes to plan, as such there were numerous changes throughout the project for a number of reasons, some good and some bad.

Modelling

One of the first major aspects of my plan that I changed was myself doing all of the modeling for environmental assets and for all of the characters as well, I instead opted to use premade assets and to do none of the modelling myself, I changed this for a number of reasons but the most prominent would have to be that it was for the most part irrelevant to what I want to specialise in, nameley narrative and gameplay. I felt this would have distracted from the more important areas of my project and at the same time they didn’t really push me towards my own goals. This combined with me being somewhat burnt out when it comes to modeling for sci-fi environments ultimately led to me deciding against doing the modeling for the level. This would also free me up to work harder on both the dialogue system and actual dialogue for the characters, as well as giving me additional time to bug fix and refine the game rather than rushing out a project that does everything in a medicor fashion.

In the end I feel this was definitely the right call for the project as to try and do all the modelling would have only led to lesser results on all fronts

All environment art assets were acquired from the unreal marketplace, all character models and animations were acquired from Mixamo

Amount of characters

So when planning out the story and characters for my game I had planned on their being more characters than ended up being, I envisioned about eight characters in the game that the player could speak to and gain information from, as the story is a murder investigation I was going to have four suspects and four information givers, however I found that too many characters would be too confusing to keep track of and two of the information givers were rather meaningless to the story. Also wary of the games length becoming a tad overlong I decided the best course of action would be to merge some of the characters together, this kept the story a little simpler and a little more concise while also making the four main suspects seem more intertwined a little bit.

The end result is five characters in total, one information giver/ tutorial and then the four suspects whom I merged most of the information giver dialogue into.

Objective Marker

One thing that I decided to add as oppose to remove was objective markers that point the player towards the characters they can talk to as I felt it would be too easy for player to miss speaking to a character by walking past them and just not noticing them, the objective markers ensure they notice all the characters.

They objective marker works similarly to the game Dishonored, were when facing the marker it appears more prominent but when facing away from the marker it scrolls around the edge of the screen, it also tells the player the distance between them and the character they wish to speak to.

It was actually rather simple to create in the end as the instructions for how to make it were easily findable online.  

Journal

A feature I was originally planning on having a journal list or evidence list of sorts that would provide the player a way to see the info they’ve already gathered, I managed to implement this in a basic form but I ultimately removed this for a few reasons. It would make the investigation too easy and I wanted to strike a middle ground in terms of difficulty and I wouldn’t have enough time to properly balance it, the second reason I removed it was because I wanted players to pay attention to the dialogue and not just skip through only to read the journal list at the end, I felt this was the best way to encourage players paying attention. And finally the last reason I had it removed was because of me having lowered the number of npcs in the game which made the story and characters easier to remember, had I kept the original eight characters that I had planned then I would have probably kept this feature too but with the lowered amount it works fine without.

Dialogue System

So obviously a major part of my project is the dialogue system so I felt it extremely important to get this right especially.  

I already had the framework from the first part of my project but their was still a lot to improve on, one of the first things I aimed to improve was the possible length of a conversation sentence, in the original dialogue system for the first part of specialism it was restricted to one sentence replies from the npcs which didn’t create for very fluid dialogue and made it extremely hard for me to get an adequate amount of information across, so I saw this as the first thing to improve, I blueprinted a system that let npc’s have continued sentences which allowed me convey more information to the player and extend conversations naturally where they would occur which gave me a lot more freedom when it come to writing the dialogue.

For much of the rest of the project, the improvements I made to the dialogue system were to make it easier to use on my end, making it faster and more efficient for me implement my own dialogue and sorting the blueprints into reusable functions that allowed me to streamline the process, while it still wasn’t great or even that practical to work with, it was still a lot better than before the second semester.

Finally I improved the UI of the dialogue system, where it had previously been using a weapon wheel for its dialogue wheel, I changed it to better suit the six option limit I intended for the dialogue. I also added an overlay so that the text stood out against the background and option boxes with lines drawn to the wheel to make it clear which option the player is picking.

The Dialogue

The dialogue was surprisingly difficult to write for, while I was no expert when it came to writing in general, I’d had a little experience, but writing branching dialogue for a dialogue system proved quite the challenge.

Once I had planned out the story and characters I moved onto the dialogue, in order to differentiate between the characters, i planned each characters dialogue a little differently to each other, both in the structure of the dialogue branches and the dialogue itself, after all the dialogue was planned and written I tested it out in game to see which kind dialogue structure worked and which didn’t, finding some dialogue to be too easy to fail too quickly I went back and rewrote certain characters dialogue with one of the dialogue structures that worked better to ensure that players didn’t feel cheated or dissatisfied with how easy it is to fail.

A number of challenges arose when writing the dialogue however, specifically in writing enough options that were of equal quality to each other, it wasn’t easy writing dialogue for options that i knew no one would see. but because of the possibility that someone might just by chance happen to click that option I needed to make it the same quality as the rest.

Further challenges arise in trying to write dialogue for a game feature, were dialogue needs to be a certain length because too much could cause it to go off screen or clip into another option and each npc reply is another set of blueprint nodes that I have to make and implement, its also an interactive story driven game so replies need to be long enough that players feel they got a worthy amount of story from picking an option but not too much otherwise it would become boring.

There is also the issue of having to write dialogue that makes sense regardless of what players picked previously, which makes it really hard to reference back to previous things stated during dialogue because it's possible that this specific player didn't pick that option in the past and so it wouldn't make sense to them now.

What went well

The dialogue system, mostly, while it is still very janky even after I’ve polished it some I feel it ultimately succeeds at what I was hoping to set out for.

From people who have tested the game i've heard they liked the dialogue specifically, though I’m overly critical of my own work it is nice to hear such positive feedback all the same, it is however still an area that I wish to improve on going forward in future though.

I’m glad I managed to get the character models and animations in as even though they don't specifically relate to narrative design they do help players identify and reaffirm the characters personalities for the player.

What Didn't

Also the dialogue system, while I am overall pleased with the result it doesnt change the fact that this was the most difficult thing to make and refine of the whole project, hampered by its initial limitations as the tutorial that I used as a starting point for it clearly did not intend for it to be used for something like this and that it's incredibly impractical for such a full scale project.

Evaluation of Artefact 2

What went Wrong?

The first mistake I had made was having too much of a scope and ambition when creating the project plan. I had wanted to make two different characters, one in a hazmat suit and another one as a transformed version. Quickly realising early on in the project that doing both of those characters would be too much for me. I talked to my project leader and reduced the scope to only one body-horror character. Even so, I had made many time management mistakes as well as other mistakes that caused my time to do the full body character become very limited. This also included time put into other assignments pushing back this project etc. All this causing me to bring the project down to a non-retopologised head.

I feel that in this project the main things that went wrong were definitely all the time constraints and the misuse of my time whilst working on this project. There were a lot of times where I felt I could have used my time a lot better to complete the project as my original project plan. The biggest mistake that I had made was that I focused too much detail on the head too early in the project, meaning that I was taking a lot of time in doing little details that should have been done as polish after doing all of the base anatomy for the full-body. On top of that, to save a good amount of time I could have used the base mesh within Zbrush to save a large amount of time rather than starting from a sphere to sculpt on. If I had a human base mesh already in place, then I could have warped the anatomy then added details much earlier in the project.  

What went Well? 

Even with all the problems that did arise from this project, there were a lot of things that did in fact go extremely well. I am very satisfied with how the sculpt went for the head. There were a lot of things that came out better than I could have ever imagined when I started this project. I feel that I have learnt a lot of new techniques, workflows and tools that I can use numerous times in other models that I will be sculpting inside of Zbrush. Some of these include; how to use alphas efficiently in Zbrush and how I can use them to save time, creating ripped skin, the workflow of sculpting from a sphere, sculpting teeth, using the snake hook tool proficiently and many other things.  

Another thing that went well was definitely the Poly paint that I had done. Due to massive time constraints I had decided not to retopologise the model and instead texture it within Zbrush. I have never had any experience of poly painting before, but I feel like the polypaint came out much better than I had planned. I had planned to only get some base colour paints onto the model to give it more volume than just the sculpt. However, I managed to do a full poly paint of the model.

What would I have done differently? 

The part that I would have done differently about this project would have to be to reduce the scope by a large margin before the project started and be able to evaluate my skills to what I can make in the deadlines I am given.  

Overall feelings on project Overall I am actually pleasantly surprised with how well the final sculpt and paint came out. Yes there were a lot of problems and it is extremely different to my original plan, however I am satisfied with the results. As with the scope getting a lot smaller as time went on, I learnt more skills in Zbrush as I was focusing on the detail of the head rather than making a large body. Then I would have had to detail all of those parts. Therefore, I know that in this case it is a case of quality over quantity with my skills as they are as well as with all the constraints of other projects being done at the same time.

Final Model

For my Games Specialism assignment 2 project, I decided to create a multiplayer game. Each team has 4 players (4 red and 4 blue) who all work together towards completing objectives to add score to their teams value.

Score

If the scores hit 500, one of the teams completely depletes the other teams chest (situated on their ship) or the timer runs out, this will end the game and the advantage team will win.

Points are added to the team score when they kill a member of the opposing team, every time they click to take an objective or whenever a point is taken from the chest.

In terms of the game, it works well, with the score, health scores, objective health bars and player movement, including players swinging their arms to hit the opponent, all replicating correctly.

Goal of the game: Objectives

The goal of the game is to take the 3 objective zones. Objective A and C were designed to be closer to the spawn points for an advantage to the spawning team, with B being directly in the center to make it anybody's game for who will get there first and take it over.

The reason why I added objective zones into the game was to provide 'conflict zones'. These conflict zones are essentially where players are most likely to run into each other and begin fighting, which makes the game fun and interactive for players, as if players did not run into each other for the whole game, it would get boring and would just be a case of objective capturing, which is not what I wanted when creating this project.

To aid these conflict zones, each objective only has a certain number of ways in. If each objective was just a big patch of ground with no cover, players would instantly know where everyone else was. The way it has been designed allows for players to use cover and hide from other players whilst they are taking an objective or in conflict. The fact that there are only a certain number of ways in, 3 at objective A and C and 4 on objective B, will make the players feel slightly vulnerable, as they have to look around each entrance point whilst capturing the objective, or if working as a team, block those zones until the objective is taken.

I was hoping to add in a widget which told everybody when an objective had been taken, however, I did not manage to get this figured out in time, as widget replication is quite difficult in Multiplayer games. If I had more time, this would be something I would focus on attempting to fix. The reason why I would want this widget in would be to let players know that they need to go and recapture that objective from the other team.

This could provide some interesting game play situations, such as players taking the objective and waiting for the other team to come and attack one another, or allowing the other team to take it back and then retaking it after, as if the objective is completely taken, the team can no longer take from it and the scoring stops. The reason why I have set this to happen is so that players are continuously moving. If players can only gain a certain amount of points from an objective, they have to move to gain more points, meaning the other team can move in and take it back. If the score continuously rose, even after completely capturing the objective, each team would just take 1 objective and farm points until one of them reached the 500 score limit.

Buildings and line of sight

I have also added a number of props and buildings into the game. This is firstly to make the map feel fuller and more believable to players that they are in this world, but also to block line of sight and allow trap zones, leading to more conflict zones.

The buildings in the game add a layer of 'clutter' between the 2 sides of the map. This stops players being able to know the location of the other teams players as soon as the game begins and makes sneaking up on other players more eligible, as they could be hidden until another player wanders by then catch up to them. Blocking the line of sight also lets players stumble upon conflicts, as it could be hidden behind an object and when the player wanders round the corner, be thrown into the middle of an existing battle between other players. This makes players have to always be alert whilst playing

Some of the assets which I added into the game provide 'trap zones'. This is where there is only 1 way in and 1 way out, e.g. Buildings. As this is the case, players need to be wary of their surroundings before going into buildings, as someone could follow them in and kill them. Although there is no real reason for players to go into the buildings game play wise, explorer type players may wander in out of curiosity or to take cover or check if anyone else is in there. This provides smaller conflict zones, as there is more chance that conflict will occur if 2 people are in the same area in or around these areas.

Tactics

Players need to think tactically whilst playing. They can choose whether to take the objectives, go for kills or take the opposing teams chest. In testing, when players have found out where the other teams chests are, that is what they have centered towards. As this is the case, games in testing were over fairly quickly, as both teams rushed to the others chests. This is the biggest conflict zone in the game, as one team is going for it and the other are forced to protect it.

This mechanic was designed to add another layer of thought into the tactics of the players whilst playing the game. Having the chests means that players must keep an eye on it and working with their teammates to discover what the other team are doing. For example, if players decided to just protect their chest for the whole game, the other team could take the objectives and win on the score counter.

When creating the game, I wanted to add 3 game modes into 1: protect, capture and death match. I feel that these have come together well to form one big chaotic game mode, with players having to debate between protecting their own chest, capturing the other teams chest, capturing and protecting objectives and killing the opposing team whilst completing these tasks.

I feel that when players gain more experience at playing the game, they will start becoming more clever and using the chat box more wisely, allowing their teammates to know where they are and what the enemy are up to. This is where leader gamer types could take control and lead the team. The reason for this belief is that if 2 evenly matched teams came together as 2 teams of 4, they could form tactics to take objectives and protect their chests at the same time. Both teams doing this, would lead to interesting game play and the score could end up being the only difference at the end of the game.

Chaotic game play

When I was designing the level for the game, I wanted it to force chaotic game play. In order to do this I create the map to be quite small. The reason why I wanted it to be chaotic is on a personal level, when playing multiplayer games I tend to find the more chaotic games to be more action focused and this causes players to be more driven and immersed in the game, as there is barely any down time for players to be pulled out of the game, as they are always looking around for other players etc. Something else I found in my own playing career is that games which force the player to hold a button down rather than continuously click it can run the risk of the players being pulled out the immersion of the game. Therefore, when players are taking from the chest or objective, they have to continuously tap the button. This can cause frantic button mashing if other players are heading towards them as they are panicking and attempting to take as much from the objective zone as possible before they have to turn to combat, which can cause more panic as the players have to continuously click in order to swing their weapon. 

Audio in game

In order to keep the game flowing through audio, I have placed a soundtrack to play throughout. This soundtrack has a pirate theme to it and will let players get more into the pirate mood. This music is also quite upbeat, keeping the players hyped whilst playing the game and causing them to want to play more. 

Feedback

In terms of player feedback in game, the objective health bars will be displayed at all times and turn to face the player wherever they are in the world. This is so that players can always see the amount of damage an objective zone has taken. The bar is split, half red and half blue and will greater the colour of the taking player’s team colour. This is a visual representation of the objective health score which all players can understand as it is easy to read. If a player is on the red team and the objective zone’s bar is fully red, they know they have taken it. If the bar is half and half as default, they know they need to take from it. 

The game holds audio feedback too, as when player’s get hit, their character will play a hurt sound to allow them to know they have been hit. Without this, players will have to continuously check the health score, which can be distracting in combat and other players would not know if they are hitting them or missing them, so this is an indicator that their shots are hitting. 

Addictiveness

As the mechanics are quite simple, this game is quite addictive to play. This is good as it will keep players interested and coming back time and time again to play it, where they can learn more about the game and play more tactically. The game is addictive as it is constantly flowing and the immersion through the chaotic nature of the game keeps players on their toes and wanting to do well. The constant action of the button mashing keeps the players moving too and the combat keeps them concentrating on the game.  

Symmetry

The level was designed in a symmetrical pattern. The reason for this is so that neither team will gain an advantage. For example, if all 3 objectives were closer to the spawn point of 1 team, they would obviously take control of it first and would keep hold of it as they have less distance to travel back into the fight when they die, whereas the other team might have to run the length of the map every time they die, which would cause a massive imbalance and cause players to get frustrated, causing them to lose their immersion in the game. Keeping it symmetrical on both sides avoids this from happening.

Actual multiplayer set up

I have set the game options menu up so that players can change their name and add their own avatar. The reason for this is so that when they talk in the chat, other players know who is talking. Another element I added was that when players are in the lobby menu, they can choose their character and team. This allows players to play on the same team as their friends and lets them play as a character which may represent them better. Once a character has been chosen, the other players can not choose this one, so each character holds the player’s identity. Another reason why 2 players can not choose the same character is due to the scripting behind the scenes. When a player spawns in, each character has been designated their own spawn point. To avoid overlapping players, when one player has chosen a character to play as, nobody else can choose this character.

Aesthetics

I wanted to solely create the whole game with everything in it. For this to happen, I chose to have base colours on the models over realistic textures, as adding realistic textures would mean I would have to spend a lot more time completing this. If I downloaded the models, I would have to learn animation in order to have the characters move and fight each other correctly. Also, as the mechanics are fairly simple, I felt that having simplistic models would work with it. 

UI placement

I took reference from other games when designing the UI. The timer and scores were laid out like the way they are, firstly, to keep it neat and centered so they are easy to see, but secondly, I took reference from games like Battlefield One, Rocket League and Tom Clancy Rainbow Six Seige for the placement of the score and timer. 

What went well?

The game runs well and does not have any major bugs in it. When people played the game they found it fun and were panicking whilst frantically button mashing in combat. This is the type of reaction I wanted the game to produce. People were also asking to continue playing once the game had finished, which is a good sign. 

I feel that the level design allows players to feel free, whilst still restraining them between blocking volumes. I also feel that players having to seek out the objective zones allows for the conflict zones to be more effective, as it the objective scores were imprinted onto the screen for everyone to see, there would be no reason to go unless the objective status changed. 

I feel that the game play flows well and keeps players involved in the game until the end, even when the player dies and is punished for 5 seconds by being stuck at their spawn point. This mechanic was inspired by Rocket League, where if a player is killed, they have to wait a couple of seconds before they respawn and can get back in the game, which gives their team a disadvantage for that duration as it is 4v3 until they are back. 

When the player is killed, the game moves their location back to spawn. I feel this works well as it takes the player out of the game and gives the other team a slight advantage as a reward for killing the player, along with the physical reward of adding 2 points to the score.

What did not go so well?

A lot of time was spent trying to replicate the actions of the game over to the clients. Due to this, I did not get much time to implement feedback or textures, however, I did get it working in the end and that is the most important factor as I did manage to get a couple of testing sessions in and next time I do a multiplayer game, it will be completed a lot quicker as I know have the required knowledge. 

Originally the chests were supposed to move to allow the players to control their chest as it is such an important asset to the players in the game. However, the replication would not cross over correctly, causing the chests to be pushed around on 1 screen and not the other and for the asset to float. In the end, I decided to keep the chests static on the ships (which also gave purpose to the ships and would be more realistic for pirates to keep their treasure on the ship). Unfortunately, this caused players to know where the chest was all the time after they first found it and meant players just ran for that instead of killing opponents and taking objectives. If this was a real game project, I could implement this in a patch once it was working. 

I also created a minimap on the screen for players to always see above them. This was created with the purpose for players to be able to see where the objective zones were easier, as they could see the letter of the objective through the minimap, as the camera was showing the surrounding area above the player. However, when playing in multiplayer with another player playing, it would cast to the camera of the other player and display that, which would throw players off and give unfair advantages. Due to this, I took the minimaps out of the game. 

What would I improve next time and how would implement it?

If I was to do this again, I would do more research into multiplayer scripting before starting the task and testing some replication out so that I was not mid project testing scripts and getting frustrated that they were not working. This would have also saved time for the texturing and more mechanics to be implemented into the game. However, I am proud that I managed to get the game working, allowing 8 players to play and that people enjoyed playing it when testing. 

If I was to continue this project, I would fix the cameras on the mini map and get those working, fix the chest movement replication to allow players to be able to move it to where they wanted and hide the chests and make the health score of the player more prominent on screen so they did not have to check all of the other players health score at the same time as their own, especially in the times of combat, however, this was the most efficient way to get it working in time to test and hand in.  

Feedback and how would implement it

The feedback I gathered from play sessions were asking to add a mini map, fix a couple of buildings which were blocking players between the blocking volume and the building and setting it so that the chests were not as easy to get to so the game continued longer. I have already determined ways to fix all these issues, they are just not working as of yet.

Screenshots of finished game

Map design on paper

Map at the start of the project

Map at the end of the project

Bibliography

Music:

https://www.youtube.com/watch?v=T8k9y2hunuU - Epic pirate battle music -  Treacherous Waters,  Antti Martikainen Music,  Jul 28, 2013 

https://www.youtube.com/watch?v=MZMBxLnD4Lw -  (Epic Pirate Battle Music) - Battleship, Peter Crowley's Fantasy Dream,  Published on Dec 4, 2013 

Scripting:

https://www.youtube.com/watch?v=abmzWUWxy1U&list=PLZlv_N0_O1gYqSlbGQVKsRg6fpxWndZqZ - Unreal Engine, Jul 14, 2016 (How to set up multiplayer through Steam tutorial)

https://www.youtube.com/watch?v=hUEXdt3wITU&list=PL56pcT0mYsOgFmbwukjKppPI_Q7E89jTK, Rainishe2,  Dec 9, 2016 (Replication tutorial)

Replication scripting:

https://answers.unrealengine.com/questions/141733/cant-apply-damage-to-players-over-a-network.html - Apply damage over network

https://www.youtube.com/watch?v=yzpiU4TY_js,  W3 Studios, Jun 28, 2017 (Game State Setup)

https://www.youtube.com/watch?v=LrcbJrf3f14, Burnrate Dev,  Mar 23, 2016  (Character movement replication)

Reference links:

https://www.youtube.com/watch?v=hVuHih9dQhc&list=PLkoVGotZWNRQaAmjSvENKuDQKzuj9LG78&index=16

https://www.youtube.com/watch?v=nFjPVVKxlh4&list=PLM6ZWbxOgIqsCb3dUJRdYoUbyi_zFCOjs&index=37

https://i.ytimg.com/vi/ATqI0yqLPwE/maxresdefault.jpg

http://www.mobygames.com/images/shots/l/31938-unreal-tournament-2003-windows-screenshot-in-capture-the-flag.jpg

https://www.google.co.uk/search?rlz=1C1GCEA_enGB755GB755&biw=1920&bih=974&tbm=isch&sa=1&ei=dyclWrGVF4KPgAbmmbXQAQ&q=battlefield+gameplay&oq=battlefield+gameplay&gs_l=psy-ab.3..0j0i8i30k1l9.102732.103832.0.103983.9.8.0.1.1.0.57.354.8.8.0....0...1c.1.64.psy-ab..0.9.355...0i67k1.0.VhH68PqEjXQ#imgrc=uUP4_3_EF5Eo6M:

https://assets.vg247.com/current//2017/08/overwatch_junkertown_map_screen_9.jpg

https://media.playstation.com/is/image/SCEA/overwatch-origins-edition-screen-05-ps4-us-03mar16?$MediaCarousel_Original$

http://play-free-online-games.com/listmachine/uploads/image_team_fortress_2_1.jpg

https://www.google.co.uk/search?rlz=1C1GCEA_enGB755GB755&biw=1920&bih=974&tbm=isch&sa=1&ei=RzIlWtqqFaaBgAbw75ewAQ&q=third+person+multiplayer+shooters&oq=third+person+multiplayer+shooters&gs_l=psy-ab.3...57237.59483.0.59642.16.14.1.0.0.0.101.841.13j1.14.0....0...1c.1.64.psy-ab..2.3.219...0i13k1.0.CJfaFOnzJhU

https://www.youtube.com/watch?v=abmzWUWxy1U&index=1&list=PLZlv_N0_O1gYqSlbGQVKsRg6fpxWndZqZ&t=9s

https://wiki.unrealengine.com/CTF_Flag_State_Blueprint_(Unreal_Tournament)

https://www.unrealengine.com/en-US/blog/blueprint-networking-tutorials

https://answers.unrealengine.com/questions/42510/how-to-create-multiplayer-game.html

https://answers.unrealengine.com/questions/240300/how-do-i-create-a-split-screen-game.html

https://answers.unrealengine.com/questions/28143/use-xbox-controller.html

https://docs.unrealengine.com/latest/INT/Videos/PLZlv_N0_O1gZS5HylO_368myr-Kg2ZLwb/TinFTxeXDho/

https://answers.unrealengine.com/questions/452268/built-in-support-for-generic-usb-game-controllers.html

https://answers.unrealengine.com/questions/49973/how-to-activate-splitscreen.html

https://www.youtube.com/watch?v=ZOc9fV6Sap4

https://www.youtube.com/watch?v=68ViQFeE02o

https://www.youtube.com/watch?v=PpGdOCvWk74

https://www.youtube.com/watch?v=OcBMXIHUMLQ

https://www.youtube.com/watch?v=so0-0dafVsE

Okay, so this is gonna take a little longer than I’d anticipated. I’ve finally finished building the layout of the level, with most of the time spent on that dedicated to the background scenery. Everything that needs a collider has one, all the lighting is in place, and there’s even a van in there with the headlights on to designate the level start/extraction point (though I may include two additional options like a speedboat and something else).

Currently the map has been divided into five sections, areas of NO threat, LOW threat, MEDIUM threat, HIGH threat, and inaccessible (as with everything beyond the play area). The low threat area will have enough cover for the player to remain undetected for the sake of level start and end. Low threat will have patrolling guards who just stick to a strict route unless they spot the player. They will only attempt to catch the player, not shoot or raise an alarm. Medium threat guards are protecting player objectives, and they also have torches. These guards will both try to catch the player and activate an alarm. Finally, the high threat guards will have guns with torches mounted onto them. All they’ll so is try to buy a 99p flake off the player. Or attempt to kill them, I haven’t quite decided yet.

Anyway, my next task will be to implement an AI system for the guards, followed by obstacles, objectives, and finally player inventory, as I reckon items are key to stealth games, be it a torch, a map to navigate (there won’t be a satnav system), a noise maker, and possibly a weapon. Well, the weapon’s probably a given considering the player already has one, but I may give it a one-use suppressor and change the projectile from tennis balls to actual bullets. After all, if someone’s shooting at you, it’s probably best to shoot back rather than just annoy them.

Following on from the previous post (DD2000 Session 22), I had a brief chat with John on how I should go about creating a portfolio. He confirmed that I shouldn’t be displaying any work of a poor quality (that’s gonna be a tough ask!), but the overall idea was good.

Below is a quick mockup of it:

Art-based work will appear at the top, with design at the bottom. Clicking on an art thumbnail will load a high resolution image slideshow of the model, whereas clicking on a design thumbnail will load up a video showcasing it (perhaps along with a link to a playable demo) Clicking on individual tabs will bring up work made around that year, so my evolution can be tracked. Clicking “Art” will display all artwork, and vice versa with “Design”. Clicking the star will bring up the highlights, ie what I feel is my best work. Straight-forward and simple.

Moving forward I plan on completing my actual XB2178 assignment by next Friday, which looking at my rate of progress, means it’ll be finished by the first Friday back... Hopefully though the international break will free up enough time for me, so I can spend the entirety of the two week Easter break in Futureworks hammering out my XB2001/2 assignment with no worries about John’s assignments.