Reflection Journal by Jake johnson

Week 1

So in the first week of our final major project we started off by presenting our group presentations in-front of our teachers and a worker called Jake who works at a games company called Void games. This was to show that we had a clear understanding of what we had to do in the project, our roles within the group and our inspirations behind our game. This in our eyes went well with the exception of not going on for long enough to last the full 12 minutes expected of us. Although in contrast to this we did go into detail on the presentation and maybe should have slowed down the rate at which we spoke in order to achieve full time.

I am in a team with Alton and Bradley. We are currently working on our 2D / 2.5D side scrolling game which has no name and the perspective is still undecided although in the following weeks expect this to be narrowed down and have a clear path set for the game. We are hoping to build on our already existing skills so that we may present the audience with the best game possible. In order to do this we must work collectively as a group to ensure that everyone is pulling their weight so the game doesn't fall apart. So far our ideas are somewhat cloudy and haven't really taken much shape, apart from the fact we have a story line set out which we plan on following for the remainder of the final major project. I think that to ensure we are keeping to a time schedule we should get ideas down on paper, decide what we want from the game and go from there, instead of throwing around ideas which lead nowhere.

One of the problems within our group is that none of us really know how to code. But I decided that it should be me as the other two are better at me with what they are doing. So Bradley is working on all of the sound aspects within the game as he is a good musician and likes to work in all the sound studios etc. Alton is working on the art side of things as his art skills are unmatched within our group so he was the best choice for the game to look good. I also got chosen to do coding as the other two didn't feel they had the skills to put together a piece of code so I am going to have to pull something off if I hope to get the coding done for the final hand in date.

Week 2

So in week 2 we have managed to make major process on our game. Currently I have created the backbones of the game in both 2D and 2.5D. This is so that if we do choose one or the other then we will have no time in getting it setup. Alton is also currently busy with the first concept pieces of art for our planets in the game. Yes, the game has finally got some background and is taking shape, we have decided on 3 planets on which you the player will fight on (yet to be given names). These planets will consist of futuristic civilisations with immense power and technology. One shall be a medieval setting, one a Japanese Samurai era and the other a Dyson sphere with its occupants living on rings around the contraption. (A Dyson sphere is a theory that civilisations advanced enough could build around a sun and capture its energy, producing immense amounts of power).

These planets all rely on each other for specific things and broader things. Both planets rely on the Dyson sphere corporation to get their power for daily life. The Japanese planet is relied on for its large amounts of food and other natural resources if the other planets are in need. And the Medieval planet is relied on for its immense military protection fro mother harmful civilisations and the technology that they themselves create. The main character is from the Dyson sphere and goes rouge after an attempt at making him accept harmful ideologies from his home sphere and the Japanese planet. These ideologies believe in an uprising against the bigger corporations but you know as the main character that this would mean the end of all the civilisations. Hence why you do not wish to help.

Week 3

So its now the 3rd week of our FMP and we have finally decided that we will go the route of the 2D perspective. This is due to the combined agreement that it would be asking too much of Alton to learn to make skeletal meshes and skin objects in Unreal Engine in the short time we have. So now the task is a lot less hectic with creating ideas for each of the routes. We can now focus on one thing at a time and take a theoretical step back from the craziness.

Brad has now also started to come up with ideas for the main audio and audio segments within the game game, as well as pitching plenty of ideas for a user friendly interface that the player will be able to interact with, without having a mental breakdown over where everything is. The audio for the game i.e main song, will most likely be of a Japanese string instrument type, but made to sound more advanced and futuristic, combining all three of the chosen themes of the planets. The reason we went for the theme is because we are using a collective of our own game design ideas from before we joined as a group and one idea that seemed prevalent throughout our ideas was this neo Japanese sci-fi theme.

I have now also started to look at how I can create a simple yet effective UI (user interface) as I did not know how to do this previously on Unreal Engine. This is probably one of the most important parts of the game as it is what gets you into the action and playing our game. I have also looked at smart AI and other resources to make our game as smooth a playing experience as possible. For me this is the most challenging part as I have only had experience in unreal engine whilst going through the tutorials in class. *Note* Alton has now also started looking at games which have won awards for best art styles so that we can take some inspiration.

Week 4

After talks with the group I decided I would start working on a stamina system for the game. This would make it so that the player could not continuously sprint and abuse the fact that you could sprint. This is a helpful piece of coding as it is more realistic that you cant just run for hours on end. We also had a discussion on me adding a crouch button which changed the players hit-box so that he could dodge incoming shots from the enemies within the game, this would be a useful addition as it means that if the hit-box didn't change then the character would still be hit when crouching

I have also started to Alton's artwork into the game so that we can model the game environment around the character so that everything is the right perspective. I'd rather do this earlier than later as it just means that I don't have to worry about getting the artwork and animations in at the last minute. This will help in the long run as to make it so I can spend more time on the coding, as this is not exactly my strong suit so I need as much time as possible. This also means that if there is anything wrong with the animations that it will help Alton with getting different animations and give him more time in the long run.

Week 5

This week I finished the code for the sprint and stamina feature we have in our game. This is a good feature as it makes it harder for the player and also makes it so that they don't just have to move at walking pace, this is better as our walking place is very slow due to the fact that he is supposed to be stealthy and it would mean that if we only let the player walk it would take years to complete a level. With a simple left shift whilst moving left or right the player can initiate the sprint and move faster or a set period of tie within the code which right now stands at 3 seconds

Most of this code was done using custom events, timers, positive and negative booleans and quite a few timing handles which were used to so that other timing events weren't effective after they had been called in the code. This is so the stamina amount, sprint speed and stamina regeneration didn't affect each other. This also happened to be the most tricky piece of code for me as I ran into a few problems where there would either be no stamina or no regeneration, this was promptly fixed by changing some of the values within certain pieces of code.

Week 6

There hasn't been much in the way of coding this past week as we haven't really decided what else we want in the game. One thing we all agree on is that we should have some sort of attacks within the game as this would be better than just running and avoiding enemies. There will be two attacks. One light fast hit, and the other and slower heavy hit which deals more damage so that you can kill them quicker and advance through the level.

This was done using some simple inputs and overlapping code blocks so that when you run the hit animations and its overlapping with an enemy it will deal damage to said enemy. This will also work vice versa so that if you aren't in an attack state and you overlap with an enemy it will damage you instead. If you end up taking too much damage then your character will die and display a death animation and you will receive a game over screen. at this point you can decide whether you wish to retry, quit the game or return to the main menu.

Week 7

Most of this week I spent tidying sets of code blocks within my blueprints so that everything was less jumbled and made more accessible if the need came to change things within the blueprints. The most difficult was the animation state as there are so many branches to get right because if one is on the wrong true or false exit then it will mean an animation will pay at the wrong time, i.e running whilst climbing.

That's the animation state machine and it is very crowded, this is after I cleaned everything up. This needs to be kept perfect as if things get too crowded again it will be unworkable and I will struggle to keep everything organised within the game. But most importantly the code needs to be kept clean as if I run the game and get an error I will be able to find it quickly and sort it out.

Week 8

So this week I had a major problem. On starting up unreal and opening my game to edit blueprints everything was fine. And for some reason still unknown to me I was greeted with a screen that was empty, with half of my blueprints missing. Damn.

And unfortunately the only version I have backed up is an older version which has even less than the version that is corrupted. Fortunately I have screenshots of the code I was going to use for this weeks journal so I can work off that and try to rebuild most of what I've lost.

I need to work on getting my game to where it was as otherwise I will fall very far behind and wont be able to complete the game

Update : Week 8

So using some of the screenshots I had I've managed to re-establish most of the game, minus one or two features that I didn't screenshot. Luckily they are only small bits of code and will be easily re added.

So during the time that this happened I looked at some tutorials on You-tube for help with some of the mechanics in the game. One in particular was a video that showed how to make the character have different shooting speeds and how to create ai that can be killed and can hurt the player in the game.

Week 9

So most of the game is fine now from the bump I hit in week 8.

The game now has its attacks in place for the character to be able to hit the enemies that will be implemented within the games levels. Below is an example of the two attacks that the player can do within the game. The light attack is activated by a left mouse button and the heavy attack is activated by pressing left mouse button and left shift together. I did this because it gives the player something else to do whilst playing through the levels and also adds a challenge on not getting hit.

(supposed to be a .gif showing both heavy and light attacks)

The good thing about this is that the attacks look so fluid when carried out and also that the amount of code needed is very small and basic which helps simplify everything. I added a light attack and a heavy attack so the user can manage their stamina correctly and also so that they can choose how they wish to take out the enemies within the level

Alton has been hard at work to get us more assets created for ideas in the game ahead of time before they are implemented so that we can just add them in smoothly and without a hitch, this is super useful as it allows us all to focus on other certain parts instead. Bradley has also sent me some audio which is important as the sound adds a lot of atmosphere and feel to the game. I will add the audio and art pieces into the game as

week 11

I have now implemented a ladder system into our game which is both developer and user friendly in the sense that its easy for both parties to use. I created this using a tutorial as I needed a ladder system where I could use more than one on each level and my method only allowed one, as when you used one ladder the other wouldn't work

This is the code that is used for both the collision within game that changes the characters movement from the X plane to the Y plane. Also set up is a little feature that makes it so instead of having to use 2 ladders to create one long ladder, you simply drag off the top of the ladder and create each ladder rung separately so you can choose how tall the ladder is. The reason i did this is because its so much easier to drag and choose the length that having to select separate ladder sprites each time. This just speeds up the creations of the levels and gets rid of unnecessary complexity

Week 12

A few weeks ago we showed our games to the other students and went around reviewing everyone's game at its current stage as it was. This was to help us find out what others thought of the game and what they'd like to see coming when the game was finished. After we reviewed the sheets of paper that had been left for the game its was clear that everyone wanted a main menu so that you choose to start the game instead of being loaded in straight away.

I added this because of the fact that it makes the game more user friendly and allows there to be more than just a level and a player. It also means that the player can quit the game from the main menu should they not want to actually play the game or need to do something before playing and don't want to leave the game running.

It also gives the player chance to change the resolution of the game should their monitor not support certain resolutions as older monitors have this problem aswell as maybe that the user doesn't have an especially powerful pc or laptop so they can run it in lower resolution for better performance in game.

I also made it so that the player collides with the enemies and that means they cant progress through the level without first killing the enemies, thus adding more of a challenge.

Report Abuse

If you feel that this video content violates the Adobe Terms of Use, you may report this content by filling out this quick form.

To report a Copyright Violation, please follow Section 17 in the Terms of Use.