Future Direction Planning Doc

• To be managed by a project committee
• Initial committee to be formed of @CTrauma @Alan-FGR @boberfly @darrylryan @rokups @mattbenic @benwolf
• All committee to have admin access all resources to ensure rapid response and no-one dying with the only set of keys.

• Continue existing codebase, streamlining and in particular removing feature areas that cannot be maintained
• Core is existing Urho based engine, editor, and C# scripting support on desktop platforms
• Outside of core, any requested/desired feature or additional focus area must have a committed maintainer to be considered

ᶜ = confirmed ʷ = working on it ᵃᵇᵈᵉᶠᵍʰʲᵏˡᵐⁿᵒᵖʳˢᵗᵘᵛˣʸᶻ

After reading through all the chat logs over the past week I was able to slap this document together. I really didn't think about how to divide it up as much because I wanted to get it out to the community as fast as possible. Hopefully I didn't take too much out of context, it was a lot to digest in a short amount of time. Hopefully my personal bias didn't seep in anywhere, tried to be objective as much as possible which is probably why this document is as long as it it.

Some things stood out for me, but read the whole doc to make up your own mind of how things are weighted.

The things that stood out (in no particular order):

• We have limited resources
  • leverage as much third party as possible
  • possibly modularize development and runtime
  • shrink the code base to just what is required
• The code base is huge, which should we use?
  • Three way tie between fork Atomic / Use Urho / Use Lumix
• Bindings are incredibly important
• BGFX is the way of the future
• Building a 1st class editor and asset workflow is complex and time consuming
• Having a proven codebase matters (Urho has 10+ years)
• We need to define the audience for AGE 2.0 to drive direction
• Xplat deployment is required
• Original build process is a pain point
• CPP core with CLR/CLI ( not sure what systems are in what camp )
• Showcasing a game could be a good way to drive use cases and features
• 2d feature should be optional
• Atomic 1.0 was not exactly focused on the wants of the current community
• Diverging from the current Atomic codebase will be at the cost of some current valuable resources
• C# is an absolute must
  • we don't really understand the binding generator
  • API holes are a pain point
  • standardize on 3rd party binding tools
  • Asset pipeline tooling should all be managed code
• UI is a major pain point
  • IMGUI for Tools
  • UrhoUI for in game
  • TB is old, inactive and cumbersome

• PhysX is by far the best choice for a physengine
• I still think it should use a 3rd party lib like glm for math
• PhysX is the best lib of its kind
• bgfx is a better renderer
• Lumix
• OzzAnimation
• Bullet
• glm vs blaze vs eigen vs imath
• for assets I'd be quite OK going with only FBX and gltf as long as it's top-notch... every modeller supports one of these today
• Outsourcing work is a good thing. Swig could do the job
• OpenFBX
• AutoWIG
• GLTF

• Bunch of modules that have primary maintainers, glued together with "engine"
• a single person can't maintain a complete engine
• just take the most popular, stable and well-maintained open source stuff on github and glue it all together.
• Focused libraries (modules) are much better development model than typical engine. Examples are ImGui, OzzAnimation, Bullet*, bgfx, etc. you glue all those with "engine" and you can have simple 2D game, or complex 3D game, etc. What's lacking is good high-level rendering library, something that deals with meshes, lights, materials, postproc, etc.
• the 3d guys maintain the 3d stuff, the 2d guys maintain/contribute to the 2d stuff as @bkaradzic earlier today said: would be really cool to have a modular engine
• atomic would be a collection of "contracts", the rest is completely optional
• we should atomic treat as a kernel
• we need to define what the kernel's job should be
• write a wrapper around bgfx, write up some contracts, everything in c# :)
• Software distro, a set of software components (i.e. open source components) assembled into a working whole and distributed to a user community.
• atomic is the kernel, rest are modules
• The kernel idea is definitively a good one, but it's something that can be achieve step by step after some iterations and should be a long term target and not something to do first. I think @mattbenic is right the focus should be on what needs some love and polishing first.
• I have a plugin system, it's totally not worth it for essential stuff
• being able to safely disable certain components (at runtime, not bloody preprocessor) would be nice

• urho/atomic work combined with bgfx and a new editor project
• what's the use in making some modules for a little-known engine that nobody uses anyway? What kind of community can one expect from/for that?
• there are too many bits of Atomic which are undocumented/unmaintained/incomplete
• prune off the dead branches so the plant can live
• maybe we want an atomic core with a bgfx in front?
• atomic has a much better community, better media, presence...
• the c#, scripting etc is awesome
• c# is broken, see #1644
• atomic's strength is doing 3d well
• working cross platform well
• nice scripting support
• i prefer atomic's structure
• the build system
• the platforms deployment
• the main thing that kept me with atomic an not lumix is that lumix scripting sucks
• do we want to keep atomic but with a bgfx renderer
• I liked the promise of the editor, the turnkey build on multiple platforms, and the deployment especially on mobile, plus the script binding
• I totally agree on having a small codebase/framework though, Atomic honestly feels too bloated
• We're fairly invested in Atomic, we've been developing with it for the last two years, have a completed C++ product application in it, the port of that product to C# and another C# product, both of which are currently being tested for issues, and we're working on another C# project which will take some time.
• the problem is Atomic is a huuuge project, so is Urho, but Atomic is much bigger.
• Atomic is just too ambitious for a project with no financial backing imho
• I guess the first thing we need to do is scale down considerably, then produce some examples and fix the API so you don't need tons of workarounds in those examples, and iterate that way, make some examples to really put the engine to actual relevant tests on real-world scenario
• it is possible to fix things like API holes, maybe not exactly to your or a former leaders liking,
• let's strip atomic down to it's bare minimum
• atomic has a nice autobinder already, but need to study it
• I don't see much to cherry pick actually, and I'd advise against picking say the math stuff while you can just go with glm which is fast and certainly much more actively maintained, you just plug it in and forget about it, that's the way to go imho
• fix the bindings and go with managed tools, fix FBX support, add gltf (maybe) and we're gold
• so my conclusion would be: a) drop duktape/js/ts/editor b) get a working wrapper for atomic core cpp and C#/CPP "just code" SDKs c) make a managed editor with a good asset pipeline (GLTF native support imo) d) get BGFX rendering it all
• what is better about a C# wrapper around Atomic with a BGFX renderer in front, vs Lumix which already has a BGFX renderer and the C# wrapper in progress, and the tooling and asset pipeline is already quite mature
• i think the main issue with atomic is that josh was trying to solve a lot of problems that none of us had but not the ones we all have, we should start with the those
• maybe we just keep the existing bindings and just fix the holes manual
• Start from current Atomic rather than a new fork of Urho. Get the editor ported to C# (while addressing C# bindings in parallel if resources allow). Once the binding work is done (likely to be done before the editor) those contributors can switch to editor or even pipeline.

• what about taking bits from Atomic, that are different from Urho, and keep them as modules for Urho?
• "atomic modules for urho" is honestly way shittier than "atomic game engine".
• Urho isn't really moving fwd these days and we'll have to keep them as 3rd party modules they won't accept them officially
• Urho might not be not moving fwd much, but it's probably better than one of both projects dying
• do we keep urho? when it is also in flux?
• the problem with urho is that it is dated
• looking at github, urho is not that more popular than atomic
• there's no-one working on the bits urho needs
• the only game on Steam is probably the worst game ever made
• urho has issues, we are looking at moving to bgfx
• I prefer the Urho architecture overall, and I've never actually uses a 'systems-first' ECS like the one in Lumix
• Urho has more than 10 years now and it's extremely complete, but it's also a bit over-engineered
• it's intended as a general-purpose
• Without cadaver and weitjong honestly I have little hopes for Urho
• Like fork urho3d, bring the fixes push bgfx, ignore 2d and make a clean simple editor
• C# bindings with CppSharp, ignore js because it's for skiddies.. Drop Lua and angelscript and redo build system from scratch
• the problem with the Urho architecture is that it's not going to be easy to MT it as Lumix
• Urho is kinda obsolete and upgrading it to run well on modern hardware is certainly going to require a rather major revamp
• The ECS implementation as we discussed also doesn't leave much room for optimization
• on the renderer front, i think there seems consensus that Urho's future is uncertain and it is going to be harder to multithread etc
• Urho is much more mature than Lumix, we just need a decent binding for it and strip out the extravagant stuff imho for a starter... and provide decent asset pipeline and tools
• refork urho, strip out the extras, selectively re-add the basics in atomic
• forking urho3d and importing stuff from atomic gives benefit of shared commit history, easier to frequently import from upstream
• at it's core atomic is urho3d with some fixes. most of atomic is other addons like editor, bindings, tools
• maybe we should consider changing Atomic so that Urho3d is unchanged have it in its original structure and namespace so that its easier to maintain?
• we should get the minimum urho wrapped and deprecate any parts which are not supported like 2d, http etc. we dont need to physically remove them, but they can be undocumented and unsupported and unused in the demos
• while Lumix has all of that, Urho is muuuch more complete, and has 10y+ of work behind it, the core is very stable at this point well, for a starter look at the core/engine/scene types, Urho has everything we could possibly need and honestly the code is much better
• honestly, I really fail to see any decent opensource alternative that's dependable and performant... Urho is pretty much the only that comes to my mind, and I've seen a lot of stuff and xplat of course
• I have not seen anything other than urho more comfy to use
• imo the only opensource engine that's fast, proven (somewhat), and really fully featured is Urho
• Urho is somewhat proven, at very least it was tested in a craptonne of hardware in the last 10+ years in development
• rokups is stripping out the stuff from Urho we don't want, and is going to add IMGUI, then we bind it all (hard part) and we can maybe coordinate some efforts to start the new editor and in parallel maybe make a game or something, don't know... but the first part is pretty clearly decided isn't it?
• so it's urho minus what we dont need plus imgui plus new wrapper plus new editor?
• reforking urho? it would make merging from upstream often much easier and we would have benefit of knowing where certain changes came from and why. git blame would immediately become useful
• after projects leaders leave we are talking about forks and what not, perpetuating fragmentation, while we should just work with the upstream.
• I agree that making Atomic better compatible with upstream where possible is idea, however it's not really possible to work directly with Urho, unless the (new) maintainers there can be convinced to accept these changes
• enough reason for Atomic to exist as a separate project. All of them together make it a no brainer So easier updating of stuff that stays unchanged from Urho? Totally! Trying to force changes onto Urho that they don't want? Not so much.
• Urho provides a lot of stuff outta the box... whenever I need something I always take a look to see if it's already there because chances are it is

• bgfx is a better renderer than urho's one
• add bgfx as the lowlevel-stuff handler after that, write a thin c-interface for the autobinder
• up to bgfx to do stuff like async compute, bindless textures, more shader stages than just compute/vert/fragment
• shaderc is being revamped so that'll be interesting to go away from preprocessor defines, the alternative I'd preferably go like pure HLSL or GLSL and try out like SPIRV-cross to convert the good thing is the bgfx API won't change drastically to add these in future and the engine can just update to these changes later
• Bgfx is totally a future imho. We all here are for it
• bgfx has been tried on a lot of hardware too which is the majority of problems for system support, second by SDL handling the rest
• Once we have BGFX though we will also be able to easily implement the goodies that are scattered around GitHub, including GI and all kinds of crazy shaders

• Lumix is totally on the right track imho
• c# for lumix?
• let's ditch Atomic and move to Lumix
• lumix has that stuff...
• what if we take lumix and make it Atomic 2.0
• would be much better to really bring the best bits of atomic into lumix
• get c# and maybe duktape working
• Lumix doesn't have the 2D stuff, but I don't think it should anyway
• lumix does 3d well, but its not as good at the cross platform and the scripting
• maybe the sensible thing would be to get the community behind lumix, and get the c# up to speed and have managed editor plugins
• the editor is already scriptable
• what's wrong with xplat? Afaik it's fully portable, maybe would need minor adjustments
• we could port various bits from atomic/urho and use a lot of the smart stuff from josh in lumix i am sure
• Also Lumix uses a real ECS which performs orders of magnitude faster and it uses PhysX
• yep, lumix tbh is superior in most ways these days
• lumix editor is more usable with terrain tools, trees, grass
• @nem0 isn't going to jump the ship right @nem0?
• if @nem0 can make c# work to a usable state, i would be inclined to think the most sensible thing might be to unite the community of urho and atomic behind lumix
• with Lumix supporting FBX quite decently, having a usable editor, physx, bgfx, and stuff like fibers on the roadmap, and also not having all the extra stuff in Atomic. I think it's not that hard of a choice
• Lumix is way less ambitious but at least all problems @nem0 are solving have a clear purpose
• I like Lumix's architecture more for a multi-threaded/cache efficient standpoint
• the editor is in a pretty decent shape
• the ECS system of lumix is easier to multithread as your entities are just handles and the systems are managers which you can restructure stuff so that you could make things cache/SIMD efficient
• my mindset gravitates towards lumix and that neil engine
• Lumix on the other hand has a very limited scope, it doesn't promise to solve absolutely all your gamedev problems, but I guess that's actually a pro
• well I'm cool with contributing lumix or neil's engine as they both have more of the core concepts and smaller codebase, then cherry pick out of atomic
• why don't we just use Lumix?
• fork Lumix and call it Atomic 2?
• what is better about a C# wrapper around Atomic with a BGFX renderer in front, vs Lumix which already has a BGFX renderer and the C# wrapper in progress, and the tooling and asset pipeline is already quite mature
• lumix pretty much has all the bits we're saying we're going to implement
• adding scripting support to lumix, is proably way easier then to remake atomic 2.0 i urho
• lumix seems to solve most of the problems i have with atomic but it falls down on one massive one which is scripting support atomic has C# but if we're saying we need to fix/replace the wrapper in atomic anyway... why not just do the same with lumix
• the ECS in Lumix is completely different so is the overall architecture @darrylryan
• I personally prefer Lumix but I think it's 50x more work to bring it to the same level compared to Urho, for instance, completely forget about automating bindings and prepare to do everything from scratch because the ECS architecture on native side isn't OOP at all, so you'd have to wrap everything in POCOs
• might be easier to just take lumix where we want to go
• i think we all agree lumix isnt what we want...
• Lumix is too big for us, no doubt about that, even @nem0 would agree I'm pretty sure
• what puzzles me is why only lumix is being targeted as a succesor, if you want people to use what you are creating, why focus so narrowly?
• Godot is too slow, and honestly Lumix is too bare bones atm imho
• but imo lumix doesnt lack any of that stuff
• lumix now has fibers and a job system for it
• lumix lacks platforms
• easier to add platforms than to start a whole new editor project and replace the renderer in atomic
• only audio is missing on linux, and fibers now
• Tbh i am still leaning towards the idea that fixing c# in lumix might be easier than fixing up atomic bindings, editor, renderer and ui
• my ideal engine is the features of lumix with the usability of atomic i imagine it would be moving the stand out tech from atomic on top of lumix a merged engine would be amazing especially with a push on usability
• while you guys restructure atomic, lumix seems fine to use albeit needs a little custom love for what I want out of it :)
• lumix with proper c# support would be my best bet too
• Well the question would be what does Lumix has that couldn't be done in Atomic at some point ?

• atomic editor needs work
• if the editor could be ported to C#, I think being able to drop the need to maintain duktape support could probably trim things a bit

• we need a better ui like imgui with splitters and stuff
• Maybe getting urhos UI back.. because tb is a wreck
• a simple scenegraph/wrangling UI that ties in with git/git-lfs will do
• ditch TB and bring UrhoUI back?
• i guess that comes down to will @JimMarlowe get turbobadger to a state everyone is happy with it or will @rokups get the Urho UI working well with C# bindings
• tb is dpi aware, doesnt suck fps, doesnt make eyes bleed
• Start one with ImGui (or actually ideally look how to extract editor parts from Lumix to be usable by both runtimes)
• urho ui can scale, although not automatically based on dpi. Easy fix. UI may need a high res texture but so would TB. Don't rendering was recently improved a lot. So people still work on and improve urho UI while TB is dead and it's code smells. I just don't see how tb would be a good idea
• For tooling, expose ImGUI to managed and build everything with
• tools imgui is definitely the way to go
• then let's go with Urho, improve it where necessary (and as necessary), and ditch TB
• I'm not saying skip WPF and use Qt, I'm saying skip both and use ImGui instead (like Lumix did)
• imgui for tools, Urho UI for ingame
• we are going to use imgui for tools
• urho UI gets more development from more people. TB UI is abandonware basically. This alone is big for me
• The best part is that since we're using IMGUI we could very easily even ship the editor with the game, so we can have a debug mode in which you can pause at any time and select stuff to inspect values

• c# is a must for me
• real showstopper to me is [the lack of] C#
• While its awesome that there's support for so many scripting languages, I think the big one everyone looks for these days is C#
• me personally I'd just stick to C# because in the long static typing is better for bigger projects imho
• C# For tools sure, for entire engine - nope.
• Like I said tools I'm fine with (if they run on Linux), but for engine itself... That would be not for me. I agree, native core with managed tools and scripting
• C# Scripting and tooling would be best
• tooling that uses C# and can be extended in C#
• i think c# wrapper definitely should be maintained
• I guess we should scale way down and start basically making the C# bindings work with the minimal project
• something dead simple basically start with a usable urhosharp
• And all attempts at C# ( for game code ) at companies where I worked failed miserably, and canceled.
• I have nothing against C# scripting, just saying you should not lock whole engine to it, allow other scripting languages too.
• Requiring C# is bad, being one of options is totally fine
• The bindings will also allow you to use any clr language, not just C#, so say for example we could easily port some python importer that runs directly in the editor and calls our API, we'd just need to adapt it to ironpython
• people telling me that C# nowadays can be built cross-platform native & statically linked but I never seen any examples of it
• C# has been top notch xplat for quite a bit of time now, there are major pain points, but that's mostly when you need specific hardware access, say for example banshee is a real nightmare, but monogame works somewhat OK on all platforms, although it fails sometimes while FNA is much more reliable but is only for desktop
• +1 for pinvoked netcore when appropriate
• it might be better to go the dotnetcore route and wait for it to go android vs using mono
• autowig looked alright, some kind of template which fills in some boring manual bind code
• what we need imho is to solve the automatic binding problem, and I honestly don't think salvaging the current generator is viable at all, no idea if autowig is an option, but I'd definitely vote for using a tool like that. In the worst case there will be some support, and also whoever is responsible for it will be learning something that's potentially useful outside the Atomic scope.
• the top priority atm is to have something capable of decently (not perfectly) binding it to a point where we can start playing with IMGUI on the managed side to make the tools
• one of the things that JSBind (the tool that generates JS and CS wrappers for Atomic) does is generate C wrappers for duktape. Because duktape also requires a clean c interface.

• josh offered to point the domain to my wordpress site i started ( @darrylryan )
• let's start with only this chat, the github issues and the forums, and a simple github pages website that's up to date and such
• atomicengine.ml is a bit extravagant don't you guys think?

• if we want a game to guide the development we should start with something that won't require other stuff like fbx/imgui/bgfx
• RPG
• Crafting
• making a shooter which is first/third person with vehicles traditionally covers a lot of ground
• zombies
• 3d arena shooter imho
• Rich destruction
• 2.5D sofa shooter game could be even better start as it is smaller scope
• i think team vs team games are good... counterstrike, tribes, battlefield etc, but combine that will ability to build bases and craft stuff, maybe resource gathering
• perhaps you first have to mine resources, build the bases etc before the match starts?
• we could very easily generate a ton of zombies with different clothes in fuse, make a big forest with alan imposters and some small towns
• implement basic shooter mechanics and melee, survival food/water crap, very easy to do
• but then we can it a step further and make it so you can gather materials and fortify your base, you can build fences, board up windows
• you can store food
• find a generator and hook it up and then you need to find fuel out of cars around etc. and you work together with other players to survive or fight rival groups
• the plus points of a zombie game: all the characters are human, so not much modelling needed, not a lot of particles, spells etc
• simple UI
• simple AI because they are MEANT to be dumb and walk into walls
• a zombie game, you can play alone vs the ai zombies, or with just 1 or 2 friends, or with 100 different people in several groups
• we can easily make tons of zombies out of Fuse
• easily make a selection of player characters, with different clothing options
• we can build a terrain with trees and grass with alanposters
• zombie ai can start very simple, just pathfind towards players when you see them or hear them within a radius/frustum
• simple fps controller and gun, melee just play a swing animation and put a collider on the end of the axe, let physics calc the hits
• but then we add some nice mechanics for survival... fixing generators, car engines, gathering food and fuel, boarding windows
• but as well as FPS against the other team, you also have to worry about food/water and the AI zombies all over
• i think a tribes style game could work

• Atomic is relatively high-maintenance, we were wondering if we have the manpower to continue the efforts.
• I personally don't really need a general-purpose engine like Atomic
• I think Atomic and maybe Urho too are just too ambitious
• they're too large to survive solely from the eventual contribution on GitHub
• especially without their lead devs
• some things which atomic/urho do better would be a wider scope of platforms
• I just want to target steam/PC so no biggie for me, others might want 2D/mobile/C# which I don't care for so much
• I feel like Atomic solved a lot of hypothetical problems, and very few actual problems
• too many solutions waiting for the problem, while some show stopping problems don't have solutions
• What are peoples intended use cases/problems they would like to solve with Atomic? Without answering that fundamental question (and now seems an appropriate time to ask it) - then people are just listing nice things. Commercial product development? Hobby dev? Mobile + PC? Big games/Small games
• to date there's not a single usable decent C# bindings for Urho, UrhoSharp has more holes than Atomic, and Atomic has some quite crazy stuff going on
• JS still has value for me, i can code and deploy to android with it, i cant do that with c#
• we are saying drop duktape, js and ts and the editor... and we dont understand the bindings system so we'll make a new one... and a new editor... and... pretty much every bit of it i think we feel we dont understand well enough, know how to fix, or have manpower to maintain
• well, im still unsure of what types of games this assembly would be good for. it sounds like 3d, and after that I dunno, but there are many now open source-ish engines out there and im assuming you'd want their users to come here.
• we were saying we need to strip down atomic and remove stuff that's too generic without a use case
• how the heck are we gonna fix the wrapper, fix the asset pipeline, implement a new editor and replace the renderer with a MT one
• gltf only support 4 bones per vertex afaik
• the future of atomic comes down to one thing can we get a wrapper that is maintainable maybe a good thing would be to wrap imgui... that would tell us if we can understand josh's wrapper, or if we can make autowig or swig do the same or, urhoui
• What does the community want in the end? What is it we want to provide? a soup to nuts game pipeline from code to deployment, with a feature game to show capabilities and test features, and for PR? Are we doing this for the game dev community as a whole? Is it customer focused or internally focused? What is the value proposition of our deliverables and who is the audience?
• personally i think optional subsystems for physics/ui/sound/etc could totally work, but if we rip current subsystems out then it will complicate importing changes from upstream
• "less programmer oriented" is a toy, not a tool

• merge the projects...? combine the community? (urho and atomic)
• i never saw the point in atomic doing 2d... there are a ton of good 2d engines
• put all our effort into one engine instead of 3, and pick the one which has an active lead, a modern renderer, and working
• come up with a value proposition, and stick with it going forward
• I don't care about 2D too
• make the tools do all the work as much as possible and keep the runtime minimal
• leverage the tooling to tighten the iteration cycles
• I want a node network that works as a dependency graph of jobs to throw at fibers :) and nest the node networks into bigger nodes that spits out .cpp code
• I do agree there's no need for 2D focus
• I think it's quite obvious what the community overall wants, I don't agree but it's certainly: Editor, Docs/Tuts, PBR w/ GI, and most importantly something that won't let you down midway
• I personally just want progress. No specific features
• it's not worth it to maintain the 2D stuff imho, at least not for a first version, we just need to produce something as usable as say unity 1.5 or something for a starter
• shaping the API around vulkan then emulating backwards I'd go with, but backwards being ES3.1 minimum spec which is roughly GL 4.
• cpp engine with cs tools & scripting
• I vote for C++ engine with C# tools and game logic
• cpp engine + a maintained c interface
• it seems we have a split, most want C# with a cpp core
• I think what we need is CPP core with a feature complete C# wrapper
• i think there is a a strong case put forward by some people to keep the cpp core
• let's go fully managed for the tools, but ability to write the games in CPP still
• 2D should go - its not particularly usable or well tooled, and its a different task to maintaining 3d really
• regarding 2d - i do not think it should be dropped. it is not focus - sure, let urho3d maintain it. or maybe someone interested in 2d will eventually come by and start contributing. i say consider removing it completely when it starts causing problems.
• we are gonna ditch 2d and duktape by consensus already i think
• let's also streamline the codebase so it doesn't take a ton of time to compile
• let's ditch the dependencies we don't need
• We need different people to take ownership of different bits
• 1. Atomic will be community managed by existing contributors, all having read/write access. 2) Different bits will be managed by different people e.g. Rokups handles PRs, Alan handles forums etc. 3) If we can't agree on stuff, we lock everyone in a room until someone turns into smoke 4) atomic will drop 2d and focus on 3D only 5) we'll drop duktape, JS/TS and the current editor 6) we'll make a new C# editor 7) there will be a collaborative 3D RPG which we all work on and that will set the focus of work on the engine itself imo we're just missing an answer to the UI question...
• i would even go as far as making build system painless and not providing binary builds to filter out wannabe noobs
• use cmake/git functionality to archive those bits of the engine we dont need in the core make the build faster and the download smaller
• so we're rather discussing just starting over, but in the model of atomic
• i've tried every open source engine from the whole of github, sourceforge, codeplex, google code, bitbucket and every other mofo out there and none of them are perfect but urho and lumix are the best imo
• noobs are not supported i would even go as far as not providing binary builds to filter them out but providing easy build process without hundred steps that just works
• if we can get autowig working i think most if not all dependencies should get wrapped
• an engine that is more advanced then the indie crowed but now as bulky and big as unreal and unity
• so our audience is 2D/3D/C++/C# WIN/LINUX/DROID folk as well as the casual JS netbook crowd?
• So I guess the aim of Atomic would be along those lines:
  • Not trying to compete with high-end engines
  • Not trying to cater for noob as a one button press engine
  • Trying to provide a good foundation for experienced folks to build a game upon.
• So in that grey area somewhere in between Godot and the like and Unity/Unreal/CE..
• I totally agree that we need to 'outsource' as much work as possible, but it's not worthy replacing some of the solid stuff we have in place
• Here are things we need to do:
  • research viability of autowig/other generator (before anything else)
  • implement a gltf importer to be used as the main/preferred format for meshes (maybe the only)
  • develop managed tools and editor in IMGUI
  • also docs

• Platforms: Windows first, Linux or Desktop Android sometime in the future. So right now xplat isn't a huge issue for us (though knowing it's possible/available when we need it is)
• We actively use the editor, and our artists have a laundry list of improvements they'd like for that. The biggest single issue there is really the importer, as mentioned above fbx importing is a real issue generally, not just for Atomic. We've discussed the possibility of getting Adobe's importer brought in.
• The build system is a focus for us, because automated builds of both the editor (dev and dist versions) and players are important to our productivity. I mentioned above that I'd like to see behavior between the dev and dist build processes be closer, and I'd prioritize that.
• Any work we do going forward would definitely be focused on C++ and C#, with the obvious exception of the editor (currently) being in JS/TS. Josh mentioned wanting to reimplement the editor in C# and it's something I'd like to see happen at some point.
• We agree with above sentiments about the renderer, and that replacing it with bgfx could be a big improvement
• I'd say a simple 3d modular engine that works as a template to build upon
• Mulit platform deployment actually brought me here, with the promise of an effective development pipeline
• my use case is a 3rd person multiplayer FPS, desktop and android
• heck, i don't even really need 3d, since my game is 2d, but 3d is fun!
• SDL support or decent enough multiplatform (windows/linux minimum), VR, very flexible graphics API, minimal DoD/C++11, RC++ and/or an easy autobinder, forward-thinking threading model to easily jobify things perhaps with ISPC, liberal license, solid DCC to engine pipeline, super fast/easy build system, modular with some ECS which makes it easy to do data-oriented design with (goes hand in hand with easier cache coherency and threading) flexible animation/cinematic system, IK, gpu-friendly blendshapes/deformers and/or an easy autobinder
• launch the runtime in another process and talk to it via a socket and use runtime compiled C++ to reload gameplay code and hot-reload of assets exported
• So - Is it this the right time to advocate for large world support?
• you guys seems to want c++, bgfx, imgui and a modern engine
• we're saying we want bgfx, imgui, a working extendable editor, cpp and c# support, terrain editor and tools etc. we want physx, we want sound, we want cross platform
• I vote for Urho+BGFX+.NET+IMGUI+EDITOR+FBX&GLTF, shortest path imho to have decent user-friendly fully featured 3d engine
• I'd say modernize the rendering but have intense effects optional
• I write 0D, 2D and 3D games in C++, JS and C#, and like to deploy on win/linux/android.
• I want to get cook some stuff to place on my CV and also produce something that is very comfortable to use and has components that fit very well together. Think engine-work-of-art. Urho/atomic already are most of that. Doing paid support for commercial customers is also a nice thought even if it is a long shot. I am also very anti-noob because focusing on them just drags whole thing down. I am especially talking about kind of noobs that make MMOs in js and are 15 year old. I could add I expect windows/Linux/Android support myself, macos/iOS aren't exactly optional for others too. Desktop is my primary focus, Android is second.
• better build system, better binding/wrapper generation system, editor and pipeline, bgfx, different UI system
• mainly a really tight asset pipeline with a flexible work flow that can deploy projects to multiple platforms
• we need something quick to compile and easy to contribute