Make the spheres touch the circles after collecting all the purple cubes. (It's quite an abstract game, isn't it.) The spheres can only move, when they are touching the ground. The game can be played entirely with a mouse or a keyboard or a gamepad or any combination of them. I advise using a mouse to play.
| mouse | keyboard | gamepad | |
|---|---|---|---|
| Start, Reset | GUI button | R or Esc | start or back |
| Choose Sphere | hover over it | 1, 2, 3, 4 | B, X, A, Y |
| Move Sphere | hold LMB | arrow keys | left analog stick |
| Rotate World | GUI buttons | Q, E | left & right bumper |
| Look Around | hold RMB | W, A, S, D | right analog stick |
When I first started developing video games, I was using a terrible game development kit, which drove me towards writing games from scratch in C++. Many years have passed since then and I wanted to give engines another try. What follows are some of the problems I encountered.
This game doesn't use shadow mapping, but for some combinations of shadow types and quality settings, Unity inverted the light direction before handing it to my shaders. It's probably a simple bug, but since I don't have access to the source code, I can't debug it myself, and Unity's developers seem to prioritize implementing new features over bug-fixing.
The time it takes from changing a script to testing the game is bearable. It's a bit annoying that Unity tries to hot-load new code into the running game, when that's pretty much guaranteed to fail. But what's really frustrating is the time it takes to make a WebGL build. Unity compiles the C# scripts to “managed assemblies”, which get converted to C++. The result gets translated to JS and compressed. Add that to the time it takes to convert all assets into different formats, while the editor is unresponsive and the progress bar hardly moves, and the build seems to take forever, even if it's a “development build”, which takes up an order of magnitude more memory.
Call me old-fashioned, but when I'm programming, I like to be in control of what the code does and when it does it. Managing memory manually takes hardly any effort and can save you a bunch of processing power and memory. In C# something as simple as a for-each loop can cause garbage collected allocations. Memory that should be stack allocated, gets heap allocated. Memory that should be freed immediately, stays occupied for as long as it takes the GC to come around. I heard from other developers that Unity's memory usage is especially problematic on mobile devices and quite difficult to optimize.
Unity has hundreds of check boxes, sliders and drop-down menus for all kinds of settings. It tries to be a tool for making any imaginable kind of game, but that ultimately makes it a suboptimal tool for making any specific kind of game. Learning how to use Unity and adapting it to your project takes a considerable amount of time. I spent many hours reading documentation and googling for answers to unexpected behavior, and Convex Concave wasn't even my first Unity project. It might have been my last Unity project though.
