Shipping to the "customers"

[okias]

Hey guys,

I know you perceive OpenAge like a code, where you can learn, design and play with new tech (well, it's not so new these days since time passed) but I was wondering, if it wouldn't make sense to release something, maybe not perfectly designed, but playable.

I already heard argument, that we can play AoE in wine, but I (and I believe so many people) would like to play some AoE in Linux with "pure Free software".

When I was writing Flatpak support for it, I was really hoping to play it at some point, but I'm little bit losing hope. Not asking for whole game, but at least some basic 1vs1 game, some stupid AI.. we have like Linux phones these days and it would be interesting to have at least few good games on them.

In case you don't planning to make at least some compromises, please at least provide ETA. If you cannot provide ETA, at least state, that waiting is futile (or you relying on someone stepping up and finishing it).

Thanks and good luck with coding.

[TheJJ]

hai! thank you for your patience :) don't loose hope, things will become better and better!
the problem is, creating a strategy game such as aoe is really not that easy, and we're all volunteers with other occupations (me for example currently doing my PhD). so people need a good motivation for this project. probably everyone sees that differently. if you just want to play aoe, you can use wine and be done.
so what's the point of openage? one of my motivations is to try to do things right, to build something cool, and not have some dumpster fire codebase with no flexibility and full of dirty hacks.
from that follows that the project needs a good foundation to run and develop the game, and that's what we've been doing since the start of the project, and plan on continuing, in the hope that it will pay off in two ways:
a) motivation: when you don't hate your codebase, you'll less likely give up, and
b) not building something obsolete because existing things are already better (which kinda leads back to a).

there have been many attempts on creating an open-source aoe, but so far not a single one remained alive until the delicate and nasty features were added properly, let alone a proper (modding) API. the "best" comparable project I know of is 0ad, developed since ~2001, and from their project you can estimate how much effort it is to create such a game.

for a volunteer project of high complexity, one of the things that help least is pressure, because giving in leads to the development process not being fun, or to messing up the codebase ("research grade code" due do deadline), so it's virtually impossible to name an ETA. I guess it's best to follow our status updates on reddit, and the pull requests.

so what can you do to accellerate our development? get involved! because that generates attention and leads to design decisions and code advancements, so we achieve the ultimate goal quicker: build an awesome game that is actually usable :)

[heinezen]

I guess I also can say something regarding this, since I'm in charge of implementing a bunch of the new changes.

The issue is not that we are still designing things. Everything we need to do is pretty much laid out in #1377 already. However, implementing these concepts requires time, energy and health which are not always as freely available as we would like. Working on openage sadly doesn't pay my bills :D Lack of motivation to finish the engine is not the issue.

The other thing is that AoE2 is one of the more complex RTS games which makes the "basic 1s1" game implementation harder than it seems at first. There are many interdependencies of game mechanics that we need to figure out and therefore, it's not really possible to give an ETA. Personally, I also think that a good foundation for the engine is necessary because it prevents sooooo much frustration in the long run.

So, are we actually working on finishing it? Yes, although more free time or manpower would help :)

[derneuere]

I have to side with @okias. The issue isn't the complexity, it's the big rewrite and not considering shipping things. You can implement new systems, and you also can improve a codebase while still shipping stuff. Not shipping stuff has negative downstream effects:

I do not know that the project exist / is active

I can only contribute to projects that I know exist. It is currently impossible to do any kind of outreach as you cannot show anything, which limits the amount of new people finding this project.

Non-working code is hard to understand

It is very hard to get into a software project, where you can't run the code. If I wanted to start to contribute, I would run the program and look for a small visual bug I can fix. If I can't do that, then I would maybe fix a unit test. But I can't do that in this project. That is the reason why most new contributors have been working on non-essential stuff like fixing bugs in the importer, because the importer still works.

The core part however is impenetrable. I can also not contribute to design decisions when I never worked with that system.

PRs do not get merged

Currently, it looks like you do not want to merge any core stuff from other people. There are multiple PRs outstanding, which are now open for over six years without any reason why they are not merged yet. There could be a reason for that, but from an outsider's perspective, it looks like there is a high chance that my feature would not get merged and my contributed time would be for nothing. I would guess the reason for that is also not shipping stuff, because there is no intention in adding awesome new features.

My feature never gets shipped

This is the issue @okias is having, as he spent time on a feature, and it never shipped. Even If I somehow found the project, understood how the non-functioning code is working, I successfully opened a PR, made all the necessary changes from the review and convinced you to merge it, then my code will still probably not ship, which sucks.

More big rewrites are likely to occur

Not shipping stuff leads to decisions which will make shipping impossible. If you do not prioritize shipping things, big rewrites are more likely to occur, because you won't consider the costs. This could kill the project, like it did with Netscape. The nyan and the curves migration could have been iterative, but instead it's a big rewrite, which broke the program for nearly two years now.

I am saying this not to drag you down, but because I like this project. I just wanted to outline the pain points with your approach.

[TheJJ]

I don't think this is a matter of picking "sides", but rather effectively finding ways on being more productive and successful in bringing this really complicated project into shape :)

The decision to remove the old engine code was hard, and it's definitively challenging to now prevent accidential project death like it happened to other projects. We're very much aware that the current git HEAD is not so useful right now, and this is definitely a pain point for us, too. But the alternatives we thought of (keeping the old stuff alive in the codebase, running both variants in parallel, staying with the old simulation approach, ...) were also blocking progress to wire together nyan, the new renderer, the gui and the new simulation. Our priority is to build a working minimal core now, and after that - so we hope - it'll be easier to contribute something meaningful 🐱
The project itself is inherently complicated, and many awesome contributions have been done in the past - the foundation they were built on was always kinda wobbly, and our building would collapse at one point or the other (scripting? networking? the interactive editor? having many units? implementing the game's tech upgrades properly? unit formations?) if we kept the fragile base code.

If you want to get involved, please come by in the chatroom, where we can interactively discuss our design decisions and the concrete problems we're facing!

[okias]

Devs, please don't take this as an offense (since it'll sound like one).
You did an excellent job coding OpenAGE. Still, this project will only ship if you change your attitude.
Here are a few ideas to improve:

1. setting reachable goals (within available times you have, which due to the last commit from October, is scarce, I assume)
2. Make advertisements for the project (to get more people to join your effort).