This evaluation purpose is to look back at the project as a whole and review the planning, development and outcome. I will be looking at the quality of the prototypes, the re-usability, the concepts used, what skills I have learnt and other aspects of the project. I will finally make a short conclusion, to sum up, my work as a whole.
Development compared to planning
For my first prototype, I was able to stay almost exactly the same as the plan itself. The reason why I stuck so close was because the plan had a great structure and told me how to achieve those programming concepts. I was able to draw out what exactly happened and what was the goals of the player throughout the two levels. Using the UML diagrams I was able to understand the progress of the prototype and what classes I needed to make. On the other hand looking at my class diagram I had rather limited knowledge on programming so I would say if I could redo it again I would have added a lot more classes that I had to create.
For my second prototype, I kept the same setting and genre but change all the gameplay. I had to recreate my UML for this new design, write out a new pseudocode and edit some of the programming concepts to suit concepts I missed out on my last prototype. While I could have stuck with the original plan, after three hours trying to create this prototype I found iI just wasn't interested in the original designs. I decided to try out something new with the same concept and see what new ideas come around. The reason why I decided to do with a new plan was the fact that the original had no new programming concepts to advance me as a programmer. So I based my new plans on the concepts I haven't done before.
Reflecting back I'm glad I took that risk as I have designed a better prototype with more complex and challenge concepts I haven't done before. My new plans had helped me understand the basics of what I was doing but most of this prototype was trial and error, to see what I could create.
Measure of quality
Throughout my development of these two prototypes, I have been measuring the quality of my programming. I have talked about efficiency ('Collision detection and handling' from 04/01/2017 ), maintainability ('Ice Physics' from 12/01/0217), and usability ('AI' from 19/01/2017). I have been able to consider how I have worked efficiency by using ready my nodes from the blueprint library. Instead of having to make the blueprint code myself which would cost me time, there are already made that makes production faster. For example, I didn't have to write out 'AI move To' in my enemy class ('AI' from 19/02/2017). I was able to use a node that was ready made in the character blueprint class. Overall I have been able to work with efficiency throughout this project.
Re-usability
Throughout the two prototypes, I have been testing my blueprints to see if they are reusable. I have tried many ways to coping classes and changing them to suit a new purpose. For example, in my 'Array' blog (posted 20/02/2017) I talked about how I was able to copy the 'Enemy' class three more times and only edit the static mesh and target points. I did not touch the blueprint script. They all worked perfectly.
The best experiment I did for re-usability was explained in my blog post 'Loop and instantiation' where I decided to migrate a blueprint class called 'PressE' for my first prototype to my second. I was able to show not only was I able to re-use classes within the same project, I could re-use classes in another project.
Further improvements
Looking back at the two prototypes I can see that there is still a lot of improvement to be made. I designed these two prototypes to display game concepts which could be made.
For my first prototype, I would have improved it by having a boss level at the end to show a more complex AI. Comparing prototype one to prototype two, prototype two had an end to the game where the player dies. Whereas with prototype 1 you finish the indoor level and that's the end. With this boss, I could have created a health bar and have the player hit him several times before he was killed. Likewise with the character, to further improve the game I could have added a health bar so he could have more hit damage and have a visual way to how much health Timmy had left.
I based my second prototype on my game concept from the game design unit from last year. I wanted to show what this horror game could be like, through creating this prototype. So if I was able to recreate the prototype in future, I would want to drive deeper into my concept and try out the other aspects I missed in this prototype. Concepts like the combat mechanics, more advanced AI for the enemies, use of physics like wood catching on fire, and how to code quick time events. I would use my game design document from last year as a basis.
On the other, if I didn't recreate this prototype and made further improve it instead I would improve the AI. As I said in my 'Array' blog post (from 20/02/2017) the AI being able to sense and attack the player would have been a better way to add tension within the prototype. This would have shown more of the gameplay style I was going for in my game design document. Right now my prototype seems to be more of walking simulator because of the lack of mechanics.
Testing
For both prototypes, I was able to do black box testing. I planned out these tests before creating the prototypes themselves. So I would know what I was trying to achieve at the start of the test. The reason why black box testing has helped me so much is because it has allowed me to test a function repeatedly until I am able to find a solution or alternative. The results of the testing have impacted the gameplay of the prototypes. For example, in prototype two I discovered that the blueprint kill player when he collides with an enemy was making the game unplayable as it kept restarting the game. So I decided to cut the stealth mechanics from the gameplay.
With prototype one, testing allowed me to better understand how to program. With the 'PressE' class, I used a tutorial which for some reason didn't work. So I decided to try and fix the blueprint, that still didn't work. In the end, with the knowledge, I learnt from the tutorial I created a new blueprint that did work.
While I did have peer reviews from peers to tested out my game, I didn't use their feedback to improve my prototypes. I should have had them test the game a lot earlier so I could have implemented their suggestions. Overall self-testing was a great success, where I was able to learn from my failures to become a better programmer.
Programming concepts implemented
I have been able to implement I wide range of programming concept with an in-depth description the basics, how I applied these concepts and why I implemented them into my prototypes. I explain all of this in the table below:
('Evaluation' post on 07/01/2017 from 'ProgrammingForGameDevelopment')
Overall I have been able to use a wide range of programming concept and improved those concepts that I learnt from last year. This is a great sign of progression and advance understanding of I have learnt. Game design concepts
With the knowledge learnt from my game design unit last year, I have been able to use what I have learnt to improve the design of my two prototypes. I have used a wide range of concepts for these two prototypes and here is a description of them below:
For both prototypes, I have considered what the interaction model is going to me. For my horror game, I go in depth about why I decided to choose first person camera and an avatar to interact with the game world.('Loop and instantiation' from 19/02/2017). The main reason was to add to horror theme to having the player be in the perceptive of the unknown character they are controlling. As the character is unknown the player will more likely project them as the character instead of just a player.
For both prototypes, I have been able to use semiotics to enhance the experience. For prototype one in my blog post 'changing colour' (from 09/01/2017), I talked about how I used colours to represent when a switch was activated. Red often represents off and green represents on.
For prototype two ('Loop and instantiation' from 19/02/2017) I called about how I used a skull and the colour red to represent death. I wanted the semiotics to suit the horror theme of the prototype. With the symbols of death, it foreshadowed the character's death in the next scene.
For the visual style of my first prototype, I talked about how I have design the aesthetics to improve my game ('Snow' from 13/01/2017). I made a snow particle system to add to the winter theme of the level. I also made a part of the gameplay apart of the level theme. The iceberg platform was a way to connect mechanics and visuals style to the overall winter theme.
For prototype two, I briefly talked about how I displayed visual style through enemy design('Array' from 20/02/2017). I created undead models to add to the horror theme. As the enemies, I showed horror visual style by the graveyard and crypts setting. Making the level take place on a rainy night and the moon turning moon. Whereas I could I added some visual way to add to the overall horror style.
I did talk about game flow in my blog post 'AI' (from 19/01/2017). Where I talk about how I introduce the player to an enemy and that enemy can't kill the player. Considering what the player has learnt so far I learnt that I needed to get them use to how an enemy would work but they prove a challenge later in the game. If I created a whole game I would make the next enemy encounter a challenge to test the player's skill before increasing the difficulty.
A new concept which I didn't learn in last years game design unit was 'design by subtraction'. I talked about this concept and how I used it in my blog post 'Collision detection and handling'. Where I explain why I didn't give any instructions on how to play prototype one. I didn't want lots of tutorials on how to play this game or a tutorial level which would take away from the main experience I am going for. I started the player in a place environment to test out the controls before any challenge start.
Why I used blueprint in Unreal?
When using Unity for my programming unit last year, I found that I didn't get on with the engine. It started off with a blank scene for my to work on. Whereas in Unreal it gave me a pre-creating character with ready made code for me to start playing with. Unity had a harder to understand interface and was less user-friendly. Most of the reasons why I decided to go with Unreal is down to my personal needs and understanding. I feel like unity is better for those who are more skilled with programming and I'm not. Whereas Unreal is easier to understand because it uses semiotics in its interface design. It colour codes what is what. For example, materials are green, levels are orange, blueprints are blue-est. It when has icons to show these as well
The biggest reason why I decided Unreal was the fact that I could use Blueprints. For someone who struggles with programming, blueprint gave me a safe place to test and experiment my ideas and learn from them. With written scripts, a beginner could be spending hours looking for syntax errors. While could be as simple as capital letters. With so many areas for fail at it can be hard for the beginning. Whereas with blueprints there are almost no syntax errors you need to worry about. It's the logical errors you get to focus on.
Skills learns
With the ability to use Blueprints I feel like I have been able to have a deeper understanding of all the programming concepts for last years programming unit. I have learnt the different ways of using collision detection and handling. Looking back at my development blog from last year I can see where I went wrong. For this code below, I can see that I haven't said which level the engine needs to reload.
('Fall Death' 06/01/2017 blog post from 'ProgrammingForGamesDevelopment')
I have been able to do the same thing and have my player restart in my prototypes from this year.
That is just one small example of the problems I faced last and what I have learnt this year which has allowed me to overcome those problems.
This year I have learnt to create two different types of AI: pawn sensing ('AI' 19/01/2017) and patrolling AI ('Array' post from 20/02/02017). I have learnt how to spawn objects ('Loop and instantiation' from 19/02/2017) into a scene. I have learnt how to have a conditional statement which opens a door once two switches are activated ('Conditional statements' from 12/01/2017). Finally, I have learnt how to create a form of physics ('Ice physics' from 12/01/2017). All of these was not able to create in my prototype from last year.
Professionally present this project
Researching into programmer portfolios I found a great example from Molly Jamesson (Jameson, M.2017). She had a page called 'Professional projects' and listed the games her has programmed for. For each game, she has explained the programming language used, her role, what she specify did in that game. For example, she explained she did all the boss AI for the game 'Ratchet and Clank' (Ratchet And Clank. 2016) with pictures of some of the bosses.
reflecting at how a professional programmer presents their work. For these two prototypes. I would create a blog that has a title for the two prototypes, description of what I had in the game, and that I used Unreal engine blueprints. I would have screenshots of some of the functions I coded. And because I have used blueprint I could have screenshots of my best example of blueprints I have made. Overall I feel that these two prototypes would be easy to present as I have used blueprint which is a visual program.
Time management
Out of 35 tasks, I have been able to complete 31. For the 4 tasks, I didn't complete I feel like they would affect this project in a major way. I have been able to keep to all three deadlines for this project with only minor tasks not completed. For example in my blog post 'AI' (from 19/01/2017) I wasn't able to complete all the tasks for the deadline so I moved those tasks to my next section on the taskboard. Overall I feel like I have been able to keep up to date with tasks and have them finished for the deadlines. This taskboard has been useful to show me what needs to be done and by what deadline. While it's not out task boards are professionally laid out. It has helped me for my own personal use.
Research
For both prototypes, I have been able to research a lot of different functions and ways to create specific things with blueprints. For example in my blog post 'Array' (20/02/2017). I was able to find a tutorial on how to create a patrolling AI. In most of my blogs, I have been able to find a tutorial on how to create some. Here is the list of tutorials below.
'Unreal Engine 4 Tutorial - Interactable Button' (Tesla Dev, 2014) from 'Collision detection and handling' (04/01/2017)
'UE4 Tutorial | Change / Animate Material Colors In-game' (Ormstad, B.2015) from 'Changing colour' (09/01/2017)
'Unreal Engine 4 Tutorial - Creating a Snow Particle System' (Jones. S, 2015) from 'Snow' (13/01/2017)
'How To Create AI And Enemy Basics' (Virtus Learning Hub / Creative Tutorials, 2016) from 'AI' (19/01/2017)
'Endless Runner: Spawning the Course' (Unreal Engine, 2015) from 'Loop and instantiation' (19/02/2017)
'Unreal Engine 4 - AI Improve Patrol' (Titanic Games, 2016) from 'Array' (20/02/2017)
As you can see I used a lot of different tutorials to help me out with these two prototypes. The research into how to create snow, AI, spawning object etc, has show allowed me to gain more knowledge of programming concepts and how to implement.
To summarise the project I would say learning through practice. I have learnt a great deal about programming through trying, failing, and fixing those failures. I now have a more advanced understanding that I had from last years programming unit. Researching concepts and implementing them as shown me new methods that I have tried out myself. Comparing this project to last years project this is a major advancement in quality, skill and management. while these are short coming like the fact my prototypes is lacking in functionary and the first is too short. The fact that I have been able to complete to two prototypes in working condition with no errors is outstanding to me. So I would call this project is a success.
Bibliography
Jameson, M. (2017). Professional Projects | Molly Jameson. [online] Mollyjameson.com. Available at: http://www.mollyjameson.com/professionalprojects/ [Accessed 23 Feb. 2017].. Professional Projects | Molly Jameson. [online] Mollyjameson.com. Available at: http://www.mollyjameson.com/professionalprojects/ [Accessed 23 Feb. 2017].
Ratchet And Clank. (2016). [DVD] Burbank, California, United States: Insomniac Games.
No comments:
Post a Comment