About me:
I focus almost exclusively on 2D game development. I come from a totally 2D background with the likes of Blitz Max - a primarily 2D game-development language which has no āeditorā or wysiwyg tools, and so am used to having to ādo it yourselfā to make engines or particle systems or tilemaps etc. Iāve also seen Torque2D and a few others which attempt to remove some of the programming needs. I am a solo indie developer with little budget. I mostly experiment with out-of-the-box approaches to 2D, but have a strong awareness of the history of 2D game technologies and approaches dating back to the early 90ās. When working in 2D I generally am only working in 2D and not 3D, so anything 3D-like or which is there to āalso support 3Dā tends to be noise that gets in the way.
About Unity:
The current 2D system is pretty good in terms of an optimized shader, asset import, atlases, some 2D physics stuff. But this is of course only the start. In my opinion mecanim is not in any way suitable for 2D game development. That it even needs some explaining goes to show you that it is not intuitive and is not easy to use. I expect many 2D developers are much more toward the beginnerās end of experience level, and things like putting together these funky charts which donāt seem to really represent what things actually LOOK LIKE in the game, makes it too far removed from intuition to be given the time of day. Whatever happened to immediate feedback, simple wysiwyg editing? I understand there are a number of elements to game like setting up the atlases and gameobjects and scripts and materials and sound and all that, but these things all seem so āseparated outā into their own windows and interfaces, rather than much more immediately represented within the view of the game. I know the scene view is meant to cater to this, but honestly the separation between how the scene view looks and how the game view looks is the first mistake, and the separation between the scene view/game view and the runtime experience is another mistake. What I want is to be able to be in āgame timeā, at a given point in a game, wherever that may be in the level, and be able to tweak any part of it right there any then. This could include changing graphics, moving objects around, changing colliders, setting movement paths, painting tilemaps, etcā¦ What I want is much more of an artistās workflow where the game is āpainted liveā. Unity is big and bulky and this forces all kinds of separations that hinder the intuitiveness of immediate feedback and in-game editing.
I am not sure what can be done differently with regards to mecanim. State machines seem to be a hot topic but surely there is a more intuitive way to like fast-forward/rewind ātimeā within the game viewā¦ something more along the lines of smoothmoves or something, where you can just āvisuallyā adjust things instead of all these extra boxes and lines which really make no sense and are hard to relate to. SHOW ME WHAT IT LOOKS LIKE!
In terms of performance, one part of the 2D-engine puzzle is the transfer of texture data to the graphics card, plus the ability to modify texture data efficiently. This is currently not done well at all in Unity, at least not in Unity Free, and even in Pro it is much slower than it should be. There are many different 2D techniques which rely on this. For example, destructible landscape games (scorched earth, worms etc), games that allow you to paint in 2D (draw to texture etc), games that allow you to spool SMALL texture changes to a part of a larger texture etc. At the moment there are three main problems. Storage of a texture as Color32 is okay, although Alpha8 is stored as a float (what?). Where is a simple 1-byte format? Secondly, to get that texture data (modified by the cpu) into the graphics card you have to a) setpixels, even if not for the whole texture, b) upload the ENTIRE texture. This is bad. Anything bigger than maybe a 256 or 512 texture cannot be uploaded every frame with modifications at 60hz. On other platforms, for example in BlitzMax with basic OpenGL code, you can do like glTexSubImage2D() call to upload only a smaller portion of a texture into an existing texture, which is optimal for speed, AND the transfer goes directly from main memory to the texture. In my speed tests, Blitz runs several times faster than Unity at this simple operation. It could process a few 1024 textures per frame, fully updated, at 60hz, while Unity was dragging along at barely 1 512 texture at 60hz. What gives? It seems Unity tries to maintain its own internal memory copy of a texture which it has to transfer/convert the data to, then upload, which is silly. I know itās a kind of cache, but we need to bypass that cache to stream uploads faster. When I say āupload this rect to the textureā, which btw should also support cutting a small part of an image from a bigger image in main memory (e.g. use a byte array with a row skip value and row length), it should then zap just that data into a possible larger texture in video ram with no other processing taking place. It can be so much faster than it is now.
The final part of this mess is rendertextures. OpenGL since like version 1 or so - over 10 years ago - has had support for rendering to a texture. It is currently a Pro-only feature, and understandably if Unity were to provide this in Unity Free it would open up some asset-store assets that substitute for missing Pro featuresā¦ e.g. shadows, screen effects, etc. But even for just 2D, being able to render to a texture opens up a tonne more game opportunities. Destructible environments, painting, textures processed by shaders, post-processing, etc. Even if you limit it to like 1 or 2 render textures per project or something that would be so much better than nothing. I really think Unity Free should have at least some kind of rendertexture support. GrabPixels or whatever is far too slow especially on mobile devices. On my Ouya for example, grabbing the screen can only run at like 20fps, all by itself, and yet rendering to a texture and re-rendering that texture can run at 30-60fps. So it would boost speed in a lot of 2D games, bypassing the extra transfer of graphics data.
I think Unity definitely needs some way to do tile maps betterā¦ itās okay to think of using lots of sprites aligned to a grid etc but there are more efficient ways to optimize for a grid. Also it must support animated tiles. And again, animation in general is just not obvious or intuitive in Unity. Some of the 2D tools have made it a bit easier to put together sets of frames etc with delays and whatever. Also Unity seems to already have hierarchical objects, which means joints, which means ābonesā, so why isnāt it more obvious how you can use this to set up joint animations, with IK and so on? This all needs to be much more visual and much less button-clicky.
Whatās the difference between a sprite and a particle? A sprite with an AI script attached is basically a particle. Iāve always thought these two things are basically the same. Not sure what Iām saying hereā¦ combine them? But how about being able to attach scripts to particles to treat them like they are mass-sprite systems, with 2d physics etc?
It would help to be able to save images more easily from Unityā¦ save in png, jpeg, bmp formats. Also please provide LZMA compression library from scripts. Unity already uses it (e.g in webplayer). I want to be able to compress generic data (e.g. byte arrays, which may later represent procedural graphics).
Unity needs to have some kind of high-speed, adjustable, properly antialiased, fully editable vector graphics. By vector graphics I basically mean, shapes, which can be composed from triangles. I know a triangle is just a basic unit of graphics rendering and Unity already has triangle meshes, and triangles can be used to build more sophisticated shapes e.g. filled beziers, ellipses, rectangles etcā¦ take RageSpline for example, it does much of this, but also it has things missing, not to mention some performance issues. Itās hard to get the antialiasing right when objects scale, it uses a lot of polygons, and all of those polygons get SAVED into the project taking up a lot of room, instead of simply storing the graphics primitives e.g. ādraw a circle at 50,50 with 25 radius in redā opcodes, which would be far smaller, faster to download, and can be turned into meshes at runtime. There are also shaders you can use to draw some geometric objects such as circles, with a single quad. I think this should be highly optimized and integrated into Unity for maximum performance and optimization. This would open up a tonne of additional 2D game opportunities - being able to ādraw polygonsā as the primary artistic medium, etc. Also donāt forget about vertex animation.
A game-length timeline would be great, above and beyond animation clips.
I think you need to build in some kind of easy support for parallaxā¦ many 2D games use this technique maybe as a visual style nowadays but when youāre not doing 3D you want to be able to simply create the illusion of different distances moving at different speeds, tied to a single scroll position.
I would like there to also be some kind of standardized plug-in control systemsā¦ e.g. character controller for Sonic, character controller for megaman, etcā¦ platformer, shootemup ship, etcā¦ these should be easy to just choose/plugin and customize in some visual sort of way, instead of having to make mecanim trees or behavior trees or scripts or whateverā¦ easily interact with the environment without having to worry about collisions and physics and all this stuff. Just plug it in, skin it, done.
Also in terms of scripting, IF it is necessary, for a 2D game and for beginners it would help to have a BASIC-derived scripting language with very simple english-like non-syntaxy language, no brackets or semi-colons or case-sensitivity etc. BlitzMax makes it so much easier to write game code. Take a leaf! Get rid of Boo and use something more like this instead.
The only other thing that comes to mind is lighting. 2D lighting. That means additional shaders for normal mapping at the very least, if not more sophisticated shaders. Shadows with automatic occluder calculations. Turning 2d images into 3d-lightable images (height maps?).
Oh, and easy isometric games.
