Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Open Source PC Games (Games) Games Linux

Physics Platformer Gish Goes Open Source 58

An anonymous reader writes "After announcing plans to go open source due to the success of the Humble Indie Bundle, developer Cryptic Sea has released the source code of 2-D platformer Gish under the GPLv2. There's a mirror on github."
This discussion has been archived. No new comments can be posted.

Physics Platformer Gish Goes Open Source

Comments Filter:
  • by K. S. Kyosuke ( 729550 ) on Sunday May 30, 2010 @10:19AM (#32397132)
    Am I the only who thinks that the whole thing suspiciously resembles an oil spill?
  • Only the engine (Score:5, Informative)

    by Jorl17 ( 1716772 ) on Sunday May 30, 2010 @10:25AM (#32397178)
    As noted, only the engine has been open-sourced. All data (levels & gfx) are still available only upon buying. Not that such is bad, but I thought I'd share it with those idiots who didn't RTFA.
    • Re:Only the engine (Score:5, Informative)

      by PatrickThomson ( 712694 ) on Sunday May 30, 2010 @10:36AM (#32397270)

      In further pre-empting of people who didn't RTFA, the game is already supported on PC, Mac, and Linux.

      • Yes, but this does allow the game to be more readily available on other architectures. Personally, if I get time, I'd like to see about porting it to freebsd.
        • Yes. And even the official Mac build (at least, the one I have) is compiled for a PowerPC processor. You can still run it on Intel machines thanks to Rosetta, but it's not ideal.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      That's unfair: calling us idiots but at the same time making it unnecessary to RTFA.

      • How so? Either you RTFA before you read Jorl17's comment, or you read it after (or not at all). If you read it before, the comment doesn't apply to you, otherwise you skipped TFA (whether you intended to read it after the comments or not is irrelevant) and therefore the comment applies to you. ;)

    • by pjt33 ( 739471 )

      If you call people who don't RTFA idiots, what are you doing on /.?

    • More games should do this, that way they get ported to other systems through community effort and you have even more people purchasing the game.

      In addition, more developers get to fool around with the engine to see if they want to use it for their game, and then pay for a commercial license if they so wish.
  • by Anonymous Coward on Sunday May 30, 2010 @10:47AM (#32397340)

    The Gish source code drinking game:

    http://github.com/blinry/gish/blob/master/game/game.c

    Find a line with a magic number and take a drink.

    Warning: You will go blind in five minutes if you take part in this drinking game.

    • I like this part:

      /*
      fuckedup[0]=timer[0].totaltime;
      fuckedup[1]=timer[1].totaltime;
      fuckedup[2]=timer[2].totaltime;
      fuckedup[3]=timer[3].totaltime;
      fuckedup[4]=timer[4].totaltime;
      fuckedup[5]=timer[5].totaltime;
      fuckedup[6]=timer[6].totaltime;
      fuckedup[7]=timer[7].totaltime;

      • by eddy ( 18759 )

        I'd like to nominate drawtext() which combines formatting, drawing and magic numbers in a wonderful way. This codebase brings me back to 80s early 90s...

        Okay, as a person with NUMEROUS unfinished [game] projects, I'm in no fucking position to throw ANY stones, I know. In fact, EXTRA kudos for releasing the code knowing the state it's in. I don't know if I could do that (which is a failing on my part).

        Again, thanks.

    • Re:Quality code (Score:5, Insightful)

      by DavidR1991 ( 1047748 ) on Sunday May 30, 2010 @11:29AM (#32397686) Homepage

      Who cares how bad the code is? The game got finished. It's playable and it's fun. The end user doesn't give a toss how many magic numbers there are

      I think there comes a point in any project where you have a choice between "Make my code pretty and perfect" and "Get this fucking thing finished". This guy obviously chose the latter. Fair play to him. Also, the coding being vile gives the FOSS community something to do, if you think about it.

      • (I'd just like to clarify that I agree some of the code is pretty nasty. Especially the amount of #ifdef DEMO abuse. But if this the code that got the game finished, then so what? Generally it seems that nice code and a finished article are opposite concepts)

      • If you think that using magic numbers, rather than well-documented enumerations, and mixing functionality across layers makes you more likely to finish on time, then I doubt that you have ever worked on a nontrivial software project.
        • Re: (Score:3, Insightful)

          by DavidR1991 ( 1047748 )

          Games aren't the same as any other 'nontrivial software project' (and yes thank you, I have)

          Games change continually through production. Business software can do this also (changing requirements and whatnot) but nowhere near to the extent of games. Because games have to be fun. Other applications don't. What this means is that sometimes 'something has gotta give'. You cannot have a codebase that is constantly in flux and 'down with' the concept of the game and a beautiful perfectly structured codebase. The

          • Games change continually through production

            Most software changes continually through production. The cleaner the code is, the easier it is to make changes. If you have layering violations to the degree that this code has, making a small change requires making modifications in lots of different parts. If you have magic constants everywhere, only the person who knows what they mean can modify it, which is a very important limitation if you have a team of people working on it and want to make a deadline.

            I've no idea where the idea that good, wel

            • by grumbel ( 592662 )

              The difference between a game and business software is that a game is done after the release. There is no version 2.0 that needs new features, maintenance and stuff, instead you start more or less from scratch with the next game. It just doesn't make economic sense to write the best highly maintainable code when you already know you know you will never touch it again. And with a small game like this you don't have new team members jumping in either, so as long as the developers are fine with it, there reall

              • The difference between a game and business software is that a game is done after the release.

                Again, this isn't really true. The game itself may only get a few patches, but most of the time the engine is reused. Of course, by the time that the next game is released, hardware capabilities have improved and so the engine will need updating to take advantage of them, or you end up with something dated. If the game is very successful, then you may end up licensing the engine to other companies to use. Or you might end up open sourcing it. In both cases, the quality of the code does matter if you ex

                • by grumbel ( 592662 )

                  Again, this isn't really true. The game itself may only get a few patches, but most of the time the engine is reused.

                  That is true for modern 3D games, it is not true for the indie 2D game we are talking about here. In those games there really isn't all that much that you can recycle. The low level stuff that can be reused is already handled by SDL, OpenGL and other libraries and the higher level stuff very quickly becomes game specific and thus isn't much good for recycling.

                  Or you might end up open sourcing it.

                  The main point of open sourcing a game like this is for future compatibility, not so much for modifications on the core game itself.

                • by tlhIngan ( 30335 )

                  Again, this isn't really true. The game itself may only get a few patches, but most of the time the engine is reused. Of course, by the time that the next game is released, hardware capabilities have improved and so the engine will need updating to take advantage of them, or you end up with something dated. If the game is very successful, then you may end up licensing the engine to other companies to use. Or you might end up open sourcing it. In both cases, the quality of the code does matter if you expect

      • I love the idea of the code made GPL, but, there is alwais a but :)

        why there isnt a single line of comentary on the source code?

        come on guys. why the code does not have comentaries?

    • by WarJolt ( 990309 )

      Take two if you find a C file in a #include.
      http://github.com/blinry/gish/blob/master/main.c [github.com]

      • Take two if you find a C file in a #include. http://github.com/blinry/gish/blob/master/main.c [github.com]

        I've found that's the best way to merge SQLite's core (a multi-megabyte .c file) with its (commercial) encryption core without having to cat the two together each time a new one is released. Especially on platforms like windows which don't have cat.

        Actually, it's possible that they're doing something similar to the SQLite amalgamation, i.e. trying to pack as much of it into a single file as they can to improve the global optimisations. Of course, they might simply be on crack.

  • by SpeedyDX ( 1014595 ) <speedyphoenix&gmail,com> on Sunday May 30, 2010 @11:14AM (#32397548)

    The link to the Humble Indie Bundle in this slashdot post linked to another slashdot post wherein that link to the Humble Indie Bundle linked to yet another slashdot post which finally contained the real link to the info on the Humble Indie Bundle.

    We all hate it when we have to jump through multiple hoops (articles separated into an inane number of pages, exit pages/frames, etc.) in the name of reader retention when it's done by other websites. When slashdot does it, it's just as bad.

    • If an article gets submitted with a link in it, and that article gets rejected (perhaps due to a bad description), that link can't be resubmitted.

      This results in forcing some of the front page links to be indirect.

  • Nice to see that the code is commented and documented throughout.

    OK, the code is neat and legible with good names for vars etc, but why are there absolutely no comments *anywhere*?

    • by sazim ( 50061 )

      Having said that, I do think it is fantastic that they have released the code in the first place! It is a great project for physics undergrads to play with.

    • by jd ( 1658 )

      Perhaps they were planning on attaching a hyperlink to Slashdot to provide all the comments.

  • by acid06 ( 917409 ) on Monday May 31, 2010 @06:55AM (#32405890)

    I don't mean to troll or anything like that (considering I think Gish is an awesome game and I've bought the Humble Indie Bundle) but... are there any indie games out there that were actually coded in a well-thought manner?

    I mean, looking at the Gish source code, it's honestly a mess. You seem to ALWAYS find stuff such as magic numbers, hard-coded level information (ala, if (level == 15) do this different behavior). I've looked at the source for other games and they all seemed to share such "features".

    Anyone knows if the non-indie titles also follow this pattern? Maybe it's just an industry thing.

    • Re: (Score:3, Interesting)

      by grumbel ( 592662 )

      I've looked at the source for other games and they all seemed to share such "features".

      Its is just a part of doing good game design with limited time. When you could spend days coding a clean framework to integrate the special feature you want in level 15 or just a few minutes to hack it into the code, the choice is not that difficult to make. Sure its not good practice, but it doesn't really do harm either, as game specific code isn't meant to be reused and there is no value gain in coding a data driven framework for a feature that is used exactly once in the whole game.

      Its kind of like comp

    • by wrook ( 134116 )

      People in the industry have told me that since they typically write "one-off" things they tend not to worry about maintainability. I think the reasoning is that they just have to keep it going until release. For the next release they will start from scratch. This was quite a while ago (like a decade at least). I believe the number of "one-off"s has diminished over time and there is some expectation of maintaining at least an engine for sequels. But old habits die hard. The development culture is hand

You know you've landed gear-up when it takes full power to taxi.

Working...