17307 words on this page!
Before I start putting everything together inside Unity, I will need a decent amount of decals made by Lucas to have a baseplate of what I'm working on. However, I thought it would be a good idea for me to begin making some UI for the game, such as some buttons and sliders, figuring out where I want everything put on the screen, and the few menus that will be included. I already had a rough idea, but personally I like to just make everything up as I go with regards to the UI, since I could be constantly adding and removing things that mean I have to change it anyway, so that's exactly what I'm going to do.
Going partially off of what we have already chosen to be an inspiration for our game, I thought I would probably use Pumpkin Panic as a reference for the main menu UI. As for the settings, I really like the minimalistic look of the one from Stardew Valley. I think putting something that looks a bit like these together will look great, and it should be relatively simple to get a few things started.
Going into more detail on why I chose these games, first of all, they are both very simple, which is good for our game since it's going to be quite a simple and minimalistic-styled game. The main things I like about the Pumpkin Panic main menu is the fact that it has some text that moves around, which looks quite neat, and the background isn't just a static image, but a very simple animation. I think this also gives off a slightly unnerving vibe that represents the game quite well, without spoiling too much. Lastly, there aren't many buttons, which is actually good for our game because I have no idea how to make a game save, and therefore, there's no reason to have a button for a new game save or for loading an already created save.
Then, in the settings menu, I think everything is laid out very nicely, and the tabs at the top of the screen look cool, and although we won't have many settings to change, I think I want to try and make something similar because it's a neat feature to have. I also like to have a lot of customisation, so I could include a lot of changes if I get time, such as different main menu backgrounds and fonts, and possibly even a max FPS cap if I can find out how to implement these.
[1]
[2]
For now, this is what I've made for the main title screen. It's very simple and basic and doesn't look that great, but I think a better background will certainly improve it, and I'm going to animate a few things too, so once it's done, I think it'll look decent. For the moment, I've just made the buttons clickable, and they go a bit darker, but that's the only bit of interaction for now.
After looking at the various things I could do with the button component, I realised that I could make an animation of sorts, which allows me to make a cool-looking animation with the buttons, making them feel a lot more responsive, as well as making the game feel more complete already. I still made the buttons darker, but it looks much better this time. Personally, I don't like how much the button gets pressed inward. I feel it makes it look quite squishy, which isn't a bad thing, but I might just have to make the transition happen quicker instead. Once you know how to do this, it's quite simple. All you have to do is select transition instead of colour change or whatever's selected when you first add the button component. You can then click a button which will generate an animator automatically for you, and then all you need to do is select the button in the hierarchy, open the animation menu and select which animator part you want to animate. This is quite difficult to explain over text, but I'm trying my best. I then just clicked the red record button, resized and/or recoloured the image and then, because I clicked the record button, at the first frame, it will have put a keyframe down for whatever you did, which is just instead of clicking the add keyframe button. After doing this for all of the animator parts (selected, pressed, hovered, etc.), you have a finished button. I'm unsure if there's a faster way to copy this to other buttons, so I had to copy the animation for the other two manually, but it works, and that's the main thing.
For the title, I simply selected the image, created a new animation and just moved it from different positions, and it created this neat pulsing, moving effect. Upon doing this again, I would make sure to alter the keyframes a bit at the end, since when it pops out to the right and goes back to the centre, it stops for a frame instead of smoothly going to the left. This is something very small, however, it is noticeable if you watch, and so I think it would be perfect if I just removed that very short pause.
One thing I wanted to add regarding the buttons was that I also don't like how they have a selected state. As you can see, once or twice, when I click a button and go off of it, it stays darker, because this is the selected state I made. To get this to go away, you either have to click on the screen elsewhere or click another button, which will, in turn, put that button into the selected state. I know it isn't a big deal, but I find this really annoying, and most games don't have this problem, so I'm hoping I can fix it, and if I can, it'll make sense when I talk about it later.
Sounds
The first setting menu I wanted to create was the audio. I didn't know exactly what I wanted it to look like, so I've made up this simple mock design as an example. As you can see, I've made it look a little different on the top of the menu, too, so you can see which menu you are currently in. In the Unity project, I'll make it so one image gets unhidden, since it's made up of two layers. For now, I've also chosen to make three different audio things that you'd be able to change. I think this works fine, however, I might end up at least getting rid of the other audio, since I don't know what I'd set this to, and it would make my life putting everything together a bit easier.
Controls
The next settings menu I wanted to design was the controls. For this, I originally thought I'd just make a screen to show you the keybinds for each action. However, I'll probably change this in future to rebindable controls, since that would look more professional, and be more inclusive to players wanting to play. Furthermore, pretty much every game that you play nowadays has bindable controls, so it wouldn't be up to the standard of games that are being made these days. Also, something I haven't pointed out yet is the close button on the top right. This doesn't have a second image like the tabs at the top - just thought I should point it out. Also, with regards to the controls menu, I think I might want to add some kind of information to each setting. This could either be on a hover over, or I could make a separate menu that pops up and explains each control. Not that necessary, I know, but I could also bring this across to the other menus, but this is going to be a stretch target for me, if I get most of the game complete.
Display
The final setting menu that I've made is going to be a display menu. This will most likely have three settings: resolution, fps cap and brightness. Brightness should be the easiest to do if I just add a black image over the camera, which you can change the opacity of. However, I could always go a bit more in-depth, since I've seen that there are better ways that are already built into Unity, but this might be a lot of work for not much point, especially since I always set the brightness to max in game so, players may not even use it. The FPS cap, hopefully, will just be a simple Google search away, and then changeable with some simple code, but I can almost guarantee it won't be that simple, similar to the resolution changer. With regards to the settings menu design as a whole, I want to spend some time designing it with some good detail, but that'll be another thing I will work on (or Lucas) if we get time to, since I think the working menu is good enough, and design should come later if we get most of the game complete.
Controls Scripting
After getting the designs of the settings menu complete, I made everything interactive. Next, it was time to make them do things. Firstly, I wanted to do the control scheme, since I imagined this would probably be the hardest and most in-depth part. To begin, I started making a script that I would replicate for each button in the controls menu. The image I've attached below is for the Forward setting, however, it's pretty much the same for every other setting. I start by adding a new text variable. Because I am using TMP (Text Mesh Pro) throughout this project, I need to remember to add the TMP_ to most variables. This will be changing the text of the button that you press, and so, I've created a new void at the bottom of the script called ChangeForward(), which I apply to the button's OnClick. Then, whenever the button gets clicked, it will set the text to "Awaiting Input".
Inside Update(), it's waiting for that button's text to be set to that specific text. Once it is, it will go through each keycode and get the values of them. If the user then presses one of these keycodes, it will make the button's text whatever the keycode is that they pressed. This will then stop the Update() method, and for the player, the keybind looks to have been changed. I did use ChatGPT for this part, purely because I had no idea how to get it to test for any key code that the player presses.
This looks all well and good; however, with a script for every control, it will quickly pile up a lot of scripts that say pretty much the same thing. Instead, I wanted to have one script that I could drag onto the button of each control, and manage it that way. This would also probably take less effort if I were to add more controls in the future, so I think it's the best way going forward.
This has no comments due to being deleted and not used. This was my first attempt of creating a keybind script for one button specifically.
After realising that I wasn't doing things in the most optimal way, I opted out and decided to ask ChatGPT for some help, since I had no idea where to start with my more optimised idea. After explaining the situation and sharing the full script of the original control changer, it told me that the best way to do things was with two scripts. One script would be the Keybind Manager, and it would be responsible for changing each control's keybind. I also needed another script, which would be put on each button, changing the text of the specific button pressed, as well as giving each button its action name, which will be used to differentiate between them in the Keybind Manager. Sound confusing? Yep, it sure is, but that's why I've written plenty of comments around the code to explain what everything does.
Although I've written comments around all parts of the code, I thought I'd just give a brief explanation as to what's going on when I press a button.
For this example, I'll be using the forward control. When the player clicks the designated button, it will straight away change the button's text to Awaiting Input. This is because I assigned the OnClick() method to the button's OnClick. It will also start the StartRebind() method in the Keybind Manager script, which is called using its Instance reference. It uses the name that I've assigned to the button, which in this case is Forward. This then takes it into StartRebind(), and sets the variable keyToRebind to Forward.
This will then start up the OnGUI() method, which, at least in my eyes, acts like an Update() method. I'm probably wrong with this, but stay with me here. Because keyToRebind is no longer null, it makes a new Event variable, which is used to register if something specific happens. This then tests to see if a key is pressed, and once it is, it will first check if the key pressed already exists as a keybind. If it does, it resets the keyToRebind, and at this time, the button script is waiting 1 second before calling the UpdateLabel() method, which just shows the same keybind that was there before.
However, if a new key is pressed that isn't already assigned to a control, it will make the action (Forward) equal to the new key code that was pressed. This will then change the button text to whatever the new keybind is. The one thing that I can't get my head around is whether I like or dislike that you only have a second to change the keybind, which could be both good and bad, depending on how you look at it.
This is very easy to use, since I just type the reference to this script and use whatever action name I want to use for anything. This will make more sense when I show it in something like the movement script.
After going off and creating some quick mock designs for the settings, I thought this was a good time to go and make all the main UI for the game. In the end, I got most of the UI done within the first week, meeting my original work plan quite well. However, my blog isn't quite up to date, along with it, and the settings don't work completely, since I don't have things to assign them to yet. Overall, I think this is going well so far, but my greatest issue of not having enough time to do my blog alongside creating the game may come back to bite me toward the end of the project.
Up next for the project, I'm going to start making some of the key gameplay aspects, mostly bringing everything across from the prototype that I made during the research phase. This should hopefully be done within a few days of next week, and I can start getting a rough map idea down and out of the way, with interactable plant patches and stands.
To see the completed UI for now, see below, where I've made a short video displaying all of the features.
The next stage of the game that I needed to work on was going to be the map and getting some gameplay aspects done. I can use the Prototype I made as a baseplate for the planting and harvesting mechanics, however, I do want to change some of the code so I have a separate inventory script, and possibly even separate every mechanic into separate scripts, since I we are going to need some more varying mechanics such as temperature and water level for plants, which would make a script unecessarily long.
For now, though, I went and searched on Google for some reference images that I could use to make the game's map look somewhat decent. I thought I'd need a bit of inspiration for how everything should be laid out, but I'm also going to have to think a bit about the story that we are making for the game. We are meant to be borrowing our friend's land to start this farming business, which is something I'm going to have to consider when making this.
[3]
After thinking a bit about what I wanted it to look like, I thought the best way to design the land was to just make a flat plane with a nice green texture, and add details to the land as I go. I really like the third image that I have attached, since it has some varying grass sticking out of the ground, as well as a rock on the ground. I think I can take inspiration from this, as well as the game Muck, which is the last image I attached. This is a great image displaying the varying landscape the game has to offer. It's nothing crazy, but the patches of grass make the game feel a little less boring, and there are some rocks, trees and a few other things dotted around to make the game feel more developed. I think something like this level of detail is going to be ideal for my game, especially since I don't want to add lots of models and make it really laggy, so I'm going to have to bunch models together and just give them a simple texture to make the game seem a little more detailed. I'll probably end up making some kind of path around the map, which could look something like what is in the first two images. So far, I'm unsure as to how I want it to look, and ideally, I don't want players to be able to climb on certain things, which is why I'm hesitant to make something other than a flat surface world, because it'll make collisions all the more difficult.
Looking at what I eventually spent some time on, you can see that I began mapping out how I want things to be placed. The problem I have with this is that it looks very blocky, so I'm either going to have to change how things are laid out or just make a bunch of stuff around them to make it seem less like this. I think once the game is done, it probably won't look too bad, but I have no idea how I'm going to implement placing things in specific areas, since I don't want to have a bunch of models stacked together and then it just displays the one you have placed, because in a large area, this is going to make the game lag a lot, at least I assume it would.
Upon questioning the great ChatGPT about whether I should keep the inventory, planting and harvesting mechanics in one script, it recommended that I at least make a separate one for the inventory, and then I could either keep the other ones together or split them up, depending on if I was going to add many more mechanics to them. Because I'm looking into having multiple plants, as well as possibly multiple requirements for plants to grow, I decided that the best thing to do was to split everything up into separate scripts. Since I was already talking to the great ChatGPT, I thought I'd ask them for some help organising everything separately, since I had no idea where to start, especially not adding any new mechanics.
The Inventory
The first main mechanic I wanted to work on was the inventory system. Although it sounds strange not to get the plant patches done first, since that's what you add to the inventory, I wanted to get this done first because it could give me a better idea for how I want the other scripts laid out.
I'm not going to go into a lot of detail regarding every step this script takes to work, since I've added a lot of comments that tell you what things do, but I'll briefly explain what happens now.
As soon as the game is opened, the Awake() method runs some code to make sure this is the only Instance with the name InventoryManager. It also makes sure that the script is kept across various scenes, which is vital since the inventory needs to remain the same at all times. If this instance is already present, then it will destroy itself to avoid the wrong script being referenced. It then updates the UI on screen to show what the player has in their inventory currently, which is most probably nothing, so it'll show "Inventory (0/5):".
The only other methods in this script occur when referenced by other scripts. For example, when the player goes to harvest a plant, it will do everything it needs to regarding the game object; however, it will then also run the AddItem method, which also requires a string of data to be input with it, which will be the item being added. An example of what it would be is InventoryManager.Instance.AddItem("Dionyvine"). This won't be the exact line of code since I'll instead use the name of the specific plant that is planted, but for now, this gives you an idea of how this script will be accessed. First, this will check if there's enough space. If there isn't, it will return false, and the plant won't be removed from the patch, and I'll probably make nothing happen. However, if you do have enough inventory space, it will add to the inventory, using the name that would've been included in the method, classed as item.
The RemoveItem method works very similarly to the AddItem method, with regards to how it starts and runs. However, the main difference is that it instead removes the specific item from the inventory. I think I have an idea for how I can specify what item gets removed and placed down, but it's something I'll have to do a bit of thinking about once I get around to it.
Overall, this script is a lot more optimal compared to my original script in the Prototype, since it doesn't have everything piled into one. However, it has become a bit more complex, but I believe I've learnt a lot so far, and understand it well and can implement the rest of the features hopefully by the end of the week.
This is my very simple inventory display that I have included right now. As you can see, it is very basic and just sits at the top of your screen, but I'm thinking that eventually I'll change this up a bit to look a bit better. However, due to the lack of time that I have, I might end up leaving this, since I think there are other things that take priority over this.
Custom Object Creation
After I finished polishing the inventory script, I moved on and started on the planting and harvesting mechanics, which would require three additional scripts to work properly. The first one I started with to get a small understanding of how everything would be made was the PlantData script. This script was simply made to add a new Object that could be used in Unity to put all of the necessary information onto one object for each plant. This is such an incredible feature that I've learnt about, which could make a lot of things easier in the future. Not only does it make scripts less bogged down with loads of variables, but it also makes things a lot more efficient.
In this very short script, we start out by making the custom object by writing this CreateAssetMenu thing, which we call Plants/Plant Data. This basically makes the class below a whole object, which also requires it to be a ScriptableObject, instead of a MonoBehaviour script. Inside the class, I simply added some variables for the name of the plant, the different stages of growth, as well as the time in between growth stages and the water required to grow. For now, I'm going to keep waterRequired as the only condition needed for growing plants. What I'm thinking is that when I get that condition done, I can start adding more, but I want this one to work well first. I'm thinking that I could make different soils you can buy, which could store more water. Overall, though, this is a really useful piece of code that I've discovered, and it should make all of this a lot more efficient and optimised.
First Gameplay Display
After finalising the planting and growing scripts, I have a complete look at what the game will be like. It isn't super smooth since my movement is a bit broken, and so far, the interaction isn't perfect, but I think it lays down a decent baseplate to work off of. This also marks the end of another week, where I wish I got more done, but considering the code I had to do was quite new and confusing, I'm happy enough with what I got done. Getting at least the planting complete and a basic watering mechanic to make the plant grow, I'm heading in the right direction for production.
Below, I've attached the scripts that I haven't yet gone through, as well as a GIF displaying the first look of the gameplay.
This first script is the one I made for movement. It is a redesign of the code I made in the prototype, adding the correct directional stationary sprite. Once again, I'll give a brief explanation of what happens, and not explain the code in detail due to the fact that I've added a lot of comments. Now, to start, I used FixedUpdate() instead of regular Update() because this runs at a fixed 50 FPS, compared to Update() running at a varied FPS rate, depending on what the player sets it to and what their device can run. So, whenever the player clicks a key, it will immediately get picked up in FixedUpdate() and add a specific amount to the moveDirection Vector3 variable, depending on the key pressed. This Vector3 then gets applied to the character's position. After that, isMoving gets checked, which is useful since this will be used for the stationary sprites later on. The facing direction gets determined next, depending on the values stored within the Vector3. If the player is moving, a timer starts, and every 0.2 seconds, the animation frame changes, and it runs the UpdateMovingSprite() method, which changes the sprite shown based on which frame is selected. If the player isn't moving, it runs the UpdateIdleSprite() method, and resets the timer and frame. The UpdateIdleSprite() method sets the sprite image depending on the facing direction value.
Overall, this is quite a simple script, even though it could look quite long and daunting. I think there's probably a better way of changing the sprites compared to using these massive methods, however, it works for me now, and that's good enough. I did have to use ChatGPT for some of this, because otherwise my methods would've been even longer than what this is. The switch function is something new I've learnt, and if I'm honest, I still don't fully understand it, but I roughly know how it works, and it would be quite easy to replicate another time if I had to do something like this again.
The next couple of scripts focus on the planting and growing mechanics, which are very developed and made in a way that it's hopefully quite simple to add new plants. This script (PlantPatch) gets put on each patch, and it basically is the controller for what the player does and can do in the trigger area. Again, I am going to be explaining what happens in the game scenario, not explaining each line of code in detail.
To start, the Update() method is running constantly and waiting for some conditions to become true, but for anything to work, the first variable is a boolean, called playerNearby, which requires the player to enter a certain area. The OnTriggerEnter() and OnTriggerExit() methods are where this boolean is changed. As soon as a collider enters the trigger area, it checks to make sure it's the player by looking at the tag. If it is the "Player", then it will display the interact key if the plant hasn't been planted, or the water key if there is a plant in the ground. It also sets the playerNearby variable to true.
Now, since the player is nearby, Update() can take place. If there isn't a plant on the patch, and the interact key is pressed, it runs the Plant() method, which is used to put a plant on the patch. However, if there is a plant, the water key needs to be pressed, and if it is, it runs the Water() method in the PlantGrowth script, which is what we'll get to later.
Back to when the interact key is pressed to plant something, it starts by assigning the PlantGrowth script to a variable created. Now, looking back at this, I wonder if I needed to include this line of code since I created this variable, referring to the script. Nevertheless, I make sure it's on this variable, and then run an Initialize function within the other script, using the custom data object of whatever plant I'm planting, as well as the plant patch script. This also now displays the watering key instead of the interact key, since that now will do nothing.
Nothing else really happens in this script, apart from when you leave the designated trigger area, and it hides the UI and sets the playerNearby boolean to false. There is also the OnPlantFullyGrown() method, which gets run when the PlantGrowth script references it, since the plant would've grown. This just hides the UI text, changes the plantGrown variable to true, and logs it in the console.
The plantGrowth script gets run once a plant is put in a patch. The first thing that happens is that the water bar is set up, depending on the plant's requirements. It also makes sure to get the right colour for the bar, which is pretty much always going to be red anyway.
Once the script is referenced by the PlantPatch script, through the Initialize() method, it begins setting up some variables and showing the first stage of the plant. After that, it starts a coroutine method, which is used to time each stage.
This coroutine method is called GrowthRoutine(), and it keeps track of the various stages of growth that the plant is in, as well as the water draining rate. It begins by entering a while loop, which runs only while the currentStage variable is less than the number of growth stages, which is the sprite images. It then starts by showing the current growth stage and resets the timer for the length of time in each growth stage. It then checks another requirement, this time being that the timer is less than the length of time needed to progress. If it is, then it makes sure the water level of the patch is greater than the amount of water required for the plant to grow. If it is, then it begins the timer. This then runs, and as long as the water level is kept above the amount required, it will eventually start the second stage of growth. However, if the water level drops below the minimum requirement, it will reset the timer, and you have to get the water level back over the minimum for the full length of time. At the same time, water is also being drained from the patch, since there is a draining rate, which makes sure the player can't just water a plant to its max and not have to worry again. The colour of the water bar also gets updated at this time, which helps the player understand how much is required for it to grow. Once the current stage of growth is the last, it runs the OnPlantFullyGrown() method in the PlantPatch script, ending the cycle and allowing the player to harvest it (when I implement this feature).
There is the Water() method I haven't explained yet, which runs when the player presses the water key and all the other conditions are met in the PlantPatch script. This, very simply, adds an amount of water every second, which fills up the bar and changes its colour over time.
The UpdateWaterBackgroundColour() method is really cool, since it changes the colour of a specific object, depending on the value of the slider used as a water level. It goes from red to blue in the section where the plant can grow, which I thought was a little better than having it go to green, since it makes more sense to be blue for a water level, since water is blue, not green. For now, I've just removed the handle from the original slider, but kept everything else. I think I could design something else that could look cool; however, for this project, it works as intended and still looks pretty good.
And, after a long time of debugging and making it look good, this is the end result. Obviously, it isn't much compared to what I would've wanted to get complete by the end of this week, but it's good enough. For now, there isn't a harvesting mechanic, however, I believe this should be relatively easy to achieve. The hardest part is going to be altering the code to plant and harvest specific plants. For the most part, it uses the custom plant data object, but selected a specific plant may be difficult for me, but I'll have to wait and see what it's like.
I have come across a few problems that I'm going to need to fix, even now. One of them is the fact that if you walk up against the patch, it will hide the button UI text at the top of the screen, even though you're still in the area. I'm assuming this is from the two colliders on the plant patch doing different things, but hopefully I can fix it, because it will get annoying quick if you keep loosing the text, and I'm not sure if you can even do anything at this time. Moreover, when the plant is fully grown, it doesn't seem to register that it's fully grown, since in my code, it should hide the interaction text when it's finished growing. However, this stays up. I still need to check this out properly, but this should be something quite easy to fix.
Overall though, I'm happy with how this week ended, and I would say it's looking hopeful that we'll have a decent amount of gameplay once we're done.
As well as me getting this far with the actual game, I thought I'd share the other work that Lucas has been up to this past week. Near the beginning, we made some buttons for the plants that the player is going to be planting. I made the Dionyvine one, which I thought was a very neat, small design of the big one he made. I then told Lucas about this, and he went and made a pyramid one for the Giza Lotus plant.
I've also attached an image of the final stage of the Giza Lotus plant. I think it looks quite good, and I like the new design he made for it. However, he did change how the lotus plants look as they grow, in the way that they grow in front of the pyramid, instead of inside it. Although this is definitely easier to draw, I think the original idea was a bit better, and he should've stuck with that. Nonetheless, I think the growing stages are great, and I can't wait to try to implement a second plant into the game.
As well as this, he went and began making the game's music and this sketchy character. I don't have a copy of what the music sounds like, and I don't think it's anywhere near complete yet, however, I really like how this new character is coming along. As you may have seen, the movement sprites of the main character have been improved, and I like how they look now. I think this sketchy character is also going to look amazing once it's done, since he already looks pretty cool, and with a bit more time, we should have a whole game coming together. The most difficult part about implementing this guy into the game is going to be the whole shop function. Hopefully, I can just make an area you need to be in, and then you just click the interact button to start buying things. This also means that I have to make some currency pretty soon, which should be fun.
Lucas has taken heavy inspiration for this character from a Minecraft villager in the way that it stands and looks posture-wise, and the overall clothing design has come from Resident Evil 4. I think this matches the game's art style amazingly so far, and I can't wait to put this into the game.
After having the mid-point assessment, I feel a bit more confident about how my FMP is going. Thus far, I am working at a merit level, and just have a few things to add to hopefully get a distinction. Some things such as the production are things we cannot give a certain grade for as of yet, since I haven't finished, so for now I've been put down for merit. I'm sure that as long as I add everything I've been given as feedback and continue working as I have been, then there shouldn't be much of a problem.
So far, my blog page has plenty of in-depth reasoning, and my researching phase was very good. However, to get top marks, I need to continue what I'm doing as well as go back and do some more research on how time is represented in games, since I didn't do much research on that, so it would be good to. Furthermore, I should also go back and give each image a short description, since otherwise, images may be misleading as to how they help me and what they are representing.
I also need to go back and talk more about the survey results I had, as well as go back and fix my PowerPoints, since the pecha kucha and game idea presentations don't work as intended on my blog, so I need to fix this urgently. Other than that though, I just need to make sure I finish everything in time, and don't miss the deadline.
I've updated my timeline, so we can get a better idea of what I'm doing in these last few weeks of the FMP. Lucas and I both have our own work, so I added some of what he's doing too.
OLD ------> NEW
After getting the code complete for the watering, it was time to begin modelling the watering can, which I imagined I would animate in the project whenever you started watering. As you can see, the middle image is inside 3DS Max, where I modelled the watering can. This was quite simple, since I just made a cylinder with around 10 sides, I believe. I then rounded off the top edges a bit, brought the bottom one outward, and then began on the top. For that, I just used the top segments that I kept when creating the model. I removed the inner faces, selected the edges and began extruding them downward slightly, then out to the side of the inside of the cylinder, before moving them down to the bottom. I then bridged the edges to give me a solid inside, gave some edges a bit of chamfering, and the base cylinder of the can was complete.
For the handle, I thought I'd go for this very large design. I started by creating another cylinder primitive that I placed at the top of the base. After setting the dimensions to what I wanted, I made it an editable poly and started extruding the top face. Every time I extruded the face, I rotated it a little, and after doing this for a little while, adjusting the shape to what I thought looked best, I had a decent-looking handle. I think it looks a little goofy, but I could also see this as a real product, so I'm happy enough.
The next part I am going to model is the spout. I started by once again making a cylinder, sizing it how I wanted, and placed it on the can. I didn't do too much to this, except I did make the spout get a bit thinner at the end compared to the front, and I did the same thing that I did for the centre of the base - I removed the centre faces, selected the edges and extruded it downward. After doing so, I chamfered the edge a bit, and was left with a great-looking watering can.
I then brought it into Substance Painter and gave it some textures. One of them I made this nice, light-blue colour, which is the basic model. The golden watering can is made of the same material, however, I altered the colour a bit, as well as changed some other settings, such as the metallicness, to make it look a little more golden. This is something that I'll make as an upgradable in-game purchase later on down the line, which will pour water out faster. I took some inspiration from the new game Schedule I, since in that game, you have some basic cutters that you start with (and you can buy them). However, you can later upgrade them and get some automatic cutters, which make the whole cutting process in that game a bit faster. This is my adaptation of that, and I think it will work well, if and when I get it to work.
At the end of all of that, here is the product. As you can see, I start by clicking the interact key, which in this case is E. At the top of the screen, a prompt pops up for you to choose the plant you want. I can plant both of them, and when I do, it puts them in the ground. At the moment, there are a few problems: the buttons' text doesn't say what it's meant to, there's a background that shouldn't be there, and the Giza Lotus plant doesn't sit in the ground properly. I will fix these things later, but at least I know that the overall mechanic works.
I think the watering can looks really neat, and the water particle effect looks great too. I think if I knew a bit more about particles, I could've made something better, but this is good enough. I know it also looks a bit odd how the watering can just appears and disappears, but I don't really want to spend the time animating them right now, and it would be difficult to get the particles and everything working properly, so I'm just going to leave it like this - it works, and that's the main thing.
Here is the updated system, in which I also implemented adding items to the inventory. Not only did I make sure everything worked as intended, but I also made sure that the inventory system worked as intended. Before I go through how I made the inventory work, I'm going to go through all of the issues I fixed. For starters, I changed the text of each button, so the players can actually know what they are planting. I was thinking about not including the text, but I eventually decided to include it, since it seemed right to. I also removed the long panel image that was just there for no real reason, which makes the whole UI look a little cleaner.
I also fixed the way the Giza Lotus is put in the ground. This wasn't too difficult, since I just added a new variable, which was offset. This offset would then be applied to the plant object, which includes the sprite renderer. The only thing that was annoying with this is that I had to make it smaller, so they look a bit underwhelming now, but it'll have to do. This was a bit annoying to get right, since it was just a bit of trial and error until it lined up properly, but it looks good. An issue that I found with this is that when I planted the Giza Lotus, the offset never got reset, so the offset would forever be at whatever I set that one to. To fix this small issue, I just added a line of code to take away whatever offset was added, which solved the problem easily.
After fixing the problems, I then implemented the harvesting mechanic, where you could click the interact key once a plant was done growing, and it would be "harvested". By this, it just removes the sprite image, resets everything in the script, and adds a plant to your inventory. One thing I may change in the future is the name, since Giza Lotus is all one word, since it gets the name from the custom PlantData object that I made for it, but I didn't include a space in this. This is an easy fix, but I might not bother with this because I don't like the look of the current inventory anyway, so I don't see the point of changing something small like this if I would ideally want to change it, if we continued production.
Because I went and harvested plants up to my max space, you can see that I have also included the full inventory. If you try to pick up more than you can store, it just doesn't let you. Down the line, I may also include something that gives you a hint as to why you cannot harvest the plant. I think a really simple way to do this is to just hide the interact button, because you cannot do anything, and then show it when you have the space. I can't wait to get the potting mechanic done next, which is going to be a long and tedious process, and then after that, I can make it so you need seeds to begin growing a plant.
I know you can't hear anything in GIFs, but I have started to implement some sound effects into the game, which enhances the gameplay a lot. At the end of this, when you go and watch a mini-playthrough that I record, it'll be really clear how important sound is, since before then, it'll just be the silent GIFs that you get to watch.
The next thing I wanted to implement into the game was a freezing mechanic that would take place whenever the player is in a menu. The main reasoning for this is the fact that the player can move their character even when they're in the main menu. This isn't a big problem right now, but it could cause some issues down the line, so I thought that it's probably best to solve this issue now, rather than later. It took a little while of searching around the web, mostly because ChatGPT wasn't helping that much with this, since it wanted me to make a long piece of code that seemed a bit unnecessary. After watching a few videos, I ended up going with this:
I have a simple script that constantly runs the Update() method, which checks if either the main menu is open, or the in-game menu. I chose a specific game object from both of these which stays open, whether you're in settings or not. Of course, I may need to add other menus to this when I add them, but for now, it works perfectly.
Update() will set the movement script to inactive whenever these menus are open, not allowing the player to move their character. It also sets the game's time scale to 0, which doesn't let anything run that uses regular, scaled delta time. If they aren't open, it just does the opposite: enables the movement script and sets the time scale to 1 (default speed).
This has also made me realise that I could implement a new feature into the game, which could be making time go faster, which would help players since they won't have to wait around for as long, waiting for plants to grow. All I'd have to do is set the time scale to something greater than one, and I have my mechanic.
Overall, this is a very simple script, but it fixes my issue well.
Adding this script did mess up some other code, though, one being the fade image for the transition when you click the Play button on the main menu screen. All I had to do to make it work was change the Time.deltaTime to Time.unscaledDeltaTime. This quickly fixed the issue, since changing the Time.timeScale to 0 only affects regular deltaTime, and unscaledDeltaTime is unaffected.
I then had a very similar issue in one of the rebinding of keybinds scripts. Originally, I was using invoke to make the script wait for one second. However, this is affected by regular scaled time, so I had to change the code a bit to instead call to a Coroutine method. Inside this method, I just made it wait for one real-time second, and then update the label. I use real time here, because the normal WaitForSeconds() is also affected by regular scaled time, but WaitForSecondsRealtime() isn't.
At the end of all that, here is the end result of making the game freeze when in menus. Obviously, this isn't perfect, since the watering can and patch can still be affected by the player. This is due to the keybinds still being active, which I needed for the rebinding script to still work. There might be a way around it that I'm just not seeing, but for now I can't see how this would be a big issue anyway.
Additionally, you can see that the fade transition still works as intended, as does the rebinding controls in the settings menu. Of course I should try to fix the other issues if I get the time, however, for now it does what I originally wanted it to do.
After a long week of making the game feel a little more polished, Lucas and I were starting to model the flowers that you harvest. The reasoning behind this was the fact that, especially for the Dionyvine, it would be difficult to make a 2D image that hangs over the edge of a 3D pot. Due to this, we thought that we could instead make a full 3D model for the flowers, which I think is a great idea. I know in a way we have kind of moved away from the 2D aspect, and it might look a bit strange with the world mostly consisting of 3D models, with a few 2D alongside, but I think it's nice.
At the end, I copied each flower and put a few of them around the pot, and the Giza Lotus potted flower model was complete. All that was left to do was texture it.
Anyway, this is the creation route that I took to make this awesome-looking model. I unfortunately forgot to take some more images of the process, but you can see the side profile here, and I think it resembles the 2D one that Lucas drew greatly.
To make this, the first thing I did was import my pot model that I made for the Prototype, since I would be using the same one, because I didn't see the point of wasting some time to make something that I already made, similar to the patch. Once I did that, I added a cylinder primitive and sized it how I wanted, before converting it to an editable poly, which I then have more freedom over the shape that it is. I didn't do much with the stem, except make it curve a little. I then added a small sphere at the top, which I originally thought I'd remove, but I ended up keeping.
For the petals, I actually started by creating a box primitive, adding a good amount of segments to the model so that I could change the shape to what I wanted. Once I got a base I was happy with, I started changing the shape so that it looked more like a petal, rather than a really thin rectangle. Initally, I was looking at some images online with some thin petals, but then I realised that the lotus flower Lucas drew had some thick petals, which was a bit annoying at the time, however, it made my life a lot easier later since I wasn't having to place that many different petals. Now, I did miss out a step that I did after making the thin petals, since I curved the petal so it wasn't completely flat. However, I had to alter this a bit because, of course, changing the shape didn't make the curve look quite right. However, after all that, I finally had a petal I was happy with. I then put it on the top of the flower, adjusted the positioning and rotation until I was happy, and boom, a lotus with one petal. Sounds underwhelming, but that was the hardest part done. All I had to do now was make a copy of the petal, rotate and move it into a different spot, and then I had another. To have made this process faster, I could've copied both of them, but I wanted each petal to be completely different, at least slightly, so I did each one individually. After I did the first four outside petals, I sized one down slightly, and put it slightly further in, and between two outside petals. I did the same thing, copying the petals around until I had a shape I was happy with. After that, I did four more petals - a bit smaller and further in again - and then it was complete. Normally, lotuses have an interesting-looking middle part, with lots of small things that stick up. However, this is going to be such a small detail anyway, you can't see what the inside should look like from the drawn plant, and it's a low-poly game that shouldn't have lots of detail, so I thought I'd just leave it.
After bringing it into Substance Painter and using some of the default materials they had to offer, I have the end result of the plant. I think it looks really cool, especially from the side angle. Although the inside could have looked a bit more detailed, you're hardly going to see the plant once it's done anyway, so I don't think it's that big of an issue. I think the colours I chose and edited for it look great too; it matches the image Lucas drew so well.
I did this all at home, where I got it recorded, since I streamed the making of this (go follow me on twitch.tv/ametrinxy). Because of this, there is a time-lapse of the making just below, where you can see the full creation of it over time. I just thought this was a cool way to show off some of what I do, and also proves that I did it myself.
Lucas also began modelling the Dionyvine, and he should have it complete by next week, which leads me to say that I think this past week has been another step in the right direction. I would've liked to have gotten even more done, because looking back, it doesn't seem like a lot, but it's difficult to figure out new things, debug the new things, all at college, with a lot of aspects prolonging the speed at which I can work. Hopefully, I can get the potting mechanic complete next week, which would put me in a good situation for the final week of production.
Dionyvine Model
To begin the week, I began setting up the plant pot stand for what I would need it for, and Lucas finished modelling and texturing the Dionyvine plant model. I also sent him the pot model file so he could work around that. For his plant, he clearly made some cylinders, made them an editable poly, and then edited the shape so they drooped over the edges to make the vine. He then added a few spheres to the vines for the grapes, and then the model is complete. I think he could have done a little bit more with this. I know that it's only going to be small, so it doesn't need much detail, but not much of the pot has been used up, and he could've made them go over each other a bit and just not make it quite as plain, but overall it's alright. He then textured it in Substance Painter, and you can tell quite easily what it's meant to be. He then sent me the file, and I brought it into the Unity project and added it to the plant pots I had set up on the stands.
The Stand
Here is an image of the stand that I had set up ready. Again, I used the same model as the Prototype, because there isn't much point in creating something different when I wouldn't be able to make something much better than this anyway. I know originally I wanted to remake these things, and for this one, I was going to add some nails or something holding the wooden planks together, but I just don't have the time, and this already works as I need it to.
I then added all of the pots on top again, and I also added the modelled plants inside. Now you can start to see how you aren't going to be able to tell what's what, because of how small they are compared to everything. After that, I added some buttons which are placed just in front of the pots. These are going to show up instead of a hint for what button to press, since the game will need you to select what pot you want to put a plant in. Once I get this working as intended, clicking one of these buttons will then display a similar menu to when you go to plant a seed, but it will instead be of the plants.
Lastly, I asked Lucas to model this little piece of paper while I was doing some code, which would sit on the stand and show the price of whatever plant is in the pot. This shows the player how much money they'll get from selling the plants, which could be useful to see. However, this is something else that'll be quite small, and I'm thinking of changing the paper to be landscape instead of portrait, since I can fit larger text on that. I'm quite happy with the look of the stand, and although it's only a basic model, I like what Lucas did for the paper. All I had to do in Unity was add some more text, group everything together, and then copy and paste them around the stand.
This is the UI that will pop up whenever you click on a button. Lucas designed these buttons, and they look... eh. I don't understand why he didn't keep the same sort of style as the seed buttons, since they looked a lot better, and these look quite blurry. I know it would probably have been difficult to draw some small petals for the lotus, but it would've looked so much better if he could've. Nonetheless, you can at least tell what they are, and they resemble the potted plants well, so it works.
After all of that was complete, I had a working potting system. It works just as I wanted it to: you click a button which selects the pot, you choose the plant you want to pot, and if it's in your inventory, it'll place it there, update the cost text, and remove the item from your inventory. The only thing that would've made this mechanic better was if I added it so you only see the plants that you can place at the top of the screen. This is mostly because as the game gets bigger, it will have more plants, and unless you are used to the game, you'll have to look for a little bit to find a plant you have in your inventory, which could just be a bit annoying.
Additionally, I could try to find out how to use the prefabs and just have them show up depending on what is in your inventory, but I don't know how to go about that yet, so I'll stick to this, especially since we only have two plants anyway.
Overall, I'm really pleased with how this has turned out. So far, I can't find any bugs or issues with it, so it should work fine for now.
Making the Computer
Next up, I wanted to make something that may seem a little strange to have, but I didn't know what else to do in our short time period that we have remaining, so I just went with a computer. This model took quite a while to make, even though it was relatively simple, but it was mostly down to the amount of stuff I had to make that took a while.
This model first consisted of me modelling the table, which was just a cube that I cut out the middle of and chamfered some of the edges. After that, I inset, extruded and chamfered four of the sections I made to get the drawers. I then made a separate model for the handle, initially because I couldn't bridge a gap across like I wanted to, but this helped later on, since I wanted a different material for the handle, which was made at least a lot easier with a different material.
Next, I modelled the monitor, which just sat on the table with a blank screen. After modelling it, I realised that it would've been more ideal if I made some sort of border around the outside, since this doesn't look great on the texture, but it's something that isn't too noticeable in-game, so I'm not too worried. I made the stand and screen separate models, which made it a lot easier to model at the time.
Finally, we have the keyboard and mouse. For the keyboard, I just made a really simple rectangle shape, and resized the bottom face so it was brought inward a bit, since most basic keyboards nowadays have this design. I then just made a simple flat cube primitive and copied it around the keyboard, roughly in the spaces that keys were. This clearly isn't an overly detailed game, so I didn't want to go for anything too crazy looking. For the mouse, I just got a cube primitive and made the buttons more defined by extruding a face in between the two buttons that I made. I kept this relatively simple because, again, it was meant to be a low-poly game, and this was another detail that pretty much nobody would look into while playing the game.
The last thing I needed to do before actually making it do things was get the background sorted out. I think this is one of the most important things when making a computer in the game, because it only makes sense to have a background that relates to the game. Yes, you could just have something random, but I think it makes the game more immersive this way. Since we didn't have a lot of time and Lucas was busy himself, I took it upon myself to go and find an image that I thought would make for a great background. After looking for a while, I found this. Not only does it just look great and resemble something like what I'd want the game to look like, but it is also either hand-drawn or made digitally, which fits the aesthetic of the game well. I removed most of the colour in the game to make it a bit less in your face, as well as making it just a bit kinder to the eyes, since none of the game, at least right now, is this bright and vibrant.
[4]
The end result actually went across the end of this next week, as well as into the next. The computer acted as a shop where you can buy seeds, as well as upgrades, during your playthrough. So not only did I have to design the computer's model and UI, I also had to make the currency system for the game, and a way for you to buy things from the shop. In the end, this all worked out fine, and I'm really happy with what it looks like.
Overall, I think this design looks pretty decent, however, I'm not liking the look of the shop UI. In a way, it kind of works, but at the same time, doesn't. I think it looks a bit too green and doesn't contrast too well with the computer background, but it works as intended and that's the main thing. I think everything it does it really cool, from the power button animations and sounds, to the way the shop works. It took a little while of confronting ChatGPT about how to make it all work, however, we got it working eventually, which is amazing.
Something that I would like to add if I were to continue this is probably moving windows, especially since I'd probably be adding more things to open anyway. Making the UI look more like a real computer would definitely make it better, and I'd really enjoy designing it and making it work. Adding more stuff to the computer would also be cool, since I could add so many things, some that wouldn't even really be needed, but just cool to have in the game for cosmetic purposes. I also could animate more of the UI, which would make it feel more real and responsive, and from doing the animations I have done, I think I should've for the entire game, since it makes everything seem so much better and professional.
[5]
After making the computer, I thought it was time to begin modelling something that would be part of the environment that you play in. The thing that I thought would be the best was a barn, since it fits in the game's theme well and is a building that I can easily make hollow and walkable. This is incredibly useful since I don't have to make some kind of teleporting thing and a whole different interior, so it makes everything a whole lot easier.
For the design, I wasn't too sure what I wanted it to look like, but I had a rough idea. After looking around for a while, I found this image, which I thought best represented what I wanted, so I took this as my reference image to base my model on.
To begin, I started by getting a rough outside base done. I did this by first putting four pillars as the corners, which allowed me to visualise the size when it was complete. I then calculated the size of the walls that I would have to make, because I was going to be doing them in blocks instead of just one big wall, because I wanted to have a doorway and windows, which I assumed would just be easier to make by doing it this way. Once I had a box complete, I split it in half so I would only have to do one side, and I could then just mirror the other side.
I next started on the door and window outline, which was just another simple cube primitive that I resized. I did two, long straight pieces, and one short diagonal one to connect them. I copied this design around for the windows, and then removed the bits of the wall, and then we have a window. I realise after doing this that I could've just done a quarter of the barn, and mirrored it around; however, I still would've had to do the door, so this was still probably the best way.
I then got a simple floor put in, which was once again just a cube primitive resized to fit everything properly. In a way, I wish I didn't do a floor since it's just going to look weird compared to the main environment floor, but I don't know what else to do, so I'll just go with it. I then got the roof done by getting a long cuboid, copying, moving and rotating it to get a nice slanted roof.
Before mirroring the build, I made sure nothing was overhanging from the centre. For example, the bottom edge of the roof was a little further on, so I just moved the edge so it was aligned at 0. I also had to make some of the wall tiles editable polys to edit their structure, since a rectangular shape would phase through the roof a bit.
After I mirroed the build, I was left with a decent looking barn building. Obviously, at the moment, it doesn't quite look enough like a barn, but when I texture it, I'm sure it will.
I think the roof looks really cool, and will resemble the metal sheets from the reference image quite well. Although it's quite a basic looking structure, I'm still happy with how the windows and door came out, since they look pretty decent.
After opening Substance Painter and texturing, this is what we are left with. I really like the look of this barn, since I think the colorus and materials are a decent representation of what they look like in real life. Not only that, but because it's going into a farming game, the players should easily be able to tell what this is. Initially, I used a more bark wood texture, which didn't look that great. However, I eventually changed to more of a plank texture, and I'm glad I did because it looks a lot better, and makes more sense because structures are very unlikely to be built out of wood compared to planks.
The one thing, at least in this image, that I don't really like about the barn is the pillar and outline texture. It looks a little off to me, I'm not sure if that's because it's too shiny or not just the right colour, but I'm just not a huge fan of it. Overall though, it looks good enough, and if I get enough time, I might be able to go in and add some more interior decoration, since at the moment, it's very basic and looks a little bland, but I'll only do this if I get time, which I probably won't considering the amount of time I have remaining for this project.
After bringing the barn into the game, I realised that I was going to need a sprint mechanic, since otherwise the player would get bored quickly of moving around the map. I know it's not going to be that large of a map, but after bringing the barn into it, I knew the default movement would be too slow. For this, all I did was simply make a new keybind in the controls menu and keybind manager script, and then edit the movement script to implement it. At this point in time, all it did was make the character move faster, as well as make the sprites change faster to match the speed. After recording this, I realised that I needed to change the audio speed too, so I asked ChatGPT for a bit of help because I had no idea what to do for it, and it just suggested changing the pitch of the movement, which basically speeds the sound up, so the sprinting mechanic was complete.
As well as that in the recording, you can see at the end I am able to phase through the building. This is an annoying bug I found when testing out the collider for the barn. It seems that because I used a mesh renderer, whenever I strafe (move diagonally pressing two keys at once e.g. W and D to move diagonally forward to the right), it clips me through the collider where there is two walls that meet, or in this case, when the wall meets the door outline or the pillars. This is a bit of an annoying bug because I assume it will require me to make my own collider for the barn, but in a way, I'd rather not spend some time doing that, so it'll be one of the things on the top of my list to do if I have time near the end.
Rocky Path
After making the barn, I thought it was probably time to actually start making the map. In a way, this is one of the most enjoyable parts of game-making once you get going, because you can shape your world however you like. However, the most annoying part in some ways is getting the models to place around. I know I could just get some free assets from asset stores, but I wanted to challenge myself by modelling the assets on my own. I'm still unsure if I'll do everything myself, but for now, I'm committed to it. I also know that I still need to get the selling mechanic in place, however, we're still unsure as to how I'm going to do this, since I could just make the plants sell after a certain amount of time, we could still try and implement NPCs (probably not), or the schetchy guy that Lucas drew a while ago could be the one that for some reason buys them off of you. I'm still wondering, so I thought the best way was to get this done first.
Nonetheless, I wanted to begin designing the map by adding a rocky path that leads the player from the barn to the patches and stands. I did begin modelling some rocks in 3DS Max, but imagined there'd be a better way, but after looking online, I just assumed I was doing it right, so I continued. I did, however, go and find an asset pack that I could sort of use as a reference for what I was doing. I thought this picture was a good one to base my rocks off of, and I liked how they made them with different colour types (see the link in my Bibliography).
[6]
After studying the rocks from this asset pack, I realised that I probably had a few too many polys for my low-poly rocks, so I got rid of my first design and made these three instead. They aren't perfect, and I think I could've done a better job, especially with a bit more time, but I'm happy enough with how they turned out.
For future modelling in this style, I at least know that it seems the fewer polys there are, the better, since too many don't quite look right.
After exporting the models separately and dragging them into Unity, I'm left with this lovely rocky path. I will probably go back and alter it a little more to not make it look quite as perfect as it is, but overall, it looks pretty good. For the material, I didn't bother texturing them because that would only waste time that didn't need to be spent on them. They look perfectly fine like this, especially considering I would've needed separate materials for each rock, which would get big quickly.
Overall, they don't look too bad, and I think I can use them a bit more around the map just as decoration, or maybe make some bigger ones for that. One of the bad things I think I did with this, though, was the fact that I copied and pasted all of these inside of Unity, so I have a couple of hundred of these models at the moment, which I'm sure isn't great for performance. I'm not entirely sure what else I'd do, so for now, this'll have to do, but I might look into a more optimised way of doing this, even if I just go through, remove a bunch and make some bigger to fill the gaps.
Low Poly Trees
The next asset I wanted to create would be a tree, or some trees. I found some of these images quite good to base my design on, since they are some decently designed trees. The first image has some nice, basic low-poly trees that are more my style, however, the second image looks a bit softer, and I also like the grass and flower, which are also probably going to be things I'll add at some point.
[7]
[8]
To begin, I started by making a cylinder that I gave the dimensions that I thought were best. After that, I set up the segments, which I made quite low because it's a low-poly build. I then made it an editable poly, and began by enlargening the bottom vertices, and gradually making it thinner. I thought this gave the tree a nice base, and I was then able to adjust each vertex slightly, and then I was left with a decent-looking log.
After that, I designed these two trees. The logs are pretty much the same; however, I altered the shape slightly for the other tree so it didn't look exactly the same. For the branches on the second tree, I just copied and pasted the trunks and made them smaller to get a branch look.
For the leaves, I just made a cylinder with a few sides and moved them around randomly. I changed them all up a bit for both trees, and this is what I'm left with. I'm quite happy with how these came out, and I'm hoping, once they're textured, they'll look good in-game.
After I had the trres done, I started placing them around the game's map. This was quite a long and boring process, since although I didn't have to place every one separately since I could just copy and paste a large selection, I did have to move quite a few since I rotated them a bit, and this made some of them phase into one another. After placing, rotating and moving a lot of trees, this is what I have so far. This isn't the final design yet, since I need them to spread all around the map, however, this is what I'm leaving it at for now.
I have also changed up the rock path a bit by removing some of them randomly and also changing the sizes so it wasn't all the same. I think this looks a lot better, and isn't as obvious that it's a copy-and-paste path.
Next, I needed to model a small shack, which would act as the suspicious person's home. What I did was open 3DS Max again and start by making a cube primitive for the base of the house. I made this an editable poly, which I could then use to change some faces to make the inset door and windows.
Next, I began making the smaller details, starting with the door handle. This was a very basic model, and I just put it where I wanted it, and will attach the models together later. For the windows, I wanted them to be boarded up with wooden planks, which was just a simple cube primitive that I made to have the desired dimensions. I then extended the top of the house and created two more primitives for the roof. After getting it all together, this is what I'm left with.
After bringing it into Substance Painter, I gave it this dark-looking texture. I wanted this to look a bit mysterious, and not really fit in with the game's colour scheme, which I think I've done well. Since this is the home of the sketchy guy, I need it to look a bit out of place, however, I'm still a bit unsure for how I'm going to implement it.
I've also attached the image of the map, with the new building and trees fully covering the ground. I think it doesn't look too bad, and it gives off the weird vibe I wanted, but the map as a whole still looks a bit plain and boring. Hopefully, the gameplay somewhat makes up for it once I eventually get everything working and finalised.
Next up, I needed something to surround the map. For this, I wanted some kind of mountain terrain, so I thought the best way to get this sort of thing was to make a cylinder and alter the shape to what I thought looked good. This is what I have, and although it looks super basic, I think it'll be good enough for what I want.
After texturing, I have this stone mountain, with some grass on the top, which looks pretty decent. I think in-game, this should look pretty good, although you probably won't be able to see much anyway, since these are going to be very large and the camera probably won't show you much of them.
After adding the mountains to the map, I think it makes it look better. Not only do they tie into the game relatively well, but they also make the map feel more complete since there isn't just space around everything. However, I do have a collision issue, since the player can just walk through these when they sprint, which isn't ideal, since this way the player can just get out of the map. I know that this is just an issue with my movement code, though, since the character's position is just being changed, which makes collisions act weird. I can't remember if I kept the rigidbody movement, but that would be my best bet to making it work. Ideally, I need to just redo my whole movement and collisions, but in 3D since it's easier that way.
This is the end of the penultimate week, leaving me just the hand-in week left. Since I don't have much time remaining, I'm going to have to try and implement some sort of story aspect, and also include a selling mechanic, since right now, I can't sell the plants.
And finally, after a long time, we have the completed game. Attached below is a link to the itch.io game page I created, where you can download and play the game. In addition, I attached the gameplay video that I recorded, which shows off everything that the game has to offer.
After making the mountains, I needed to finish up the game, which meant not writing everything up that I was doing. This is because I simply wouldn't have the time to do the work, as well as write everything up, which is clear since I am writing this on deadline day. Nevertheless, I got the majority of the game completed that I wanted, so I'm happy enough.
You may ask what I have added since making the map look nice. One of the main things was getting the selling mechanic complete, which was very simple to implement, since the player will get rewarded with the money from the plant between 1 and 3 minutes. This makes the game playable, since without it, there's no way to get money and buy plants. As well as that, I implemented the sketchy merchant into the game. I did this by first making him stand outside his home, and when you first come across him, you are put into a bit of a cutscene where you are talking to him. This is a part of the voicelines that I have also added, where Lucas voiced Bob, who you play as, and I voiced the sketchy merchant. After 10 seconds, he will walk to a different place, and he has three spots where you can find him. I would've added more, but for his movement, I animated it because it was the only way I knew, and I didn't want to waste too much time diving into a different way. This was very time-consuming because I had to animate him moving from one place to another, and back the other way, by moving him a certain amount, changing the sprites at the right point, and then reversing it. It does look cool, though. I believe the last thing I did was make the debug commands work, which is a neat little feature you can use to give yourself money, seeds, or plants. Nothing too crazy, but I thought it was a good idea, especially if I need to test something.
All in all, this project has gone very well, and I'm quite pleased with the outcome. Obviously, I would've preferred to have more time to fix bugs and implement some more content, but I think it's good enough. I have had a few people playtest the game as well, including my Mum, and they all seem to enjoy it, so that's good!
What Went Well
Overall, this project has gone brilliantly. The end result isn't quite up there with what I would've thought was incredible, since there is a handful of bugs, and not a whole lot of content. However, the game is playable, it has a bit of story, and you can basically play it infinitely. In the game, I think the core mechanics were made really well. For example, the plant patch works as intended, and I can't seem to find any bugs with it. Not only that, but the stands also work well, and I think they look great too. Talking of things looking good, I think the game's art looks pretty good. Everything complements everything else well, and it's a comforting game to play in. I think Lucas did a great job with regards to the 2D art - the characters look great, the walking looks nice and smooth, and the plants look nicely detailed. I'm relatively happy with the 3D models. The potted plant models in particular look great, but so does everything else. It's all very simple, low-poly stuff, which I think I've made quite well. Furthermore, the map's design looks great. Once you play the game for a while, you will get used to where everything is, especially since the map is actually quite small. However, I think it's big enough for this game, and sometimes I still get lost when trying to find the sketchy merchant, which I think is a good thing since it proves our map is big enough, and not too repetitive or basic. Additionally, you will feel immersed in the game when playing, because I have tried to focus on getting the sound design nice and polished. For example, whenever you get a new objective, there's a sound effect that plays. After the first few objectives, the player's brain will notice this, and they will automatically know what the sound means. This is the same as when your money changes from buying things, selling things, or being given money. Also, I think the subtitles, along with the voicelines, are a great touch since it not only makes the game more accessible to other people who can't listen, but I personally like having subtitles on in games if you can't quite understand what someone says, so this is a great feature - and I think the animation is great too! Lastly, the settings are pretty good. I didn't think the resolution settings would actually work, but they do. It's a little buggy because I didn't have time to refine it and make it perfect, but it's good enough for me. Additionally, I still love my volume sliders, and the fact that I made it so they each do different things is great in my opinion. And finally, the control scheme. This is something that I thought would be more difficult to implement, but it works amazingly, and is ridiculously easy to add more control to. This is another big accessibility feature, which I think is super important to have in games. Also, one last thing that went well was the teamwork with Lucas. I think it made the creation a lot easier having two people, since he could make some of the assets, and I could spend time implementing them. This made the game a lot easier to make, and I was able to focus and improve on my own skills, rather than worrying about having to do the things he did.
What Could've Gone Better
Now onto the not-so-good side of the project. To be completely honest, I don't think there's much that didn't go well in the final product, apart from the bugs. One of the most obvious ones is the movement. Because it just changes the character's position, it doesn't account for whether there's a collider in the way or not. Therefore, the collisions are a bit broken. Moreover, when I tried to fix it, the character started glitching out, so the visuals were a bit broken. Unfortunately, this is what I had to deal with when making the game, and I just settled for it. In future, it would definitely be easier to make you play first-person, since then I wouldn't have to worry about the character's model not acting right with collisions. This is because they would be separated, and collisions would probably work properly, so everything would be improved. I still don't completely understand why it doesn't work that well, since I assume the movement code is very similar between what I did and if it was proper 3D, but I guess that's something I'll discover down the line. If I were to do a game like this, I'd have to spend some time trying to find the issue and the fix for movement like this, because it does take away from the immersion that the player gets when moving around. As well as that, I would've also liked more models and better textures. I think the barn's model is pretty good, but I only did a quick unwrap, and it just doesn't look too good. It's not that easy at all to unwrap, since it's a slow and boring process, and I'm not experienced enough to do it quickly. I also think I should've added more assets to the game, not to make the scene seem so bare. Since I didn't have much time, I could've used an asset pack, but I'm trying to reduce the number of things I use that aren't made by me, so a boring map is what I went with. Another bug that I found includes some UI still showing when it shouldn't. There's also the resolution setting, which starts at the worst, even though it says the best is selected, and for some reason, numbers 1, 2 and 3 on your keyboard change the resolution, which is strange since I didn't code that. The last thing that I think could've gone better was the fact that we didn't have a whole lot of gameplay. Yes, you can technically play it infinitely, but it will get boring after a while. Due to the lack of plants and upgrades, once you get the golden watering can, there isn't really anything else to do. This is also quite a prolonged process, since, let's say, you are grinding the game, buying lots of Giza Lotus seeds, you buy 6 to grow (costs $30). You then sell these for $90, making a $60 profit. I'm not even sure if this is the most efficient way of getting money, but if it is, then this whole sequence will take four tries to can the can upgrade. Let's say it takes 5 minutes to get one of these sequences complete, you're going to have to spend around 20 minutes of solid grinding, with not much to show for it come the end. Overall, I think this just proves that we needed way more things to buy to keep the player invested in the game.
What I Would Need to do to Publish
If we were to continue production, upon completing the full game, we'd need to make sure we have everything ready to publish. One of the first things you need for this is some artwork for a thumbnail picture, which is basically the front cover for the game. We do have a simple logo, which I've used as the game's executable file icon, but I think some higher detail stuff is better, and makes it look more professional. Additionally, we'd need to actually upload it to somewhere like Steam, which would need you to include plenty of other details to fill out, that we'd need to be ready for. Something similar to the thumbnail could be in-game screenshots and a video trailer. Building off of this, we'd want to do some public marketing, so having a trailer uploaded online to YouTube is a good start, but joining communities online and spreading the word of the game could help boost its popularity greatly. Of course, we would have a finished game, so I wouldn't expect this to be too difficult, but there's a lot to think about. Additionally, we may need to set up specific communities that players can join, which gives them a space to talk about the game, ideas for updates, and get help regarding the game. Some of the most popular communities include Discord servers, Reddit communities, and, of course, the YouTube channel where you upload videos, and people respond in the comment section. There are many steps you should take when making a game to ensure it gets as popular as possible, and these are certainly some of the best. Now, I have published this game already onto itch.io (as you should've seen above), however, this isn't quite the same as uploading it to somewhere like Steam or Epic Games. itch.io is a website that anyone can upload their games to, but I think for a small project like this, it's ideal. It's perfect for trying to see if your game would do well, and a lot easier to manage compared to other ways. Now, the last thing I would need to make sure I change before properly publishing a complete game is creating all of the assets myself. This is because there could be some copyright issues, even though I have got things for free or paid for them. I think it's important to have your own assets, because it means that players won't have already seen or heard something, which has already happened with the game, since some sound effects I used have been from other games that people have played. This isn't necessarily a bad thing, but I prefer to have everything my own.
What I'd Change if I Did This Again
If I were to do a project like this again, which I will be, I would definitely try to do even more planning for the game in the research phase, plan out what we need to do, and give myself specific deadlines for everything. This is because by the end of this project, I really started to struggle with the time remaining. It doesn't help when making a game where I don't know what code I need to make for things, though, so that's one thing that should be better next time, since I have learnt a lot from this. For example, I should probably try and get a better idea of what the game is going to look like, since I was pretty much just going with the flow when making the map. I think Lucas was doing well by making some concept art plant designs, however, he should've done them a bit rougher and faster so he would have more time to do even more. Additionally, we should have gotten a good idea of what the gameplay was actually going to look like, since when I needed new stuff, I had to ask him for it, instead of him knowing what I'd need and just getting it all made, which would've saved a lot of time. Also, I don't think the UI was that bad, but it looked very basic. This is something in the future that I would really want to change, and really, I should try and get an idea for everything I need to change and lay it out clearly, so I can easily make the assets I need. This is because I know I spent a lot of time trying to figure out what I needed to edit in the UI to make it look like what I wanted, but if I had everything laid out for each part of the UI, I could very easily change it. Also, if I had more time or made this into a proper game, I would've added more gameplay aspects. I have already talked about the fact that I would need more content in the demo I made to keep the player invested in the game, but adding more things to do would make the game so much better. I think Schedule I and Stardew Valley are great examples for this, primarily down to the fact that you can explore a vast, open world, talk to NPCs, and interact with the world in many other ways. I know I'd need to increase the time to grow and decrease the water drying timer to give players time to go and explore, but this is a great way to keep players interested, since they have plenty of things to satisfy their attention span.
Conclusion
In conclusion, I am satisfied with how this game has turned out. I believe that it could've been even better if we had devised a better plan in the research phase, but that's something that I'll learn from and improve in projects to come. Also, I think I'm going to work individually from now on. Lucas and I worked very well as a team, and I think it wouldn't have gone as well as this if we hadn't. However, I know that for future projects I'll most probably want to make it completely 3D, and UI will be most of the 2D assets, which isn't much. I know this will put a lot more pressure on me, but I don't have to worry about sending things to someone else, and I can make a game exactly how I want. At the same time, coming up with ideas is going to be more difficult, since having someone else was useful, since we both had ideas and could combine them. Overall, though, this has helped me get more knowledgeable with Unity and Visual Studio. I have also learnt a few other new things, which is all going to make other games a lot easier to make since I won't have to learn everything from scratch. Having attached multiple images of code and the GIFs of things working is also very helpful to look back on, and will make it easy if I need to look back at this previous work for help. Lastly, upon looking back at our game pitch presentation, I saw our goals for this project. I would say that we have basically completed what we wanted as the minimum, which was: main menu and settings, background music and sound effects, main character, npc variation (maybe not), small NPC interaction, one plant patch and a shop, plant patch has a few upgrades, hopefully 8-12 plants (ah). So, overall, we met most of our minimum goals, however, we didn't really get any NPC variation since we only had the sketchy merchant, and we only had 2 plants. I would've said, though, that we did get a few of the stretch goals. One of them that we kind of got was the more in-depth settings, which I think we got with the controls and resolution kind of working. More sound effects and background music can kind of count since we added voice lines and had menu and game background music. We had a bit of story implementation, and I sort of detailed the map, but not much.
[1] Bailey W (2023). Pumpkin Panic main menu music OST. [online] YouTube. Available at: https://www.youtube.com/watch?v=uICqR_85XwU [Accessed 23 Apr. 2025].
[2] Dayton, S. (2022). 11 ‘Stardew Valley’ Tips for Beginning Players. [online] HubPages. Available at: https://discover.hubpages.com/games-hobbies/Stardew-Valley-11-Tips-for-Beginning-Players [Accessed 23 Apr. 2025].
[3] Lerman, J. (2021). Muck Beginner Guide to Surviving - Slyther Games. [online] Slyther Games. Available at: https://www.slythergames.com/2021/06/08/muck-beginner-guide-to-surviving/ [Accessed 1 May 2025].
[4] Freshprompts.com. (2023). 25 Creative Background Drawing Ideas for a Wow-Worthy Artwork. [online] Available at: https://freshprompts.com/article/background-drawing-ideas [Accessed 15 May 2025].
[5] flavio (2017). Barn. [online] OpenGameArt.org. Available at: https://opengameart.org/content/barn [Accessed 20 May 2025].
[6] ArtStation. (2023). ArtStation - Low poly rocks | Multiple variants | Game Assets. [online] Available at: https://www.artstation.com/marketplace/p/xWeAm/low-poly-rocks-multiple-variants [Accessed 21 May 2025].
[7] Sketchfab (2019). Sketchfab. [online] Sketchfab. Available at: https://sketchfab.com/3d-models/low-poly-trees-free-asset-pack-13968bae706b4d6ba5074be9a0a0f974.
[8] ArtStation. (2019). Low Poly Tree Assets (2019), Achraf H. [online] Available at: https://www.artstation.com/artwork/R35BYv [Accessed 22 May 2025].