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?

Comments

  • Definitely keep a single codebase, and avoid branching by platform (that will be a nightmare as your project moves forward). For a feature like this where the behavior differs per platform, define an interface for the general behavior you want to achieve, and then classes implementing that interface for each.

    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.
  • @mattbenic - I am using Unreal Engine but I understand in concept what you say and your advice was mirrored by other advice I received from The Chaos Engine forums. :)

    Thanks ... I will now focus on making sure I keep these principles in mind while working on Hyper Drift.
  • For VALA we went with 1) as I find it easier to manage.
    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:
    image

    And create instances of those at the start of the game depending on the platform
    image

    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.
    Annotation 2019-07-04 223942.png
    201 x 165 - 5K
    Annotation 2019-07-04 224354.png
    328 x 176 - 13K
  • (new post because I don't see how to add a photo when I'm editing a post)

    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).
    image

    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)
    image
    Annotation 2019-07-04 224727.png
    310 x 117 - 6K
    Annotation 2019-07-04 225340.png
    507 x 206 - 18K
    Thanked by 2quintond mattbenic
  • Thanks everyone ... much appreciated for the tips and information. I know most of the advise is Unity related but Unreal has some similar features as well ... so I can translate a lot to Unreal Engine.

    Thanks again ... :)
  • Whoops, yes I assumed you were using Unity, but glad to have helped in some way.

    @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.

    Thanked by 1quintond
Sign In or Register to comment.