Home | Documentation | Atomic Chat | Github

Something like Playground Project - Viability, Interest, Planning


This is a topic that was discussed to some extent in other platforms but I feel this is the best place to talk about it.
This isn’t intended to yield short-term results at all.

What is the ‘Playground Project’?
Basically a bunch of Unity scripts to allow people to easily drag and drop them around to add some recurrent functionality to their projects. It includes art and stuff but the important part are the scripts and there’s always Kenney’s :laughing:. Apparently it’s progressing very slowly (what a surprise coming from Unity devs! :stuck_out_tongue_closed_eyes:) and so far there’s only one genre covered (2D physics platformer of kinds). And I’ve no idea if they’re stopping there (this is important info).

Advantages to the user:
Not reinventing the wheel. Having a decent underlying logical architecture that leverages the engine to production levels with carefully standardized and easily extensible components and world class mechanics, etc. In other words: InstaNoob2Pro.

Potential dealbreakers:
Needs a decent cross-language event system with inspector UI. Probably lots of other things I’m neglecting.

What are your opinions on the viability of having something like that for Atomic? Is the community strong enough to maintain it? Should we centralize everything or just congregate/curate (semi-)independent efforts?

The original Playground Project has a ‘masses’ appeal. The target audience is beginners with no programming experience. Even if we don’t want to appeal to that audience, we could still benefit from something along its lines I believe, but this is certainly something to be discussed… are we (the current community) interested in having something like that? Are potential future users actually interested? What impact can we expect?

Development plan:
First and foremost, we need to determine what genres are the most important so we tackle them first for extra ‘marketing’ appeal. We need to come up with top notch standards for stuff like scene queries, collision layers and masks, when to use physics triggers or casts, how to perform common global state changes, etc.

After we have some decent guidelines in place, creating the actual content is gonna be the real deal. I myself could provide scripts for a full 2D platformer (Mario style) after some months (4-6hr/week) starting possibly on Q2 or 3 2017.

Input! :smile:


I think the Atomic Examples repo is a good start to this. There are a variety of templates in there ranging from how to use specific engine features to complete games. For instance, see the Shooter example, Breakout example, Platformer example, and Atomic Blaster example.

I could see this being expanded with more content, but maybe that’s not what you are looking for. One caveat to this is that any contributions would need to be PR’d through github. Should the playground instead be something akin to a wiki or type of asset store where anyone can contribute examples? Should there be an Atomic Playground Contribution Template that contains a base project with some kind of manifest that people could build from and then upload or link somewhere? This approach could also be taken advantage of in the editor with some kind of import playground asset that could import the content into an existing project.

Anyway, I think this is an interesting train of thought. Let the ideas flow :slight_smile:


Yeah, these will end up being too project-dependent: it’s not easy to re-use components in different projects. Even a basic ‘movement’ script could be unportable if you’re using different approaches, for example physics in one project and directly manipulating transforms in another one. The idea is to have these scripts as portable as possible… but that’ll require some strict guidelines and won’t result in ideal solutions nor efficiency. I think we could think of them more like some kind of extended default components, for really basic functionality it’s very easy to make them, for example a ‘character controller’, problems start when you want to extend that even further for example to add movable platforms you need layers for detection. I think a good solution in this case is to have a field in the platform component where you can configure what layer/tag/something will activate it. And we do that until we cover a huge portion of some genre (so you can make say 90% of a classical platformer only by using the playground assets).

Yeah, that’s an option for sure.

Hmm… possibly. However, I think we should keep the scripts as autonomous as possible. Maybe we’ll need a small shared ‘API’ for the playground stuff that we encourage the contributors to stick with when possible, but overall I’m thinking about something really generic and with maximum re-usability. I don’t think we should expect massive contributions but small extra scripts to add functionality. Say for example we start with some components for a platformer, once we have something usable, it’s easy to add more components to allow the player to shoot stuff so we can make an action game while reusing all the characters logic originally intended for the platformer. To keep it very generic the shooting logic could be just a component that spawns objects which are configured with detect/ignore layers, etc. this is when things get substantially harder to decide…

A bullet object could be composed of a ‘raytracer’ component that traces rays from the last stored to the current position of the transform and with configurable events for when it hits different layers or tags. You then link these events to maybe a ‘decal applier’ component when it hits the ‘scenario’ layer and to a ‘damage applier’ component when it hits the ‘enemies’ layers… possibly these events could pass the raycast result data so we don’t have to cast again. That way you could have bullets that are translated using either the physics engine (so you apply an initial velocity), or by manipulating the transforms directly, in which case you’d need another ‘translator’ component in the bullet. You’ll also want a component to destroy the bullet after some time in case it never hits anything. That’s a lot of components for a bullet though :stuck_out_tongue:. Alternatively we could have a single bullet component with booleans for various configurations and centralized logic, but a problem that comes to my mind in this case is a technical difficulty: I don’t think we’ll ever be able to extend logic in another languages: we can’t subclass a JS object in C# for example, so we’ll have to make sure to cover that in the guidelines, for example when the logic gets too complex, it’s better to split them in separated components and use events for communication because that way you can ‘compose’ objects using separated components in different languages.

Overall, I think something like this is also a good opportunity to improve the API, if we come across a function that we recurrently need in the components, possibly it’s a great candidate to extend the core API.


this wood be awesome, we need this!