Current Project Status

Which race do you like most? What do you like - what you don't like? Discuss it here.
1 ... 78, 79, 80, 81, 82, 83, 84 ... 86
posted on May 24th, 2016, 10:37 pm
No kickstarter planned.
Or is it simply the case that due to personal and work life commitment the development work is a bit slow at the moment?

Our available free time to develop NX hasn't changed much from that developing Armada-FO. Sometimes more, sometimes less.
posted on May 24th, 2016, 10:39 pm
I can't speak for the devs, but the Axanar debacle has had a significant chilling effect on the crowdfunding of fan projects. Even projects that fans have happily funded before are not getting money.

And with today's announcement that Axanar are countersuing CBS and Paramount, despite the announcement that their lawsuit is "going away", that climate of uncertainty isn't going away any time soon.
posted on July 26th, 2016, 7:26 pm
Does FO Team still host game events?
posted on July 27th, 2016, 4:33 am
Even though we haven't seen much in the last few years, I'm well aware that there's lots of progress being made behind the scenes, and I want to thank all the developers, voice actors and artists for working so hard on the new version of Fleet Ops. Fleet Ops is probably my favourite strategy game of all time (though Civilization VI might have something to say about that), and definitely one of my favourite videogames, period. I never played Fleet Operations consistently enough to be great at it, but every game of Fleet Ops I've played online has been a good time. I'm really looking forward to Project NX. Keep up the good work!
posted on July 28th, 2016, 4:48 am
Thank you, we appreciate the support!
posted on October 19th, 2016, 7:18 am
I hope this isn't taken as to harsh as honestly I have held off on making this post for over 2 years.

As a long time fan and a developer I will say the lack of openness about the project especially in regards to the EZEngine is a bit concerning. I was excited at the prospect of the project moving in an opensource direction however their were some warning signs from the start. The use of a license that the license creators of which specifically do not recommend it for software was one. https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software The use of a closed access old style SVN was also concerning.

I bit my tongue and did not comment as I assumed this would change as the project became more mature but instead the website has not seen a milestone release in over 18 months and no merges into the github mirror in over 7 months. This has caused great concern for me.

I sincerely hope that this is simply due to busy work in the background, however I hope that at least the engine development if not also the NX development soon finds itself more in the open. We live in a golden age of opensource and collaboration tools available for free allowing many to contribute even in small ways to the advancement of large projects. Simple contributions to documentation and automated testing on platforms like Github.com or Gitlab.com can save massive amounts of time for core developers and be easy ways for those with little experience or time to contribute.

Thanks for your understand and all your hard work.
posted on October 19th, 2016, 7:29 am
Last edited by DOCa Cola on October 19th, 2016, 7:37 am, edited 1 time in total.
Reason: edit
Internal ez build had it's last code check in this morning at 1am
Internal FONX build last code check in was last Thursday and has some ongoing changes i haven't submitted yet.

However: As previously said, there is currently no source code release of FONX planned.

I am sure ezEngine will continue to push updates to their public repo. I assume they want to get a bigger chunk done before publishing it to their public site.

Edit: To clarify. I don't know what the ezEngine release plan for their milestones is, but i'll try to ping someone from ez to chime in.
posted on October 19th, 2016, 7:39 am
@DOCa Cola I am glad to hear that as I said I held off on even posting my concerns this long out of the assumption work was still happening. I understand your right and desire to keep NX closed source (though I do assert development would be faster if it where not)

Honestly it is pattern of development of EZ (and the licensing) that has me most concerned. I have watched the repo closely and when I see comments on issues that say "so far no one tried to do anything on Mac and Linux that required a window"

.... it is a bit of a concern in that virtually all large github projects do that kind of testing in travis on every commit. In large part because developers like me who aren't game developers want to help and go "Well I can't write game code but I can write a great Travis/Gitlab CI config" and help how they can.
posted on October 19th, 2016, 8:13 am
I know they have several virtual machines set up on a server that test each build on commit for every one of their target platforms. For almost every single feature or class a test unit in ez exists.

For FONX our priority is a Windows only release. At least for the first versions.
posted on October 19th, 2016, 1:09 pm
Hey corbo950

Regarding the license: We actually wanted to use a license that is as open as possible. Creative Commons seemed to be a good fit. Until now I was not aware that they actually discourage use for software projects, so thanks for pointing that out. We had already considered to maybe change it to MIT license, which is more common, but so far had no real reason to do so.

Regarding the progress: Our last public release was October 1st 2015, so pretty much a year ago. That was revision 1195, the latest revision from yesterday is 1932, so we had 863 check-ins over the last year. That's more than two commits every single day.

Now why isn't that public / open-source? Frankly, because making a release is a significant amount of work. We don't want to just work on a public repository, we prefer working internally through SVN and then push larger changes out in a polished state, otherwise people would have a broken code base most of the time. Before we release something, we basically stop working on features and focus only on bugfixing, adding tests and writing documentation. In the past this was a bit easier, because our features were smaller and more isolated, which made testing etc. easier. Now we are working on larger things, such as the whole rendering, where it is harder to test for correctness, simply because things tend to change every once in a while and writing an maintaining tests is much more complicated.

Previously it took me about 3 weeks from starting to work on a release till we could push it out. That's a lot of time, and we just feel that it is not worth it, as long as we still have enough things that are somewhere in the middle of development anyway.

"But when it's public, people can help out": Yeah, no. That's unfortunately a myth of open source development. Only because people CAN contribute doesn't mean there will magically be people who actually DO contribute. So far we had exactly one external person who wanted to contribute. And it's really hard for external people to get into this sort of development. Engine development in general is hard. Getting everything set up for the first time is often a bit tricky, even though we already try to make it as easy as possible. Therefore getting just one person up and running takes up a lot of MY time and I think people overestimate what they can help with when they are only superficially involved. So far we actually had much more success recruiting people that we know and see regularly and have quite high quality contributions from them.

At some point we will make a proper release again, but right now we don't see it as an important thing. The FO-NX team has direct access, they don't need this, and even though what you are saying makes sense in theory, in practice it would slow us down and probably not benefit us.

Personally I would like to be a bit more open about what's going on, but there are reasons why we currently hold back. One of those reasons is that development in ez does not translate directly to NX and people might confuse our progress with the NX progress. For instance I am currently working on a particle system and theoretically I could show some screenshots of crappy programmer's art, but we don't know whether NX would use that system at all, there might be reasons for them to use something else and we support their decisions to use whatever is best. Therefore talking too openly about ez development would do the NX guys a great disservice, so we prefer to rather shut up entirely.

Long story short, development is going very well on the ez side, but we can't talk for the NX team. If anyone feels he can actually help out with expertise that we might not have, just contact me directly. Right now I would say, if anyone has artistic skills to make 3D models, textures or sounds that we could use entirely freely (basically CC or MIT license), then that might help us, because one of our problems is, that we cannot test some of our features really well, because we have no good test content. For instance I could really use a few good textures for smoke and other particle effects, that I can check into our repository without worrying about copyright.
posted on October 19th, 2016, 8:39 pm
Thank you for your long well thought out response I will address each thing in turn:

Regarding the license: We actually wanted to use a license that is as open as possible. Creative Commons seemed to be a good fit. Until now I was not aware that they actually discourage use for software projects, so thanks for pointing that out. We had already considered to maybe change it to MIT license, which is more common, but so far had no real reason to do so.

Glad I could help

Regarding the progress: Our last public release was October 1st 2015, so pretty much a year ago. That was revision 1195, the latest revision from yesterday is 1932, so we had 863 check-ins over the last year. That's more than two commits every single day.

I am glad your work is going well

Now why isn't that public / open-source? Frankly, because making a release is a significant amount of work. We don't want to just work on a public repository, we prefer working internally through SVN and then push larger changes out in a polished state, otherwise people would have a broken code base most of the time. Before we release something, we basically stop working on features and focus only on bugfixing, adding tests and writing documentation. In the past this was a bit easier, because our features were smaller and more isolated, which made testing etc. easier. Now we are working on larger things, such as the whole rendering, where it is harder to test for correctness, simply because things tend to change every once in a while and writing an maintaining tests is much more complicated.

Previously it took me about 3 weeks from starting to work on a release till we could push it out. That's a lot of time, and we just feel that it is not worth it, as long as we still have enough things that are somewhere in the middle of development anyway.

"But when it's public, people can help out": Yeah, no. That's unfortunately a myth of open source development. Only because people CAN contribute doesn't mean there will magically be people who actually DO contribute. So far we had exactly one external person who wanted to contribute. And it's really hard for external people to get into this sort of development. Engine development in general is hard. Getting everything set up for the first time is often a bit tricky, even though we already try to make it as easy as possible. Therefore getting just one person up and running takes up a lot of MY time and I think people overestimate what they can help with when they are only superficially involved. So far we actually had much more success recruiting people that we know and see regularly and have quite high quality contributions from them.


At some point we will make a proper release again, but right now we don't see it as an important thing. The FO-NX team has direct access, they don't need this, and even though what you are saying makes sense in theory, in practice it would slow us down and probably not benefit us.

This infact is exactly my point as a member of the Node.js and Ember communities I can tell you this “myth” is false. It is simply a common misunderstanding that open governance and open-source are two different things. If you throw code over a wall every 3-6 months of course nobody wants to help. Your point about release is exactly where people not framilar with engine development could help. Most large open-source projects have run into these issues and they tend use a small core team with open planning of features. Things then inherently get more efficient as they remove barriers to allow others to help. Exactly because people like me don’t know that much about engine development, but we know a lot about unit testing, continuous integration and documentation. If these issues with release were in the open I am sure somebody like myself (or even I) would have written a build release script complete with auto generating markdown docs. As for this “otherwise people would have broken code” issue well A) anybody familiar with GitFlow/Github will not expect the master branch to be working all the time only tagged releases. B) thats exactly why people “superficially” involved in such projects they are great a small bug fixes, documentation, smoke testing and increasing development automation.

As for “won’t slow you down” here is an actual case study of an opensource project with far less barriers to contribution to yours before and after open governance. http://anandmanisankar.com/posts/nodejs-iojs-why-the-fork/
Sustainment of the contribution spike and increased release rate due to greater participation after the remerge of the two projects under the Node foundation can be seen on the Node.js git repo

I am sorry but that is the true myth and I can think of many other projects to cite as case studies if you need more evidence .NET Core of the top of my head. Microsoft has event chosen to manage one of their closed source projects "BashOnWindows" via github to allow the community to participate in suggestions and bug fixes.

Also one of Ember.js's core contributors did not even know how to program when he started making documentation contributions to the project. He just wanted to learn to code web apps. Now hundreds of developers who come to learn how to use the framework benefit from his contributions and he is writing core code and helping drive the ECMA spec forward.


Personally I would like to be a bit more open about what's going on, but there are reasons why we currently hold back. One of those reasons is that development in ez does not translate directly to NX and people might confuse our progress with the NX progress. For instance I am currently working on a particle system and theoretically I could show some screenshots of crappy programmer's art, but we don't know whether NX would use that system at all, there might be reasons for them to use something else and we support their decisions to use whatever is best. Therefore talking too openly about ez development would do the NX guys a great disservice, so we prefer to rather shut up entirely.

True this is why greater openess for Ezngine on a forum or github would be beneficial I chose to post here because of the lack of any sort of public presence anywhere else. Where features and issues not directly related to NX could be discussed.

Long story short, development is going very well on the ez side, but we can't talk for the NX team. If anyone feels he can actually help out with expertise that we might not have, just contact me directly. Right now I would say, if anyone has artistic skills to make 3D models, textures or sounds that we could use entirely freely (basically CC or MIT license), then that might help us, because one of our problems is, that we cannot test some of our features really well, because we have no good test content. For instance I could really use a few good textures for smoke and other particle effects, that I can check into our repository without worrying about copyright.



All I will say is I believe your pattern is why you don’t have good test content. If there was a public forum for discussion that could have been addressed long ago I am sure (just open an issue on github “Call for copyright free test content” and describe what you want). I will personally make sure some of my friends in the game industry get copied on it.

For a moment I would like to speak for myself personally. I have large experience in real time communication and high availability servers and could have and probably would have contributed in the flowing ways over the last year. However I suspected and now know for sure that your code base has diverged so much in the last 7 months any anything I had done most likely would have been useless to you due to my not having any knowledge of the current state of the project
1) Improve testing on a public CI/CD server (however the test harness does not appear to even be in the repo just the tests themselves)
2) Write a small sample game with CC licensed content … even just something as simple as checkers
3) Written and released app for matchmaking, chat along with a WebSocket based multiplayer for said small sample game. Not saying you would end up using it but a lot of time the benefit of open source is not core contributions or even contributions to the project itself. If somebody like me has already built a companion project for multiplayer features that could help in many ways
2 a) Adopted as a standard partner project
2 b) Adopted by NX or some other game built on the ezEngine
2 c) Used as a spike/stand in for either projects eventual implementation
2 d) Used as a talking point on how to or how NOT to build internal implementations.

If you do decide to open up more of the project I would be happy to help in setting up a gitter, opening and seeing through some github tasks like automated testing and release, triage github issues and comments (so they don't distract you), etc

However I firmly believe projects should ultimately be governed by their core contributors so just want to leave it as an open invitation. You are all also welcome to reach out to me if you have any questions about how Node for example manages these sort of issues. My github is [url]github.com/corbinu[/url]

In closing all I can do is implore you to learn from the many successful opensource projects on how to build a strong user/contributor base. I am not here to rag your team and felt I have said my piece. I do still believe ezEngine and NX will be great. I just also think they could come faster and better if some changes were made. If my advice is not accepted well it won't bother me I have plenty of great open source projects I can spend my time on (really into ESlint at the moment)
posted on October 19th, 2016, 10:14 pm
Thanks for that insightful post, I will have to discuss this with the rest of the team, I won't make any promises though, especially not short-term.
posted on October 20th, 2016, 7:53 pm
Here is a thought.

It makes sense that you don't want to divide your most productive coding time if the returns from outside coders will not be as valuable. Assistance from the community that requires you to train people from scratch won't shorten your development time, when what you really need are art assets and skillsets that aren't directly related to coding. If there isn't enough time to make public releases, maybe people from the community could help you with those?

If it isn't feasible for you to work on full releases, what about bringing on one of these community programmers, to have them periodically go through the code and if they find something interesting, post just that part of the code in a public SVN. You would never have to worry about the quality or prepare for a release, but still get other programmers interested in your work. Then when you need something they CAN provide, like some assets or a class from some open source library, you will already have the connections you need to find them quickly, similar to the in-person relationships you talked highly about in your post.
posted on December 15th, 2016, 10:45 pm
DOCa Cola: Sorry to keep posting here just not sure where else to.

Jan:
Something you guys might want to take a look at for EzEngine https://github.com/gamestdio/colyseus
It is a Node.js server for managing multiplayer games. It has a UnitySDK which I assume all you would need to do is port to C++ for EzEngine. It uses WebSockets with binary delta compressed JSON messages so should be extremely fast while still abstracting most of the hard parts of networking games.

If you go that way or even another way as long as it has a standard protocol I would be happy to write an Electron app that would make it easy to create/find/schedule games for multiplayer Just a thought.
posted on December 18th, 2016, 5:32 pm
Hi guys. I'm sorry for intruding on the conversation.

I'm the author of Colyseus and there's already some interest in the community to have a C++ client. (https://github.com/gamestdio/colyseus/issues/16)
I'm not a C++ expert, so if you guys are interested in helping me out with this, I'd be glad to contribute to it.

Cheers!
1 ... 78, 79, 80, 81, 82, 83, 84 ... 86
Reply

Who is online

Users browsing this forum: No registered users and 4 guests

cron