Procedural Programming - Testing & Peer Review

To round this unit off, I have been tasked with creating a test document and a peer review for completion.

I have had my level tested by a peer, with two runs performed, one for playthrough purposes for peer review answers, and the other for testing. The test document consisted of 37 separate tests so to cover all of the transitions and animations within my level.

One segment of the test sheet can be seen below;

There were two issues within my level, one of which I had not seen before, and the other, at this point, is an unknown entity (the blueprint applied to the falling platforms in corridor 2 works for my peers, but only partially works for my own instance of the same blueprint implementation).

For the time being I have created a workaround for the falling platforms in form of a simple ramp up to the ending platform in the corridor.
The other issue however will take some further investigation, and tweaking within UE4, as despite the blueprinting for this element being solid, if the falling killer objects are destroyed in the process of killing the player pawn, the character will not respawn and break game progression. This would be an issue of the highest concern in the production of a full videogame.

I will be continuing to look into this issue both before and after submission date, to fix it and expand my knowledge inside UE4 that little bit further.

I also asked three questions of my peers, to gain peer feedback on my packaged level, the questions were as follows;

• Do you feel my level presents enough challenge?
• Do you think my level is long enough?
• Are there any ways I could improve the level’s functionality?

I received a mainly positive response from the two peers I have had feedback from thus far, with the only negative point being that of the issue with falling platforms not respawning properly.
The questions regarding the challenge and length of the level in itself were met with positive responses, and as such I will be looking to improve the functionality of the physics based traps in corridor 2, though with an identical blueprint working for one of my other peers, it may be a tricky fix, I will work on fixing this effective immediately, and may use the unreal forums for help if necessary.

Procedural Programming - Final level blueprints/conclusion

Through this unit, I have been tasked with producing a small level from base meshes, with the addition of any Infinity Blade assets already provided via the Unreal Engine 4 Marketplace.

I began by creating a top down floor plan, making simple use of a Room and Corridor based design. I intended on each corridor and room to have a different kind of obstacle to tackle.

Due to my intended theme being that of a medieval type gauntlet, I felt it necessary to model a few simple meshes of my own for various items. I created an Axe, a Hammer, a Buzzsaw Blade and a Spiked Pillar as on first glance, these did not seem to be available in either the basic starter content within UE4, or the additional Infinity Blade packs we were allowed to use within out work.

I began building my level by blocking out the surrounding walls in-engine, then began placement of subsequent items.

I ran into some issues with certain animations of objects, for example the spiked pillars were intended to spin, and move laterally at the same time. Through developmental changes I figured that rotating an object in place through an event tick and triggering a Matinee do not co-operate, as when the Matinee starts, the rotation is commanded to stop.

I fixed this issue by triggering the object rotation on an event tick and adding in a vector timeline, which allowed the mesh to move laterally on a set distance and return to it's original potition, whilst spinning in place as intended.

Whilst there is almost certainly a way to fix this and allow both processes to operate simultaneously using my initial process, and not using a timeline, at my current level of knowledge I am unsure as to the solution, I am sure as I develop my knowledge further I will be able to come up with solutions to such problems with use of extra programming nodes, fixing the problem with the use of a timeline however, has improved my problem solving abilities in-engine.

I also ran into a platform location issue, in that I was triggering simulated physics on a number of platforms in the “Pitfall Peril” corridor. Upon triggering of physics, I had coded a string to disable the physics and use transform values to put the platform back in its place. Whilst this in theory should have worked, some of the platforms did not relocate back to their original locations, this was particularly puzzling as some of the other platforms relocated perfectly fine.

The only other problem I have run into through my progress in this unit, was a ‘pending kill’ related issue. I used some Infinity Blade assets in the form of floor spikes, to act as the traps beneath my elevator puzzle and balance beam sections. Upon hitting these spikes, sometimes the pawn would respawn with no issue, and other times the pawn would respawn twice, bringing with it another skeletal mesh which was suspended in the air.

This drove me to believe the ‘pending kill’ issue was triggering as the pawn was suspended between two of the meshes and had not hit the floor art the time of respawn.
This was easily fixed however, with the use of a separate node resulting in the mesh no longer appearing, however the main player pawn does still sometimes stutter on respawn.

Whilst I was somewhat familiar with the setup of the blueprinting process as I have some basic knowledge of Kismet within UDK, I have learned a lot through this unit. I have learned about new nodes I did not know existed and utilised them to my advantage, to give some of my traps actual functionality without issues hindering them.

If I was given more time with this unit, or was to begin the whole unit anew, I would possibly implement more of my own meshes to create more intricate traps, and utilise a higher quality mesh for the traps also. Due to time restrictions however, I used quick, easy modelling techniques to make the trap models and textured them in DDO for extra speed.

I have enjoyed this unit as it has tested me and improved my work in general as well as my ability in-engine, I will continue working within UE4 not just on study based projects, but in personal projects also, this will help me expand my knowledge on engine functionality across the board and assist me in further portfolio projects.

Procedural Programming - Introduction/The Principles of Procedural Programming.

Through this unit I have been tasked with creating my own Assault course, or gauntlet if you will, in Unreal Engine 4 using procedural programming methods provided through the blueprints within.

To be successful in this task I must first gain an understanding of the principles of procedural programming.

Procedural programming is a programming paradigm, a term used simply to describe the way in which a program or application is written. At its core, procedural programming has the aim of keeping the code as concisely written as possible, to aid this even further some coders physically write the intended code out using a more logical path of thought, giving themselves a plan to follow, this can help not only coders who have dealt with procedural programming for a long time, but especially people new to the system.

The programming paradigm is built around the structuring of a sequence of linear commands and as I will be using Unreal Engine 4’s blueprinting system through this project, I can take advantage of the implementation of the code into a very user friendly interface to make coding easier. Coupled with this I will be using and comparing my blueprints with Pseudo code, which entails the aforementioned writing out of the coding or blueprints, allowing me to become acquainted with programming through potentially plain English.

As I have already started coding in some capacity before beginning this blog, I feel understanding pseudo code will be somewhat simple for me to understand, in the sense that writing out any exact event with happenings consequential of that even to be triggered one after the other will make more sense than diving into coding and not entirely understanding what certain nodes, events or functions actually do.

Having used Unreal Development Kit prior to using Unreal 4 I have had some minimal experience in the animation of meshes via coding strings, and so some event instances and function strings thereafter I have encountered before.

In the implementation of pseudo code, I will be creating a numbered list of nodes which I will be using to simply generate an outcome, though the list may vary from event to event, for example;

To assign a mesh to swing on a pivot upon a trigger box being entered;

• On Actor Begin Overlap
• Play
• Target – MatineeActor
• Set Looping
• Delay
• Revert to play

To remotely trigger a simulation of physics in-engine;

• On Actor Begin Overlap
• Delay
• Set Simulate Physics
• Target – Mesh

Ultimately, pseudo code and procedural programming within blueprints feels like a much neater method to coding than anything I may have imagined before, having envisaged a coder sat in front of a screen of nothing but text. This will inevitably help me in making less mistakes as I go and allowing me to keep the coding as uniform as is necessary throughout, knowing where everything is placed through the coding and the user interface linking as one.

Whilst I am sure there are still 'screens of text' occurrences frequently in the games design industry, I feel more confident in my own abilities knowing that I have tackled some very basic features similar to this in the past, and knowing I’ll come out of this project having a lot more knowledge of coding.

I am sure there are flaws within my listings and this is one thing I am to learn to implement correctly through this unit, with this in place I hope to be able to effectively procedurally program a level myself, something which will benefit me greatly going forward if I were to independently create a game, or begin work within a small team in which extra coding work was necessary.

This blog will be updated with each session to keep tabs on my progress for my own future knowledge, and to serve as a point of reference as to how far I have progressed.