How to test on other non windows platforms?

Hi all

I am working on a horror game, who isn’t right? and wonder how I can create a test build, say for Linux and Mac, and test them even though I don’t have either OS?

I assume for Linux I can install Ubuntu for example, make a Linux build of my game and test it in Ubuntu?
As for a IOS build, how could I test my game?

Thanks!

Short answer get a system with the OS on it, if you want to release a game for an operating system you have to test it on a real system, not an emulated one.

1 Like

Okay, thanks

You can always borrow of a friend! :slight_smile:

true

Or ask for a beta tester that has the platform. Many volunteers will step forward. If you don’t use platform specific subsystems like DX11 it should be good to go.

That’s an great idea! It will probably be the route I will take.

Make a beta tester checklist you want them to test out and score/evaluate and tell them to press every button/key/mouse/joystock and stress test the heck out of it.

It’s not a thing you can do. It’s a thing you absolutely should do. The problem with beta-testers is that there’s a whole lot of overhead due to communication and management involved in working with them. On top of that, they’re no replacement for local testing.
If there’s some issue only on iOS, how are you going to fix it? By randomly changing “something” and hoping that it works “somehow”? You absolutely need local installations for development purposes.
On top of that, miscommunication will always be an issue with them. How they describe something and what really happened™, tend to be two things.

If you don’t own a Mac, don’t support OSX.
If you don’t own an iPhone or iPad, don’t support iOS.
If you don’t own a Windows Phone, don’t support Windows Phone.
If you don’t own an Android device, don’t support Android.

It’s that easy. Supporting these platforms despite not having any means of developing on them is irresponsible.

You get 2 platforms essentially for free.

  1. Either Windows or OSX (whatever you run Unity on)
  2. Linux (because it’s literally free)

Everything else requires some form of initial investment.

1 Like

I know it sucks, but it’s true. Before lamenting that having all of those things costs a lot of money, consider the amount of effort it takes to build and support something for so many different devices. Don’t spread yourself too thin. It’s better to have good support for one or two than half-baked support for many.

If you’re a hobbyist, stick to supporting what you’ve got. If you’re a professional, make sure you personally have direct access to every platform you’re going to support.

2 Likes

If yer doing the desktop platforms and not the mobile then generally unless you are accessing the more esoteric sides of the OS equations then it should work in 99.9% of the cases. Linux I cannot comment on having never used it but like has been pointed out…you can dual boot from either PC or OS X machines. Just get 'er done…get someone with the desktop platform you do not have currently to run it through a beta test series and if they do not have any show stoppers or functionality askew… release it…when you get the cash back from your efforts step up the pro regime and buy yourself the appropriate platforms you want to release to for further development. Don’t let the “you gotta” strictures bandied about hold you back or you could vacillate for years.

This.
If you can’t afford development devices, support less platforms first and buy others from the money you made from your initial platforms. Alternatively, go to work and buy them right away.

Demanding money for a version of your game you have not and will not test, is highly unethical.

1 Like

This is definitely one possible approach, but consider how long it takes to squash “release only” or “device only” bugs even when you can deploy to the device yourself. The other day I spent an hour just getting something to the point where I could start debugging it, for one platform, where I have the device sitting on my desk and am motivated to fix the issue. From there I’ll have to make several more deployments where I’ll want to (at least) have detailed access to log data.

Admittedly, this is all because I’m using a platform-specific library that only runs on the target device. Unity does a brilliant job of making almost everything else nice and painless. With a bit of design consideration in advance I have indeed had many projects which could be ported from one platform to another just by selecting a different target and clicking “Build and run”. The point is, though, that if you’re getting someone to test on your behalf all they can really do is confirm that something does or doesn’t work. Once any non-trivial issue is identified you’ll really want access to the device yourself. It’s not impossible to succeed without the device, but I suggest that spending money on the device is a far better investment than continuing to spend your time (and the patience of your testers) on long and indirect test cycles.

That is kinda the point. It in the first stages of a business often 20 bucks is the difference between that new asset plug or eating that day. In this case the business decision to do as i stated is perfectly sane. In the case that there is money there then of course purchase the targeted platform. In this case the OP seemed to be focused on desktop… and money did seem to be an object of delay… or why the question…here the interoperability of the OS’es is generally in the 99% plus bracket if DX11 is not used to make the build/shaders on PC and expecting it to just work the same on OS X. Linux I don’t know about DX11 interoperability and whether the Linux community made drivers or emulators. Even the big boys…see Assassin’s creed as an example…released and then went about bug fixing. So…to err in this manner is not particularly catastrophic. If a platform beta tester…on desktop…can open and stress test and play the game to conclusion you have a fairly safe bet you can ride the release and pick up the targeted desktop not in the arsenal to deal with what seems to be the standard round of fixes from the small portion of users getting glitches. Now devices…phones & tablets…yes…a wise choice to get the device to test on…or the various game consoles…yes…of course…again desktop… Yer fairly good to go with a stress test and button mashing to break the build beta test approach.

1 Like

Linux, just like OSX, uses OpenGL. At the moment all the DX11 features are Windows-only. The reason for this is not that OpenGL is inferior to DX feature-wise, but that the Unity developers have neglected their OGL renderer for a very long time. It was stuck at 2.1 (iirc), which is about the same as DX9. I say ‘was’, because they are working on a brand-new OGL renderer.
If you look at the roadmap, you’ll see that Unity 5.3 is not only supposed to bring us DX12, but also OGL 4.x (which is the OGL equivalent to DX11).
So this problem will solve itself later this year.

As for DX12 I have to say that I frankly don’t give a shit. I’m more excited for Vulkan, because it’s cross-platform. I wonder if Unity will get Vulkan support…

Whoa, I have to stop you there.
This will easily break the neck of your business. Firstly, the launch of AssCreed Unity was a PR disaster of such enormous proportions, it caused Ubisoft’s stock prices to drop. Secondly, the only reason publishers/developers were able to get away with such practices in the past, was the lack of refunds on Steam.
To put it bluntly: Your customers are no longer required to keep your shit. They can and will request refunds and they are likely to get them.
Just look at the newest Batman game. The PC version launched in a state that’s no better than what AssCreed Unity launched in. The only difference is that we now have Steam refunds. What happened?
Within a couple of days the publisher suspended the sales and the game will launch properly at a later point.

As a small developer, you typically don’t have those reserves when it comes to money. When your game is broken, your customers can get their money back with just a few clicks. Given that you don’t have millions and millions of dollars to spare for marketing, the chances of those customers coming back after you’ve fixed your game are rather low.
If you take quality assurance lightly, not only will you ruin your reputation, you’ll also lower your chances of making enough money.

Conveniently ignore the stress testing part. I doubt the OP’s game is a complex as the new Batman or Assassin’s Creed. I still disagree with your assessment for a one man dev team just starting out. Your advice is to waste time getting his product to pay him any kind of return whilst he saves cash and then gets another desktop computer to do what a beta tester could do in it’s stead… If the app/game is stress tested and button mashing tested on desktop PC or OS X it will most probably work on the other desktop platform. Six years of experience tells me this is most definitively the case and I ain’t talking though my hat. If a beta tester can ram it through every set of button mashes and nothing awry happens they will not ruin their at that point non existent reputation. There is a time and place for anal retentive by the book rule following and there is a time for considered fly by the seat of your pants methodology. It has nothing to do with not caring about quality assure as you so slyly imply to bolster your view.

Isn’t this an oxymoron? If you’re making it up on the fly then how is it also a “considered methodology”.

“Beta testing” and “QA” are really different things. For starters, most beta testers probably aren’t considering things like test coverage. That’s not their job. That’s the QA team’s job. Getting a “beta tester” to “button mash” is at best a part of a thorough QA cycle. And if you’re asking people to pay for something then you really should be doing an appropriate level of QA. What the above post is suggesting, though, is to QA on one platform and then just cross your fingers and hope it works on others.

Remember that the point of QA is to uncover unforseen issues. After all, your developers probably already addressed all of the ones they could predict. So the mere fact that you don’t think there will be issues on other platforms really isn’t enough to be confident that there won’t be.

Plus, what happens if people do find an issue on a platform you can’t personally support after your “button mashing” fails to pick it up? Personally I’d feel obligated to fix it, since I’d charged people for it, but I wouldn’t be equipped to do so.

1 Like

Metaphors are often oxymoronic in appearance but studied appraisal of their contextual format shows them to be coherent. And making it up on the fly is not the same as flying by the seat of your pants…i.e. ->instinctual knowledge.

Really folks. I have worked on OS X and Unity for six years and provided a couple of dozen desktop systems for PC clients with NO QA or beta testing on PC at all and have not had one issue arise from platform differences. Unity does a fine job of taking care of that as evidenced by their public releases and my six years of beta list emails in my mailbox. That is what experience tells me and I am relaying. So…blow all the procedural smoke and pretend to other issues as though I am saying just go rip folks off. I find it quite disengenuous and mildly insulting. To the OP… go make some money with your game if it works and deal with the platform issue when you have cash. No sense starving whilst some anal retentive game devs dance around the rosemary bush and imply that such amounts to thievery. It doesn’t. It is called good business sense for a struggling to establish itself business where further delays can result in a job flipping hamburgers…or pawning the only platform you have to eat.