In cooperation with MyMachine, me and four other students visited a class of a primary school with children between 6 and 7 years old. Dressed in a ghost hunter team, we asked them to draw different kinds of monsters, traps and ideas. With those drawings we created a game for them.
In the game you play a ghost hunter that is trapped in a dream and has to defeat the monsters to escape the bad dream.
This project is made in cooperation with MyMachine.
MyMachine is an organization that takes initiative to stimulate creativity within all levels of education by combining them.
The idea is that children of primary school (aged between 6 and 12) make drawings of ideas and 'machines'
With these ideas, students of a university design a concept and define technical properties
Finally, students of a middle school (ages between 12 and 18) make the design a reality
With this project, the second and the final step are combined meaning that the children drew ideas and we designed and developed a game with these ideas
Like in Enter the Gungeon, the game visually looks 2D but in reality, is 3D.
The sprite renderer in Unity lacks the ability to perform well when used a lot since there is no batching
In addition, the sprite renderer does not support light baking or anything alike
I decided to write a tool for it. With two tools you can create sprite atlases which is uv data stored inside a scriptable object
A script then takes in this atlas and generates a quad with the right uv offsets
This results in easy to use sprite and support both batching and light baking
On average, without any post processing effects and dynamic lighting, a frame could be rendered with only 6-10 batches (One for each atlas used in the frame)
A big problem during the project was that Unity still did not support nested prefabs.
This was a big problem since we needed to save the rooms so they could easily be reused
I wrote a tool that saved all gameobjects inside a room in a scriptable object.
With this scriptable object, you could easily rebuild the room and make changes if necessary
The big advantage of this was that changes in prefabs that would be made to an object inside the room, would reflect on the room data aswell so the room does not have to be recreated again
A big reason of time loss was the constant stopping and starting of the game to debug and make changes.
Because of this, I thought an in-game developer console with access to any method registered would greatly speed up the debug process.
I created a console that could be brought up at any time of the game.
By using reflection, I created a custom attribute [ConsoleCommand()] that can be placed on top of any method and takes in a command name.
This consolecommand attribute will register the method in the console so it can be called in-game.
I've learnt alot about reflection about this and I'm sure this console could come in handy in any kind of project.