Group Project

"Space"

Home

Brief

After looking at the brief, I don't think it's going to be the most difficult project work-wise; however, based on the time we have to complete everything, I'm a little less confident. Unfortunately, we only have a very short period in which we can produce some work, which then should be shown to a university lecturer, so we are going to have to work very quickly. There are two main good thoughts I'm having for this project so far, however. Firstly, we don't have two or three other projects happening at the same time, so we don't have to worry about managing our time quite as much and can just focus on one project. Moreover, this is pretty much the last couple of projects until FMP time again, and this is great preparation for it. I think, considering that we are alone for the FMP, the time will sort of get spread out to be very similar, but this gives us a starting point and gets our minds engaged in one large project. Not only this, but it's obviously very helpful for university, since we will be in groups a lot then, but also for future work, since most people will end up working at a company which includes many employees.

Either way, my initial thoughts are that I need to try to get all of the research done as quickly as possible to have the maximum amount of time for production. So far, the first week has been relatively uneventful, but we have started discussing ideas, mostly through the use of a Trello board. I have already given a game idea that would start us off well, so I'm hoping we can either use that or come to a different conclusion to begin researching what kind of models we'll need, what artstyle we're using, and what kind of mechanics should be created. I'm having ideas of how we can be really productive by having a list of things that need doing, and you can drag them into your collumn when you are working on them.

The Team

For this project, we were split up into groups. Initially, we were shown the groups that had been put together for us, but we eventually shuffled ourselves around into groups that suited us more, and I ended up in a group of four people of various skills.

- Olly (me): Team leader, primarily a programmer but can do other things, particularly likes UI.
- Xander: Another programmer who will probably be mostly helping with gameplay.
- Dylan: A modeller for all of our 3D asset needs.
- Ash: 2D designer and writer (e.g. GDD)

I believe this is quite a strong team since we all have our different strengths that can be used together to make a basic game. Unfortunately, we only have 6 weeks total for this project, which includes research, production, and a final presentation showing off what we made in that time. This means that we will want to get the research completed as fast as possible to have enough time to make the actual game. Additionally, we should give ourselves enough time towards the end for creating a presentation, which will probably be a collection of production images throughout the weeks. I think everything is going to be so much easier the more organised we are at the start, so I'm going to work on getting the Trello board organised and simplified so we can work without any overlapping problems and others wondering what could be being done. For example, if I took on the task of making a player character controller, maybe once I finished that, I could look through a list of what is left to do, so I don't have to go around and ask everyone what needs doing, and who is doing what.

Week 1 - Team Creation & Planning

After a relatively short beginning week, not a whole lot was completed, but I think either way, it was decent since I got a lot of the plan mostly done on our Trello board with plenty of ideas and being nicely organised. Initially, we just had our first kinds of ideas that we quickly listed. While we talked, we also thought that we could think a bit more outside the box and make a game about literal space, so Xander had the idea of something based around a restraining order or something similar, but in the end we thought we'd just stick with the outer space theme since we had a lot more ideas, and it was going to be difficult to make a game out of something like a restraining order. After thinking and talking for quite a while, we went away mostly undecided on the first day. The last couple of days of the week included us brainstorming a bit more, doing blog work and working on another project a bit. In the end, Xander and Dylan didn't really care about the story, and Ash wasn't in, so I decided a Mars Exploration game was a cool idea.

Initially, my idea for it was that you had been sent to fix a Mars rover that had malfunctioned or broken in some way. While this was an alright idea, it wasn't quite good enough for me yet. So, I started thinking a bit deeper and decided on a better game idea. My idea is that you have been sent to this planet to fix a rover's AI that has begun to take control and become conscious. I think this is not only a realistic issue and concern with AI in the real world, which gives us ethical points, but also quite a compelling storyline that we can shape accordingly. The rover wasn't the only additional consideration, though, since the real planet Mars is pretty boring and has very little interesting terrain. I think it would be a brilliant idea to instead have a fully fictional world that is clearly based on the real world, but with its own custom planets, so we can add lots of various plant life and man-made structures without it being too controversial based on the realism. Obviously, this will keep evolving, but for now, I think having a rover that's gone rogue is a cool idea.

After I wrote up my idea for the game, I began making the rest of the Trello board look professional and organised so it would be simple for us all to work on. My original idea was going to be having a large list of things that would need doing, and two lists for each person: in progress and completed. Therefore, whenever one of us would be working on something, everyone else would know, so there would be no overlapping work. I then decided to split everything up into designated columns to be easier to find, and I thought I was done, but I was far from it. Once I started putting all the various things that needed doing into their columns, I found that there was a lot. Not only this, but the two columns per-person was very messy, but I luckily found a way around it. For each list, you add cards, which is pretty self-explanatory. However, for each card, you can add lots of things, such as labels, checklists and more. In the end, I removed the columns per person since I instead made a label for everyone, so whenever you start working on something, add your label to the card so nobody else works on it. Add the Done label when you finish, and it simplifies the whole process I came up with before. Additionally, I added checklists so I could include various tasks that fit within one card, so I don't have to create cards for literally everything. Obviously, I have probably missed some things, but I went through most things we would realistically need in a game and laid them out so everyone has ideas about what to do.

I have sent a message in our Teams group briefly explaining this, and also asking for screenshots to be uploaded whenever you do stuff for all of our blogs to keep everyone on track. I'm really trying to take my team leader position seriously by sorting everything out, and I think so far, it's going well.

Final Trello Board Design & Initial Content

Card Example: Labels, Checklist & Mark Complete

This is relatively self-explainatory, but this is basically how each card will look like when opened up. We will each be able to assign our own labels to anything we begin working on so there's no double-ups. I've added a description to most stuff, explaining how they'd work etc. in the game.

The checklist is a very useful thing to break a card up into different things. For the character controller, me or Xander will very easily be able to keep track of how far we've come with it.

Finally, I have actually removed the label for marking something as complete due to the fact that there is literally a button you can click to mark a card as complete.

Week 2 - Finalising Game Concept & Gathering References

Finalising Game Idea/Concept

After the first week passed quickly, I knew I needed to get as much research completed in the second week as possible to give myself enough time for production. To begin, I needed to finish the set gameplay loop for the game, so I knew what else to research. In the end, I came up with the idea that the player would begin in their rocket, travelling through space towards their planet of destination. Ideally, I think it would be awesome to have the game start in the rocket and allow you to look around and interact with the environment a bit. There could be various screens that you can go to for the main menu settings and the ability to quit the game, but also so you can have a look out of the rocket windows to view the lovely space around you. You could have mission notes and game help information, as well as just some things you can play around with in the rocket. I would probably just make it so you can only look around, not move, but it would be a lot more unique than just the regular title screen with settings on. Once the player is ready to start the game, you could just click a button that moves you into a cryosleep tube, which basically skips the time remaining in the journey.

Cockpit Reference/Example

Cryosleep Tube Reference/Example

Once landed, you are ordered to begin your search and rescue mission that involves finding and repairing the malfunctioning rover. You should have very little information on what is actually in store for you, since the video feed cut off randomly, and you need to find out why. I don't know how we'll make it seem like the space company back home doesn't know what exactly will happen, but they will have to prepare us for any dangers that may be lurking. We'll obviously have plenty of tools at our disposal, but due to the expense of the robots, the main outcome should be to safely reset the software so everything is back to its default state, without destroying any of the hardware beyond repair.

Mission Info Board (holograms of drones and rovers) Reference/Example

Toolstation Reference/Example

After you gear up and begin heading out, it should be clear that you are not completely safe. The drones, designed to protect the rovers from invading companies trying to steal the classified research, have been turned on you. When the player first encounters one, they may try to say a codeword (just through automated voicelines) to disable the drone from attacking. However, this will not work, and you will be instructed how to disable the drones by Mission Control over the radio. Once you've learned that, you pretty much will just have to travel around, resetting drones, until you come across the rogue rover boss. I don't really know what it should be doing, but this is where the boss fight would begin. After you beat it, you will simply need to reset the AI, maybe update it so it doesn't happen again, and then fly back home. It would be cool to add a few different endings depending on various things. Maybe if you destroy something, you get fired, and your rocket gets disabled, leaving you floating in space forever. We could make part one of the mission, resetting all of the drones, and if you forget one, it secretly boards and kills you on the journey back. Or you just have the good ending, where you do everything correctly and survive the mission.

Drones Reference/Examples

Rogue Rover Boss Reference/Example

There are a couple of other ideas that we could include if we have time towards the end. The first is having you joined by a companion of sorts. It could be either a dog, a human or a robot, depending on what suits us best, but I think the robot best fits its use. This is because, instead of having a robot as just a friend, it could replace Mission Control, since having a radio with barely any delay is quite unrealistic from a whole planet's distance away. Not only this, but I can't think of what use another human or dog would have in this situation. Additionally, your robot going rogue itself could be either a part two to the game, or possibly another ending if you didn't do something correctly, or if it gets controlled by the boss and you don't reset it before leaving. There are many ideas I have for this game, but we just lack the time to make a fully made game. In this time, we might not even have enough time to have a complete game, but I think as long as we get our idea solidified and have a variety of assets and examples of how it would work, that will be good enough. The other idea would be adding more missions and enemies that you can encounter before finding the rogue rover. For now, all we have included are the surveillance drones that span the planet, but I feel like there should be more. This is mostly because, apart from some interesting PvE mechanics, we won't have a lot of gameplay actually in our game. Ideally, we either need various side-missions or it needs to be more progressive, where you have to go around and talk to other rovers to find out more information about the rogue's whereabouts. Currently, the game will be extremely quick, since you just go and find the boss, reset it, and the game is done in a matter of minutes. Even if we increase the map size and the number of enemies, it will become quite boring over time for the player, since the gameplay would quickly become very repetitive. For this small and short group project, I don't think it's the worst idea, but if we were to continue working on it, or if it was actually meant to be a proper game that was worked on for a while, there would certainly need to be a lot more content to explore. We could even build upon the story, so when you fix the robot, you find out you've been followed by an opposing organisation that wants to steal the classified research, so then you begin fighting them.

Robot Companion Reference/Example

Additional Enemies/Opposing Organisation Robots Reference/Example

Drone Design Ideas

Drone Taser Stun Gun Reference

Key Idea & Reference for Hole

AI Gemini Nano Banana Drone Reference

After I put together an idea for the core concept of the game, it was time to begin getting reference images and the PvE combat ideas together. The main starting point of this would be the drones, since it's the first thing you'd encounter in the game. For the combat, I thought that it should probably have a stun gun, taser-like weapon to attack you with. Considering my initial idea for their existence was basically security, they shouldn't have anything incredibly lethal. Something like a taser is great to temporarily damage you, but over time will be fatal. To counter their attacks, I feel that you should have to dodge their lunge towards you by crouching down. Due to the lunge speed, they should then be temporarily stunned, giving you a chance to get behind them and input a key into a specific slot and turn it, which will force a reboot and reset the drone.

I think the interaction is relatively simple, but the timing should be difficult enough that you can still mess up now and then. I'd need to add quite a few different animations, which is probably going to take up most of my time, but I think that at the end of it, it will be worth our time, so it isn't always the same attack type.

For reference images, I found a good few ideas, so everyone knows the kind of design I was going for. I also asked AI to generate an image of what they think the drone would look like from a description and using the reference images, and I think it was a decent outcome.

Power Tower Design Ideas

Power Systems Generator Tower Reference

Keypad Reference

AI Gemini Nano Banana Tower Reference

After the drone, I basically went and did the exact same for the power tower. These are what the rovers use to charge a vial that would usually be used to do some kind of work. However, in this circumstance, the rogue rover will be using it to attack the player. These towers will act as a source of power that the rover will syphon gradually over time into a vial. The player has the aim of disabling the towers by entering a specific keycode, preventing the rover from syphoning any more power from a specific tower.

Overall, I think this is a decent idea that adds a few extra steps to the boss fight instead of just trying to disable it straight away. I think there's going to be a lot of work going into it, actually working, since I'm a bit confused about how I'll make the syphoning look and work, but I'm sure there's a YouTube tutorial out there that I can follow.

Again, I found a couple of reference images for the design, and asked AI to generate something based on the description and reference images. I think the AI Design looks pretty cool, but there are definitely a couple of changes that are needed. For starters, the keypad had no reason to be so large, but I really like the lightning coming out of the top, which could be where the rover syphons the power from. I'm hoping that when Dylan makes this, it can have a wider base like the tower reference I found, but have the cool-looking aspects of the AI tower.

Rogue Rover Design Ideas

Cryo/Power Canister Reference

Power Vial Charge Visualisation Reference

AI Gemini Nano Banana Rover Reference

After the tower, it was clear that I should next do some research into what the rover could look like. In my mind, I was already getting ideas for how you could disable it by having to remove its power sources that keep it running. I also thought that having some sort of gauge for the player to see how charged up its main attack is would be a good idea. After that, I began getting some reference images for the rover itself. I still don't really know what kinds of attacks it should have, especially when you destroy all of the towers. I was thinking it should just resort to melee attacks, but I don't know what kind yet.

Now, looking at the rover, I think the idea is still good, but we definitely should've had a look at what kind of weapons it will have when it can no longer charge its main ability. I like the power vial idea for visualising the charge amount, and I think my idea for disabling the boss by removing it's power canisters still links to the kind of story I was imagining, where you are instructed to not destroy any of the expensive technology.

For reference images, after I found the vial and canister examples, I went on and found a rover image that best represented what I had in my mind. I then sent all of it to the AI again, with a description, and it came out with a decent enough design. I think the vial for the charge visualisation on the side looks nice, but the three power canisters on the back should be horizontal, and should have the handles showing out the back. I like the idea of the side things that are maybe like stun sticks, but then they can also change to be a regular melee weapon.

Space Ship Ideas

Rocket Exterior Design Reference

Boarding Ramp Door Reference

Lethal Company Space Ship Example

Up next had to be the rocket ship's design. I already had a somewhat decent idea of what I thought was good, but I needed to find images to help visualise it for everyone else. From playing Lethal Company, I knew that we didn't need anything too large, since it would just take up too much space and time to make it. Additionally, for the amount of time we'll be inside the ship, we don't need to spend a whole lot of time. Obviously, you'll be starting in it, and you will be able to walk around a bit before leaving, but I think we can just reuse a bunch of assets to make it look decent. We may also end up using asset packs to fill out the ship, since we shouldn't need to make everything just to pack the ship out. I think focusing on getting the main assets complete and leaving any accessories and fillers to the end, if we have time.

I believe that having a relatively compact ship is best for this project. For one, you are more than likely to be travelling alone or with an AI companion, so you won't need much team space. Additionally, there is no need for lots of living quarters areas, since we are just going to slap a cryosleep tube somewhere in the ship to skip time, so you won't need a bed or entertainment.

Another Cockpit Reference

Compact Interior Design Reference

Planet Ideas

Mars Landscape Reference

Rocky Landscape with Dead Trees and Bushes Reference

Fallout Landscape Reference

For the planet we'll be exploring, I thought it was a good idea to get some examples so we know what we need to make it feel right. Initially, we were going to be doing the game based on Mars, but when I realised Mars was really boring, I thought it was a good idea to make our own, somewhat inspired by it. I found a nice reference image that displays the rocky landscape really well with it's unique deep orange colour. After that, I wanted to find something a bit closer to Earth, but with some dead flora, such as trees and bushes. I think the example images I found, with some in, closely represent what I was thinking. When the time comes for modelling some of them, I think making the shapes weird, twisted and spiky gives off an ominous and unfamiliar vibe.

Lastly, since I played Fallout 4, I will always remember loving the exploration aspect that the game has to offer. This was obviously accompanied by some lovely landscape, so I thought getting an image from the game, or inspired by it, was a good idea. Not only this, but we've considered adding buildings and stuff, which Fallout has some of, but abandoned, which is what we need.

Cryosleep/Hibernation Tube Pods

Sleeping Pod Reference

Sci-fi Sleeping Tube Reference

Human Hibernation Pod Reference

One of the coolest parts of the ship that will inform the player about a decent amount of the story is going to be the sleeping tube. I think it immediately shows that the game is set in the future and technology is far more advanced than we are used to. Additionally, this lets you skip a large, boring part of the game, which is travelling, so the player doesn't get bored before the main part of the game even begins.

In my mind, I imagined them being more tube-like and relatively small, whilst also having basically no comfort since you won't be aware either way. However, while researching, I did find this one pod that had an interesting shape, and I can see us using this kind of futuristic design in ours.

Tutorial

One of the aspects we could try to explore in creating a game would be through the tutorial. I thought having a somewhat interactive tutorial would be good, so you are told what to do while you play. Having a list of keybinds and their uses on screen is also useful for informing the player on what to do. This could just pop up once, or be a constant reminder when needed, like when they're low on health.

With regards to a game I've recently seen, I thought the tutorial and help in Silent Hill F was a good idea that doesn't take much to implement. Not only this, but I know some games slow down time and tell you when to attack, giving you a literal walkthrough of what to do. In a way, I kind of prefer the 'tell, and you do' approach, since it allows the player to teach themselves, can easily be skipped for replayers, and it's probably simpler to implement.

UI

UI/Holograms Reference

Buttons & UI Designs Reference

Main Menu Reference

Up next, I thought the UI needed a good look at. For the game, because it's quite futuristic and Sci-Fi-like, I had a look around for some UI's we could use as examples for our game. I think the vast amount of stuff I found can be of great use. One of the first images I found gave off a lot more hologram vibes than just cool-looking UI on a screen. Although I was thinking we'd probably use screens for most of the stuff, there are some instances in which we may need to use hologram-like displays, specifically for the toolstation and/or the game info, such as the mission.

As well as that, we need some kind of main menu and settings to be used across the game. I think having you start on the ship, looking at a screen basically showing the main menu, is good, and maybe you can return to it at any point. However, alongside this, we will also want a way for you to be able to change settings on the fly. I feel like it might be cool to have a gadget that basically mirrors the screen in the ship, so everything is changed together, but it also gives it a more realistic approach, in my opinion. Since I like doing this, I believe I will be making most, if not all the UI, so I look forward to trying out my idea.

Settings Reference (I like how everything is on one page)

Valorant Settings Reference

HUD

HUD Ideas Reference

Halo HUD Reference

Lethal Company HUD Reference

The heads-up display is arguably one of the most important aspects of a game. If not done correctly, it can ruin the immersion, at least for me, because I like a game to be somewhat realistic. In a Sci-Fi game, like what we are making, I feel you can add quite a bit without ruining the immersion, because you should feel like you are in a mask with a display.

As well as some ideas for certain HUD components, I've included two game HUDs as examples, since both Halo and Lethal Company have themes very similar to what I feel we want in our game. I feel like Halo definitely has the upperhand, with you really feeling like you're looking through a screen inside a helmet by seeing parts of the helmet and it really glowing. On the other hand, I really like Lethal Company's scanning feature and how it can display information on your screen. In this example, it's the scrap on the floor along with how much it's worth. Including something like this, but for the drones, etc., in our game would be a great addition.

Player Model

Space Character Helmet Reference

Valorant KAY/O Agent Model Reference

Futuristic Astronaut Reference

Up next was the character, and usually something I would've thought about a bit more by now. Unfortunately, due to time constraints, we decided it was probably best we just avoided making a character model. This was because not only has Dylan expressed his hatred towards making humanoid figures, but it would just take too much time for something you'll barely need to see. If we get around to it and see it as important, we may want the hands and arms, especially because for animating stuff, it'll look a lot better, but again, it'll take a lot of time to animate stuff like that because I haven't really done it before, so we might as well forget it. I believe Ash was going to do some concept art for the character, so he can probably use my references and any others he thinks are good, but other than this, it's pretty much all you'll be seeing about a character in this project.

Moving on to what I actually think it should look like, it obviously needs to be something more futuristic compared to our current suits for astronauts. At the moment, they're bulky, and I would imagine they get extremely warm inside. Clearly, this is for protection, and because it keeps them safe, but in the future, I imagine them being a lot more fitted and mechanical-looking, even maybe a bit like Iron Man. My immediate thought was the Valorant agent, KAY/O, but I also found a really cool model someone made online that looked awesome. Thinking back to the HUD, I think both of these are great choices since I could implement a design that resembles the helmet edges. Moreover, they look mechanical enough to also be a screen to show you information if they were to be real.

Oxygen Wall Refill

Oxygen Wall Outlet Reference

Oxygen Canister Reference

My Oxygen Station Example

One of the last things I felt like I needed to do some research into, so everyone had an idea of what I meant, was the oxygen refill station. I thought that if the player was able to just walk around the landscape indefinitely without any worry, then it would make the game significantly easier. Implementing a new mechanic such as this requires the player to keep thinking about their oxygen levels and if they are able to keep going, constantly keeping their guard up and forcing them to have something of a plan.

While thinking of the creation of this, I've had some ideas as to how we can implement this so it doesn't drain too slowly or too quickly. One way we could implement something like this would be to have the player carry around an oxygen canister supply with very little total volume initially. After exploring a bit, maybe they are later able to switch out canisters with a larger maximum capacity one, allowing the player to travel further on one refill. The problem is, how would we get an upgrade? Is one being made in the ship, so after you travel a certain distance, it becomes ready, or do you find a larger one while exploring? Instead, we could have the player place refills around the map, and maybe they slowly fill up from oxygen that's trapped in the ground? Or, we just go with the simpler and more boring approach, where they can just carry around spare canisters. Personally, if we can get an "upgrade" system working that doesn't feel too scripted, I'd like to go down that route. It would force the player to first explore the landscape closer to the ship around them, and later on, begin to travel to further lands and eventually find the rogue rover. I think we'll need to get a variety of things you can find across the map, like power-ups that improve movement speed and other things, so the player doesn't feel too bored looking for one thing to progress. We'll need to get a rough map layout drawn at some point, and then we can begin adding the gameplay loop. I'm thinking that maybe we are informed of one place close to the ship. You can find a few upgrades and information on other areas (a bit like Fallout 4's map unlocking), and travel there. Eventually, you'll get everything you need to make the long journey to wherever the rogue rover is situated, but we'll make it so you need the maximum oxygen container capacity to make it there without passing out.

Now, moving on from the long list of ideas for how this affects gameplay, I think having something that looks cool is important. My idea for the refill station is that you can see the oxygen canister in the wall, and the player will have to go up to it. When you're in the range and looking at the wall, an animation will play where a tube is put over the outlet, which refills your tank. Later, I can make a rough animation as to how it would work, so Dylan knows exactly what I mean, but I think it's a good idea. I'd imagine it would work like filling up a tyre with air does.

Week Summary

As the second week of the group project comes to a close, it's time to look back on what we've been up to. So far, I've mostly been focusing on the research phase, getting lots of ideas for the game together and adding them to the Trello board. After researching pretty much every aspect of the game we'll be attempting to create, it was time to begin production. For now, I've decided to start on the in-game HUD, since Xander has begun creation on the character controller, so he'll be able to make everything work as intended.

Trello Board End of Week 2

Speaking of Xander, here's what he's been up to this past week. Thus far, he's begun making the player controller, so you will be able to move and look around in-game. The big chunky script is the main movement script, and it was made completely from scratch. Parts were taken from a previous project, but it has been refined for this game that we're making now. It includes the basic walking and looking around, but also adds running, jumping and crouching. It uses the old input manager instead of the new input system, which works perfectly fine, but means we may want to leave out control changing, unless I try to implement the new system instead. Technically, we could make a changeable controls setting, but I don't think I want to waste the time making something like that when we should focus on getting the main game complete first.

Alongside the main controls, he's also put together a view bobbing system, which makes an arm move up and down as the player moves, a bit like Minecraft. We might want to remove this if an arm doesn't get modelled for the character, but it's still great to have it just in case. Other than this, I don't think he's done a whole lot else yet, but he's starting to look at doing some research soon.

Xander: Player Movement Script

Xander: Arm Position Follow Script

Xander: Main View Bobbing Script

Xander: Arm Rotation Follow Script

For Ash, he's begun making some concept art for the drones that'll be flying around. Initially, he made a quick design that he got from my initial drone reference images, and later went on to start another concept art, but of specific perspectives. I think so far they're looking good, and I can't wait to see what else he creates in the upcoming weeks.

Ash: First Drone Concept Art

Ash: Various Drone Perspectives Concept Art

Finally, you get to see what Dylan has been up to this week. So far, he has been making the planets that will be seen in the distance inside the rocket ship, and probably while you're on the landscape of the planet you've travelled to. He's used procedurally generated nodes inside of Blender to make the textures, and they're looking awesome. Because of the way he's made them, they're very easy to customise, which is what he's thinking of doing, since we had the idea of making our own solar system. Nevertheless, they're still looking good now, even if we just ended up using these. The only thing is, he probably didn't need to go so crazy with the details, since these were planned to be placed really far from you, so you aren't going to be able to see the planets in great detail, but it's still cool.

Dylan: Mars Style Planet Model

Dylan: Saturn Style Planet Model

Dylan: Earth Style Planet Model

Dylan: Sun Style Model

Week 3 - Beginning Production

HUD Concept/Actual Design

The first thing I wanted to work on was the UI. Since Xander could do quite a bit of the coding stuff, I could do some of the designs that he could later use for more work. Ideally, I still want to do some kind of coding at some point, but it's looking like I won't be doing as much as I would usually like to. Overall, I'm not too bothered, and I was planning to put everything together at the end to complete the game.

To begin the UI, I thought I'd start with the HUD, since Xander is working on the player character currently, so it makes sense to get that working first. I began by drawing out the mask of the character model I was thinking the character would look like, using the square tool to create the various shapes I imagined being inside the helmet would look like. After that, I wanted to make the visor sort of design that the character seemed to have. It was a mix of different colours, so I made a solid gradient initially, and then added a texture overlay to stop it from looking completely flat. I made the layers significantly more transparent, so it's not that easy to see on a light background, but as you can see below, it looks pretty good. I'm hoping this will be a bit more noticeable in-game, since I was imagining the planet being quite dark and gloomy.

HUD Textured Overlay

After getting the base part of the HUD complete, it was time to design the rest. To start, I found an image online of a Mars-like planet for a background piece, roughly for what our game may look like. As you can see, you can't necessarily tell that the colour and texture are there, so I'm hoping that on a darker background, it'll be more visible.

After sorting the background out, I began by adding a subtle glow to the helmet edges to give it a display look, before starting to design the parts displayed to the player. First, the oxygen meter was made, and our idea was that we could disappear in a circle as it decreases. It's a bit difficult to explain, but I think it's a cool idea. Additionally, we can have some text in the middle showing the actual amount of oxygen you have remaining, so the player doesn't have to guess. We could remove it, but I think it's better to keep it in. After the oxygen meter was looking good, I needed to make a health bar. It's a bit difficult to see the designs on the small image below, but I'm hoping it looks good in-game. We could probably just make it go down the more hurt you are, using a similar method to the oxygen meter. Lastly, I made a speaker icon, which might not even be used, but we could just have it overlay, maybe with a little animation, for whenever mission control or the companion is contacting the player.

HUD Over Example Landscape

HUD With Included UI Elements

UI Concept/Actual Design

Main Menu Planet Reference

Main Menu Cool Design Reference

Main Menu Title Design Reference

After finishing the HUD designs, I now knew it was time to make the UI that would mostly just be seen on a monitor of some kind in the rocket ship that you start on. I thought it would be a cool idea if you started looking at the monitor, and then you could click the PLAY button to begin, and then go back to it at any time.

Before I started making anything, I first got together some images I found online for examples of how I could design the screen. Initially, I thought about making it completely like a computer or tablet device that you could open apps like settings to change stuff and messages to find the mission objective, but eventually settled for something a lot more game menu-like.

To begin making my menu screen, I first found a nice image online of a Mars-like planet in space. This gave me the perfect placement of the planet, since I wanted to have the main buttons off to the side so the planet was clearly visible the majority of the time. I also thought that the simplicity of the planet background was perfect for our game. Ideally, I would've loved to create our own image, but Dylan was doing other stuff, so I just asked if he could make something if he got the time later. For now, though, this is perfectly fine and works well.

After that, I wanted to make the title first, since then I would be able to base the rest of the design around that. Since one of the reference images had a really cool design for the title of a game, I decided to use that example to base ours on. To begin, I just used the simple cube shape tool in Photoshop to make some lines. I curved the edges a bit and added some nice shapes to them, before altering the colour a bit. I think the fading-out ends look great, as does the design as a whole, thus far.

Background & Title Outline

Title Background Hexagon Shapes Created

After creating the lines, I decided I wanted some kind of design behind the text. Originally, I was going to do the lines that can be seen on the reference, but I want to use the other example image I found with the hexagons. To do this, I used a shape tool to first create the hexagon. After, it was as simple as just copying and pasting the shapes around until I was happy with the area they covered.

After making the hexagon layout, the first design part of it was going to be making the glowing colour gradient that emits from the centre. In the end, this was the outcome, and I think it looks really cool. I also added some bevel to the cubes, which does make them somewhat visible when the colour is no more, but it'll be fine when I add my next part.

Main Colour Fill Fade

Glowing Outlines

After the main design, I wanted to make an outline that I was hoping would become more visible as the filled colour disappeared. Luckily, this somewhat worked; however, it only seemed to add the outline around the areas where the lines were. This happened because I used a different blending mode that makes it look cool, but not as much as I'd like, against the black sky.

Finally, I added another layer of outlines, but this time basically reversing the gradient from the hexagon fill. I think this looks pretty cool and should work quite well. If I were able to get the colour of the glowing outlines looking like this, it would be perfect, but maybe combining them would work...

More Prominent Outlines

Design 1 - Glowing Outlines

Well, I decided to make up three designs, using each of the outlines to decide my favourite a bit easier. To begin, I used just the fill fade and glowing outlines. The outlines look the best by far, but they aren't showing up everywhere, which makes it look sort of weird. I feel like something is needed to fill out the empty darkness, but other than that, it looks great.

The second design was the fade with the more obvious outlines. I think the outline fading transition looks pretty cool and fits quite well, but compared to the one above, it just looks kind of boring and flat, and doesn't give off the glowing vibe I was thinking of.

Design 2 - Prominent Outlines

Design 3 - Combined Outlines

Finally, I have the combined look. I think this looks pretty decent, but still not quite perfect. I think it looks like it's glowing a bit more now, but the colours just look kind of weird in my opinion. They've lost the varying colours, and I think it looks too bright on the outside. Looking back now while writing this, I feel I should've instead made it fade back out at the end, but either way, it could be better. Additionally, it's lost that really unique glow that the first outline had, which is kind of disappointing.

Overall, I eventually decided to go with the combined result, since I still feel like either of the other two looks a bit plain on its own. It became a bit easier to tell what looked better when I added the text, too, and I think this was probably the correct decision. The final touch-up was removing any hexagons outside of the lines. Unfortunately, I had to export an image of the design to be able to remove some, since it would mess up the effects, and it still made it look a bit odd, but it's good enough. Although I'm really pleased with this outcome, I think I would be able to create something much better upon making it again with the knowledge I now have.

First Design With Text

Final Design With Text

Play Button Design with Icon

After making the title, I needed to start work on the buttons, specifically, the PLAY, SETTINGS and QUIT buttons. I imagined these would be relatively simple, since I would be able to copy and paste most of it, just changing a few things for each button. My initial thoughts immediately went to including an icon on each button to improve the game's accessibility in case someone wasn't English or something. I thought this was great, so I first made a triangle shape and altered the dimensions to make a nice play symbol. I then made some other buttons for the other options.

After making the play button, I duplicated it twice to make the other two buttons. For the settings cog icon, I found a design online that I liked and brought it into my Photoshop. Since it was looking a bit weird, I cut three-quarters of it off, and then connected everything back together so it was the same all the way around. Finally, I added the colour overlay, and I have a pretty cool-looking icon.

Lastly, I had to make the quit button. I got the icon again by finding an image online and adding an overlay to it. I think all three icons fit their respective buttons very well and give us some ethical points too.

Main Menu Design with Completed Buttons

Beginning to Make the Settings Menu

Since the UI was mostly done, all that's left is making a settings menu that pops up to allow you to edit the settings. For this, I was mostly going to be drawing inspiration from my previous research on UI, especially since I wanted all of the options to get displayed on one page, since for most simple games like this, making multiple menus is actually kind of pointless due to the lack of settings to change, and it makes finding things more confusing for the player. Either way, this is all I had time to make before the week ended, but I'm happy with the space I have to create it.

Week Summary

At the end of week 3, we had a bit more complete, but not as much as I wish we had. So far, Dylan and Xander haven't given any screenshots for what else they're doing, but they are just doing some small parts on some of the stuff they were already working on. I've finished the HUD and began to create the UI designs inside of Photoshop. Next week, I will hop into Unity with the completed parts of the UI and begin making some kind of menu that works. Xander knows the HUD has been completed, and they're in parts, so he can begin putting the whole character controller and additional features together to work in-game. Unfortunately, I didn't get a whole lot of time this week to do as much as I had originally wanted. On Monday, I had a hospital appointment, meaning I missed a large day. Not only this, but I also had my university interview mid-week. Because of this, pretty much all of my time at home was spent getting my portfolio website up to scratch, since I needed it for one of the interviews I was attending. Alongside us three was Ash, who continued the drone concept art, and made one for the companion robot. He's also planning to make the logo when he gets a chance.

Trello Board End of Week 3

So, this is what Ash has produced in week 3. He finished the drone concept designs that he began outlining at the end of week 2, which look pretty cool. There were a few changes I have suggested, going off of my initial vision for the game, but it's still a cool looking drone.

After that, we have the companion. This is a simple little robot that could be made to follow you around to give you information and help. It would only be small, a size similar to that of a small dog, but I think this design fits into the game really well. I still think it's something we should focus on last, since this won't be necessary to the core gameplay that will be provided, but it's still nice to have a concept design of something that would be added to the full game if we were to make a fully packaged product.

Ash: Drone Concept Art

Ash: Robot Companion Concept Art

Week 4 - Diving into Unity

Finishing UI Design

Completed Main Menu UI Design

After a while of designing the main piece of UI for the game, I think the outcome looks pretty good. Last week, I was all but finished with the majority of the screen, but I needed to complete it by adding the settings menu. I put together a bunch of shapes to create the outlines, and then I also made the main part of the settings, the bit you change. After making everything and finally coming up with a result I was happy with, I exported all of the parts, just like what I did for the HUD, and now I can begin making everything work in-game.

Overall, the design looks great, and I'm very pleased with the outcome. However, I do think this took a little longer than needed, but I like doing this type of thing, and I need to experiment with a few different things for every project, so this is a great start.

After finishing the UI for the main menu, I decided I would get straight on with bringing it into Unity and getting the majority of it working.

My first objective was to create a world space UI canvas and put it ontop of a monitor-like display. For this, because we didn't have exact models for the ship and it's screens, I just quickly made a table with a basic looking monitor on it, and put the canvas on the front face. This gives me a decent looking grey box prototype-style model for the game ideas that we're making. I think with how the rest of the modelling is going, it's not looking like we're going to have many assets to be able to play with, so I may eventually resort to using asset packs, but for now, what I have is good enough. It's now time to make the UI interactive.

UI Inside of Unity Project as Example

Interaction Area Script Part 1

Due to the sheer size of this script, I'm only going to briefly cover what it does, since I've added comments to pretty much every line, as I have in other projects.

Clearly, straight away, there's already a bit going on with all the variables. The most confusing is probably the "Camera Positions", which is basically a few position and rotation variables that are used throughout to tell the camera where to move. Two of them are public, meaning that I should be able to make multiple areas of interaction to streamline any other interactions we add.

Start() is very simple, just locking the cursor since it's a first-person 3D game, meaning you'll want the mouse to rotate the camera, not be a regular cursor.

After that, OnEnable() and OnDisable() just subscribe a method to the interact key, meaning the method OnInteract() will play when it's pressed.

Lastly, the OnTrigger enter and exit methods are what control the boolean variable inArea, so the script knows when the player is within range to interact. Later on, I can add to this by including some simple UI that shows up on screen to hint to the player that they can click a button.

Now comes the more in-depth parts of this script. To begin, we have Update() that is constantly running, but will only do something if the transitioning variable is true. This variable is just used when the camera should be moving, so as soon as it's true, it should smoothly move and rotate to a specific place. Additionally, the if statement checks whether or not the position and rotation are close enough, and if they are, it just snaps them to the specific location to avoid any camera offset over time. It will also give the player control back as long as it isn't focusing on whatever they're interacting with.

Next is the OnInteract() method that the interact action has been subscribed to. This first ensures the player is in the area, and once they are, it makes sure it isn't currently focusing. If it somehow is, it just returns to playing. However, if you are properly interacting, it first saves the current position and rotation of the camera to move back to later, and sets the target position to whatever values have been assigned for the area. It then changes the controls to prevent the player from moving around and breaking it.

Finally, once the player wants to return to playing, they will probably press the play button, which plays ReturnToPlaying(). This simply sets the target position to the saved values from where it was originally, before ensuring Update() plays to move the camera.

Interaction Area Script Part 2

After a fair amount of coding, testing and debugging, I finally have a basic system that moves the camera to face the screen, allows you to interact with only some parts for now, and uses the newer input system. Alongside the main playing perspective, I've added the scene view so you can roughly see how it works. Each interaction area is simply an empty object with a box collider. When the player, which for now is just a capsule shape, enters the trigger collider, they will be able to press E (or whatever the interact button is when I get that working). This then moves just the camera to a specific place, and it returns when the play button is clicked. Not only this, but I also made sure to avoid giving the player the controls back before the camera began moving again, since otherwise the player could move a short distance away, putting the placement of the camera away from where it should be.

Overall, this works pretty well, and I would assume it will work perfectly fine when adding more areas and allowing the player to move the camera around. However, there was one issue that kept happening, which any keen-eyed viewers could notice in the GIF below. This was how, sometimes, clicking the play button would not work, and you'd have to click it again, sometimes more than once, to get it to work. This is obviously not ideal, but I'm hoping it's either a Unity Editor bug or just an issue that will sort itself out with time. I also have a few more issues, all of which seem to be happening from using the Unity Version Control, so both Xander and I can edit the same Unity project. For some reason, it keeps throwing random errors in the console that don't seem to affect anything, but are still weird nonetheless. I'm also wondering how difficult it's going to be to combine our work, and if it will even be worth it, since we are not going to have a properly playable game due to time constraints, lack of assets to actually pack out the map, and very few actual gameplay features.

Although at this point, this project is just an example prototype for what we could make, I do have another issue that I think Xander has worked out fine, but I'm still having problems with. That would be the character controller, and although it appears to be working perfectly fine here, in-game, it does not. For some reason, if it gets lifted upward at all, the character will not fall back down for some reason. I don't quite know why, since the player character has a rigidbody component that is meant to use gravity, but overall, it doesn't matter too much since, as I've said, Xander has the polished character controller, and mine is just so I can test everything working in my section of the project.

Video of Working Interaction Area with Moving Camera & Somewhat Usable Settings

Settings Button to Show the Settings Menu

After getting the camera movement working, my next objective was to get more of the menu working. Firstly, I quickly made the settings button actually show the settings menu, and also made the close button close it. This was as simple as changing the active state of the menu through the buttons' OnClick() functions.

Next, at the bottom of the InputManager script that I grabbed from my Pinball project, I added a very short method that I could put on my quit button which would close the game. I still feel like adding a quit button is necessary in a game, especially with how simple and easy it is.

Code for Quit Button

Audio Mixer Script with Saving Function

Lastly, I also brought across my slider audio script from Pinball and edited it a bit to fit into this project. By editing, I mostly mean removing the stuff I didn't need, like the change of text, since I was just going to have a plain slider that doesn't actually tell you the exact volume, because I didn't plan ahead for it.

Again, the script has plenty of comments and is pretty simple, but I'll give a brief overview anyway. In Awake(), the slider component is automatically assigned if it isn't already. Start() then ensures it's loaded from the saved values.

Whenever the user lets go of the left-click button on their mouse, it will simply save the value. At the moment, I've had to comment out the playing of the sound, since the ?.Play() didn't work as I was told it should and threw an error, since for now I have no sounds.

Finally, I believe I just set the method ApplyVolume() on whenever you change the value of the slider, and it will set the specific mixer group's volume to the slider's value equivalent.

After messing around with the scripts in the game, the final part was making a loading screen. For this, I've literally just made a few different layers of the computer screen and animated them. This is because, ideally, you would be staring straight at the screen at the start of the game. An issue I quickly realised with this currently is that you are able to move around a bit while the animation is playing. However, I now realise that this wouldn't be a problem in a more developed version of the game, since you would be starting in front of the screen, meaning you wouldn't be able to do anything anyway, since the control scheme would be the UI by default. I might try to get this working as intended a bit later, but for now, it works perfectly fine.

Another thing I will be adding later is the control for pausing the game and adjusting settings on the fly. My idea for this was going to be that an animation would play where you bring out a tablet or look at your watch, which mirrors the screen of this display. You would then be able to interact with it this way, which I think is a pretty good idea, and keeps up with the futuristic theme.

Video of Loading Screen & Straight Into Gameplay

Creating a Basic Map

Map Skybox & Landscape in the Distance

To begin making the map that I would be using as a baseplate for the stuff I was making, I needed to find a skybox that would better match what kind of atmosphere I was going for. As you can see in the distance, I did begin a bit of work on the landscape, but the main thing I wanted to focus on first was the skybox. For this, I just had a look around some different websites online until I found one with the kind of design I wanted. I thought a dark sky was the main feature, but the one I eventually went for also had an environment I sort of wanted to replicate. By later on adding some relatively high terrain, I could hide the majority of the skybox terrain, just having a bit stick out to enhance the look.

For the landscape in the game, I decided to just use Unity's landscaping tool to make the ground, and then add trees later. In the end, I found out that you could add tree models straight through the landscape tool, so that's exactly what I did. Originally, I was going to try and model a tree myself, but when 3DS Max didn't do what I wanted it to, and I knew it was going to take plenty long enough for just one tree, I decided against it and began exploring other options. Initially, I found out that you could create trees directly inside of the Unity Editor, probably to aid the landscaping tool. However, I later found out that you needed a specific material, and for some reason, none of the texture maps would make it work, so I also had to abandon that, which was probably for the best, since I had quite a few issues.

In the end, I settled for a free asset pack I found on the Unity store which had pretty much everything I needed inside, plus a few extra I could use to decorate my environment more in the future if I want. I picked out a variety of models, placed a bunch around with the landscaping tool, and boom, I had my environment. A bit desolate? Yes. Repetitive? Yes. But good enough. Especially because I had no original assets and this wasn't going to be released, I tried to avoid spending any additional time I didn't need to on it.

Map Design

Mouse Moving Camera Script

After completing the landscape, I wanted to finish off the week by trying to make the camera movable so you could look around instead of just being able to move around without rotating at all. To make this, I had to add some code to my script that would take the mouse position and rotate the body if it was moving side to side, or rotate the camera if it was up or down. I also had to clamp the camera to a minimum and maximum angle since otherwise, you would be able to look around unnaturally.

I also had to lock the cursor to the centre of the screen to allow me to move the camera around properly without the mouse flying around across my screen, which would become very distracting very quickly. Overall, this was a good start; however, I will definitely come back to alter this script since not only is it very basic and not the best at the moment, but I will need to be able to interact with the screen and lock the rotation so mouse movements don't affect it.

Week Summary

As the fourth week comes to a close, I'm unfortunately realising that we are not going to have a playable experience due to the lack of time remaining. We are missing a lot of models to fill out the area, but also quite a lot of the gameplay mechanics that would need to be in the demo part of the game. This is because I have many other ideas if this were to become a fully-fledged game, but unfortunately, we're not even going to get the demo part complete, which was our main goal for this project. As we near the remaining few weeks, I think it's beginning to show how slow we have been. I don't feel like the blame should be put on any particular person, because we all could've done more. I think one of the most frustrating parts for me was how I had to make the 2D designs because Ash said he couldn't do this and would rather make concept art. I think overall, this makes sense, but with two programmers in the team, I really think we should've focused on getting a playable demo as the base idea for the game instead of a random set of assets and ideas, since there was a fair amount of potential in this team from the start.

Nevertheless, I still think my week has gone well. I've got a lot more added to my section of the Unity project, including finishing the idea for the working UI with the interaction area, as well as a basic loading screen and map. I'm struggling a bit with what else to do, probably similar to Xander, due to the fact that I don't have any models to work with, but I am still making things work with the simple Unity shapes and assets.

Trello Board End of Week 4

At the end of week 4, we will first look over what Xander has made this week. He has been kinda busy making some scripts for the game. For starters, he got the health and oxygen working by making a script that will gradually remove oxygen when you are outside of the ship's area. He then allowed you to refill the oxygen by pressing Q, but this is very simple, without any animation or anything, I believe. He then also added an if statement that checks if the player's health or oxygen meter is 0. If they are, it will change a few things that I assume just make the game know the player is dead. Lastly, he added it so that if you click E, it will do damage to the player, so we can test if the health works. This is a very basic script, and would need a fair bit of editing for the main game, but it works fine for our game example.

Next, he made a script that makes the companion follow the player around. This is pretty short, but it works well. It will make the companion look at the player and then work out the distance to the player. It will then move toward the player if it's further than 4 meters away, and stop when it's close enough. I'm not too sure how it all completely works, since the movement speed isn't included here, and I haven't really used a nav mesh myself before, but I assume everything works as intended. Personally, I would have also added something like a wander system so it can move around a bit around the player, and I assume the moving toward the player is very linear, but maybe that works since it would feel quite robotic.

I think that Xander is now waiting for Dylan to complete some models and will improve either of these by using the oxygen chamber thing or making the companion look more real. I believe at the moment, it's just basic Unity shapes that he's using, which works for the example demo sorta thing we're trying to make, but it could look better since we aren't going to have time to make something actually playable, so we should just focus on making some of the gameplay ideas look good.

Xander: Health & Oxygen Manager Script

Xander: Companion Follow Script

Next up is Ash, and he advanced a bit more on the 2D designs by making some concept art for the rovers. This included two different variations that could also be found around the map. These could be friendly ones, or enemy rovers that have been overwhelmed and taken over by the rogue rover's AI. For what we're doing with everything else, there probably isn't much point to modelling and trying to code in any of these additional things, but it's still cool to have the ideas.

He's still left out the colour for now, leaving a colour palette for what he'll use later on if he comes back to colour them in. He's going to start work on the game's logo soon, and since nobody else has an idea for a name, we're sticking with my idea of Rogue Rover, so he's going to make a stylised image of two Rs.

Ash: Tank-Like Rover Concept Art

Ash: Turret-Like Rover Concept Art

Lastly, Dylan has been busy modelling the head of the companion robot from Ash's concept art. He also did a bit of modelling on the oxygen canister, but I have yet to get the finished screenshots of it.

I think the head overall looks pretty cool, and he's done it in a way that it would be pretty easy to rotate around for animations that we may or may not add. I've since asked him to model the tower instead, because apparently, Xander said he probably wasn't going to implement the oxygen canister into his system. Therefore, I suggested he begin modelling the tower, since I was planning on getting that working next, since I don't want to spend the rest of my time trying to figure out how to get the drone or rover PvE mechanics working.

Dylan: Companion Head Front

Dylan: Companion Head Side

Dylan: Companion Head Front Angled

Week 5 - Finishing Gameplay Ideas

Finishing Interaction & Adding Control Scheme

After a relatively successful previous week for myself, I still found there to be quite a few things needing to be done. To start the week, aside from doing blog work, I wanted to start work on the towers found in the boss battle. Since I didn't yet have a model, I thought that I would probably do something very basic, just using Unity's 3D objects to get the base idea laid out and complete.

Canvas with Interaction Text

However, before I began production on the towers, I first wanted to add the interaction text that would show up on screen to tell you when you could interact with something. To do this, I first made a very simple canvas with some text on it.

After that, I opened the interaction area script again and began making some changes to the code to make it show up whenever you entered the area.

After I made the text UI, which was very simple, I then simply added the interaction text appearing and disappearing code by changing the active state.

Although this worked as intended, I knew this wasn't good enough for this example, so I wanted to go a step further by ensuring it displays the correct keybind that the player assigned to the interact action. I thought this might be a bit difficult, but it turned out easier than I originally imagined.

Adding Showing the Interaction Text to InteractArea Script

My Initial Attempt at Displaying Specific Interact Keybind

Initially, I started by using this line of code, which just grabs the specific action and converts the output to a string. However, the output of this is: Player/Interact[/Keyboard/e] to interact

Since that wasn't working right, I had no idea how else it would work, so I decided to ask my good friend ChatGPT how to do it. After first asking, it got me mostly on the right lines by replacing .ToString() with .GetBindingDisplayString(). However, since I was using the default Unity Input System that comes with every new project, it includes a variety of console and other controls, so the output would this time be: E | Y to interact

ChatGPT's Code to Display Specific Keybind

Since I was all but there, I told the AI bot about the second issue, and it told me I could make it work by specifying what control scheme is currently in use. In the end, it spat out this section of code, which would work perfectly fine, but not only through my obsession to have my code written in as few lines as possible, but also so I can change it at other points in the script, I imagined it should be possible to make it all in one line.

So, I used my genius brain to produce this line of code, which does it all in one, meaning I can very easily use it in other methods in this script. Combining the active state changer makes two lines of code that do exactly what I set out to make, so I'm very happy.

AI & My Improved code to Display Specific Key Assigned & Correct Control

The next few scripts were generated by ChatGPT because I had no idea how to create a raycast interaction to be able to interact with the screen without a cursor. Since I was just using a crosshair to visually show the player where they were looking, I needed to create some code to make their interactions work just like they would with a regular cursor.

Raycast Code Controlling Hover and Unhover Button States

The raycast would be created by sending out a new ray from the front of the camera in the centre. I added a debug ray, which would display a red line for the ray in the Unity editor, so I could ensure it was hitting everything properly. We then needed to test if the ray hits anything within a certain distance, and if it does, it will get the button component from said object and first test if it's being hovered over by comparing the grabbed component to another button variable. When they're not equal, it ensures nothing is displaying the hovered form and sets the current button variable to the component. Whenever this runs again, it will just keep it hovered then instead of instantly clearing it.

However, if the ray doesn't hit anything or gets hovered over a new button, the ClearHover() method gets run. This is actually a pretty simple piece of code, and just calls the unhover method and sets the selected button component to nothing. To signify nothing being selected.

The next piece of code made was the UI interaction part. This basically made it possible for me to left-click on buttons as long as something is being hovered over and the player is focused on the screen. I subscribed to this method inside OnEnable() by grabbing the new action I added inside the UI Action Map, so it only works when you're focused on the screen.

Button Interact Code Linked to Raycast

Script Put on Each Control Button to Allow Raycast to do Cursor's Job

Here is a relatively short script which is required for the interaction script to work. It's actually pretty simple, since all it does as soon as the project starts is grab the correct button component placed on the parent object. It then has three methods, all of which you've seen already in the interaction script. These basically just allow the interactions to tap into the specific button being hovered over, and will execute particular events which control what the button does. Think of the cursor interacting with the buttons as a wired mouse; all of your mouse data goes straight to the computer. However, a wireless mouse must connect to a dongle of some kind and then feed the information to the computer that way. I'm technically adding more steps, but it all works the same, and looks and feels a lot nicer than hiding and unhiding the user's cursor.

After getting the button interaction working, I now needed to give the control buttons some use instead of just changing colour a bit. Luckily, I already had an idea of how to do this since I made a custom control scheme menu for my year 1 FMP, but now I was returning and creating it with Unity's newer Input System. Again, I've had to use ChatGPT for this script as well because I didn't know how to even really start, but I went through every line of code with it after and got an explaination so I was able to comment everything. I still don't fully understand some parts of the code, and feel they could've been made a lot simpler, but what do I know🙹

This script requires an action to be selected for what it signifies, the text displaying the current control, and the index for the control (used if there is more than one control assigned to an action). After everything is loaded, the settings menu that the player can navigate to will display the current keybind for each of the controls. Since I have put the ScreenButton script on a new collider for each of these controls, you are able to click on them, which will run StartRebind(). This will first change the text to "Press a key...", indicating you should click something. It also ensures the action is disabled to prevent accidental movements. It then gets ready for an input by listening for anything except mouse inputs, and when something is pressed, it re-enables the action, updates the displayed control and saves the binding.

Everything else is relatively self-explanatory with the comments, but the AI, ChatGPT, told me to use BindingOverridesAsJson because this saves any overrides while also remembering defaults, allowing you to go back quite easily.

Code Controlling the Update of the Control Scheme

Script that Loads any PlayerPrefs Saves on Startup

This last script was mostly just a rewrite of the loading script I created in my previous project: Pinball. All it does is activate certain layers that wouldn't be active on game start, and then hides them after just 1 second.

I've also kept a method for deleting all of the recorded PlayerPrefs saves that I can set to a button's OnClick() if I want to include a game reset.

To get anything to load on startup, I just have to add them into the layers array. At the moment, I'm able to just show the whole settings screen, which works pretty well for that. Having the loading screen prevents the player from seeing anything happening, keeping everything seamless.

After all of that coding and teaching myself how to make things work, we have this finished result. I start off by moving around and then show off how the crosshair can interact with buttons by changing the colour upon hovering over them and having the ability to click. You can just about see the debug red line moving around with me, which is basically showing how the raycast line is working.

After that, I changed some of the controls, first just changing the interaction key to G, which not only works, but it also changes the text at the bottom right corner of the screen to the new control. Following that, I made the forward movement control to E, as well as the interaction control, which then makes them both work at the same time. If I were to continue developing this part of the game, I'd probably make it impossible to rebind the same keybind to more than one control, or at least flag a warning to the player, but everything works fine, so I don't mind leaving it in. Anyway, next I altered a bunch of controls, stopped the game from playing and then straight away started it back up. As soon as everything loads, you can briefly see the settings menu show up for a second before hiding itself again. This was the loading mechanic working. I then go up to the screen, and you can instantly see the controls have saved since the interaction text shows the correct keybind, and then so does the settings menu.

I think overall, this was a great success, and I'm very pleased with the outcome. Not only have I made changeable controls that I can put into future projects really easily, but I also have basically remade the mouse cursor controls. Having everything working, with a cool, immersive feel, and being able to look around, I feel really proud of this outcome. For now, the only thing I feel like I'd really want to change would be making the player's body also move to a certain place with the camera, since sometimes the looking around feels a bit janky because it's rotating the player's body, so if you're far away, it doesn't quite feel right. Nevertheless, I think this mechanic is super cool, and I'll definitely consider using this in future projects if I want the player to feel really immersed, even with menu screens. The main annoying thing that I don't think I've said about yet is the fact that the volume sliders no longer work. Luckily, there is a way to make them work with another script, but it's not like I can just change some things in the button script. I could instead make the volume set amounts, like 20%, 40%, 60% etc, but that feels a bit odd, and I feel like having a slider is just best for everyone. Either way, I don't plan on adding any more interactions to the UI part of the game, so this is its finished state for this project.

Video of New Camera Working Crosshair & Control Scheme (Includes saving)

Week Summary

At the end of the penultimate week of the group project, as we are beginning to wrap everything up and begin putting together a presentation to present to a university professor, I think what I've done this week is decent. I feel I could've produced quite a bit more if I didn't have as much blog work to write up, and if I hadn't spent so much time trying to get a customisable control scheme to work. Nevertheless, I think this was actually a pretty beneficial investment of my time long-term, since I will very easily be able to copy and paste this work into my FMP and other future projects. Not only that, but I've taught myself a lot about the new Unity Input System and how other features work that I hadn't even heard about yet. Additionally, I have brought the boss battle tower into the project and applied all of the textures, ready to be used. Unfortunately, I don't feel like I'm going to have the time to produce anything worthy in the time. I can maybe get a working example of how it would roughly work, since I just need to apply a bunch of stuff that I've already been working on, but it's not going to be very functional, especially without a boss to battle.

Trello Board End of Week 5

Ash: Logo Example Design

At the end of week 5, Ash has produced a very rough logo design for the game. Due to my game name idea not having any competition, and having made the start menu with the game's title already too, we just decided that Rogue Rover would officially become the game's name. After deciding that, he went away and made a logo for the game which was just going to be two Rs next to each other. I think I might have already said this somewhere above, but that is the exact outcome we see here. He also added some colours blurred in the background, which I guess we could say represents technology how you sort of have RGB colours, along with a few others which could sort of link to technology.

Next up was Xander with his model of the boss tower. I think he mostly just took inspiration from the AI generated image of my idea for the tower, simplified it, and quickly whacked some textures on. The one thing I really like about it compared to the AI design is the size change for the keypad. It looks like it's actually meant to be there now, and I think the buttons look pretty cool. I asked for the buttons in particular to be kept separate so I could animate them all separately, which he did, so if I get the time, I can try and at least make it somewhat work.

Xander: Rover Boss Battle Tower Model

Dylan: Cryosleep-Like Tube Model

Lastly, Dylan modelled the cryo tube thing that I was wanting the player to be able to get into to pass the time after you've had a look around the ship on the game's start. I should add that he actually got the model rendered at the start of week 6, but everything was pretty much complete at the end of week 5.

I think overall, this looks pretty cool, and it shows how good a model he can make, even if it is really simple. However, this doesn't fully fit in with my ideas and screenshotted ideas for it originally, since I ideally wanted it to be something with a clear doorway to be able to get in and out of. I think we could try and implement something from this design, but I was hoping he'd go more down the lying down pod design, but I guess he just preferred the simpler standing tube design. I think with this, we'd have to make it something similar to that seen in Fallout 4. I say Fallout 4 in particular because that's the only one I've played, but in the opening section of the game, you are put in them and wake up a lot of time later, heavily replicating what my vision for them was.

Week 6 - Wrapping up Production & Presenting our Ideas

Adding the Boss Battle Tower Keypad Functionality

At the start of this week, I was well aware that we had to get a presentation completed and ready by the end to show off our idea and what we have created in these short 6 weeks. However, alongside creating it and adding my content, I still wanted to finish off what I was doing: making the boss tower keypad interactable. Due to me now having a proper model to base things off of, it felt a lot more natural, and it makes watching everything a lot easier to understand.

To begin, I mostly just created both the script for the keypad and the script that would be put on every button for the keypad. This is because every button would need to have some specific data that would tell the keypad what to input or do every time it's pressed. The keypad would be the main brain behind it all, though, and where most of the code goes.

Before I show the finished scripts, it should be known that the majority of these were done completely by me, without searching anything up or asking my good friend ChatGPT. I feel this is a real accomplishment, because I usually have to at least look up something for scripts, but at least now I can do some very basic things completely on my own. However, once everything was complete, there were a few issues with the code; the first being how the pressed button inputs were added. In my code, I simply wanted to add the string of the pressed button to the end of the text variable. I originally did this by making the text equal to whatever it currently was and then adding the string. However, this wasn't quite doing what I wanted it to, since it would instead display what the variable is and then add on the string. This small logic issue was due to my forgetting to add .text to the end of the second use of textDisplay. However, AI would later tell me to just use += instead of =, making it a little shorter and, in my opinion, easier to read. The other thing ChatGPT recommended was that instead of clearing the display if a button was pressed when the length was maxed out, I should just stop the method running, which does make it more realistic since that's what would happen in real life.

My Button Press Code

ChatGPT's Altered Button Press Code

Output Display with My Original Code

The second AI-altered code was at the start when the random number was generated. The majority of what I wrote was completely fine, and although I didn't really need to type 0000 as the lowest since it would just be 0, it still worked. However, the logic error was converting it back into the password, which was a string. Either way, the integer value could have been incorrect already, since if a zero was at the start, it would only be a three-digit code (e.g. 0123 -> 123). Therefore, when it is converted into a string, I needed to add "D4" in the parentheses of .ToString() to ensure it's formatted to be a 4-digit number, adding any zeros at the start. This then makes sure everything works correctly. If I wanted to, I could've left this out so the random number could generate proper numbers, but then I'd have to always check the length of the password, which just seems unnecessary. Not only that, but it's not how keypads work, since they would usually require a 4-digit password anyway, so it just makes sense to add the "D4" in.

My Random Number to String Code

ChatGPT's Altered Random Number to String Code

The first script I made for the tower was the keypad script, and it's the one with the most in it, too. This relatively large file of code does a fair amount, and I'm going to talk through the few parts that haven't yet been looked at. To begin, we have ClearDisplay(), which was created for a quick and easy way to clear the display of the keypad. Although this might seem pointless since it's only one line of code at the moment, it would be a lot more useful in a fully-made game, since I would have probably added sound effects, more things changing and maybe even particle effects, so this way is a lot more scalable.

Moving down the script, we have ConfirmPress(), which is where you check if your input is the same as the password. This is triggered by pressing the confirm button on the keypad, which also then starts the coroutine ConfirmColour(). This simply makes the text green for a second if your input was correct, or red if not. After that second, it's changed back to white, the display is cleared, and the boolean variables are reset.

A couple of things I will add on to what was already covered are that I added a note in-game that displays the password for the tower. This note's text gets changed straight after the random number is generated. Additionally, inside ButtonPress(), if the player has clicked confirm, pressing buttons will not do anything until the colour changing has taken place, avoiding any extra button presses to mess up the system.

Boss Battle Tower Keypad Script

Finally, there is also the script for each of the buttons. This is incredibly simple and just requires the script to be placed on each button for data loading and then can be called whenever clicked. The reason I've put this on every button is because they need to have a value that will be sent every time it's pressed. I could've done this a bit differently, assigning two arrays to store the data of the buttons and inputs instead, but for the size of this project, what I've done feels better.

All I need to do for each button is input a specific value (e.g. input = 1 for button displaying 1 or input = X for button that clears), as well as the keypad script to be able to run certain methods. Then, all that happens is upon a button being pressed, it's tested for whether the clear, confirm or another button is pressed, and references a specific method inside of the keypad script depending on the one.

Boss Battle Tower Keypad Button Script

And then, after writing all of the new scripts and utilising some of the old for the interaction area, we have a working keypad. I think this works really well, and exactly how I envisioned it. Obviously, there'd usually be other things happening as well, such as the rover losing power from this specific tower, but I think this gives you a better idea as to how the boss fight would go. Obviously, this seems quite underwhelming at the moment, but I'm sure when the pressure of having a robot chasing you is looming, as well as the atmosphere and environment looking better, it would work very well. Moreover, we could even add more functionality, as the keypad allows you to access the wires inside the tower, and then you need to cut a specific colour to disable the power, but you have to be careful because cutting the wrong one could electrocute you, losing valuable health. Also, maybe the keypads could get disabled for a certain time if you get the code wrong, meaning you have to be certain about which code correlates to what tower before trying. There's a lot more functionality that I can think of; it's just unfortunate I didn't have the time to properly think about how to improve certain features when researching or having the time now to implement more. Even so, it's great to get more ideas that I could use in future projects.

Video of Working Boss Tower Keypad & Random Code

Text

Week Summary

Well, at the end of the final week, finishing the few bits I was doing and beginning work on the presentation, I think what I've produced went pretty well. I wish I could have done more, which I probably could have if I really wanted to, but I just haven't had the motivation with this project as much as others. Either way, I think the few finishing touches on the Unity project on my behalf this week seem pretty cool, and I'm glad I was able to at least make one of the main game mechanics.

Alongside my production work, I've also put together my part of the presentation, which I think has gone pretty well. I'm happy enough with how it looks, and I've done a few mini rehearsals in my head to prepare myself for what I'm going to say.

Trello Board End of Week 6

As well as myself, Dylan has continued in the production area to make something else for the game. This ended up being the companion robot that would follow you around. He had already started a bit of work on this in the previous week, but it was quite minimal at that stage. This week, he continued working on it and completed the whole model. Additionally, he also

Dylan: Companion Robot Model

Text

Page updated

Google Sites

Report abuse