When do Mac users get a build?


#61

Please note: This is not my opinion, this is the flagship feature of Unity.

They’re obviously competent software authors, and I love their past works. It’s also obvious that they misunderstood Unity and could benefit from some help. Not knowing how to fully utilize your development environment !== incompetence.

That’s my whole point. None of that work would exist if Unity was set up correctly. In Unity, you build one cohesive project and write abstractions/special cases to handle the differences between platforms that aren’t handled by Unity. Instead it is 3 similar projects where they have to do work over and over again.


#62

None of what work? They’re building an older branch (the pre-alpha) for a platform it wasn’t previously built for. The abstractions/special cases had not been implemented in that branch yet - my understanding is that they are then cross referencing any problems this throws up with the latest branch/commit to see if they have already solved this problem there or if this is something specific to the pre-alpha that is not required in the latest branch. This is not describing a scenarios where there are 3 separate projects.

Now I may be misinterpreting what has been said (let’s face it we’ve hardly got much detail to go on) but I think you are jumping to a negative conclusion that is not necessarily true.


#63

There really shouldn’t be linux/OSX/Windows branches.

To give an grossly simplified example, consider this:

You want an orb to appear, so you make an OrbObject that has all of the code of what it means to be an orb. Now you want to display that orb on Windows, OSX and Linux machines. You write 3 renderers which hold the logic of how to display an object on each platform. You tell Unity that when compiling for Windows, use the WindowsSceneRenderer, and so on for the other platforms. Now when you want that orb to handle changing colors, you can write that into the OrbObject. You want that orb to interact with another orb? Extend the OrbObject.

Instead, what they appear to be doing is writing 3 OrbObjects. 1 OrbObject for each platform. When they find a bug in a function of the orb, they have to manually reconcile against the other 2 OrbObjects. They still have to write the 3 renderers, one for each platform.


#64

I work in cross platform software development, I understand the problem.

Perhaps I’m not explaining it clearly (and again perhaps I’m wrong in my interpretation of what Otherside are doing here). There is one code base. Over time various branches have been created for adding features, fixing bugs, preparing releases etc. Depending on their Dev approach old branches may be deleted as they are either merged into the master or otherwise determined to be no longer required - or they may maintain some older branches. I believe the branch that held the pre-alpha code was one such old branch that was maintained (or at least a tag to that commit).

As they have been encouraged to provide a release of the pre-alpha for both Mac and Linux platforms the team have returned to that branch (on the single project) and have been performing a build, test, and bug fix cycle for that branch on those platforms. In doing so they will have been adding the platform specific code required for the game to run on those platforms alongside the windows code. In parallel to this the team have been continuing to develop the alpha code, which will (hopefully) have been having the Mac and Linux code added at the same time (or as near as possible) as the Windows code, such that any future releases should be possible simultaneously across each platform from their single project.


#65

I sincerely hope that my understanding of sluangkhot’s post is wrong and that the workflow you mentioned is more in-line with reality. Reading, and re-reading the posts, my assessment remains unchanged. I don’t get the sense that these are issues are limited to back-porting the pre-alpha but are a generalized explanation of their build process. Communicating is hard.


#66

smpita…yes, communicating is hard. That is why it is generally advised to establish reasonable doubt before forming conclusions, and then rationalising them backwards to justify as certain (accusatory) tone.

Plenty of us have hard had some quite harsh things to say over thelast couple of years, but that’s usually on the back of dev-announcements or concrete omissions to specifically-asked questions, and (okay, yes) deadlines, not suppositions. Id include lack of comms in that, to be fair.

As to the meat of it…I hear (perhaps justified) frustration…but remember that this project has lagged and jostled in any number of areas, not just this area. I used to over-see cross-platform testing, and solitary branch-builds are entirely possible,as testbeds for instance…and don’t cancel out either a central trunk build and general compiler, or indicate a methodology. Possible, yes, but we don’t know here.

We do know, though, that they’ve had their hands full pretty much since day one, and seem to be in permanent jugle-mode. I’d wait for a solid response regarding this testing-build-separate-thread thing before construing anything. God knows we’ve all played the waiting game on any number of fronts.And they’ve mostly come up up trumps (orequivalent…). I understand it’s a more fundamental for you, but hey.

If I was told my entire process was ignorant crap, I’d probably think twice before providing reasonable info, too…?


#67

These concerns were in my mind prior to starting this thread, and may have biased my comments since the thread’s inception. Otherside kept relatively silent about OSX/Linux development. I stayed silent until the pre-alpha was released. Fearing they were writing themselves into a hole of extra work, I started this thread. I was correct that they hadn’t started multi-platform development. They also stated that they were planning to wait until the Windows build was complete before beginning to “port” to the other platforms, suggesting a lack of insight into Unity design philosophy.

This is why I don’t want them repeating work. I only became vocal about these concerns after I saw another big red flag.

If my understanding of their process is correct, then it is not in-line with core development philosophy of Unity. This would be detrimental, compounding their permanent juggle mode.

When I am told that my process is wrong, which does happen, I review the allegations and my processes. It’s hard to see the forest from the trees and the person calling me out may be seeing something I missed.


#68

Again, though: why start from an assumption – and that is the strongest thing any of us out here can possibly have – that professionals are doing a dumb thing through ignorance?

Assuming incompetence (and that is what happened here) is not just a bad idea in that you may be wrong on a specific question. And it’s not just a bad idea in the more general sense that you could simply request more information so that you don’t have to level a criticism based on nothing more than assumptions.

It’s a bad idea in that it’s rude. This is the sort of behavior I find frustrating as a project lead because it needlessly screws up group dynamics when someone cops this attitude, talking down to experienced professionals. I have to waste my time unruffling feathers instead of on productive tasks.

That’s not my role here, and I’m not trying to do it for OtherSide; they don’t need me or anyone else to white knight for them. I’m trying to explain that seeing this assume-and-accuse thing done to anyone rubs me the wrong way because it is so unnecessary when you could just ask politely for more information.

Is there something wrong with that approach?


#69

I can admit that my post was unnecessarily aggressive. I’m sorry that jumped to conclusions based on speculation through sparse details. I was wrong to assume. I was wrong to be reactionary and should have thought out my choice of words more carefully.

It’s clear that they are all working hard and capable in their fields. My message was intended to be one of concern over the health of the project and perhaps reduce the amount of labor they had to put into it.


#70

There’s obviously nothing wrong with having concerns and sharing those here, but yeah it’s important to think about the way we communicate those concerns.

Similarly an important factor is whether or not we have enough information from Otherside to actually say “you’re doing it wrong”, or “this approach/design/mechanic sounds bad”. How much info we each need before we believe we are at the tipping point in that equation is going to differ from person to person but I think over the years we as a collective have been somewhat guilty on this forum of slamming some of the info we see coming from Otherside before really understand the context or getting the full picture.

That’s not to say that challenging voices aren’t important, steel is forged in fire and all that, but striking a balance is important. I guess we all care so much about the franchise, the team, and the hopes of the genre that it’s easy to get a bit hot under the collar about things!


#71

While it isn’t necessary, it’s certainly a valid approach in some situations and it doesn’t mean there’s three ‘entirely separate’ code bases (which I agree would be the wrong approach).

Where I work we’re encouraged to create a branch for every major feature as well as just for each public release. It seems from reading your comments that you interpret a branch as somehow throwing away the previous code, this is opposite of what happens - you keep all the existing code and then add your changes.

Branches allow you to isolate a set of changes so that you can work on them without having to deal with problems due to other features in development (and so you know that if something in your branch is broken it’s you that’s broken it). In the normal course of things once a feature is complete it will get merged into trunk, feature branches periodically pull changes from trunk to add the new complete features.

This is an ideal world description of course, sometimes stuff happens or deadlines approach and some compromises have to be made in terms of keeping trunk or your feature branches clean.


#72

Oh gosh, sorry for the ambiguity everyone! And smpita, we don’t feel your assumption was out of line. To clarify on the situation, Jenuall was correct:

To give some insight into “why wasn’t porting made a priority earlier,” (which is extremely valuable to do), a big part of that was time (and money) constraints. Recall the end of the Kickstarter, back in 2015/2016, and how we were running off of mainly KS money and private investments without a publisher. We wanted to build our systems and important content as quickly as possible, which at the time meant focusing on one platform. Similarly, when hitting publisher milestones, the requirement is to make sure we have one build that’s playable and exhibits all of the criteria we need to hit for that milestone. (ex: All of the main characters are in,at least 3 levels are finished and 5 more are in draft, etc).

We make a new branch for every major milestone, and the (Windows) pre-alpha has been on a standalone branch ever since we pushed it. Since then, back on the main branch, we’d add new features and mechanics, and hammer out bugs accordingly. Now, when we return to the (Windows) pre-alpha branch in order to make a Mac and Linux build, we have to keep in mind that some bugs that are present in this pre-alpha branch have already been addressed in the main branch. Additionally, if there are any errors that run while trying to build the Mac and Linux on the pre-alpha branch, we make a note of the fix and duplicate it for the main branch so that when we make the next milestone (Alpha), it will be as up-to-date and Mac/Linux-compatible as we’re aware it can.

I agree that it would have been easier if we were keeping the Mac and Linux ports in mind throughout development. However, we most likely would have run into this problem either way, in order to make sure things work. Since we’re still in Alpha, there’s bugs and all kinds of systems still being worked out, so it doesn’t make sense to fix certain bugs in a Mac and Linux port if we’re not even sure it will survive to the next Windows build tomorrow. As a result, we generally do a lot of work in the Windows version, and then near the end of a milestone, we go back to porting to Mac and Linux so it’s up to date. I hope this makes sense!

Speaking of which, we’re getting closer with the Mac build again. There’s still some startup problems (?), but because we have more eyes on it, Will and I have been able to give it more attention than usual.


#73

On the contrary, the only isolate the changes from the start of the branch, not considering branch mergers. But they are doing a lot of manual work reconciling code between branches? Why would you go through that pain unless you’re not planning to merge? What are these branches for? Oh, the changes to support alternate OSes?

I also failed to understand that this only applied to back porting the pre-alpha. It sounded like this was their approach moving forward through the project, keeping the branches isolated as forks.


#74

The separate branch is because the Windows pre-alpha is currently “live” on Steam right now.

If we didn’t make a separate branch, then you would all be seeing our daily builds on Steam :stuck_out_tongue:


#75

I’m ok with this.


#76

Interesting that you bring that up, because normally Windows-only games don’t show an “Install” button on macOS or Linux, but the Pre-Alpha does. It doesn’t install anything and after a 0 byte installation it shows a “Play” button, but complains about the missing executable, BTW the Windows-only .exe file…

[Update]
So what exactly is the problem of making this already existing branch include the macOS and Linux builds? Wouldn’t it be possible to tell the build process to keep the Windows binaries as-is and only add the other platforms?
[/Update]


#77

This is what they are addressing and in the process of fixing. They are in the process of building the alternate OS binaries. There’s no point updating the steam installation until there is something to install. As far we’ve been told, neither Linux or Mac are boot capable. That also implies that neither OS has seen any play testing, which could reveal more bugs. They may or may not take the time to squash some of those bugs before calling their Pre-alpha ready to publish. I don’t quite understand the way they are abstracting their concerns, so it’s hard for me to comment on the state of their Alpha branches. I assume they are not boot ready or play tested either.

The time table largely depends on how they allocate their time between furthering their master branch, furthering their alternate OS branches, and other time demands.


#78

I think it was prior to having a publisher they said they already had out-of-house testing facilities. I’d imagine that the publisher has its own in-house testing hurdles to clear, so any final build should in theory be handed off for multi-OS testing to more than one department (not including Unity themselves, of course).

So that should mean quite a lot of nit-combing on a common final build. The devs have also said they welcome help from here.

I think time - not inclination - is the only issue.


#79

Okay, I do understand all this for the Pre-Alpha. This was meant to be Windows-only. But now, as it seems, they are incorporating multi-platform into their main development branch. Which is IMHO a good idea.
Yet, two things come to my mind.

First, I ask myself, why put effort in porting the old Pre-Alpha to Mac and Linux anyway? Is this worth the effort? I use Linux as my primary gaming machine and I love how well Wolfenstein II and Bioshock Infinite run on Linux with the open-source amdgpu drivers. But even I don’t mind if I won’t see the Pre-Alpha on Linux. What I want to see is the Alpha and the Beta, as well as the final game, on Linux. And, yes, on the Mac as well. (I personally don’t have a Mac capable i.e. performant enough for the game… :’( )

Second, and this is mainly addressed to the developers… hardcore coders to be more precise… Sometimes small optimizations make the difference. I think we all remember what Valve did back in 2012 with their Source engine. No? Read here, here and here. @Otherside: When you do your port, make sure you do it wholeheartedly.

The performance optimizations are of course most important for the final release version. But it wouldn’t hurt for the Alpha and Beta versions if they did’t suck performance-wise as well… :wink:

Thanks.


#80

Us porting the pre-alpha build will, at the very least, help us start making preparations to build the main branch’s Alpha port for Mac and Linux. Plus, it’s still a promise we made to backers, and we wanna follow through. (Unless the majority of you Mac and Linux users would rather us not publish the pre-alpha and only publish the Alpha?)