Hohoho, a new game released by me, made in Unity. This time I made a short couch co-op game for two players who need to play together on their farm. Try it on your own right now.
Development cycle
I feel that as usually I must admit it took more time than I expected on a game of this size. I started on May 8 with my first, initial commit and considered the project to be finalized by the Independence weekend on 4th July. Two months sounds a lot, but I want to mention that for 2-3 weeks I totally stopped and turned myself off from the project.
Platforms
Due to co-op character of the game, I am releasing the game “exclusively” on itch.io – therefore you can find the game as a downloadable file for MacOS, Windows or just play it in your browser. I recommend playing the standalone version.
Apple Silicon
I want to give a few sentences around new Apple M1 chip. During the project I received a work update computer and was able to experience how new Apple’s ARM based chipset works with Unity. My old laptop (MacBook Pro, 2016, 8GB) is by now a little bit older and I am happy to replace it with a newer model. Even though it’s practically the lowest model Apple offers right now (Mac mini on M1 2020, 8GB). I wouldn’t hesitate to recommend it, especially the price is the lowest Apple has..
It’s a solid chip and I am amazed that a brand-new architecture runs in its first year so smoothly. Damn Mac Mini have only a passive heatsink and I haven’t experienced any application not running or having problems. I will share build times below. Even though my project is way too small to give precise scientific data I feel improvement.
Apple M1 Unity builds:
Windows 110.6 MB, 31 seconds
MacOS M1 102.1 MB, 20 seconds
MacOS Intel 105.5 MB, 17 seconds
MacOS M1 + Intel 133.5 MB, 17 seconds
WebGL 31.6 MB, 36 seconds
I can imagine that future Unity releases will be only smoother. And I have to repeat that such a high performance Apple achieved with their first own attempt.
A quick shootout to Blender. As anybody else I had some attempts to finish legendary donut tutorial by Andrew Price. In the past, once I started texturing and rendering my MacBook Pro started immediately choking, heating vent ignited itself to maximum and I could almost smell some smoke :-). M1 silicon isn’t the most powerful processor you can have, it doesn’t give shortest rendering times, but it’s solid cheap step into the Apple PCs. I haven’t experienced any heating issues. Maybe with some bigger projects they would appear, but it was more than enough to finishing the tutorial series I mentioned above.
I did not have any issues with other software I am using – no difference if they run natively or are translated via Rosetta to the new ARM architecture. Pixelmator Pro, Audacity or Visual Studio Code – it’s all good.
What I am happy about
I created 3 different playable characters with variable stats. It was fun to implement, I had to think in a bigger picture and I hope it at least some way expands gameplay.
From the coding perspective, I continue my slow journey on decoupling code more and more, creating various classes rather than monolith endless functions. I feel I better understand constructors and I am more conformable with using them.
Sideproject – Blender. I want to be able to do basic tasks in the software that is famous for not being exactly user friendly.
Small things
Issues with Visual Studio Code
Last time I was so excited that I finally replace Visual Studio with Visual Studio Code. But this time… ??? Mid project I migrated to a new desktop computer and have problems ever since. For God’s sake, I cannot figure out what I am missing as the same settings worked perfectly on my old laptop. IntelliSense just doesn’t work; smart fill is not recommending available methods and validation is gone until the moment I recompile the code in Unity. It really slows me down as I still make tons of mistakes, typos and just silly things. VS Code I need to fix or I will go nuts.
Scaling UI
I am trying hard in this field. For sure I am getting better but I need to start thinking through my UI in bigger picture right from the beginning. I usually start prototyping quick placeholders rather early of the project. But at different stages of the development I lose consistency and ultimately break UI. On super big 4k screens, or basically anything else than FullHD resolution. I’ll admit, at the end I was just missing mental power to polish and fix small bugs and let them go out. Experience tells me: start small, minimalistic UI and limit resolutions as much as possible.
Read about my previous attempt and share your feedback with me. Better or worse?
What I tried differently since my previous project:
Game design document
At the beginning of the project, I was dedicated to write a brief GDD to outline my upcoming work. I found rather soon that it doesn’t really work with my limited creative process. As there is little to none proper creative process. 🙂
I still agree it’s better to come to the canvas with a plan and well thought intend. I did additional research on best practices and I for sure want to adopt them. I need to scale down, this is still my hobby and I want to make it fun, not writing extensive documentation. I have enough of that at work.
Experimenting – new input system
As I promised the last time I tried to build the game with a new Unity feature. I gave myself a choice to experiment with the newest UI or the new Input system. I chose the latter one.
Let me tell – the new input system is very, very robust. It offers you what is called “action map” what is basically a scheme for different situation (e.g., action map for gameplay, action map for menu or action map for player 1 and for the second one). Using maps is much cleaner than traditional Input section in Player settings. You can still use in the old fashion, inefficient reading the input in Fixed/Update method. Now you ideally set up an Input Action which is triggered specifically by the input rather than constantly testing via the Update method.
What I didn’t like is you cannot easily run the old and the new system simultaneously next to each other. I still found some actions easier to do in the previous system. I found out way too late it’s possible to overwrite this rule Unity lets both systems coexist.
Net, net – I see benefits of the new approach beneficial for bigger projects, a simulator, or a very complicated game where many input buttons are required, but for the type of games I am creating at this point it’s just an overkill. Probably I’ll roll back for my next project and will not adopt the new input system until it’s needed.
What is coming next?
Once again, I want to give myself a goal for my next mini project. I want to continue itinerate on some sort of document, plan better work, scope and even more with the gameplay as I am not feeling satisfied with the current result.
And from a technical point of view – I want to end up with a clean UI. Maybe even trying to use the new system, although I am already expecting, same as for Input one, this is going to be an overkill for my scale.
Goals for the upcoming project:
- Fix my IDE
- Improve gameplay
- Clean UI
As I want like to practice my Blender skills I wouldn’t be against some simple modeling (+ my PC finally handles the program 🙂 ). Let’s see, will depend on the genre.