As an early point to mention, we did not use any model or blueprint from an asset pack, the level designer did but they left and we didn’t end up using the assets, and they were swiftly removed from the game. Also it helped keep file size of final game low.
Early week planning
At the start of this project we all spent around 1-2weeks just planning on how the game will go. This was done to ensure everyone knew the vision we was going for. The original concept was a 2.5D pixelized game, with the perspective being a isometric orthographic camera rig that would follow the player. We produced a quick Trello list and even started a log of our activities! We tried to keep these updated throughout the project.
I started to work on the game creating a quick little testing area that showcased the controls and functionality. This worked great as it showcased how the pixelization worked and how the controls worked in a easy to learn way. This was just a quick test to see the art style and to have something to upload to git-hub to get that started.
Git-Hub
The team and I created a github page with the game on it so we could keep a constant updated version of the game and we can go back and look at old version when we need to. unfortunately, I was the only person to upload anything of significance to the github page until the last day meaning i was crunching adding in all different elements like skeletal mesh’s levels and some UI. A few bits of UI was sent to me privately to add in as github was not working as intended.
Animal creation
After this prototype i went on to try create some animals and enemy’s. However i made them i a way that all i have to do is add a component that i made to calculate the cost, mesh, icon and weight of the item. I made sure it had more than enough item info to the point where some of them aren’t used but they are good to have in case i want to do something with them in the future, such as the category and the habitat. This was achieved by making a blueprint component and adding a Structure that contains all the relevant item information.
Due to the nature of the game and needing to suck the animals into the gun to transport the animals safely, i created some nifty code to handle capturing and saving the animals. it isn’t the cleanest code but it worked well for what we had.
Player
The player movement was originally a isometric camera but with time coming closer and closer to the deadline without much work being done for models like the, i felt like the best course was to switch to First-person so that the animation team didn’t have to make a good looking model for the character and animate it. All we had to do is animate the gun which was done swiftly.
I made a bunch of different event graphs for the player to help organise the graphs to something more readable. As it got to the point where the blueprints was too complicated.
I also made a bunch of variables for the player and put them into category’s that made it easier to read and to implement certain things instead of looking through a big long list.
I made a floaty feeling auto jump to mimic the casual tone i wanted to set for the game. Something similar to slime rancher and how their running feels floaty. it auto jumps as every time it lands it triggers another jump if you have the button pressed down. This is determined by the branch and it works perfect. The delay was needed as it didn’t register that you have hit the ground before trying to jump again.
This is what one of the event graphs looks like, it is filled with important pieces of code and it also has debug keys that help me experiment with the game, allowing me full control of how the game behaves so we have an easier time to test the game.
Player Game Instance
I made a game instance to store information throughout the game as it keeps up when going to different levels, allowing me to store information from one level to another. This is where i keep my save and load game features and keep all important info like the hot-bar information and also the cash that the player has. I send all the relevant info to the game instance when the player faints or goes back into the ship to avoid having massive hitching from always sending irrelevant info to a game instance.
Creating a tutorial level
I started work on a prototype level that the original purpose was to act as a prototype and that was it. it let me test the game while waiting for the level artist to do their job. However, at the end 2 weeks before deadline we was hit with the news that no levels had been created causing us to use my level as a tutorial. I then prettied up the level to make it as professional as possible and to make it a valid level for beginners. This meant i created a new type of collectable called plants. They act the same as the animals but they cant move and they sell for less of the value.
The level is set up in a way so you can meet each type of thing you can encounter one at a time so you can learn how they are. I made sure the location of the enemy’s were far away and was locked off by a intimidating door that looks like there’s bad things inside which can harm you.
Unfortunately, i am not a very good level designer meaning it was harder for me to develop the level especially to how i envisioned it. I would have ideally had some more elevation in the level and to have a big centre piece but i was running out of time.
Unique blueprints?
I made a few unique blueprints for the level such as the water teleporting you to a safe spot if you jump in, with a time penalty to stop you from jumping in.
The water blueprint is relatively simple to set up and i made sure that there is something that stops you from wanting to constantly jump in especially if you find a bug that helps teleport you around the map. also if it bugs out it will quickly make you faint instead of having to wait.
Pixelization
I made a blueprint that converts the data on screen to a pixel image that basically gets a pixel on the screen averages it, flattens the colour and then puts it back on the screen to the desired pixel size.
Models?
I had to help out in the modelling area due to time restraints or due to someone not understanding the art style too well. I helped make the vacuum gun model and all the animations, the model was based off the initial concept that Szymon made.
I also made a flower model for the water as i needed to make something quick that would help teach the player about sucking in objects. I tried to model it so it kind of makes sense as an alien plant, the bottom half collects water while the top half collects sunlight and expels clean water.
Interfaces
I made a bunch of interfaces for different objects, these being mainly the objects i want to suck into the player but needing slightly different inputs on each to help fire the correct event.
These were used especially when wanting to enter the spaceship.
Interfaces make making interactive elements easy to do.
Main Menu/Spaceship Menu
I made a character that you turn into when you travel to the main menu and also the same for the spaceship. This is because it means i don’t accidentally trigger any events from having code that isn’t meant for a section of the game. It also makes it easier to understand the code and where it goes.
They only house HUD related Events.
This way of doing HUD related things means that you don’t have any overlapping widgets of the same class. Very handy when working with a bunch of different widgets.
Widgets
I created all the widgets and outfitted them all with prototype buttons that i made, which don’t look to bad with the theme.
Upgrade system
This upgrade system basically checks if you have enough Cash from freeing animals and selling plant life and then gives you the upgrade, this also saves with your other items. So you don’t have to keep buying them between runs.
Spaceship Menu
This acts as the main place to keep up to date with all the information you need. it keeps track of all important statistics. The clickable buttons also light up when hovered to show the player what can be clicked. The hot-bar in the top left shows the player what their current inventory is. It resets every run so you cant over cramp it.
HUD
A basic HUD that shows your coins collected that run (serves no purpose apart from guiding player to new areas) a health bar that goes down every time you are hit. And a hot-bar to show your current inventory. However it hold a lot of information from the player leading to a packed blueprint. This is because it also handles how the fainting mechanic works.
Timer
This widget simply counts down the remaining time you have left before fainting. This was done so you can’t stay on a planet forever and making you explore different areas in a timely manner. It also makes sure that it only appears when it’s on a planet without a breathable air intake.
Inventory system
i made a bunch of widgets that display information of what you are holding use a struct that keeps the data. It is then displayed on these widgets and you can then use the data for things like selling and keeping things easy to read.
Planet Selection
I created this style of menu to give visual clarity of where you are going. It highlights the planet you have hovered buy the buttons on the bottom right. It makes it easy to understand where you are going with big text and visual indicators.
Icons
I created a few icons for the game, this includes my water plant icon. These were primarily used for the inventory system. These are all made using Adobe illustrator meaning they are vector images.
Prototype buttons, alpha not visible in context drawer.
Materials
I made 2 master materials, a solid base and a water base. This is so i can create solid colour grounds and walls so that the pixelization can work better and makes the game look better overall rather than noisy textures.
AI
The ai was made to act as a way to show that the player is actually trying to capture and save animals instead of static models.
Animals
The animal AI is primarily just a random roam in a specified area. They do not react to the player. These were made using blackboards and behaviour trees.
Enemy Ai
These were made to target the player and chase the player when they see the player in a certain area Infront of them using the ai perception node they have in UE5. When the player is too close to the Enemy then it damages the player for one health point. If i had more time i would have made more versions of the enemy class.
Feedback to others
With the limited time i asked the others to scale back what we need with our enemy and animal type. we went down from a bunch of lifeforms on different planets to slimes and a sheep.
Playtesting
Putting up a link on itch and sending it over to my teammates i had all our people test the game to make sure it worked well, we also had my girlfriend play the game. My Girlfriends feedback was that the game looks awesome and the visual style was good, but it could be developed further and that the controls were good but they were too floaty and a need for a proper tutorial to teach you each control would be a nice change. Also she would like more worlds to explore but she noted that she knew it was okay due to it only being a prototype.
