Once upon a time, the idea of using some kind of middleware or major external library in my projects was out of the question. Writing all my code was the one and true way! I had a bad case of NIH syndrome.
Over the years I’ve mellowed out quite a bit. Now I recognize my obsession with writing endless tools and technology was more of an escape from doing the really hard part of game development. In comparison to making all the decisions involved in the design and implementation of the game itself, writing the perfect resource streaming system sounds like a really good time. It’s amazing how early it started too: I still remember spending weeks writing a Basic-to-assembly translator in 1986, before I had even heard the word “compiler”.
Now I just want to make games.
I’ll gladly use code other people have written as long as they fit my needs. For example, I’m very happy with Box2d in Casey’s Contraptions. Was Box2d perfect? Far from it, but it was good enough and I’m very happy with the tradeoff.
So how come that Casey’s Contraptions, apart from Box2d, is all custom code, written in C and OpenGL? Why didn’t I use some of the great tools and libraries available like Cocos2d or Unity?
In the land of AAA console games, developers routinely pull off the performance card: Only our code will allow us to make something that is so tailored to the hardware that it will make the game stand out above all other games. But for Casey’s Contraptions that’s not much of an issue: Any of the middleware options would be able to handle that amount of performance on an iPad just fine.
It wasn’t a lack of features either. We’re not doing anything particularly fancy, and I’m sure it would be possible to implement it in almost any other framework.
So if it’s not performance of features, why not?
Creating a game is a craft. It’s a mix of art and technique, and the craftsman or artisan has a vision and slowly probes, guides, and implements the final product. As with most crafts, the tools you use are extremely important and will directly affect the final product. If I’m going to change my tools and my techniques, the payoff I get needs to be huge to make up for the change. It’s as if I give up a set of hand woodworking tools for a power tool. Maybe it will be faster when I’m cutting in a straight line, but it will be very different and will completely change what I create.
As a game developer, my main tool is the language I use (C with a dash of C++). Things like editors or IDEs are secondary, and I can easily adapt to different ones without much of a problem (like when going from Visual Studio to Xcode). The way I like to work involves fast iterations, unit tests, very explicit memory layout, and processing data at a global, rather than local (entity) level.
I feel that by going to Unity or Cocos2d, I would have to completely give that up. A lot of middleware are frameworks instead of toolkits. That means I’m restricted to implementing bits of code that are embedded in a larger system and called by the rest of the framework. I give up the ability to architect the game in the way I want. Maybe it wouldn’t be a big deal if I liked a component or inheritance-based, entity-centered approach like a lot of frameworks, but I don’t.
Will I get enough benefits from using one of those frameworks to make up for the loss of productivity and techniques I like to use? Doubtful. All of a sudden I can’t just use fwrite on a memory block for serialization, I have to parse data files to load game state, undo/redo isn’t as simple as copying a block of memory, rendering becomes much more generic and less tied to the game, I can’t easily do test-driven development, iterate quickly, etc.
Sometimes, shifting workflows and techniques is inevitable. You may be used to solving collisions in a particular way, but when you move to a full physics engine, you need to process things differently. The payoff you get from using a pre-made physics engine is huge, so it’s worth it in my book.
For 2D games, there isn’t that much that I need: cross-platform support, simple math functions, ways to load textures, play sounds, and render simple things. Throw in some kind of simple UI display and layout tool, and that’s it. The rest I can handle. Actually, that’s not true, let me rephrase that: The rest I prefer to do myself, because it’s always highly dependent on the game.
What I really want is a toolkit-based middleware that does exactly those things without imposing any workflow or architecture on me. It saves me from doing the boring bits, gets out of the way as much as possible, and lets me work the way I want to. That’s already what I have with my current code, minus the UI library/tool part, which I’m still stuck using mostly UIKit. The idea of using Unity just so I can have cross-platform UI seems total overkill.
Even in the case of middleware that fits my style, I still need to be weary of the quality of the code. The last thing I want to do is trade time implementing my own code for time debugging someone else’s crappy code. Also, having learned my lesson years ago, I’ve sworn that I will never use a middleware/library that I don’t have source code access to. Nothing more frustrating than having to reverse-engineer UIKit classes to work around their bugs just because I don’t have the source code.
I’m not even going to go in the debate about middleware lock-in, future portability, building tech vs. relying on it, and financial aspects. All those are important, but secondary to how using some middleware will affect my everyday development.
If my next game were a networked, 3D game involving moving some kind of character or vehicle around a world, and I had nothing to start from, then the pain of adopting a foreign workflow and architecture might be worth it. Might. Even though it might be a wash on the code side, the tools and pipeline might be the thing that sways me over to adopt it.
In the end, as an indie developer, I chose to make games because it’s something I enjoy doing. I get up every morning excited about it, and I enjoy the development process. Whichever platform, tool, middleware or process I end up choosing, it needs to be enjoyable. The day I’m not having fun making my own games, I shouldn’t be an indie anymore.
What do you think? Am I being overly paranoid? Is there a good solution out there that’s multiplatform and will double my productivity once I get used to it? Has anyone written their own code for a 2D game and later switched to Cocos2d/Unity and liked it?
I think there is a big difference between Cocos2D and Unity IMO. Cocos2D is a “just” a render engine with animation support, while Unity is a full blown game engine. We used Cocos2D for our game because I did not want to reinvent the wheel of sprite sheets/animations, and I am glad I did. When you switch to a complete game engine (like Unreal, talk about overkill for Casey 😀 ) you will be pushed a lot more in their workflow, also for gameplay, editing and whatsnot.
For me the ideal scenario is having middleware taking care of parts of a project, the parts i “dont care” about as they are not crucial to the specifics of the game. So choose a middleware for rendering sprites, another one for playing sounds, another for physics and so on. This allows you to throw one out and do it yourself if you are not happy by the way it works or need specifics for your game. The “one size fits all” middleware approach I don’t like very much. This is good if you are not very skilled as a developer or very limited in time or resources.
And of course source code is a must, for the reason you pointed out (and that in case the middleware company goes bust, which happened more than once before at least you can maintain it yourself).
my 2 cents 🙂
Is that true about Cocos2d? If so, I got completely the wrong impression when I looked at it a while back. I thought you had to create nodes in some kind of hierarchy and they were rendered by the Cocos2d code. In other words, Cocos2d has control over the high-end loop and calls into you. I’d love it if I’m wrong and Cocos2d is what you describe instead (low-level support for sprites and animations).
Well you are right that it calls into you, but then again it also provides a way to schedule different calls to be made at a certain frequency. I have my gameplay code running at 20 fps and the graphics run at 60fps without any issues. For rendering you instantiate CCNode subclasses like CCSprite and so on, but that is what sprite rendering is all about (imo). You need a minimum of infrastructure to support sprite rendering and animations. Also since the game we made contains an object which cannot be represented as a sprite I wrote a custom node with opengl code to render the rope.
There is absolutely no “everything should be a CCNode” restriction. I’ve seen people make mistakes like that and include gameplay code in CCNode subclasses, but that is (imo) more a design error than a Cocos2D limitation. You can perfectly have the gameplay code in completely custom classes.
In our game all the rendering is objective C but the gameplay is written in pure C++ and can be completely reused on another platform without any dependencies on Cocos2D.
One thing I forgot to add:
In a way UIKit is middleware too. Using UIButtons and UIScrollViews and some CoreAnimation can save you a lot of time compared to handling UITouch events yourself in a custom rendered Opengl user interface
At this point your good enough of a programer that jumping into someone else’s toolchain shouldn’t be much of a problem. I just finally took a serious look at Unity, and I feel stupid for not considering it ages ago.
You really need to decide what is most important to you, making a game, or making the layer to make the game?
Players at the end of the day don’t care or appreciate your custom built game engine vs another one. Just did they like the game.
Actually that isn’t always the case… as I stated in my monster length reply (sorry Noel btw) we couldn’t have built our game using Unity or Cocos2d because we needed texture streaming and a lot of other custom functionality. Sure we could have caved and either went pure 3d (while drastically changing gameplay by having half or less of the units or by dropping polys extremely low) or by having less animations, lower frames, etc.
So while the player won’t know or care about all the extra work that went into it, they definitely get a much higher quality game to play because of it.
I don’t think you’re being overly paranoid at all and I also think you *may* be overestimating the “double my productivity” with middleware.
For us the main decision was made based on the business reasons. At first we looked at Unity but after seeing a bunch of bugs complained about in the forums, the lack of GLES2 (an earlier version for reference!) and the fact it was around the time Apple wanted to pull everything not written in C/C++/ObjC it scared us away from the solution entirely. This decision was solidified when we hit some things in the project that we would not have been able to control with middleware such as various render sorting orders, texture loading / queueing / streaming (being 3d pre-rendered we have to watch memory and swap in/out textures like crazy), explicit memory management over everything and extremely fast load times for the entire dev cycle… and even adding things like mmap, etc for loading/paging. I don’t mean to knock Unity at all because it is amazing middleware (hai Aras!) but I think there are still some solutions that are better built from the ground up.
So in hindsight if we chose to use a closed source middleware package right from the start, we would have either had to scrap it and code from the ground up or made some fairly significant design cuts / choices due to a lot of the issues we have run into and had to solve on the fly.
We prototyped the game concept using Cocos2d which went very quickly in the beginning but as soon as we noted that we *needed* shaders (certain things we wanted to do *could* have been done FFP but we didn’t have the texture/memory budget so wouldn’t have been able to) we decided to break from the prototype and actually build a fresh codebase. Sure we could have tried to hack GLES2 into Cocos2D but when you look at the structure and how it works it’s mainly just to get things up and running quickly for people that aren’t graphics/game programmers for the most part in my opinion. We got our basic renderer and scene system ready in pre-production and it only took about 2 weeks to build and debug all the features we would have used from Cocos2d.
Now as a programmer I didn’t like either of the above solutions in our case… with Unity I kept feeling like my hands were tied (even if they weren’t at the time) because I knew there was a good chance I was going to run into texture streaming / memory budget issues that I would have to address… and also we like playing tricks with render order for a few things. With Cocos2D the more I used it the more I realized how bad the code is (meaning fat, in Obj-C, using a lot of slow constructs) compared to a nice slim renderer/framework written in C. Since it is open source I could have always dug in and changed things.. but I didn’t see why I would want to run through the hassle of it tearing it apart and hacking in GLES2 support when I could build a nice tiny framework that had it from day one. Also I ran into a bunch of bugs during prototyping that I traced into Cocos2D and were eventually fixed but wasted a bunch of time and wouldn’t have happened with a fresh codebase.
So in the end we have our own framework (I hesitate to call something so small an engine) that has stayed small and it’s likely taken the same amount of time (or less) in comparison to using Cocos2D. I mean when you dive into their engine and check out what you’ll actually be using from it (i.e. most people only use the it for rendering) you would quickly see that 90% of it you likely already have or could be written in a few weeks in C/Cpp if you wanted. Down the road we added some cool things as well such as lighting using normal/spec so we can add a little bit of dynamic lighting to the characters, etc… but the framework has always stayed small instead of just throwing a million things into it. Also our load times are over 1000% faster with our own formats/code in comparison to the Cocos2D prototype which used their loaders (which in turn everything was based on plist/dictionaries.. so massive XML structures even just for tiny pieces of data!)
Now I don’t want to bash middleware and engines as something like Unity or Cocos2D definitely has a place, I just found that I prefer to craft the code myself and our titles are still small enough being 2D that we really wouldn’t have saved much time. If I were going to build a 3d title like a platformer or shooter I would be using Unity right from the get-go because at that point the actual rendering/physics/optimization work is going to start taking a lot of time and of course the bugs that go along with that… and with Unity I could concentrate entirely on the game and leave optimizations to Renaldas 🙂 Not to mention the amount of time and thought (and debugging!) that has gone into the editor and game object system, I’d probably call someone crazy not to use it for a 3d title with any amount of meat on the bones! Sure at first to someone that has always written their own tech at first it feels a little foreign but that’s just the usual NIH syndrome mixed with learning at the same time… once you get used to the editor and workflow you’ll be having just as much fun or more.
This echos my thoughts about middleware, Noel. My biggest concern is being forced to work a way that doesn’t feel right to me, and losing control over the lower-level stuff that I enjoy fiddling with when I make a game. On the flip side, maybe it would be good for me to give up that control and concentrate on making a game. But like you say, I wonder how much the game making process would be affected by switching tools.
What I’ve been doing lately is looking at other open source tools, and looking at how the systems I like are architected, then re-implementing them in my game engine, in my own way. This gives me the benefits of other tools’ structures that I like, but still gives me control over my own engine.
That being said, my game engine is aimed squarely at 2D games. If I ever want to do a 3D game, I’ll definitely be looking to something like Unity.
Owen
At the beginning of this post I thought it’s going to be one of those cases where an experienced developer tells its tale to someone younger and greener, but at a time, when the younger and greener cannot benefit from it. Long story short, for almost an year now I’ve jumped into some really deep waters and not only began to develop my own games, but also my own technology on top of OpenGLES and Cocoa (without even considering for a second solutions like Cocos2D). I got really scared that I’ve probably made a huge mistake in doing so, until I red this: “Now I recognize my obsession with writing endless tools and technology was more of an escape from doing the really hard part of game development.” It turns out we have slightly different motivations for writing our own tools – I often bump into limitations in my library, which prevent me to go further with my design, so I need to develop more and more.
Anyway, what I really wanted to share is that attempting to write my own engine – from texture loading to animations, to physics, to particle systems and so on has been the most cathartic experience in my short career as a developer. Since my background was mostly in graphic design and drawing, I would’ve benefited tremendously from using middleware in terms of production time, but looking back I must say that I’m glad I didn’t cave in to the intimidation of “doing things my way”, it’s the most rewarding thing any developer could do in the long run.
And thank you for this article, as it made me reflect on all of that. I don’t know if further down the road I’ll mellow out too (certainly not unless I’ve seen enough of how deep the rabbit hole can be), but as you said, establishing your own way of doing things and channeling your thought process into the code is something that can easily offset the benefits of a middleware solution. I can really see that now.
There’s only one way to find out if it’s for you or not. Download the free version of Unity and build a prototype.
A prototype is a great way to see some of the strengths of an engine, but I don’t think it’s a sufficient way to put technical fears to rest. As per Joe’s case mentioned above, he ran into some unique needs for texture streaming that I don’t think they would have emerged in a prototyping experiment.
On a personal note, we’re using Unity for our first batch of projects and for the most part it’s been a joy to work with. As a new company we would have had to ‘start from scratch’ on a 3d engine, toolchain, level building tools, etc. The cost of buying the engine (and learning the engine) have still been a cost win for us, but with a different set of projects it easily could have gone the other way.
The mention about entity and component based architectures really resonated with me.
These things are absolutely critical if you’re developing a do-anything engine that needs to meet any possible needs and where you may even be licensing the engine to third parties who will want to extend the functionality in their own directions.
These things are absolutely not required if you’re doing it for yourself on your own. Indeed, components, entities, object hierarchies, all that jazz often just gets in the way of actually making the game. These things make it harder to reason about the code and the data and ultimately make the code harder to edit (and debug). Separated from the rest of a game’s concerns, for many if not most games something simple is absolutely sufficient. This simple thing however will only really be applicable to your own game.
The “orthogonal bits of functionality” that so few middleware providers offer can really help, though. Noel mentions the Box2D physics engine and UiKit; there are also movie players available and AI middleware and all that stuff; these are great when you can just drop it in and it works with you. These become less great when they start dictating to you the way you need to change to serve your new master. There’s no sense reinventing the wheel, but you may be well served by inventing your own axles. Use the middleware where it makes sense and write your own simple code for everything else.
Noel- how big is the codebase (not including middleware packages except for any mods you made to them) after all is said and done? I’m guessing that the entirety of Casey’s Contraptions is quite a bit smaller than one of these all-in-one engines would be, for the simple reason that all code goes to serve exactly what it needs and there isn’t any code lying around that someone else in some other application may need.
I’m using Unity3D right now on a project, in combination with Detox Studios uScript engine. I will say this about it: as soon as you need more than one person on the team (e.g. an artists) you’ll need to have $6000.00. (Or just $3000.00 if you are willing to bend the law and share a license: it can be installed on two machines).
iOS Basic is $400, but it is deliberately nerfed such that you cannot work concurrently using version control. Just for version control you need Pro, and that means Pro ($1500) and iOS Pro (+$1500). You can’t even use Pro + iOS Basic.
Is it worth $6000? I’m not sure yet. It is fantastic for rapid prototyping. However even with version control, I find myself nuking and re-cloning. Our framerate isn’t what it should be, but I haven’t looked into it to deep, so I can’t blame Unity yet.
OTOH, the game is pretty much built and populated by the designer, with me dropping in new uScript nodes when she needs to do something cool. In terms of designer/artists productivity it is unbeatable.
Interesting. That’s also a very different set of requirements from mine since Miguel and I do all the design. So if we want a feature we code and tweak it on the spot directly in C. Funny how things change so much depending on your team size and structure.
Thanks for the shout out Jamie regarding uScript! We’ll be entering open beta soon for anyone that wants to give it a try with Unity.
I think deciding for (or against) a middleware is one of the more sophisticated skills that defines you as a developer. It doesn’t really matter if you are Indie or work in a team, if you have the power to make such a decision, you better use that power wisely.
In my experience, it is always a very complex weighing of Pros and Cons. Ultimately, you want to transform your vision into a playable game. Does that middleware get you there faster? Does it impose restrictions that will influence your vision? Those are the big and obvious parts.
But there is much more to it. You will have a learning curve, but maybe it will pay off with your next project. It might bend your vision, but it might bend it to the negative here and to the positive there. Even more abstract, will you be the only one not using that middleware in two years and miss out on a bunch of amazing extensions? And much more like that.
The biggest factor for me remains time. Does it speed up your completion time and/or give you features that you want and could only do yourself with a significantly time overhead?
But if that is the ultimate factor, that means something else: The answer to your question is highly subjective! Because it depends a lot on your experience level (and that of your team) and the featureset of your game.
You know so much about opengl programming, I don’t think Cocos would give you as much of a jumpstart as it gave me (oh and I paid my dues on the way). Can you claim the same for complex 3D including asset pipeline tools? If not, Unity probably deserves a really good look in case you will finally make Flower Garden, the egoshooter version.
Overall, I’d say that you make some strong observations on what influences that decision. “Fun making the game” being a factor? Hell yes! As long as you feel you can weigh them out neutrally and make a decision for every new project you start, in a way that in your post mortem you can again neutrally judge if it was the right decision (with all the knowledge you have by then), you should be quite alright.
I’m currently in the process of writing my own engine structure and trying to figure out a way to just use Cocos2D for rendering. I had previously made the mistake that Joris mentioned, trying to build a game on top of Cocos2D instead of just using it as a rendering component, and am paying for that now in re-write time (not to mention having written basically everything in Objective C).
I think there are two types of programmers – ones that don’t mind working within a particular engine’s constraints, and ones that really need to have the engine laid out in a particular way to do their best work. While I thought I was in the former group, I now realise I’m in the latter; even though I’ve just started the re-write process, I’m already a lot happier with how things are laid out, and it’s going to be a lot easier to track down bugs and figure out how to implement new features/etc.
That said, I’d recommend CocosDenshion for a sound component – it seems nicely modular and separate from the Cocos2D engine, and from my experience handled what I needed it to handle nicely. I’ll try to remember to comment here once my attempt at integrating only the rendering of Cocos2D is complete – I may end up simply writing my own OpenGL renderer and just using CocosDenshion for sound.
The huge problem with most off the shelf 2D engines for iOS is they are poorly written for performance, as it is hard for coders to think outside of a blit sprite / blit tile mentality and this is why they produce hundreds of unnecessary draw calls. Sometimes problems need NIH to be efficient.
Great piece.
What really resonates with me is the part where by using middleware, you need to either adapt your game to the middleware’s architecture, or adapt the middleware to your game, both of which are not ideal cases.
In my previous experience, whenever I tried to use a third-party rendering engine or game engine, it’s architecture seriously restricted me in what I wanted to do, or it did some things that I considered sinful (using reflection to instantiate classes). That’s probably why I like XNA so much: it simply gives you out-of-the box support for all the little tasks that no one takes pleasure in writing(loading textures, sounds, models, setting up the graphics device, amth libraries) but it lets you code you game however you want.
But for some tasks, using middleware is indispensable. In Chickens Can’t Fly, the requirements for our physics simulation were low enough that we first tried to do it on our own. But after 3 days we decided to drop it and use Box2D because it was simply not worth the hassle to do it ourselves.
No doubt people that are used to the inner architecture and restrictions of Unity, Unreal Engine, Cocos2D get a great deal of benefit from them, but for smaller teams I feel it’s easier and more rewarding to work closer to the metal (or at least closer to the JIT compiler 🙂 ). This way, all the code we write matters and directly adds something to the game.
Noel, one last question: If someone were to write a middleware that encouraged DOD, and had a system for generating a DAG based on data and transformations that you defined, would you consider that sort of middleware acceptable? If a middleware implemented an architecture very similar to what you usually used, would you consider bending your code ever so slightly to adapt to that middleware?
I am still to find such middleware, but I can’t help but wonder what I would do if I stumbled upon it.
I agree with Noel: where’s the fun if you are forced to inject your code in some bigass framework which tells you how to act. And makng games should be fun. The uncoolness increases with every added level of abstraction. (now’s the time to call me immature newb :))
I got some experience from both sides of the fence.
I’d say your arguments are solid. The more you put hours in your current paradigm, the more pain it is to learn a new one. Also you need more in return to justify the pain. I wouldn’t be surprised if you were in a position where you don’t need to make a shift anymore. Ever.
That said, I could see some potential with Unity for prototypes and C for the final product. If you invest some pain, you’ll get sweet prototypes out of Unity so fast that it can make a grown man cry. And it’s fun too.
Just as I was getting my iPhone development sea legs I came to the realization that I needed to stop the engine churn and focus on the most important aspects of the projects I was working on.
At my day job that meant leading the team, design and architecture instead of trying to have code that I had written personally take a center stage in each module.
On my personal projects it meant I needed to stop wheel making and actually create something people could safely ride in.
I decided to focus on gameplay,UX, and interaction opting to sit out on the engine development time sink for this chapter of my development life.
I stumbled upon Cocos2d after a game engine dev relapse and recognized that for all of its flaws it had the majority of the things I was looking for, imperfectly implemented but implemented none the less.
I whinned about sprite sheets and they showed up. I whinned about particle effect speed and it got better. I needed physics and by golly Box2d and Chipmunk were integrated. I could still dip down into raw OpenGL calls when I needed to do something interesting and integrating other things like data access, internet, and audio was a snap because I was still native to the platform.
The only thing really missing is OpenGL ES 2.0 based shader functionality but I think I can do without it until the heat death of the pre 3GS handsets and devices.
I have come to the understanding that at the end of the day I have to release something fun and that as long as I can produce a fun illusion with the tech I have I should focus on the illusion and not the tech.
You guys know what you are doing, and your way is obviously working for you. You guys have 2 very popular applications out on the App Store. If it aint broke don’t fix it. The avoiding middleware thing seems to be/is working for you.
A thoughtful post, Noel, and similar to the thoughts I had recently about using Unity for an iPad project.
The project was primarily 2D, but had some definite realtime 3D aspects, so I chose Unity as the solution. I had never used Unity before this, so I was a little nervous about getting up to speed with its workflow. After a couple of books and some video tutorials, I was able to do everything I wanted to do with reasonable ease.
However, over the years I have built our own 2D API with supporting tools and everything else and it is now very mature and very efficient (and very platform-agnostic). We will continue to use that for all of our 2D games as we’re so intimate with it, we can use it for rapid prototyping as well as full-blown commercial products. I only considered Unity for the realtime 3D requirement of the project I mentioned earlier.
Do I think Unity was a good choice? Yes, for that specific project. Will I consider it again for future projects? Absolutely, if the project has specific needs that our own API is lacking. I don’t think there is a generic answer you can apply to all projects, you have to look at the needs of each one and then base your decision on that.
I know a lot of x console developers that are in love with Unity3D. It’s pretty good UI. Iteration, which you seem to harp on, is nearly instant. Add a class in C#, the public fields show up LIVE instantly. If the fields are typed they only except the right type automatically. Add a field of type Model and a field shows up in the UI you can attach a model to from the UI. It’s pretty slick.
I know how you feel though as there’s a learning curve involved. You already know C++. You already know OpenGL. If you write your own code you know exactly how to add a feature. Pick up an engine + tools and you have to learn both the engine and the tools. Expect the first project to have a large learning curve. The 2nd and 3rd should be cake though.
On the other hand, what do you lose by writing it yourself? You probably lost months writing tools and you’d have an Android, PC, Mac, and possibly XBLA and PSN version today with little extra work.
As for the guy above complaining about price I don’t see how that’s relavent. Unity3D is just a tool like Photoshop, Maya, Flash (the app) etc. They cost money. Unless your going to try to do it all open source and most likely spend even more money on salary than you saved on software, Unity3D is just about the cheapest thing out there for what it provides.
You’re not paranoid. I distrust middleware so much, that despite the effort I am currently creating my own. Why don’t I trust Unity, CryEngine, Unreal, Source and a bunch of other Open Source tools? Well, simply because I fear that I will find that they have some limitation that I can’t work around AND the knowledge that they aren’t User Centric. You see they are tools designed for programmers by programmers – on the surface of things that shouldn’t really matter if the user of the middleware has the tolerance for the technical “bleed through” of the tool’s System Oriented Design, but even though the user is themselves a programmer creative flexibility and productivity would be greatly increased if it “spared them the details” through interfaces and paradigms that abstracted the underlying complexities, assuming a set of defaults unless manually overridden.
Look at early Paintboxes with their stunted ability to draw lines, triangles and circles. That wasn’t art. Even when they included a paintbrush it was a fixed single-size bristle texture to repeatedly blit onto the canvas. Years had to pass before anyone attempted anything close to oil paint with dynamic colour mixing. Hence, the early tools were ok for the programmers who created them. Only recently do we have tools with which an artist’s proficiency matters.
3D modelling programs aren’t remotely like actual sculpture. They are weighed down with complexity. Raw HTML and TeX have been gradually replaced by more “user friendly” Desktop Publishing Tools, but I remember those early years and the increased control wasn’t really worth the tradeoff of inaccessibility. Consequently, the “creatives” must be central to the consultation process conducted during the product’s iterative development. Also, programmers can benefit from languages that have been expressly tailored to their requirements – rather than some hack that was ok for writing device drivers in the early Seventies. Skeptical about the performance overhead of OOP and FP? Well, you don’t have to support them. Prototypal programming can support Actors and Futures for Concurrency. A language can be extended with Macros: supporting notations that better articulate the problems of a particular domain. Data Oriented Design, Pre-Allocation, Transformation Pipelines, Static Single Assignment with Uniqueness Typing can support Multidimensional Tables operated upon by Generic Tensor-savvy Referentially-Transparent functions, etc.
Yet, here we are stuck with dumb For/Next loops and no automatic bounds-checking. How about some abstraction? Then write the next abstraction with the last. Use exploratory “live programming” environments with the undefined variables remaining their symbolic name in the reduced result, via support for Equational Reasoning and Constraints then link some of those Constraints to a parameterised HUD console, so you can tweak a slider and observe how the gameplay changes dynamically.
The reason I think we are stuck with shoddy tools is that no one has the time to make better ones. A bottom-to-top comprehensive overall of the whole production pipeline is out of the question, unmarketable. To reinvent the wheel one has to accept lower initial standards, to turn the clock back before the obsession with photorealistic 3D graphics and focus on enriching gameplay even if the final game looks like it could be running on an Atari ST. Perhaps, given time, the look of it won’t be so “retro”, but I’m of the conviction that this obsession with presentation has been a big drain on the evolution of the medium’s articulacy and depth – i.e. the industry has overlooked the “feel”.
iOS and DS games may be an exception to this trend, as their technical constraints stimulate gameplay innovation to compensate for what may otherwise be perceived as an underwhelming experience. Yet, Dwarf Fortress & Minecraft have shown that even PC games can gain aficionados without spectacle.
Personally, I feel that “high production values” and “the pursuit of realism” have been a tragic distraction for a young medium that should be refining what uniquely defines it: non-linear dynamical interactive systems – THE GAME.