Always the Armory 0.x Version ... not really !?

I agree with @simonrazer about it not being ready for 1.0 yet. From a game standpoint, there is a lot that will throw people off and make them think that Armory is just bad because it is in 1.0 and they can’t get it to make a game yet.

Another reason is that 1.0 implies that the API is stable enough that your game won’t break from version 1.0 to 1.1, but every Armory release definitely has the potential to break games from the previous version, even though that should be much reduced after the jump to Blender 2.8 in Armory 0.6.

I do agree that, depending on the capacity that you use Armory in, it is a great platform for even production applications. It seems that some people have been able to do ArchViz with it, which is cool. @Didier it is really cool to see how well it has been working for you. Haxe, Armory, and logic nodes are so cool. :slight_smile:

2 Likes

@zicklag, effectively, keeping upward compatibility, and don’t throw people off is important.
On the other hand, it seems to me an important thing if this software increases its population of users and get more funds.

Not promising “the moon” as early as v1, but not getting tired of this software with too many V0s maybe could be too strategic for the future.

Being timid to switch to V1, it could exclude too potential users who could contribute to the subsequent faster growth of an open source software, due mainly to the size of the user population.

This reminds me of the long debates that existed on whether it is better to have an expensive embedded computer that has passed many tests,… and thus has few users, rather than a cheaper, less reliable and inexpensive one that has a large number of users. If you make some reliability calculations, you will see that quickly the less reliable calculator quickly takes over because being put in the hands of a large number of users, it generates more defect detections / field returns and finally becomes the best of both products.

Today leaders knows that speed and agility are the main keys for sucess and that actually we see that the @Lubos internal ressources are too limited and so that we don’t have the already expected V1.0. Thus users like @Simonrazer thinks that Armory is far beyond his normal expectations before to be in V1.0

Getting in V1.0 and leverage it to build community, respond kickly to issues, harness ressources and talent both inside and outside, inspire and motivate to act at different levels with accountability and maintain Armory at the cutting edge.

While I see your point, I don’t know that simply switching the version to 1.0 is going to bring in a lot more people that will contribute. While it might interest more people who are looking for a stable engine, I don’t know that it is any more likely to interest an adventurous dev who would want to help. I think we probably need more developers with time before we can adequately address the need of a larger user base with high expectations. Like you said, Lubos can’t do everything himself, but switching to 1.0 probably won’t help that. The people that will help are the people who are willing to put up with a non-1.0 product and contribute to it, not the people who are only going to try something if it is already in 1.0.

1 Like

@zicklag I think we share all an inkling of a desire to see an innovative, fast-moving and engaged community for Armory … and thus I think that staying too long in a draft version seems to be not desireable, as if Lubos wants to succeed, maybe it’s necessary to be in the future outside of a traditional comfort zone.

Disclaimer: My background is in building enthusiast communities which eventually help launch micro-startups, FOSS or otherwise. The following are my personal opinions, not those of any business that I’m associated with. Anyway, that out of the way, onto my long, opinionated, unedited rambly-rant… :popcorn::open_mouth:

Personally I agree that swift and agile are what are needed, which comes from a larger community of users, as long as that community has a realistic understanding of what they’ll find so they’re not disappointed. It also needs to be a community who contributes. This largely still comes back to making sure we find people who want what we already have or will have in the near future - ie an engine they can enjoy and influence with their contributions.

I agree with @zicklag that the version number isn’t the major thing that will make that happen. It’s about finding communities of people who would love what we have (or will in the next release or so).

I do feel that if the Armory fund were making more money (like 100%+ of the goal), that we’d be seeing more feature release tweets for Armory on the Armory3D twitter, rather than mainly retweets of the new stuff in ArmorPaint. After all, which is putting food on the table for Lubos? FOSS or not, a dev’s gotta eat and pay their bills…

Often though I feel like people make a false dichotomy between becoming popular and being stable / feature complete. Yes, exaggerating what Armory can do to reach people would just create jaded, disappointed ex-users who won’t try it again. That doesn’t mean that we shouldn’t try to reach many, many more people though, We should. Just limited to the people who’ll love Armory as it is. The people who Armory can give what they want, at a price they’re happy to pay. Note: by “what they want” I don’t just mean a list of technical features. I mean less tangible things like ease of use, a welcoming community, an easy path towards learning and then contributions, a sense of growth. By “price” I also don’t mean dollars. I’m talking about things like that the features missing are just ones they can live without, not deal breakers. Things like needing to help with bug reports and triaging if they want to see something work how they expect. Things like having to sometimes figure things out through experimentation because the docs are incomplete.

To the right user, we already have a lot that they’ll love and the downsides are just niggles not rage-quits.

Personally I LOVE how Armory is integrated into Blender. I ADORE the node logic system (while despising Godot’s “visual scripting” although I love many other things about the engine). The ease of which I can try an experiment and dig through Blender settings to see how to tweak it make me so happy, that when there’s a lack of documentation it’s still a joy to try and puzzle it out.

Other users will have different joys and pains, but the point remains that if we’re careful to mainly bring in the people who will find joy in Armory, like many of us already do now, then there’s really no problem with finding MORE people like us to help pay Lubos (and possibly even others) to give our favourite engine the love it deserves. Then as it gets better / more stable / more feature complete we communicate that with th wider community and bring those new groups of people in, as and when Armory is ready for them.

Communicating to those people though is more about hilighting what’s happening in our community rather than a version number. We need videos hilighting cool new stuff on BlenderNation, not a verion bump. We need release notes for 0.6 that we can share, rather than hype about being a “Unity-killer”. We need artists and programmers working together to make cool stuff with what we have, and people sharing that, rather than trying to chase the latest new feature from the popular engines.

Create. Communicate. Contribute.

That’s how we win. We create cool stuff. Communicate about it to people who would love what we have and then encourage contribution of all kinds at every level.

Then, even though we won’t have done any of it perfectly by a long shot… we’ll be ready for “1.0”.

PS (ok, a stable API/ABI here wouldn’t hurt here either! :stuck_out_tongue: )

3 Likes

@Armored_Blob Very well put! I think that what you have said is a good picture of what will make the Armory community. That attitude is what is going to help all of us make Armory and its community better.

I think that we have something very good here and even if it takes some time before everybody else sees it, I think it is going to be worth the wait. The spirit that we bring to the community now, when it is smaller, is going to make all the difference as the community grows.

1 Like

I definitely agree that we shouldn’t announce “1.0” yet. It is very much “still being developed,” in that some planned features don’t exist yet, and there are still hundreds of open tickets about those that do. All of which is really “par for the course” in an effort of this size and at this point in its … well … infancy.

I think that the product “is on everybody’s radar” now, though. It’s very obvious that “tight integration with Blender,” coupled with “the Haxe programming language,” is a one-two punch that will ensure success. Which means that the work has to be done thoroughly and well – most likely by a very small team of developers who really, really know their stuff.

4 Likes

@MikeRobinson, Maybe I’m wrong, but the “the work has to be done thoroughly and well – most likely by a very small team of developers who really, really know their stuff” don’t reflect a “Communities of passion” we have here, like with developers, but also game designer, artist, infographiste, modeler 3D, sound designer …

I think that contribution will matter more than credential, and thus for example, ideas must always compete on an equal footing and the coordination to suppress the big list of actual bugs that actually slow the Armory versionning and agility, must occur through collaboration and not centralization on a small team, and thus still with control achieved through transparency and peer feedback.

I think that @lubos is doing a really incredible and fantastic work as main single developer.
But in my opinion Armory is not ready for production for now to be a 1.x release.
And as Armory is based also on Blender 2.8 i would wait for Blender 2.8 ready for production too.
Another important step is reach the 100% of the Armory Fund.

After Blender 2.80 official release and 100% of Armory Fund i think would be different and better perspective for a path towards the 1.x release.

2 Likes

@AndreaMonzini Considering to be in a 1.x version, maybe like me and lot of others users, when a new version is coming, we try to be one of the first to download it and make comments on thoses new features on the forum … :sunglasses:

Thus how to stoke user’s passion, how to engage community-workforce and why everyone in this open-source adventure has to earn a level of influence throught merit, I think is at center of this debate about versionning.

Actually for me the challenge is that @Lubos seems too much alone, versionning is too long and community-workforce is not enough engaged.

IMHO I think it is tooo early to call Armory 1.x, Armory is at 0.7(just started) and I still don’t think it would another 3 versions to be called 1.x in fact, I think Armory will go over versions to be called 1.x for example, Armory could go 0.9, 0.10, 0.11,… (don’t get me wrong, I am not in anyway trying to say anything against Armory, i am just saying that it need lot of features and stability), just getting nodes and matrix to work doesn’t make armory 1.x, it cool that you aren’t facing any problems, but calling any product 1.x is lot more than that.

Calling Armory 1.x will generate lot of interest from lot of people and would set these people’s exception bars high, this people when come in and use it and would face problem and like mention above(rotations, graphics, physics, etc), and this would break their exceptions and people would start to whine that this and that is broken and would start to debate over why godot/unity/ue4 is way better than Armory, and as their exceptions is trampled over, these people would leave armory and chances are that these people could bring bad name to Armory. This is generally what happen when people exceptions are not met.
Versioning or whatever it maybe, should be displayed what it really.

So, to called Armory 1.x(to me at-least), it should have features that all game engines have in common and this feature should be stable, Armory’s graphics shouldn’t do parkour on different drivers/OS/Graphics cards, Armory should be able to export game to platform it features, should have docs ready on both making game and contributing to Armory

I’d just like to say that I’m really enjoying hearing everyone’s perspective on this. I’m also impressed that it’s all remained civil and constructive. Nice going everyone! This thread is a credit to this community.

@BlackGoku36 :passport_control: It’s also getting armature/bones, animation, mesh, parenting, shaders, UI 2D, iron.math, iron.object, kha to name only the main ones … but I agree with you that it essential things are missing like when you write “Armory’s graphics shouldn’t do parkour on different drivers/OS/Graphics cards, Armory should be able to export game to platform it features, should have docs ready on both making game and contributing to Armory”, last point particularly. So wait and see before the 1.0 if it’s better for as many people as possible.

Honestly, this is the easy part, once the other things you mentioned get taken care of.

@Armored_Blob It’s on my point of view “that actually for me the challenge is that @Lubos seems too much alone, versionning is too long and community-workforce is not enough engaged.”
Last point could be a great progress to avoid those pitfalls.

@Didier - Yeah, I couldn’t agree more on that point. We need an engaged community more than a single superstar developer (although both are nice to have).

My point was just that it’s much easier for someone to document a feature, than it is to code it in the first place. Granted, it would be very useful to have all the features we already have documented! :roll_eyes:

Yes, but you know, not everyone is programmer :wink:
@Armored_Blob, @Didier agreed documentations are easy to do, I would be more that happy to help, but the only thing is that I don’t how to document properly, where to put this document, etc

Me, too! :smiley:

Well, the obvious choice (to me, at least) would seem to be in the documentation section of Armory.org. My main concern about this is that, as far as I know, only Lubos can approve commits there and I’m guessing that he is probably overloaded already. My preference would be for someone, or some people, who can afford to be active daily, to be given privileges to accept commits on the docs and then to do documentation there.

Of course this all depends on @lubos agreeing, and actually giving permission to other people to help accepting commits. Until then…???

PS. Does anyone know how to check on GitHub who actually has the right to accept a merge to the docs? Maybe I’m incorrectly imagining that it’s just Lubos…

Yes, I know, i was more of asking like which section to put in, what goes in which section, how to properly do it, etc. :smiley:

Owner and member of repository/organization can merge commits, anyone outside it can only do PR. So yes, it just lubos

Well, i don’t think it would be easy for lubos to give access to anyone directly to repo, since anyone can push unwanted commit to it, tho IDK :man_shrugging:

Yeah, this is true. If someone pushes something they shouldn’t though, it can just be reverted and their privileges get taken away. It’s far easier to fix mistakes/issues than it is to make up for the community not contributing.

The alternative of having a single person be the choke point / bottleneck for a whole open source project just isn’t sustainable. I mean, Armory is still pretty small and we’re already hitting it now… You and I would both like to contribute to the docs @BlackGoku36, but it’s unclear if those contributions would get accepted in time to avoid becoming a mess of merge conflicts.

For example, while it’s not the docs, my pretty uncontroversial pull request to add more detail to the issue template has no merge conflicts. It’s still been sitting there without even a comment, unaccepted or rejected for over a month.

Don’t get me wrong. I’m extremely impressed and grateful for what Lubos has pulled off already. I’d just like for us all to be able to help.