* Student? Hobbyist? I'm a computer science student and I've used Unity free for a university project in a team together with 6 other people. We decided to use Unity because it seemed very user friendly, not because it was mandated. Here's a link, so you can see we really did stuff https://github.com/tronza/hy-sheep-defender/releases I also like to make games as a hobby, though I prefer to develop small things rather than full fledged games with a story. * Tell us what type of developer you are and what kinds of business model works best for you. I'm an experienced programmer and I have a Bachelor's degree in CS. I use Unity free, but I see that sometimes I really need stuff from the Asset Store (e.g. the pathfinding engine). I bought some stuff on the asset store for myself, but when I work in a team, I've found that plugins that require "one license per seat" are completely out of question, as they simply get too expensive. I'd just like to tell you that I've seen other students work with Unity, and buying it for a University project is something completely out of question, even if it made our work easier. * Now, Unity Pro is essentially free or close to free on almost all platforms including consoles. Is this interesting to you? I don't really care about consoles. Unity itself may be free, but publishing on a console is not cheap. * Most games today are 2D games by a wide margin. What kind of games are you making? Where are you located? 3D games! I studied computer science in Italy but I'm an exchange student in Finland now. There are a lot of people making games here, and University have courses on it. * Are the technical blogs really helpful? Should devs reduce their workload and spend more time on these forums answering questions? Technical blogs are ok, but only if you listen to feedback from people reading the blog. Developers should check the forums, yes. Not once every hour, of course, but at least once a week. You could have the mods select the topics to be brought to your attention, but nothing beats the "come and see" approach, IMHO. * We used to sell software licenses only, now we also offer subscriptions I don't really know about subscriptions, but I may consider it if you make it possible to revert to free and keep working on a project. * Unity is currently closed source Big fan of open source here, and I'll tell you why. Because I've seen it work. If you make clear rules for accepting a pull request, like "always provide test cases", then reviewing them becomes pretty easy. It's something that should be handled in source version control and bug tracker not in the forums, so there's not much talk to be done. Still, I can see that, if open source is not part of your corporate culture, taking steps in that direction would take time. I guess you could only open source some of the parts you are not currently focused on, and let somebody propose patches for them. Right now, if there's a glitch that few people are experiencing, or in a component that's seldom used, it just never gets fixed. If you decide not to take any steps in the direction of open sourcing anything, you should consider providing some APIs to interact with your components. For example, Google Maps is closed source, but it provides APIs to do really interesting stuff with it. If your editor provided APIs for selecting GameObjects and changing their transforms by code, a plugin could save a lot of handwork. Tricks like "positioning all boxes in the scene to fit into a pattern" would become possible. * The biggest problem game developers have The biggest problem I have is that working in a big team with Unity was one of the most challenging experiences I had as a developer. I write code, I know how to do it, yet version control in Unity seems to be very difficult. We worked by branch and merge in GitHub, but fixing the merge conflicts was very difficult, thanks in part to the closed source, binary nature of the game scenes. What's making the conflict? What's this inexplicable series of symbols that's making a conflict in the scene? Those were though questions to answer. We spent so much time solving conflicts that actual coding took a hit. Moreover, some choices like the SendMessage stuff make the code very difficult to test and easy to break. A more event classic event system working as publish and subscribe would be far more intuitive for both Java and C# programmers alike. I'll link to this very concise blog post which I think better explains what's the matter. http://blog.sebaslab.com/whats-wrong-with-sendmessage-and-broadcastmessage-and-what-to-do-about-it/ I read somewhere that there's some kind of event class coming in Unity 4.5, I sincerely hope it's supposed to solve this problem.