Releasing on Steam and Xbox - Questions...
If you are releasing on both Steam and Xbox do you have two separate code bases (i.e. one for Steam and one for Xbox) with the specific platform features in it or is it worth trying to have flags that set what features are available and use only one code base.
The other option I am looking at is a generic node where I want to unlock achievements and stuff in my my master branch and then a xbox and steam branch that is created from those where I then put the specific Steam or Xbox nodes in.
Are either of these viable options or is there another way to do this?
The other option I am looking at is a generic node where I want to unlock achievements and stuff in my my master branch and then a xbox and steam branch that is created from those where I then put the specific Steam or Xbox nodes in.
Are either of these viable options or is there another way to do this?
Comments
You can then either:
1) Wrap those classes in platform specific defines (#if UNITY_XBOX) or
2) You can use Unity's Assembly Definition files to keep certain code in different assemblies (libraries) and specify which libraries will be included for which platform.
I prefer the latter, but I understand how some may find the former to be simpler.
You then need to tell your code on application startup which class should be associated with the interface. Basically telling your code that when something looks for an IAchievementUnlocker, it specifically wants an XboxAchievementUnlocker. You could try and do this "manually" with something you roll yourself, but IOC is perfect for this, and TinyIOC is a really nice lightweight and easy to use library for the purpose. https://github.com/grumpydev/TinyIoC
You may be tempted to just use #if guards to put the code for different platforms in the same methods in one class, but again this is something that will make maintenance really nasty as your project progresses. As a general rule, try to keep the wiring up for a particular platform as centralised as possible, so you don't need to make changes in a dozen places to switch platforms for building and testing.
Thanks ... I will now focus on making sure I keep these principles in mind while working on Hyper Drift.
We didn't use a specific dependency injection library or anything, but it is really simple to make this work.
So we'd have everything split out like this into logical groups (storage, video, achievements, user stuff, etc)
And have a provider for each platform:
And create instances of those at the start of the game depending on the platform
What's nice is that if you structure it well, and properly separate out all platform dependencies then you can largely add a new platform by just writing a new handler for each of those. We did still end up with some #if's in the middle of other code, but it is pretty minimal.
I know you're on Unreal, but thought I'd mention some Unity stuff anyway: Unity creates specific projects based on the platform you've got selected. This is good, but if you're using lots of #if's you'll run into wanting to edit some xbox code while you have Windows selected and that is hard because VS will have all that code grey'd out. And switching platform all the time is not something that you can do with a large project because it takes forever. So you end up having to uncomment #if's then edit the code. This is really crappy.
So what I did was write some code that latches onto Unity's build event (basically every time unity builds your code) and I generated all the projects we needed, with the correct compilation tags.
That looks roughly like this, except on the machine I'm writing this on I don't have anything installed so they're all unavailable).
And then with those projects being generated, VS has a drop down like the following with each platform. And as you select it, the right block of code will light up. It makes it really nice to work with cross-platform stuff.
(once again, don't have stuff installed so the platforms aren't listed in this picture)
Thanks again ... :)
@roguecode yeah an ioc container is pretty much what you're doing anyway, just that it's not a class (like your "Helpers") that actually "knows" about all the classes you're adding references to. Same thing in the end, just a bit more flexible :)
On having to switch platforms, I know of folks who have written some scripts that bait-and-switch the Library folder under Unity's nose (because that's what takes so long to regenerate). An alternative to that is just having multiple clones of your project, each set to a different platform, but that has its own challenges (like having to push changes before they're visible to that clone). Regenerating the projects yourself is a great approach.