What went right?
1. Met all of the creative limitations
As part of the project, we were given creative limitations in which we must satisfy and create our games around. All of the creative limitations were taken into account and the game was successfully completed with satisfying all limitations. These set limitations were as follows:
- One variable must be in constant, continuous decline when not influenced by the player.
- This variable reaching zero is the end-state for a play session.
- There can be no overlapping verbs between students.
- If verbs are repeated in pitches, they will be banned for everyone.
- The player must interact using only the mouse, OR touch.
- There can be no UI buttons.
- The game must be in 2D.
The constant, continuous declining variable was the battery level in the flashlight. As the battery was dying, the light intensity of the flashlight was dimming and when that variable reached 0, the game was over, the Big Bad Wolf got you in the darkness.
Once all students in the class had decided on a verb, we discussed in class our different verbs, just to make sure they were diverse enough that none would overlap with each other. There were a few close calls between student’s choices, but new verbs were chosen for them. My chosen verb was ‘navigate’ but later was changed to ‘trace’ as it fitted more appropriately to the verb of the game.
Nothing was used to interact with the game, apart from the mouse movement. Not even clicking or scrolling were used, only the movement of the mouse decided, depending on the current state the game was in, what happened in the game.
Forcing myself to only use mouse movement to interact with the game, helped with the limitation of having no UI buttons. Not being able to click, really helped me not be tempted to add clickable buttons to the game, so mo UI could be clicked on, totally dismissing the idea of ever putting UI buttons into the game.
Although it was very tricky working with manipulatable light in a 2D environment, it was successfully implemented after quite a while and after white a lot of playing around trying to find the right values and settings. In the end, the product is a totally 2D game, satisfying the last of the creative limitations set.
These creative limitations were successfully met as I always had them in the back of my mind, and I always strived to better the game from the limitations that were given. At certain points in the development process, I ran into issues where what the game was doing wasn’t satisfying a brief limitation. I had to, a couple of times, rethink how the mechanics would work, so that 1: the mechanics would satisfy the limitations and then 2: make those new/modified mechanics work together nicely. Doing this and checking with the brief at any time a change were to occur, assured that the brief limitations were met in the end. Doing the same process for future project would be a good thing. Not hitting requirements and limitations for real-life-in-the-industry projects would probably get me fired, or at the very least, be trusted less by my employer and/or my colleagues.
2. A working 2D light system!
This was my major risk coming into the project, I had never worked on a lighting system in my games previously. I had been told that it would be a lot more difficult to do 2D lighting than in 3D, as I could not use half the light types available in Unity due to evidence from other developers that they simply do not work. I had finally discovered how to make a flashlight-resembling light-form solution, after many hours of testing. I lied about how many hours it actually took me, becuase I felt bad for reporting 6 hours working on the same task. It turned out I had to use a few tricks to make the flashlight look good enough, I used a flashlight light cookie on the light source and a moving halo at the source location. This was only half the battle, as once I had this all down-pat, I now had to figure out how to lerp-rotate this light source the way the mouse was currently moving. This was more difficult than it sounds, as opposite rotations simply did not work properly. Custom values were used to make the light look similar on the vertical axis and similar on the horizontal axis (I also wanted the vertical and horizontal axes to look different, but this was added near the end of the production of the project). At least now, for the future, I have gained knowledge in the process of working with lights in 2D, and have a solid base for using lights in 2D, at least with flashlights anyway.
I had never previously done anything with the lights in a game, only moving the directional light further from the elements on the scene so that I don’t accidentally click it. So lighting was a new concept for me this project, I have learnt a lot about what you can do with lighting in Unity, with what the different light types can do, light cookies, flares and halos, and the baking of the lighting. With anything new you learn, it takes a good amount of time to get everything sorted and to understand everything and how all the things work together to create something good, so with saying that, I should have estimated more time to the learning of lighting. I do feel more confident and comfortable with working with lighting more in future projects now. In future projects I shall assign more time to lighting my games as the time I did assign this project, was way too small! There is still a lot to learn about lighting in Unity, but I now have the basics down and can only grow from there!
3. Collaboration and feedback to and from the consultants
My consultant, Jake A was amazing. He was so very helpful with all the questions I asked him, and I asked him quite a few. Whenever he asked me for any feedback or comments on his game ideas or the prototype of his prototype game, I helped as much as one person could physically help. He, and his project, were as equal of a priority to me as my game idea and project completion was. The whole process with having a consultant to bounce ideas off of and get feedback from was amazing. The game would definitely not be the same without having a consultant, especially with Jake A being my consultant, as he was always there when I needed him and was ultra responsive and thorough with his feedback.
I think the reason we were both so helpful with each other was from the initial spark of friendship, with our common interest of cars. Throughout the project, we would get to know each other better and know what each other’s schedules were, so knowing when the other was on would allow non-rushed feedback as you would assign a time to help each other with any questions the other may have and with up-front feedback on how the game was looking. Definitely in future projects, I shall aspire to form a relationship with all team members to the level that Jake and I were, so that the collaboration can be thorough and we can be upfront with each other about what we think of their ideas and about our own ideas. Forming relationships is important in life, the more people you know, the further you shall get in life, so knowing, and getting along with many people is a good thing. Once we start working with other disciplines, this relationship forming will reap greater benefits, as we can learn from each other the terminology and general practises of the other disciplines so that we will all be generally better game developers, and less of being assholes.
What went wrong?
1. Non-dynamic mouse cursor follow at different resolutions
There is the problem with the mouse light following the mouse cursor. The light following the mouse is setup to only work on my screen, in only fullscreen. This is a problem because no one else could download my game and play it on their computers how it is supposed to be played. Also, when recording the playtest, OBS would be very finicky and sometimes would not record properly in fullscreen, so half of the playthrough videos were recorded in a windowed resolution, making it difficult for the players in those playthroughs to play the game how it was intended. I knew these problems could have been fixed by normalising the MousePosition, but I only had time to test it after the project was due. It only took another two hours of testing to find a great solution that can be used in so many different situations, both in 2D and 3D, so by exhibition week, this will be fixed.
I believe this happened due to poor planning before-hand. I previously knew of normalisation but when making this game, I didn’t even think of normalising the screen width and height for the MousePosition. I believe there is also an in-built function in Unity called ScreenToWorld Position or WorldToScreenPosition that I could have used in this project, which would have saved me a lot of time. I have learnt my lesson, I need to plan how I think the main mechanic will work, and at least write pseudo code of the way the script would look, so that before I am working hard to get the game done, potentially rushing features, not thinking properly, I can have a plan of attack and write scripts that will do the mechanics so that they are usable in not only one environment, but many. Planning before-hand will also save me time in the long run, as entering the ScreenToWorldPosition line in my script could have saved me about 2 hours of testing to see what values I needed for the light to directly follow my cursor.
2. A black plane that did not show the flashlight when hovered over it
This was a very interesting problem to me, at the beginning, I had no idea how to solve the issue. If I had never solved it, I could have just shown the light if a raycast hits a light-showing-acceptable tile, but half the light still would have shone on the non-tile plane as the raycast would still be on the very edge of the light-accepted tiles. Luckily, I solved the issue, it just required a material which had the Unlit/Color option selected as the shader, to be placed on the background which the light was not supposed to touch. I still have the problem with the halo showing on the black, Unlit/Color material, but it is much dimmer than on the path, so that is at least a positive, as you can still tell what is “on the path” and what is “off the path”. Even after an hour or so of testing in my spare time after completing the project, I could not find a solution to the halo problem, but I shall keep trying if I ever get more time.
Again, this problem occurred from my limited knowledge and experience with lighting in Unity. More specifically though, this problem had to do with my understanding of how shaders and different material types work. Now that I know that a material can accept or not accept light, I could now make a material that doesn’t accept light in a matter of seconds. That would have definitely saved me the just under an hour that it took to figure this out, this project. I believe I will use this a lot more in future projects, and I know there are a heap of other options than just the Unlit/Color option, so I bet a lot of the different options will succeed for different needs, I will just have to experiment, but know for next time I need something changed on a material, where to look.
3. Maintaining a consistently working repo
After a long time setting up the Git environment, it was noticed that a lot of junk was being added to the repo as they were not included in the.gitignore. I then had the problem that some important files were not being uploaded to the repo as some parts of the .gitignore were too vague when modifying it, so changes to the .gitignore were made so that both the files that were being ignore that shouldn’t have, and the files that were being uploaded to the repo that shouldn’t have, were both now doing the correct thing. This whole process took over an hour to sort out, which was time I could have spent doing much more productive things to my game. I now have a better understanding of how the .gitignore works and have saved it elsewhere to be used in other future Unity projects.
The .gitignore I used for this project was an auto-generated one from GitHub’s website, the one for Unity projects. I thought that this .gitignore was good enough for use, as the GitHub peoples had made it themselves, but apparently not. It is also due to the fact that I was using Visual Studio to do the scripting, not MonoDevelop, as I did notice a lot of the files not being ignored were VisualStudio related. The .sln files from Visual Studio were very important to include in the .gitignore, as those files can be several hundred megabytes in size, and would not be good pushing to GitHub, let alone for other team members having to pull down the .sln files every time they are worked on. I have modified the .gitignore to include ignoring Visual Studio files that are not needed to be included in pushes, so I can now use the modified .gitignore in all future projects, as long as Unity doesn’t save any other types of files, and the same for Visual Studio.
This is Daniel Jochem, signing out.