Tower Climb Platformer

Tower Climb Platformer

Assignment Overview 

The purpose of this assignment is to introduce learners to the fundamentals of audience engagement in creative media production, with a specific focus on 2D platformer games. Students will explore the characteristics of their target audience and learn to tailor their creative decisions to meet audience expectations and industry standards. By creating their own sprites and 2D pixel art designs for a tower climber game in Unreal Engine 5, learners will develop essential skills in creative problem-solving, technical proficiency, and audience engagement. These skills are crucial for careers in game design, animation, and interactive media production. 

Learning Outcomes 

On completion of this unit, learners will be able to. 

• Analyze and identify target audience characteristics to inform creative decisions in game design. 

• Conduct research to develop ideas and creative proposals for engaging with a specific audience. 

• Design and create 2D pixel art and sprites suitable for a platformer game. 

• Plan and develop creative solutions that align with the needs and preferences of the identified audience. 

• Apply technical skills in Unreal Engine 5 to develop a functional 2D platform tower climber game. 

• Evaluate and reflect on creative decisions to assess their effectiveness in engaging the target audience. 

• Present and communicate ideas effectively to peers, incorporating feedback to refine the final product. 

• Critically assess personal development and set SMART targets for future projects. 

Unit Criteria 

Unit 10: Engaging With An Audience In Creative Media Production  

LO1: Understand the audience for a chosen creative media production activity.  

1.1 - Analyse the characteristics and context for a chosen media and communication activity.  

1.2 - Interpret research activity to develop ideas for creative production.  

LO2: Be able to plan and implement a creative media production activity for an identified  

audience.  

2.1 - Demonstrate independence in decision making in planning and developing creative solutions.  

2.2 - Select appropriate media and processes to communicate ideas for an identified audience. 

LO3: Be able to use evaluation in support of creative media production for an identified audience. 

3.1 - Critically evaluate creative solutions against identified audience characteristics. 

3.2 - Critically evaluate and reflect on learning to inform personal development. 

Task One: Research & Audience Analysis 

Conduct research into different types of tower climb platformer games, focusing on the intended target audience. Analyze how audience characteristics influence game design decisions, and explore legal and ethical considerations, including the PEGI rating system. 

Unit Criteria: LO1 (1.1, 1.2)  

Task One Breakdown: 

• Research and document different types of tower climb platformer games. 

• Identify and analyze the characteristics of the target audience for your game. 

• Explore the impacts of audience characteristics on your game design decisions. 

• Investigate legal and ethical considerations, particularly focusing on the PEGI rating system. 

Task Two: Sprite & Pixel Art Design 

Create your own sprites and 2D pixel art character designs based on your research. These assets will be used in your 2D platform tower climber game. 

Unit Criteria: LO2 (2.1, 2.2)  

Task Two Breakdown: 

• Develop concept sketches for your game’s sprites and characters. 

• Create final sprite designs and pixel art using relevant software. 

• Ensure that your designs align with the identified audience's preferences and expectations. 

• Document your design process and decision-making. 

Task Three: Game Development  

Follow tutor-led tutorials to create a 2D platform tower climber game in Unreal Engine 5. Implement your sprites and pixel art designs into the game and develop a game level. 

Unit Criteria: LO2 (2.1, 2.2)  

Task Three Breakdown: 

• Attend all tutorial sessions to learn the basics of Unreal Engine 5 for 2D game development. 

• Implement your sprites and characters into the game environment. 

• Develop a fully functional game level using your assets. 

• Test and refine your game level to ensure it meets audience expectations. 

Task Three: Game Development  

Follow tutor-led tutorials to create a 2D platform tower climber game in Unreal Engine 5. Implement your sprites and pixel art designs into the game and develop a game level. 

Unit Criteria: LO2 (2.1, 2.2)  

Task Three Breakdown: 

• Attend all tutorial sessions to learn the basics of Unreal Engine 5 for 2D game development. 

• Implement your sprites and characters into the game environment. 

• Develop a fully functional game level using your assets. 

• Test and refine your game level to ensure it meets audience expectations. 

Task Five: Evaluation & SMART Targets 

Critically evaluate your project’s success in engaging the target audience and reflect on your learning. Set at least two SMART targets for future improvement. 

Unit Criteria: LO3 (3.1, 3.2) 

Task Five Breakdown: 

• Write a detailed evaluation of your project, focusing on how well it met the needs of the target audience. 

• Reflect on your learning experience, identifying strengths and areas for improvement. 

• Set two SMART targets to guide your future projects and personal development. 

I've been in a huge slump for a while, so today, I've set out to get started on programming Dream Eater. I tried earlier during half term, but I grew quickly dissatisfied and scrapped it before it really went anywhere.

After creating a new project file, I made these to start off. The graphics are simple placeholders for now. Getting everything functional is my priority, it doesn't need to look pretty just yet.

I have an idea on how the player object will work, so I brought over a script function I've used in a previous platformer which I believe I got from a tutorial. This will allow me to control when the player object is allowed to start moving.

With this, I went over to the player object and defined some of its variables in the Create event.

Some simple movement related variables and some state related variables. I'm gonna start off focusing on horizontal movement only, so I won't touch the vsp and grav variables for now.

And this is where that other object shown above, obj_devstats comes in. In this object's Draw GUI event, I wrote down some code which would draw a few lines of text telling me about the state of the variables in the player object, and likely other objects at some point. This may come in handy later on, and it's good to keep track of things like this.

This is what that looks like in action right now. The resolution of the game is really small at the moment, displaying at its base size of 320x240, and the text appears really large on screen. I'll upscale that when I need to.

Going back to the player object, I created a Step event and set up some input variables.

After a bit of writing using the set up I have so far, I ended up with this simple horizontal movement code. I feel like I'll probably have to reconfigure how the DEFAULT state works at some point, but that's just a hunch.

I noticed that the player moves very sluggishly when changing directions mid-movement. I wrote a little bit of extra code that I should have written down in the first place to make sure these turns are sharper, also adding a base acceleration variable that wouldn't change so that the regular acceleration variable can fall back to it if it needs to like in a situation like this.

Also tinkered with the acceleration in general. Made the player accelerate a little faster.

I'll probably keep tinkering with the speed and acceleration along the way.

Coming back to this, since I finished with a solid framework with horizontal movement, I'm building off that and moving on to collision, gravity, and a jump function. Besides horizontal collision, these are all pretty interconnected, so I added them all at once.

I brought in some code that I've continuously passed down from some previous projects. I believe I pulled it from a tutorial video I watched back in 2022. It's effective, but it was originally made to account for slope collision as well, so I had to modify the code to erase any traces of slope collision or slope collision related variables.

Same for vertical collision.

Funny little thing I forgot would happen. I moved y += vsp to an earlier part of the code so it'd be next to x += hsp, forgetting that doing so makes the player object slowly sink through the ground like it's quicksand.

Wrote some code seperately which changes the current substate depending on whether or not the player is touching the ground. Doing this in the vertical collision code didn't work as well from what I tried, as it uses the vsp variable to determine the collision detection.

Set up gravity which I forgot to do somehow. This one is very simple, nothing much to say here.

And to finish it all off, I wrote the jump function.

Here it is. Functionally, the simple, base player code is complete. Granted, there are a few things I want to iron out, general polishing that needs to be done, fixing some bugs (one of them is very apparent in the gif, another is a small oversight regarding the code that determines the player's jump height based on how long the space bar is held down.), etc.

I decided to put a bandaid over those bugs for now and brought in a camera object from an earlier project. This also noticeably upscales the game display by 2x.

After adding in the camera, I wanted to move on to programming spike objects. I'm excited to see how it turns out, since I don't believe I've ever really had the chance to program death before.

Though I didn't want anything too showy, I decided to drag along a screen shake function, also from an earlier project, to add some impact to the player colliding with the spikes.

I didn't take any inbetween screenshots of the spike code as I got too in the zone. I do have some older footage displaying an earlier version of the code in action, what the final code looks like in action, and of course, the code itself. 

Here's the earlier footage.

Current footage. 

The final-ish block of code. I decided to annotate this one a lot more.

I started off by setting up a global object with some global variables. I want to try making a checkpoint system at some point. I don't believe I've ever really used arrays on my own, so this'll be interesting.

I put it aside to complete the remainder of the player's animations, though, since the next logical step is to start implementing proper visuals and assets. 

After a little bit of work, I finished the spriteset, and I imported it into the project.

Added these variables to the player's Create event. In the Step event, I piece them all together and set the sprite index to that. This allows me to quickly change the direction and the animation independantly and on the fly, without having to change the whole sprite manually.

And here's the animation code in the Step event. Also annotated this one a bit, and it's generally straightforward.

Here's how all of that looks in action. I still have some tinkering to do, mainly things like jump height, but overall, I'm really proud of how this looks.

After getting that out of the way, I pieced together a quick and lazy checkpoint graphic and got back to working on that.

It was surprisingly easier than I was expecting. Like I said at the start, this is the first time I've worked with arrays, so this project is proving to be pretty educational.

Here's the collision code for the player and the checkpoint object. If the player collides with an instance, it changes one of the global variables to state that a checkpoint has been passed.

I added two variables to the checkpoint object. xPoint and yPoint. when declared, they're assigned to a value of 0, but Gamemaker allows you to change a specific instance's creation code in the room editor, which allows me to set specific xPoint and yPoints for each checkpoint. Once you've passed a checkpoint instance, the global array for the checkpoint position is changed to store instance's xPoint and yPoint. Since this information is stored in a global object by global variables, it remains the same once the room is restarted, which is what happens upon death. If checkCleared is on, stating that you've passed a checkpoint, then upon creation, the player's x and y positions are set to the values stored in checkPosition, respawning you at those assigned coordinates.

Once this is all done, the instance becomes claimed and is no longer able to be interacted with. At least until you die, of course. If you respawn, every checkpoint becomes unclaimed by default. I didn't see this as a big enough problem to really waste time fixing, though. If the player wants to backtrack after death just to revert to an old checkpoint, they can do that.

I realize I rambled a lot more about this checkpoint code than I have about anything else, but I guess that just shows how proud of it I am, haha.

Moving on, homestretch, I began work on designing the level, after having implemented the tileset I had made.

And it's done! It's a very short level and it was kinda cobbled together with what I got to do in such little time. It's not very interesting or challenging, and I didn't even account for spikes facing different directions while coding them, so they have to be constantly facing upwards. Regardless, I'm proud of it. 

You can find the video I recorded alongside the evaluation in Kim's Projects, Final Product and Evaluation - Unit 10