Pre-Order the Game!

Desura Digital Distribution

Monday, June 3, 2013

Enough with "Beating around the Bush"

Alright, I'm gonna be open and honest here.  The main reason for me adding modding support to Beyond Beyaan was to have the ability to play it like MoO 1 without being a blatant clone, "Oh, check this awesome 4X game, but if you don't like how it plays, you can just load up a mod and play it like MoO 1!"

If you check the 0.5 version on Desura, you'll see that I actually had it almost playable, it was just lacking AI, research, and certain features to make space combat work.  But most of the stuff were there.  You can invade planets, you can colonize, you can build ships, etc...  Now look at the latest version.  What do you see?  A galaxy... That's it pretty much.  What happened?

Well, right after that 0.5 version on Desura, I decided to re-do the economy system so that it'd be moddable.  That's mistake #1.  After finishing it, I felt that it should be moddable in other ways.  That lead to a sequence of a lot of work that just aren't visible to the users.

I'm not saying this to tell you that I give up.  No, far from that.  I'm telling you why I'm changing course and doing things differently now.

Instead of pretending that I'm not copying MoO 1, I'm outright just doing it now :)

I'm creating a branch and putting the current version in that branch for reference.  Then I will clear out most everything that I have so far, and focus on getting things implemented the non-moddable way.  This means hard-coding everything, including technologies, races, AI, etc.  I will restrict myself from using data files other than graphic files and save files.  I will copy MoO 1's gameplay as a base, to avoid design decisions.  This will be a re-imagined MoO 1 in every way.

You may be thinking, that'd be a drastic change.  The truth is, most of the delays were from me figuring out how to support modding for a certain feature.  For example, star systems?  I had to write code that reads in a data file that defines star systems, and the code had to be flexible to accommodate the different star systems.  It contains a list of planets, which in turn contains the bloated economy system that can accommodate any kind of economy that you want.  When doing it the hard-coded way with MoO 1 as base, the star system will just contain 9 values: the 5 sliders, population, factories, which ship being built, and owner.

Once the game's playable and all features are implemented, then I will start swapping out hard-coded parts of the game with code that uses data files to support modding.  Then after that's done, I will finally start tweaking the game to incorporate my design ideas.  I will keep the MoO 1 gameplay as "Classic" dataset.

I realized all of this when working on the new UI system.  The whole project has gotten so bloated that I'm basically endlessly designing and tweaking and getting nowhere, and having a hard time staying motivated.  This change will give me a boost, focusing on only the essentials now.  So please bear with me...


  1. Very smart move and I fully support you in this. Making that decision must have been incredibly difficult, but I fully agree it's the right one.

    For modders (like me), well, your game is still open source!

    I know that's often held up in the open source community as an excuse for not implementing features (that aren't fun to code) and such but in your case your code is very easily understandable and very hackable so I don't see an enterprising modder having any difficulty changing a few constants or for the more ambitious integrating a new "Data Module" and it's "Data Manager".

    So again, I applaud you. Get this thing done! I think I can safely say there are a lot of us who really just want a "good Moo1 clone" and if you can give us that, and improve upon it later (with moddability, interface and gameplay improvements) I think you'll enjoy great success :)

  2. Thank you for your kind words of support! When making this decision, I was afraid that I might anger some people. But I believe that having a simple working game that can be added on later would be better than my current approach.

    I'm glad that my code is easy to understand. I will strive to keep it easy to read and understand. There is one caveat, since I'm only including four races and certain technologies for the demo version, the open source will be the demo version. However, when I add support for modding, the full and demo versions of code will eventually merge, and I'll just distribute appropriate data files for each version.

    1. I see. I'm not sure what your trying to achieve by branching the commercial and demo code base.

      If you think you're going to be maintaining two branches and merging the code across, I can assure you that while you may go in with the intention of doing that you are in fact just massively increasing your workload, again massively slowing development.

      So you spend a little time on the commercial branch and figure you'll merge all the changes back over later. And if you're still using SVN for revision control, well once those branches get far enough out of sync, the tasking of merging them back quickly becomes effectively insurmountable.

      So, let's try and fix that. Another option is to use conditional compilation and a code censoring tool ( as an automated build step, building the open source and commercial releases from the same code base.

      This sounds better, but let's look at what happens--The open source version fails to attract a mod community because no one wants to play a mod of the incomplete version of the game.

      An interesting but unlikely outcome is someone forks the code and creates "Closer than Centauri", and hey, it's awesome! It even gets it's own community around it. Cool, definitely, but any benefit to you personally is tangential at best.

      Or you might just drop the open source project for now. "Later I'll fix it, make it data-driven again and release that", you think. Except after the game is released you'll probably be busy making more content for it that you can actually sell. You've got a family to support, right? You know what your priorities are.

      Finally you may decide the game is past it's commercial peak so a few years later you decide it's finally decide to just go ahead and make the code drop.

      This isn't the worst thing that could happen, really. But I won't follow that scenario any further as it's far too early to realistically speculate the outcome.

    2. [continued, due to character limits]
      So it comes down to what you're trying to do by segregating the codebases. It is a question of piracy? It shouldn't be, the game is going to have a 90%+ piracy rate no matter what you do, censored code, DRM, no DRM, whatever. That's an absolutely dreadful thing to hear (including to me, as a fellow software developer) but that figure's not really controversial in itself, it's the conversion rates that and marketing value that people can debate 'till the sun burns out.

      So long as some of your assets are proprietary than redistributing them without permission isn't legal, and honestly that's about the best you can do.

      Or are you worried that someone will take the complete game code and because so much data will be hard coded, they would not have such a hard time replacing all the assets and having a functionally similar free clone?

      Well there's projects like OpenArena and FreeGish that are doing that. In both cases despite the identical game rules, the game is significantly different due to the use of different assets (particularly as they have entirely new levels).

      And despite your intention to hard code everything there will surely be enough data-driven systems remaining that any clone games will have enough differences to not significantly affect your sales.

      So, at last, my recommendation. A unified codebase with conditional compilation between "demo" and "release" mode and no code censoring. That way modders can mod the full version, and piracy of the complete dataset it still piracy.

      You can even keep them in different directories (or archives) to segregate them, and then using something like PhysicsFS (which I understand has C# bindings available) to transparently load them into a unified virtual file system.

      Or you could give up on the open source quest for now, wait until the game is past it's commercial shelf life (three years) and do a code drop then. Or never, and just move onto making the sequel.

      Well, I'm personally hoping for the first :)

    3. Whew, lengthy read :) But I understand your concerns. There are several things that we need to consider:

      I promised the Kickstarter community that the game is open source. So it will remain open source.

      As for "Full vs Demo", the main reason behind that is that I don't want to make people who paid for the game to feel ripped off knowing that I'm giving it away for free. I'm not aiming to get profits from this game, but to raise funds to obtain more content (artwork and sounds).

      Perhaps a compromise can be made? I could re-use the same 4 races for all races, but give them different attributes, for the demo version. In full version, all races' artwork will be included. With technologies, I'll work up to a certain level, then release that as the first version. Then the first hard-coded stuff that I'll replace would be technologies, and I update both full and demo versions to use data files for technologies, then add the rest of technologies in full version in data file.

      That way, the code won't diverge, and there's an incentive for people to buy the game. I'm not worried about piracy, as evidenced by my game being open source. Is this compromise acceptable?

  3. I am relieved by your post, because it means we can play the game much earlier.

    Every time you thought about some great idea and how it is planned and how it works, somewhere in me I had a little voice saying:

    "Not again! He did it again, throwing everything away he already had for some new (really cool) feature."

    I liked most of you ideas how to improve the game and the modding considerations. But it just added more and more scope, in a probably endless loop.

    So I really applaud to you, for coming to that decision, to get something running very fast (compared the recoding of everything) and add stuff to it later on!
    Dwarf Fortress Style!
    Its not easy to make such a cut when you just have so many ideas and just one more level to do ;-)

    So happy coding!

  4. Thanks for your comment! Yeah, I have too many ideas. I've fallen into the "feature creep" trap, rationalizing "Hey, modders might want this feature, and it's not feature creep since I'm building an engine". But I need to have a playable game as a base before I add all those neat ideas :)

    That's why I'm putting my ideas to the side for now, and just copying MoO 1's gameplay as exactly as possible. No design decisions, no new ideas, no feature creep. Just coding to get the game done. The only differences will be art graphics, technology names, race names, and other stuff that helps avoid copyright infringement.

  5. Hi,

    This is just my opinion as a fellow developer and long time reader:
    I think where you really went wrong was deciding to make the UI moddable. This is really difficult and time consuming. It's one of those "Solve the universe" problems. You could in theory, spend more time making the UI modding system than the real game!!!! You're by yourself and I don't really think it's a good use of your time.

    I guess if I were in your shoes - I'd set aside all of the UI modding code in another branch and then revert to the revision directly proceeding it. Then I'd just finish up whatever needed to be done in and go from there. Off hand I'm not totally sure what else needs to be done in terms of modding (besides the UI of course) as I only casually follow your blog.

    Just my two cents! But good luck on whatever you do.

    1. The other modding stuff that I did broke basically every feature in the game, leaving me with only the galaxy stuff working. So that's why I reverted to the current version shown in the new blog post

    2. Ah, from my perspective while reading the game seemed to be in good shape prior to you tackling the idea of modding the entire UI and all that. Knowing that, then I think you made the right decision.