Why aren't more fan games open source?

Discussion in 'Fangaming Discussion' started by flarn2006, Feb 27, 2020.

  1. Gnidel


    I think the biggest issue in making game open source is that most fan games are never finished and many of them don't have anything worth open sourcing as they are based on existing engines with minor alterations.

    They are abandoned, what means the authors don't want to put more effort into it and open soucing it is more effort. Especially with hosting because games can have some large assets, as well as some leftovers.

    Another option is open development, which is great because other people might join, but it scares away people who want more control over the project and don't want it to turn into an unsorted collection of random levels with random quality.

    Even with open development there's, again, the issue of large assets. With code/frameworks it's easy, just use git, but storage of textures, music, models, videos and Unity/UE4 project files - not so much. Gitlfs and hosting are additional expences and I doubt anyone wants to spend money on development of a non-profit game. Git also has an issue of people not knowing how to use it, fan games are often made by amateurs, after all.

    Personally I want to open the souce of Sonic Stranded (formerly known as Sonic Liquid Survival), but only after finishing the game. I'll do two releases - of the full game and cleaned up and streamlined framework with tutorial level and some level design tutorials. If people will make bad games from it, I will blame myself for bad tutorials, but I will be honored anyway because it would mean I helped someone have fun making a level.
    But I won't release it until I'm done with the game and some post-release bugfixes.
  2. SF94


    Tech Member
    SA1/2 hax
    The way I look at things like this is: there is always room for improvement. I wouldn't wait on an infinite timeline.

    I have a lot of respect for programmers that are able to say "yeah, that code isn't the greatest/isn't up to my standards, but it's functional and can be changed later" - it shows good understanding for prioritization and its impact on the project.

    When you say documenting code, are we talking in the fairly literal sense, like so?

    Code (Text):
    2. // Does some cool function
    3. // param_a is for something
    4. // param_b is for something else
    5. void some_cool_function(int param_a, int param_b);
    Because let me tell you, it's a good idea to get in the habit of doing this up front. I've had this help prevent scope creep, even. As a side note with love, always write your code and its inline documentation for somebody else to read. That somebody could just be you in a week, month, year, decade from now, and without good naming and documentation, you bet your ass you won't be able to understand it, let alone newcomers. ;)
  3. BlazeHedgehog


    A "Community Enigma"? Oldbie
    Releasing my projects open source would require that I implement clean, legible code that other people could easily read

    It also means the burden of fielding questions from people confused by what I'd written

    And that starts to sound like a level of work beyond casual funnin' around
  4. Xiao Hayes

    Xiao Hayes

    Back on track Member
    Bilbao, Spain
    Upgrading my own life to pro edition
    Something I wanted to do but probably never will at this rate was to develop and release a toolkit to make fangames with basic stuff from existing games so people had something to work with, but keeping the stuff of my own fangames out of it to not spoil the fun and protect the stuff I cared more about. I think we would have more quality fangames if they had a robust base to work with that doesn't necessarily ask them to code, much like what happens with rom hacks, but on the fangame side. Of course, a lot of shitty projects could emerge from that precious framework, but my own stuff would still be mine.

    About code quality, I'm such a perfectionist that I would polish the code and write every comment even if I wouldn't make a public release the source code, so that doesn't worry me, and I'm so out of the coding trends that feeling embarrassed about my coding style would make no sense, at least it would be polished and documented enough for them to update it quickly. XDDD
  5. BlueFrenzy


    I will probably open source Sonic Frenzy Adventure. There are three main reasons I would not do it:
    1- It's obsolete. By far you will end up doing much better with Sonic Worlds.
    2- It contains several copyrighted stuff, like music or art, so it will be hard for some people to identify if they can use the asset or not.
    3- It's extremely messy.

    Still, I will probably release the original files because maybe someone wants to mod it. Feel free.
  6. MainMemory


    Have no fear...Amy Rose is here! Tech Member
    All you people saying that you have to have clean code in order to release it publicly have clearly never looked at any of the programs or mods that I've released on GitHub over the years.
  7. Ralakimus


    Ding a ding dangin' my dang a long ling long Tech Member
    IMO, it's highly preferable that the code should be kept clean and documented if it's going to be open source. It just makes it easier for the people who want to look at it and understand it.
  8. Sparks


    Kyle and Lucy: Wonderworld
    I mean, aren't most fan games full of copyrighted assets out of proxy? :V There's plenty of projects that are open source, but I think it's safe to assume that the community understands and assumes it's all owned by SEGA and whatever other sources are used, unless said otherwise (such as original music compositions).