I urgently require admin access to your repository in order for judging to take place. Please convert me to Admin asap.
I'm not sure if there is a notes box for you to add a link like that to when you do your submission but the repository should be private anyway so a link isn't that useful.
I wouldn't worry though as you have already shared your repository with me and I can see the changes you have made. I might need to give you an additional username to share access with while we judge. I'll let you know if I need you to do this.
Anyone who hasn't shared their repository with me should do so now (Beeski)!
This is the style I generally use in my code:
- Serialised Member Fields (values specified in the inspector which shouldn't be edited runtime) Start with a capital letter and camel case
- Private Member Fields (values for tracking runtime state) Start with lowercase m and then camel case
- Locals (values that are local to the current scope) Start lowercase and then camel case
- Functions, enums, constants, etc Start with capital and then camel case
Basically anything that shouldn't change starts with a capital and things that can be changed start with an m to indicate that they are members or lowercase to indicate that the values are local to the current scope.
When I write code into an existing project, I usually try to copy the style that surrounds it so that it doesn't look out of place, therefore making the code neater and more readable.
It isn't just your canvas loading in if you have UI set up in your load scene, it will also be loading all the resources that are referenced in that scene as well including textures.
The key here is control, as a programmer I like to have control over what the player sees as much as possible, that initial load into the first scene is a period of time where I only have limited control over what the player sees: a static image. So I like to minimise the time that the static image is shown and instead load in a super small start up scene, I then show an animated load screen whilst everything else loads in. This is a better experience for the user because they can see something is happening and that the app hasn't crashed.
Does that make sense?
I always split my scenes up because I always assume they will need to be at some point in the future and it is often easier to do this up front than it is to retrofit in later.
When you have multiple people working on a project it is a good idea to split up the data into multiple scenes to avoid conflicts. This way different people can make edits to different scenes without having to resolve conflicts. Even though the scenes can be set to save in text format, conflicts can still be a nuisance and are not always easily resolved. This is also true for a single person developing where they decide to work with branches and end up editing the same scene in different branches.
Additionally, the size of the launch scene dictates how long you sit on the splash screen for. Therefore keeping this initial scene as small as possible is good practice to help your game load in as quickly as possible, this is especially true when running on mobile. As soon as you are past the splash screen your own code is executing and you can control exactly what the player sees as you load in the rest of the games resourses.
Singletons are used often in the game industry, in some projects I've worked on they have been used too often and can end up creating confusion. One or two can be helpful but the more you add the more difficult to follow the code can become. Additionally, you can often achieve the same effect with different approaches.
For example, if you want to force a class to have only one instance, then you can store a static instance on Awake and if you find the instance has already been set then print an error and destroy the extra copy. This method of ensuring a class doesn't exist more than once does not require public access to the instance. If you want a set of helper functions that you can reuse anywhere, this can be a class of public static functions which are accessible from everywhere but the class itself has no state and no instance is required.
When the Gang of Four wrote the original design patterns book they stressed that Singleton should be used sparingly. When it isn't used sparingly it usually indicates that code has been poorly thought out before being written, as there is almost always a more elegant solution.
Also remember that Unity is based on the Object Component pattern, if you do not know what this is then look it up, you should avoid OOP methods when using Object / Component. Write small components that can be reused on multiple objects, rather than inheritance. I'm not suggesting that you can't use inheritance only that there may be better / smarter ways of reusing your code.
If you have any questions then lets discuss them!
If you want the file to do almost the same thing, then why not just edit the file? Unless there is a compelling reason to keep the original file as it is, which is unlikely, then edit it to work the way you want.
The point we are trying to get across is: in order to demonstrate that you understood the original code base, you should edit it. If you delete a file and then add a new file that does the same thing (even if in a different way) I'll have to assume you could not get your head around the original file and therefore rewrote/replaced it.
It is important in a game development studio to be able to effectively read, understand and edit the code of your peers, spending time rewriting a class simply because it wasn't written the way you would have done it, is rarely acceptable. The time you spent doing this, could usually have been better spent elsewhere.
At the risk of slightly contradicting my friends here, I would add that I always try to mimic the style of the code I am working with, as it makes the project more readable for everyone involved. This is why when working at a studio you tend to have a coding standard to follow, it helps everyone to read everyone else's code more easily and therefore we can all be more productive.
Also, if I'm reading you right you are suggesting putting the opening curly bracket on the same line as the function / control statement. If you do this, you are wrong and most likely evil :-)
Good luck, I am looking forward to seeing what you come up with!
I'd just like to add that we are trying assess how well you are able to read, understand and integrate with an existing code base, because this is what you will be required to do when starting a new job programming games. Dropping individual files is fine, if you don't need them, but don't submit a project where every single one of the original files is redundant.
Additionally, if you drop an existing file and then end up writing something else that does almost exactly the same thing, then I have you assume that you didn't understand the original file.
Good luck, I can't wait to see what you come up with!