Update: Map tools practice

I have been practicing with a variety of 3D map creation tools in the UE4. The link that did help me was this: https://www.youtube.com/watch?v=w2oDxgeBPlI.

The Unreal Engine tutorial has helped me a bit, but I could not for the life of me figure out how to get multiple layers so I can paint on.

This is what I have so far:

TournaMix Tool practice 1.PNG

Note: The final map is going to look much different, because this is just for practice.

A quick tip before you try making complex shapes. They are both Geometry tools or BSP.


Update: Unreal Tournament Map

I have chosen to do the DM-ArcaneTemple map and will start work on it after I have completed my research, mood boards and mind maps. This will be the first part I will be working on:

AcraneTemple underwater passage

There is more on the surface.

The map is on a deathmatch mode and starts off symmetrical with the outside of it being identical and the entrances being the same.

The map uses some outside scenery to immerse the player into the map. The scenery is made even better with the holes in some of the ceiling, so you can see the outside, which makes the maps feel like they are experiencing the map and time goes pass them:

AcraneTemple scenery.png

Something else  that is special about this, is the sky is animated; the clouds move in real time. That may not sound special, but since it came out in 1999, it is very special.

The amount of paths the player can start with is 2. There are so many paths in this map that it is hard to count.

Lets start with the first entrance, which is on the land.

The first path is linear, but after a few seconds, you’ll come to a split path. The path straight forward is a trap, sort of. By entering this you will drop down into the second area entrance. The other path enters you into a massive room:

AcraneTemple hallway.png

In this room you have multiple paths, the first is the way back, the second is forward and the other two are by the sides. The paths on the sides are identical, with a spiral staircase to the top. The path forward will bring you to this room:

AcraneTemple tripple staircase.png

If you follow this all the way up and follow the path, it will put you in the middle of the map, which should look like this:

AcraneTemple Map middle

The side paths also connect to this area.

From seeing all this, we can tell the developers are trying to lure the player towards the middle. On a bonus note, the most loot is found in this area, which again leads the player towards the middle. This is good, because bu luring the player to the middle, most matches won’t last as long and be played if you only have 5 or 10 minutes, for example.

Within this level there are three teleporters, 1 in each team base and one at the triple bridge area, which again lures the player towards the middle.

Analysis: Unreal Tournament CTF-Coret

CTF-Coret to me was rather  boring compared to the other maps, but there were a few good level designs and they are these:


CTF-Coret Sniper advantage

This area here is giving players on each side a sniping area, so they can get kills easier, however you are really easy to see, all a player has to do is look up. This is another risk and reward level design, but more on the risk side, because you are very easy to see in that area.


CTF-Coret strategy point

This here is a see-through floor and you guessed it, it’s a floor for seeing through. This is a lot different to the one I showed in the last blog post, however this is less of a risk to use, because all you need is a second or two to respond.

Analysis: Unreal Tournament DM-ArcaneTemple

Throughout the map I notice it used portals:

AcraneTemple teleporter

These work really well, because they stick out from the rest of the map. With the use of the teleporter, it makes the map seem bigger than it is.


AcraneTemple bridge  This was the next big thing I noticed; A bridge. This bridge may look useful and it is, but by using it you make yourself seen and you can be kill from behind, however the bridge gives you the opportunity to sneak attack enemies. In short it is a risk and reward level design.


AcraneTemple Sneak Shoting

This is the next good level design. This floor can be shot from and by doing so gives you easy kills and the enemy will not know what happened (unless they know about the floor area), however someone can sneak up on you and kill you, because you are looking downwards.  Another risk and reward level design.


AcraneTemple underwater passage

This is an underwater entrance. This is  to reward players that are adventurist by giving them a shortcut to a certain area or access to an exclusive area. Just by adding an entrance underground, it makes a game more re-playable and enjoyable, while adding in more strategy to the game.

Analysis: Unreal Tournament DM-Agony

I am playing Unreal Tournament and analysing the maps to see what I think is the best to recreate.

The map in this screenshot is DM-Agony

Agony Graphics.png

In this screenshot you are introduced to some interesting scenery.

The scenery tells you that you are underground in some type of dungeon. The lantern indicate that you area in the older time. Straight away there is a weapon in front of you, which allows one of your team to get a head-start, which encourages teamwork, because to survive you need to team up.

Agony Graphics 2

The scenery in this screenshot hints more at where you are, which I believe is a type of mine.

New Project: Characteristics and Context

Who I am and what am what will I be doing?

I am ScribbleChalkEvolve and I am starting a new unit called: Unit 10: Characteristics and contexts in art and design.


Unit Introduction

The task I have to do is, to look at three games and determine if the level design, genre and key gameplaye is good or bad, then research the game, either by physical or theoretical testing; Researching the game or playing it.

After I have done the research, I will recreate the map and try to improve it, either on my own or with a partner.

I will update you throughout the project.

FMP Evaluation

Project name: Bullet Switch

Project period: 29/04/2019 – 14/06/2019

The end of the project is just around the corner with just the last view write-ups to do. To see how I did overall, read this post: FMP Update: How I Did Overall and to find out how all the levels look in its entirety, read this: FMP Update: New Levels and an Overview of the whole game.

Project concept

The project concept I made was not as clear as it could have been, because I didn’t explaining the type of research I would do or the mechanics in enough detail. I adjusted this a little after finishing it, which now includes the missing information and a more detailed purpose of the project.

The research I did, mostly related to my project concept, but some of them may have looked like it was for another project. This was because, I was exploring game design as well as level design.


The planning in my project was done was at a reasonable pace. I may have planned a bit too slowly at the start, including missing a few weekly tasks, but after I got to the fifth week, I filled in the rest in. The tasks then were asking myself for a bit too much.

When I planned the tasks I wanted to achieve, I did also plan for the practical aspects I would need, like on the 27/05/2019 (week 5) task, which was sketching level layouts. The practical aspects of that was paper, rubber and a pencil. The one things I didn’t mentioned, was I also needed cardboard and/or other objects for representing the objects in the game.

Here is the full plan filled in (except week 7):

tasks weeks 1-8

I stuck to the plan almost entirely, but some of the times I did go a bit off track and added in more mechanics when it wasn’t in my plan. I did this because, it increased the quality of the level.

Not sticking to the plan fully maybe seen as a negative, but by not sticking to it entirely, I was able to improve level designs, puzzles and my knowledge much, much more than if I stuck to the plan.

What went right?

In the past couple of months I have made tremendous strides towards creating an amazing game. The following is what went right:

  • Level design – The main purpose of this project was level design and I believe I did this correctly. The levels had a consistent goal and always kept challenging the player.
  • Fairness – Continuing with level design is fairness of the game. I have tried to make the game as fair as possible.
  • My original goal – I believe I have did most if not all of what I originally sent out for; A puzzle game that uses a small amount of mechanics in a multitude of ways.
  • Mechanics – This wasn’t that necessary, but by creating a reasonable amount of mechanics made creating more puzzles easier and made them more diverse, which could be a problem if done too fast or/and incorrectly.
  • Puzzles – The puzzles I made were good in my opinion and others. All that was needed doing was a little bit of tweaking.

What went wrong?

Even though so many things went right, there were somethings that didn’t go right. Here they are:

  • Bugs/glitches/errors – The main issue I had were errors, but I did encounter some bugs with the software, which I did fix. It wasn’t all bad though, because I learnt how to solve them for future projects.
  • Using mechanics – In the most part I used all the mechanics in the game to a large degree, but I could have used the slide and teleport mechanic a bit more. I would if I was given more time.
  • Player feedback – I did include player feedback in the game audio-wise, but I didn’t include much visual player feedback.

Following on from the bugs/glitches/errors I had, these were the problems and solution (in no particular order):

  • Shoot at mouse location not working properly – The solution to this was to learn about the Mouse Location node and work out how it could be done on my own.
  • Teleporting infinite loop – A Boolean variable and a branch sorted this out.
  • Character movement not working – By adding in the character movement to the level blueprint whenever I had a jump wall (technically a jump door) or slide fixed this issue, this is because, by giving the level blueprint the jump key, it takes ownership of that key, meaning no other blueprints can use them.
  • Moving platform is buggy – The fix to this bug was very weird. To fix it I needed to reset the platform location and then start the movement, befote it goes back to step 1, otherwise it will go in the opposite direction than requested.
  • Character jumping too high – A fix to this was adding a collision box in that when overlapped will reduce the characters velocity, which means that they will start falling faster.
  • Music track mixing together/overflowing integer – The fix for this one is to create a controller, store the variables there and use a cast to retrieve the integer, which will be used to chose the song for that level. This will also stop overflowing from happening. The overflow bug seems to happen when you use a random integer node in the criteria of an equation.

What would I change and improve upon?

If I was able to edit the game more then I would change and improve the following:

  • Improve player feedback – Adding more visual feedback in.
  • Utilise mechanics more – I would start to use the mechanics I haven’t used that much to create more levels.
  • More levels – I would add in more levels with more visual dialogue.
  • Bigger music track – Increasing the size of the music track, but only adding suitable music.
  • Make puzzles that trick/think out side the box – I didn’t really know what made a good level specifically and now I do I would deliberately try to trick the player or try to make players think outside the box.
  • More puzzle combinations – I would also further develop the combinations of the mechanics to create more complex puzzles. I was starting to do this, but not in the same degree as I would like to if I had more time.

How important was the dialogue?

After talking to my colleagues I decided that it was not that important, but I should keep it in for the player to figure out the story.

A few comments I got were:

  • Mathew, “I hate dialogue shoved in his face.”
  • Thoughts – I have put this into my memory and will always try to make dialogue optional, unless it is important.
  • Rhys, “I Like dialogue, but not when there are pages of it
  • Thoughts – I know where he is coming from with this comment, but sometimes pages upon pages of dialogue is necessary, but I will try to keep all dialogue small with only keeping in the important parts.

What have I learnt?

I have learnt a huge amount from this project from all areas in level design, game design and mechanical wise. Here are the following:

  • Mouse events and inputs – I’ve learnt how to enable and disable mouse inputs and events. I used this for the shoot at mouse location function.


  • Storing variables throughout the game – I have learnt how to store and use variables in any map in the game. This can be used for a currency system.


  • Saving and loading – I haven’t used this yet, but I know how to save and load a game with any amount of variables I want stored


  • HUDs – With the knowledge on knowing how HUDs are made and used, I know can make more advanced UI screens.


  • Alter text – With this I can add in story and lore of a game.


  • Good puzzle design – My puzzles have became more fun and challenging.


  • Location change – I’ve learnt how to alter and set the players or object position. That is how I made moving platforms and portals.


  • Arrays – I knew this already, but I have realised how useful they are, even with just 2 objects.


  • Expand on a mechanic rather than make more mechanics – I have learnt how useful building on top of a mechanic can be. It is much easier building on top of a mechanic than making loads of nechanics to do the same thing.


  • Paper prototypes importance – I have learnt how useful paper prototypes are, even though I like to just jump straight into things. I normally did just add in level designs straight away, but occasionally there were some I ignored or altered a bit. This showed me no matter how successful my level designs always are, there will always be one bad one or more in the bunch, which can waste a lot of time. The only downside to paper-prototyping is a ultra close deadline, which can be 1 day or lower. The reason for this is because, the time taken to get everything setup or made. In some cases the paper-prototyping will still be important in an ultra close deadline situation.

There are probably more, but I can’t think of them currently.

I am extremely happy with my results and wouldn’t have been able to learn as much if I didn’t deliberately focus on adding a mechanic in.