{"id":3566,"date":"2015-04-26T13:54:55","date_gmt":"2015-04-26T12:54:55","guid":{"rendered":"http:\/\/t-machine.org\/?p=3566"},"modified":"2015-12-31T18:33:31","modified_gmt":"2015-12-31T17:33:31","slug":"kickstarting-entity-systems-in-unity3d-what-to-include","status":"publish","type":"post","link":"http:\/\/new.t-machine.org\/index.php\/2015\/04\/26\/kickstarting-entity-systems-in-unity3d-what-to-include\/","title":{"rendered":"Kickstarting Entity Systems in Unity3d – What to include?"},"content":{"rendered":"

A first-class Entity System for Unity3D<\/h2>\n

Unity is a great 3D engine and a good editor – but the programming environment is 10-15 years behind the curve. Entity Systems are a much better way of writing games, but they are surprisingly difficult to add to Unity.<\/em><\/p>\n

I’ll bring the latest in modern ES techniques to Unity, turning parts of it from a “weak” programming environment into “one of the best”. In game-engine terms, this will put it far ahead of the pack.<\/p>\n

This blog post is testing the waters:<\/p>\n

    \n
  1. You can give me direct feedback on the proposed contents\/scope\n
  2. I can start to see how much interest there is in making this\n<\/ol>\n

    First round of feedback<\/h2>\n

    A lot of people read this and got the impression I was going to charge them extra for the final product, and provide a library with no tutorials. Big confusion and misunderstanding! So, I’ve reworded those bits to be clearer.<\/p>\n

    Kickstarter: planning the campaign<\/h2>\n

    Target Audiences (Expected)<\/h3>\n

    I think I have four target audiences:<\/p>\n

      \n
    1. Newbie devs, and non-programmers (artists, designers), who find the “coding” parts of Unity overwhelmingly difficult today\n
    2. Unity devs who’ve never used an Entity System on a real game project, and don’t know what they’re missing. They may have a lot of experience (shipped multiple games), or none (University\/College students).\n
    3. Small Indie teams \/ sole coders who’ve used Entity Systems elsewhere, and feel that coding in Unity is slow, error-prone, boring, frustrating, and time-wasting by comparison\n
    4. Large Indie teams whose games won’t work in Unity because Unity is so bad at scaling to large projects. They’ve already re-written or replaced substantial chunks of Unity’s core so that it’ll work fast enough \/ reliably enough.\n<\/ol>\n

      Types of Reward<\/h2>\n

      Reward type 1: Discounted License<\/h3>\n

      Everyone who backs the KS gets a copy of the library \/ license to use it. By backing the KS (at any level) you’re getting a substantially cheaper purchase compared to the final launch pricing on the Asset Store.<\/p>\n

      There might be some options here for different team sizes, different levels of support, etc.<\/p>\n

      Reward type 2: Expert Knowledge<\/h3>\n

      When you have non-trivial questions about ES design and usage, it’s hard to get the attention of experts. They’re usually experienced, older, programmers with young families, or working in senior jobs. They have little free time.<\/p>\n

      Big developers fix this by hiring experts for a few days at a time. But small teams\/individuals can’t afford the “entry” cost – as a Consultant, you need to charge at least $5,000 per engagement to cover all the admin overhead and hidden costs.<\/p>\n

      So, we have some options here to give everyone this kind of access.<\/p>\n

      Reward type 3: Source Code<\/h3>\n

      In mainstream IT, when you purchase a library you rarely (if ever) get the source code. If you find bugs, or missing features, the vendor works hard and fast to fix them for you.<\/p>\n

      In the games industry, it’s the other way around: vendors take no responsibility for the code they’ve sold you, and in return … they give you full source access. “Fix it yourself, dude!”<\/p>\n

      If I let everyone have source, it raises my support costs. With each change, it won’t work for some people – because they’ve modified their copy – and I’ll have to help them update it.<\/p>\n

      On the flip side: Source code is your “Plan B” in case I get sick, or sell-out, or lose interest in the project, etc. It also gives you an easy way to add features of your own and send them back to me (which I then take on responsibility for maintaining).<\/p>\n

      I’m offering this, but it’ll be a high-cost. The teams that really need it should have no problem justifying the cost.<\/p>\n

      Types of Stretch Goal<\/h2>\n

      To clear up confusion: these are things that would be present in the core product (e.g. the GUI is going to be a major part of the library!), but stretch goals would allow me to add extras to each of them.<\/p>\n

      Goal type 1: Editor GUI<\/h3>\n

      In my experience the biggest effect on programming speed – once you get past your innate ability + level of experience – is the quality and “friction” of your tools.<\/p>\n

      As soon as you go beyond the simple stuff it’s damn hard to extend the Unity editor. But I’ve been hacking the Editor for a few years now, and I’m willing to do pretty much anything. Especially if it makes it easier to make games with!<\/p>\n

      Goal type 2: Example Games<\/h3>\n

      The core will have some form of tutorials, but it probably won’t have a complete demo game.<\/p>\n

      Writing a game just to demonstrate an API is extremely time-consuming, and it’s not what you’re paying for when you buy the library.<\/p>\n

      But … it’s also a great idea: it improves the quality of the API, by giving me a reference product to check everything is as easy-to-use as intended. So I’d like to write one (or several), but I can’t do that on the base funding.<\/p>\n

      (Aside: If I ran the technology division at Unity corp, they’d be writing and publishing games every quarter)<\/em><\/p>\n

      Goal type 3: Tutorials<\/h3>\n

      There will be tutorials with the core library. They’ll cover the basics of how to use it.<\/p>\n

      But … I’d like to go further, and do tutorials for every aspect. I’d like to do a written tutorial for everything, and I’d like to ALSO do a video tutorial for everything (some people only use written tutorials, other people only use videos. I’d like to make it great for both groups).<\/p>\n

      With a new library, tutorials are extremely expensive to write. Minor changes to the API – bug fixes, refactorings, feature additions – invalidate whole pages of tutorial at one stroke.<\/p>\n

      Pricing and Funding levels<\/h2>\n

      Tier costs<\/h3>\n

      These are approximate<\/strong> based on extrapolations of cost and expected “version 1.0” feature-set.<\/p>\n