Home | Documentation | Atomic Chat | Github

Heartfelt Request


#1

I’m sure a lot of folks would agree that there’s a steep learning-curve humped right smack at the front door to Atomic that is pretty hard to get past, especially given the current state of the documentation and Editor UI.

There’s one thing that I know would help me a lot while we’re waiting for things to flesh out more and that’s a ‘first steps’ video.

If someone out there with some real AGE savvy could make a screen video that demonstrates the following, I know it would be a big help to me, and I’m sure others too:

  1. Creating a new project, ideally set up to use an external editor or visual studio

  2. Import a textured 3D object in a popular metaformat (eg. FBX)

  3. Instance the object (textured) to the scene, attach a script to it and make a prefab then delete the object from the scene

  4. Create a ‘game controller’ script that does any boilerplate housekeeping typical in AGE games, calls an initialization function that instances the prefab created above once to the scene, then goes to a game loop and loops happily there

  5. Edit the script attached to the prefab created above so that it does something interesting in its game loop, such moving based on keystrokes and casting a ray to see if it’s about to collide with something

I get the impression that there may actually be examples of some/most of this stuff already out there on the AGE site. Thing is, I can’t find them. :wink: And besides, there’s much value to be derived from watching foundation stuff like this built from the ground up that can’t be had by parsing existing projects top down.

I know it’s a lot to ask, but the knowledge that you folks already familiar with AGE have, if shared in this simple way, could help us noobs, or at least this noob, immensely. I hope you can find that time to help. :slight_smile:

TIA!


#2

Take a look at the video “Atomic Game Engine - Editor Development Update” https://www.youtube.com/watch?v=XUPgj9Oh3dQ There are other videos available, but this one I’ve found to be helpful.


#3

Thanks, Jim!

That video includes many of the things I wanted to see in a ‘first steps’ video.


#4

Strangely enough I have always learned more from videos than wading through meaningless docs. Compare how many videos there are for Unity to Atomic and you will see what I mean.


#5

Yeah, we definitely need tutorials! I personally don’t like videos, I find them too slow and it’s hard to revisit some specific point. Even if I did I’m not qualified to produce them because I don’t speak German very well (non-native). I was planning to contribute with stuff like written tutorials and examples, but some things happened and I don’t have time recently. API documentation is mostly generated from in-code docs (comments), and while it’s definitely lacking, once you get used to how things work I don’t think it’s that big deal. Tutorials are much more important imho, plus, maintaining decent coding documentation is not easy and nobody likes it :P. Every place I look there are people complaining about the ‘documentation’ (or lack thereof), but I’m not 100% sure if they actually mean the coding/scripting documentation, which basically documents the API, or manuals and tutorials, which I guess are much more important for beginners than detailed API docs. We need however an action plan to improve that because from what I’ve seen it’s by far the No1 complaint.


#6

All good points.

Long-term aside, this one video would be a huge jump starter.

It doesn’t have to be slick. It doesn’t have to be perfect. It doesn’t have to be part of a series.

It just has to be. :wink:


#7

Yeah, well said. At some point we have to start collecting data from the users on how we can improve Atomic. I’ve no doubt tutorials will be 1st on the list by far.

I think @JoshEngebretson makes good video tutorials, clear voice and pronunciation, but as the main core dev I don’t think he has much time to do them. @dragonCASTjosh also have a couple of videos showing some stuff, but compared to the competition what we have is not significant. I’d rather have less content with better quality though instead lots of redundant stuff like Unity or Godot.

Since video tutorials apparently are huge these days, I’m curious on how @JoshEngebretson plan to tackle that. Maybe we could make written tutorials so the community can contribute, and once they are tested and approved somebody just record a video following it, I guess it would be much easier that way and perhaps @JoshEngebretson himself could do that or maybe hire a voice talent.

I think the priority at the moment is improving the editor and making it more usable. I personally don’t use the editor and I’m mostly interested in using Atomic as a replacement for XNA/from_scratch, and code-only tutorials are much better in written form. I was planning to reproduce the popular XNA tutorials so people could easily ‘migrate’ to Atomic, but unfortunately things didn’t work out and I don’t have the time now.

In my opinion the best thing we can do in terms of docs not only to increase our userbase but also to improve the API is to reproduce the XNA tutorials and the official Unity tutorials for Atomic. That would help new users tremendously and definitely help find omissions in the API, and would also have an extra appeal for users of these techs. While Atomic isn’t yet on Unity level, nothing keeps you from using it as a replacement for XNA, optionally taking advantage of the other tech it includes (like ECS/UI). It’s a pity there’s no complete tutorial for code-based workflows and Atomic isn’t as popular as it deserves, because since XNA was discontinued people started to migrate to fully featured engines (Unity/UE4/etc) or MonoGame, but both routes are far from ideal… still today people are making huge leaps to replace XNA, and Atomic could provide a decent solution to that, but not only they don’t know about it, but the lack of docs is also discouraging.


#8

Resources being super-limited, I agree that the UI needs attention first.

Back in 2005, I join the Unity beta and while the software wasn’t ready yet, the UI was already so good that I was able to make several cool proto-things that first afternoon. Nic Francis did a great job of borrowing, inventing and designing to get that Unity 1.0 Editor UI tip-top and it really paid off.

I hope AGE finds it’s Nic soon. :wink:


#9

So you’re a Mac user then? :stuck_out_tongue: I’ve started using Unity when it was released for Windows (2.5 I think), and although I jumped aboard later on the UI was already awesome. I could produce playable stuff on the very first week.

Problem is finding “Nic” on a zero budget :stuck_out_tongue: . I myself was planning to work part-time on Atomic but you know… it’s not communism over here, you need $ to survive :laughing:. If I ever make some money with this game I’m developing I’m going to do the next one in Atomic and I’ll surely contribute everything I can, including tutorials examples and docs.


#10

Well, I was a Mac user in 2005. :wink:

Actually, I’ve always been an OS omnivore.


#11

Well I used to do 3D modelling on an Amiga, and now I do 3D modelling in 3ds max on the pc.
Never really got on with linux until I got the Raspberry pi and now I am learning all the command line stuff.

When you are following a written tutorial and something goes wrong it is very difficult to understand why it isn’t working. When you are following a video and something goes wrong you can re-watch the video and find out where it went wrong.
When you follow text you are never quite sure if what you are doing is totally correct, but if you taken step by step through a video you know it is going to work because it works on the video, and it is not something you are doing wrong, but something you missed, and very often a re-watch will help you.

I think written documents are also important, but for beginners I choose videos every time.
I learnt to program in C on the Amiga because I had these huge books I bought before the internet. I learnt php,c++ from youtube LOL.


#12

Videos are a great jump-starter. They make terrible references but they’re ideal for imparting instant visual familiarity with a new subject.

And production values be damned. Quick and dirty walk-throughs with coughing and oops-es aplenty will be enough to get us noobs up to speed on the basic processes of using AGE.

BTW, those Amiga Technical Reference manuals were pure pain, weren’t they. :wink:


#13

The Amiga manuals were very big and heavy going, but they had all the information you ever needed. I think I would have learnt quicker with a good video however LOL.


#14

Where to start the grande project? Where is most interest?
Be it platform specific? Windows, OSX, Linux?
Scripting Language Specific? Javascript, Typescript, C#, C++?
2D or 3D ?
Atomic has it all, but one has to start somewhere.

And keep these tutorials and examples on the wiki ?


#15

My outline above is a good start for the content. Josh already has a great, albeit oldish, demo video that covers a lot of them (see above). The scripting side though is pretty much neglected.

Authoring platform shouldn’t matter for this tutorial video.

Output platform shouldn’t either.

JavaScript or Typescript are probably good bets on the scripting language.

And 3D not 2D. Definitely, 3D.

:wink:


#16

I would personally love to see tutorial videos. The best tutorials are probably short and specific feature driven, how to make a prefab is a good example. Longer deep dive can also be good, this is especially true for “code tutorials”

Videos can take a lot of work, I want to get setup here so it is a bit easier. That Xbox video hurt my back trying to get it all filmed, you need a comfortable setup!

I tend to make a couple practice runs and then quickly record takes until get one that is the “best” one. This only works for 2-3 minute videos, for longer videos good to record discrete sections and speed up and edit out parts. Another thing that can help for longer videos, is to get good takes of the showing, and then record the audio track after, doing both at same time can be a struggle. This probably all seems obvious, but hey, took me a bit to figure out :slight_smile:

Making tutorials also quickly exposes editor and API pain points, as does writing examples, and games, and apps, oh man! I also am a believer in the school of “you don’t really know something until you have successfully explained it to somebody else”, and this also flushes out “what was I thinking?!?!?” scenarios :rabbit:


#17

@marty I like the tutorial outline, maybe consider cutting a “Getting Starting with Atomic” series out of the sections. This breaks the project down into manageable chunks, can release videos individually as they are done, and then set them up as a playlist. If one video works better for you, that is cool too, maybe just make time markers for people to skip to bits they are interested in (or want to rewatch)


#18

I don’t know what statistics are being collected from users, but that’s definitely something to decide based on reliably collected data. (more on statistics below)

I’m with @marty… That shouldn’t matter imho, the tutorials shouldn’t be so specific to the point they won’t be useful for other platforms.

Yeah, that’s exactly what I was trying to say here:

What is your opinion on that @JoshEngebretson? I know copycatting stuff isn’t ideal but the XNA tutorials got a lot of our gamedev needs covered, and we don’t necessarily need to follow them closely, we could use the underlying architecture so the user already gets familiar to how things work in Atomic (scene/viewport/nodes/components/etc.). I was thinking these could be purely code driven tutorials (C#), maybe using the editor akin to the asset pipeline in XNA/MG. I think Atomic isn’t ready for us to reproduce some Unity tutorials since they rely too much on the editor, but the most code-heavy ones are already doable I think. Another thing we could provide, maybe in the wiki, is a ‘conversion table’ of Unity->Atomic API listing the Unity classes/methods and their equivalents in Atomic. I would be interested in contributing to something like that, but I really don’t have much time recently (I’m only active on Gitter because I use it on the move), so although I definitely can contribute sporadically I can’t promise consistent contributions… I’m not happy with my contributions so far… stuff assigned to me inactive for unreasonable amounts of time. I’m not doing a decent job :disappointed:.

Also, I know you’re collecting some statistics, but are you collecting something from the registered users already? Maybe it’s time to start gathering data from our userbase and/or potential users, I have no idea what programming language people are most interested on, I think (and hope :wink:) it’s C#, but guessing doesn’t help. Maybe something as simple as a twitter poll could shed some light on that, but it’s not easy to reliably get meaningful statistics from potential users, even a poll on the website because you never know what kind of visits you may get.


#19

@Alan I view examples, tutorials, docs, porting the same as code, follow the license and usage guidelines. If something doesn’t have a license or usage attached to it, only usable if the author can be contacted for permission, though even in this case good to get a standard license applied (MIT, Creative Commons, Public Domain, Share By Attribution, etc)


#20

@JoshEngebretson Well, as long as you’re not using copyrighted arts and porting complex code like algorithms I really don’t see what could go wrong. I’m not talking about a 1:1 port but just something following the same ‘pattern’, for example, ‘how to make a character controller’. Something we could perfectly say was ‘inspired by’ instead of ‘ported/copied from’ the source materials.

Anyway, do you have something in mind regarding tutorials? Maybe a road map or something. I really think that although the editor needs some work Atomic is already perfectly usable from scripting. I personally am quite satisfied with it as a XNA replacement for example. It needs some work to replace Unity for me but I’m pretty sure we’ll get there eventually, and even faster if in the mean time we attract some users interested primarily in a code-based workflow.