It has been a very busy time for me. I am a graduate student so spare time isn't always available. However, I can't really call it a good excuse for not posting on the blog for such a long time.
I've been playing around with Unity 4.6 and have to say Unity is an outstanding engine in terms of ease of development. Especially with the UI framework coming with 4.6. However, on the surface and playing with the tutorials, it really makes me feel like its a tool designed for non-programmers. It does provide you with everything and a high-level abstraction for most concepts but it is really not designed for someone who has worked with low-level frameworks.
LibGDX vs Unity. Naturally, after years of experience with LibGDX using Java, Scala, Groovy, and Xtend I have started to getting tired of having to write the same sort of code over and over to do relatively simple things. Yes, I can reuse most of the code, but after years you have to maintain it and update it to work with newer versions of both languages and libraries. In the end, it is usually best to rewrite it than spend the same amount of time fixing up your already existing code. However, this wastes my time as I spend it working on "engine code" instead of actually making a game. I have a model in the back of my head that every game needs to be written like its a fully networked game (even if it is singleplayer). This is because it forces you to think about your design and really makes it clear what the "game" needs to communicate with the "rendering" and "input" systems.
As a singleplayer game, the "game", "rendering" and "input" systems are all wrapped up into a single unit because it is easy to do it that way. This is why when I see countless games first released as singleplayer I pretty much know they will almost never have high quality multiplayer and won't scale beyond a small group of people. I laugh at all the kickstarters, indiegogo, etc that list multiplayer as a stretch goal, because it tells me that they don't know what they are doing. They don't realize the hole they are digging themselves into and the amount of work it takes to dig yourself out of the pit.
Developers like to do things the easy way, even if it means more work down the road. This isn't specific to games, this is all software, this is being human. This is why governments spend tons of money over the long run on multiple jobs sold to the lowest bidder when they are tendering projects. Everyone sees it as spend 100 and then another 100 later, instead of 150 now and 0 later. Obviously my numbers are made up, but its a very common theme. There is also the fear of spending 150 now is worse than spending 100 now for something nobody is going to use. Decision making is a very hard process, so I don't blame the government for all the poor decisions they make. Just because everyone does this does, it does not mean we have to do it. Just like everyone should be recycling because its a great way to preserve our resources, but it doesn't mean everyone will or even care about it.
Unity so far seems to be a really good basis for the "rendering" and "input" part of the game. However, the whole component and script part is only good for a subset of games in general (obviously you could liberally apply it to every problem and it might do a decent job). Looking at 7 Days to Die, HearthStone, Timber and Stone, Race the Sun, and Kerbal Space Program which are all written in Unity and comparing them with Space Engineers, Prison Architect, Path of Exile, and Xenonauts which are all "in-house" engines sorta, you can really tell a difference in the games in terms of the number of bugs and development time. The Unity based games typically (note: not representative of all games) seem to get unbuggy features completed more quickly at the start of development. I really want to highlight 7 Days to Die against Space Engineers. The games are both approximately the same age and they both have: decent graphics, support multiplayer, voxel-based, and use C# as the main language. Space Engineers updates weekly, and 7 Days to Die is about monthly. I believe Space Engineers has a larger development team at least it sounds that way from what I have seen. 7 Days to Die's multiplayer is significantly more stable, supports 'infinite' generated landscapes, has pseudo-objectives, has a form of AI, is really a survival-based game. Space Engineers has pseudo-survival, it has some interesting automation mechanics, but lacks large world support, no gameplay-based objectives, and no gameplay-based AI. Both games offer a form of modding support and both would be considered sandbox games.
From a software development perspective, I would easily rate 7 Days to Die higher, but both are certainly well made early access games. What has got my attention is how 7 Days to Die is done by a smaller group of people, seems to offer more features, and overall has less bugs (but still has bugs). The only real difference between the two is one is written on an "in-house" engine using SharpDX with Havok and the other is done in Unity. Let us not forget that Unturned (which is a relatively popular game for younger people) was written by a single 16 year old developer using Unity. If I compare Unturned to any of my earlier work, it hands down slaughters it in quality. This is using Java's 2D library, XNA with C#, MonoGame with C#, OpenGL with C++, DirectX with C++, and Android/Desktop games/apps with LibGDX. What is a common theme here? You can probably guess it Unity.
After walking through a bunch of tutorials, I can easily see what is so attractive about Unity. Doing things in it is so mind-numbingly easy that even non-programmers could learn the basics and make a simple game with it. Advanced concepts are available right through the menus, and are typically done well enough they can be used right out of the box in the above games I mentioned. More importantly, the things that don't work out of box can be modified to make them work reasonably well for games. Certainly, good quality code, low-level logic and a whole other set of things seem to be lacking in most Unity games. However, they work, they sell, and more importantly they make money.
One thing I haven't poked around with yet is the quality of networking libraries for Unity/C#. Java has extremely good libraries for this which work automatically across platforms (Win, OSX, Linux, RoboVM, Android) and architectures (ARM, x86) almost seamlessly with the exact same code and binaries (sorta binaries). It does appear on the surface that not using Unity puts small developers, hobbyists, and single developers at a huge disadvantage. There isn't much else on the market which is as mature and able to easily support tons of platforms (read as multi-platform == more money). Yes there are other game engines which can produce much more stunning looking games. However, "stunning looking games" == "has lots of artists" == "Not a small developer" which really means it would be stupid (yes I am going to just outright state it as it is) for a small group or individual to bother trying to make a game using those engines. The biggest hurdle for developing games is finishing the project. The best way to finish a project is to make everything as easy as possible and take as little time as possible. I really believe Unity can help me with that aspect.
So where is this long giant blob of text leading me?
I have a potential game idea I want to explore, it is related to other projects I have worked on (many not ever released to public), and I really think using Unity might actually allow it to come to life much faster than if I was trying to do it in other engines/libraries. Of course, jumping immediately onto this larger project without really getting personal with Unity is a recipe for disaster. Therefore, I will likely be working on a much smaller and simpler game first to make sure I understand the bells and whistles of Unity.
Last but not least, a minor side note: C# > Java. This is coming from someone with 10+ years of Java experience. My reason for not using C# more often, sooner was trying to find a way to easily develop mobile/desktop games without wanting to bash my head in from lack of high-quality tool support and libraries. Fortunately, in the last 4ish years C# has grown massively and it's widely accepted as a good language to use. This means going forward I will likely stick with it for my main development. Of course, Java and Python offer other advantages as well so they will be kept around for their nice features. Now if type annotations make there way into Python 3.5 I will think Python is the best scripting language ever! Okay Perl, Ruby, Javascript, Dart, Lua, and Coffeescript are nice but I still prefer the syntax for Python. Besides, I can mix and match as well. I would also really like D to become more popular because it just makes C++ look silly, but D has pretty much been out of the spotlight for so long I doubt it will gain traction any time soon, at least not like C#.
No comments :
Post a Comment