Pre-Order the Game!

Desura Digital Distribution

Thursday, August 8, 2013

Demand for Linux version

During the development of Beyond Beyaan, I've been asked many times if I have plans to port the game over to Linux.  So here's my official announcement regarding Linux version.

Yes, I will develop a Linux version.  However, since it uses an different environment, and don't support DirectX, hence SlimDX which my game's 2D engine relies on, I will have to change to another 2D engine that runs inside Linux AND Windows.  Since this is a drastic change, I will wait until the game enters beta, then branch off and work on a Linux compatible version.

Now, when will the game enter beta?  It will enter beta when all the gameplay features and UI are implemented, similar to Master of Orion 1.  AI won't be tuned or balanced, those will be done during the beta phase.

Here's the remaining major features/UI that need to be implemented before the game enters beta for clarification:
Saving/Loading games
Ground Combat (Transports are working already, just need to add this)
Researching Technologies (The technologies are already in the game, just need UI and logic for researching them)
Fleet Management Screen (Code already stores all fleets, just need UI)
Planet Management Screen (Code already stores all planets, just need UI)
Diplomacy Screen
Diplomacy relations code (such as no combat if you arrive at an allied player's planet, penalties for attacking a colony, meeting a new race, etc)
Ship Design (The technologies and underlying code already support ship designs, you can see scouts and colony ship as evidence of this, so only UI is left to actually add new designs)
Finish the planet code (Such as refitting factories, building ships, missile bases, etc)
Start on some rudimentary AI code
Victory/Loss checks

Here's what will be implemented after beta starts, not in any particular order:
Random events
Newscaster (BNN)
More work on AI
Linux version
Bug fixing/polishing

After those are done, the game will become a full version.  Only at this point will I start adding modding support (replacing hard-coded values with data-driven values, like technologies, scripts, etc)

Hopefully around winter, the game will enter Beta.


  1. Hello Brent, you should check out SFML ( SFML has bindings for C# which are actually up to date (maintained by the core developer of the library).

    SFML is a native C++ library but the has several bindings to other languages, which are regulary maintained in comparison to other media libraries out there.

    Also several published games (atom zombie smasher for example) have used the library as a whole, so not just for window context, like many folks do with SDL.

    Hope this helps you out, greets -JD

    1. Thanks, I'll look into it and see if it's feasible for my project.

  2. I have previously evaluated the possibility of porting BB's code base to Linux (et al).

    The options I had considered are:

    1) Port Gorgon's use of SlimDX to OpenTK.
    I quickly discounted this after looking at Gorgon's source code. It's a complex codebase, and the rendering code is not abstracted at all. Porting Direct3D to GL is never trivial in any case, and without a proper renderer abstraction (plus DX calls are all over the place so it's not like you can change just one file) IMO this is just not a good use of time.

    2) Straight up replace all Gorgon function with MonoGame. This is again not trivial.
    It's a compelling option though, as the whole codebase could be migrated and it could target every platform (even Windows 8 store), thus preventing the necessity of "Linux fork".

    I strongly considered this, but I can't think how to do it while the code is in such a state of flux. If I made a fork then ported that, Zeraan would be chugging away on the trunk and I'd be hard pressed to merge in all his changes, not to mention a large amount of work would be duplicated.

    3) Replace Gorgon with an imported C++ DLL for drawing/input functions. I was investigating the possibility of using my own engine and generating C# bindings, SFML would be the same (except C# bindings to the C++ DLL are already provided). Alternatively, a C++ engine with embedded Mono bindings. This would be the most work of course, and has the aforementioned issue of merging changes, but remains an intriguing (if impractical).

    4) Write a Gorgon "shim" for MonoGame (or SFML, but the former supports more platforms) using only the functions BB uses, which is actually only a small fraction of Gorgon's functionality.

    Since Gorgon's API isn't going to change (the dev is onto the next version which breaks backwards comparability so BB's not likely to upgrade) this has the advantage that the wrapper can be developed in a separate branch, tested with it's snapshot of the code, then merged all at once with hopefully few side effects.

    That said, I haven't actually tried it and writing a wrapper can have it's own share of pitfalls.

    1. That's exactly why I'm holding off on porting until after the base game is done. I don't want too much duplicate work when the code is in flux.

      I tried to keep BB's drawing stuff separate from the game, and abstracting away sprites and such into "BBSprite". So if I need to change underlying 2D engine, I just need to replace the "BBSprite" and the game should work mostly. There's some special cases (name coloring, ship shading, etc) but I think those should be easily resolved.

      Again, I never experienced developing for Linux, so it'll be a good experience for me.

  3. Best news this year :)
    I use fltk and considered Allegro (because of the iOS and Android port), but as far as I know there is no C# binding for either of them.
    This SFML looks good at first sight.