Physics Platformer Gish Goes Open Source

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

Comments

Oil spill...

[K. S. Kyosuke]

Am I the only who thinks that the whole thing suspiciously resembles an oil spill?

Re:Oil spill...

[Gothic_Walrus]

You know what other indie game resembles an oil spill?

Re:Oil spill...

[CODiNE]

Yeah, BP is real stupid, they just have to hold down the D key and the oil will bunch up and turn solid.

Only the engine

[Jorl17]

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

[PatrickThomson]

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

Re:Only the engine

[Anonymous Coward]

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

Re:Only the engine

[Luther Blisset]

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

Re:Only the engine

[pjt33]

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

Re:Only the engine

[HalAtWork]

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.

Re:Only the engine

[ToasterMonkey]

Idiot watching

Re:Only the engine

[Score Whore]

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

Shooting fish in a barrel?

Re:Only the engine

[Anonymous Coward]

You mean like the one who submitted the article?

Re:Only the engine

[hedwards]

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.

Re:Only the engine

[Anonymous Coward]

(whether you intended to read it after the comments or not is irrelevant)

No, because the OP is claiming (or at any rate, implying) that to do it that way round makes you an idiot, which is what the guy you're responding to was objecting to. I suggest you RTFC!

Re:Only the engine

[Luther Blisset]

I don't see how that does anything other tan proving my point. According to OP, what determines the idiocy of the reader (or as the case may be, the non-reader) is whether he/she reads the article before commenting/reading the comments. Therefore, by merely reading or posting a comment before actually reading TFA, said idiocy has already been determined, and thus it no longer matters if TFA is read afterwards, or at all. So either said idiocy is determined at the exact moment one reads the OP's comment, or it had already been determined, and thus the fact that OP's comment makes it unnecesary to RTFA is irrelevant (and consequently not unfair).

I suggest you read my FC, and this time make an effort to actually understand it. ;)

Re:Only the engine

[ChrisMounce]

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:Only the engine

[jd]

Using a chain-gun on fish in a barrel qualifies as merely shooting them?

Quality code

[Anonymous Coward]

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.

Re:Quality code

[3.1415926535]

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;
        fuckedup[8]=timer[8].totaltime;
        fuckedup[9]=frame.numoflights;
        fuckedup[10]=numofsounds;
        fuckedup[11]=game.bonus[7];
        fuckedup[12]=numofanimations;
        */
        fuckedup[7]=game.levelnum;
        for (count=0;count<16;count++)
            {
            if (fuckedup[count]<8000000)
                drawtext("/i",0,128+count*12,12,1.0f,1.0f,1.0f,1.0f,fuckedup[count]);
            else
                drawtext("/i",0,128+count*12,12,1.0f,0.0f,0.0f,1.0f,fuckedup[count]);
            }

Re:Quality code

[DavidR1991]

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.

Re:Quality code

[Anonymous Coward]

To be fair, that's inside an #ifdef TESTIT

Still, not the most well-commented source I've come across :)

Re:Quality code

[DavidR1991]

(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)

Re:Quality code

[Anonymous Coward]

This.
Anyone who does otherwise either has too much spare time, or they are wasting time.
Either way, both aren't good when it comes to money.

Making code according to some pretentious quality standards is a waste of time for anyone who actually depends on it getting out ASAP.
Code improvement comes with the newer versions, not the first release.

I say this myself with fantastic code statements, such as:
nfi++;if(newframe[nfi-1]==0001){sc_fi="onclick='frame("+newframe[nfi]+","+newframe[0]+")'"}
As you can see, horrible variable naming, looped an index and used both indices in the same chunk of code, JavaScript, arbitrary array name, values comparison not quoted, said value being defined in comment only, probably other stuff that nobody but idiots care about.
Oh, and barely any comments since I know what most of it means.

This was for the creators eyes only, initially.
They never expected one day that they'd open the source up for others.

Re:Quality code

[Anonymous Coward]

And the criticism above is post-release criticism, and should not be dismissed due to some idiotic "but he release the code!!!!!!!!" argument.

Re:Quality code

[Anonymous Coward]

Also, the coding being vile gives the FOSS community something to do, if you think about it.

Yeah, we should make all our buildings dangerous and rickety, because it gives the emergency services something to do.

Re:Quality code

[Anonymous Coward]

It doesn't matter if the code cures cancer, it's still eligible for criticism.

Re:Quality code

[sammyF70]

Considering Gish (linux) has been very stable and bug-free for me so far, I'd say your comparison is just plain wrong. More making a building out of wood and bamboo, painting the bedroom walls in pinks with green dots and using revolving doors instead of plain old ones. It might not be pretty or stylish, but it's liveable.

Re:Quality code

[WarJolt]

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

Re:Quality code

[Anonymous Coward]

Just because you code like shit doesn't mean everyone should.

Re:Quality code

[grumbel]

Some people care about creating beautiful games, other care about creating beautiful code. The former end up shipping a good game, the later kind never gets stuff done.

Re:Quality code

[Anonymous Coward]

code snippet below...
i think that in this case, releasing their code as open source is going to have the unintended effect of disappointing young game developers, and to help them understand how to not write code.

no documentation makes my brain hurt.

#ifdef TESTIT /*
        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;
        fuckedup[8]=timer[8].totaltime;
        fuckedup[9]=frame.numoflights;
        fuckedup[10]=numofsounds;
        fuckedup[11]=game.bonus[7];
        fuckedup[12]=numofanimations;
        */
        fuckedup[7]=game.levelnum;
        for (count=0;count16;count++)
            {
            if (fuckedup[count]8000000)
                drawtext("/i",0,128+count*12,12,1.0f,1.0f,1.0f,1.0f,fuckedup[count]);
            else
                drawtext("/i",0,128+count*12,12,1.0f,0.0f,0.0f,1.0f,fuckedup[count]);
            }

Re:Quality code

[TheRaven64]

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:Quality code

[DavidR1991]

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 two things are diametrically opposed concepts.

I'm not explicitly stating that a horrible codebase = more likely to finish on time. I'm saying not fixating on codebase quality when your end product is a constantly moving target = more likely to finish at all

Re:Quality code

[TheRaven64]

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, well-structured, clean code was harder to write than this kind of mess. It's equally easy to write, and significantly easier to maintain and modify. The attitude that writing bad code is a time saver is why so many software projects run over budget and behind schedule.

Re:Quality code

[Tapewolf]

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

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.

Re:Quality code

[grumbel]

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 really is no problem.

Now that of course doesn't make the code pretty, but when the choice is between implementing a new user visible game feature or spending time refactoring the code, time is quite often better spend working on the new user visible feature, as no user will ever care about the quality of the source code.

Re:Quality code

[Anonymous Coward]

Hm... Yes. I'd say source looks suspiciously like it's been stripped of anything resembling meaningful comments or constants.

Still, it's open now; time to fork, figure out, add comments and let people create cool things with it.

Re:Quality code

[TheRaven64]

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 expect other people to modify it.

Re:Quality code

[grumbel]

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.

Re:Quality code

[tlhIngan]

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 other people to modify it.

Most engines are licensed from a third party, who's in charge of maintaining it. The game company licenses the engine (which has nice interfaces and the like) and writes the stuff around it. So the engine is well-maintained and not dated (since those companies are interested in continuing to license the engine for next-gen hardware). Very few companies have their own engines - Valve, Bungie and iD come to mind (Valve and iD license their engines, I believe), most use third party ones - Unreal, Unity, and many, many others (too numerous to mention).

The thing is, customers pretty much use one version of the engine and throw it away for the next game, so the code around it is more "get 'er done" style quality than "look good". This also means the engine APIs can change since there's no legacy code to speak of.

Games have no longevity code-wise - once it's shipped, start another game pretty much from scratch. There may be libraries and such reused, but that's a convenience - if it's too messy, it'll be re-written, and copy-and-paste coding rules the day.

Valve and Blizzard are the few exceptions, where games can get updates long after release that fix game issues or other things...

Re:Quality code

[hviniciusg]

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?

Humble Indie Bundle

[SpeedyDX]

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.

Re:Humble Indie Bundle

[The_mad_linguist]

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.

Re:Humble Indie Bundle

[ranulf]

How about adding ?junk=1234 or somesuch to the link to make it unique...

Re:Humble Indie Bundle

[k8to]

How about making the slashdot link handling code less ridiculous?

Re:Humble Indie Bundle

[X0563511]

Hey! Logic ain't welcome around these parts! Leave that shit at home!

For the love of Gish...

[Anonymous Coward]

For realworld playtesting of new user made levels, nothing beats a tossable, squishable, abusable Gish plush... It's simple to check the accuracy of simulated physics by chucking one across the office. http://www.bigshottoystore.com/category/gish

That's nice, but...

[Anonymous Coward]

...what about Siamese Dream?

Thanks

[eddy]

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:Thanks

[Anonymous Coward]

Exactly, I have code in much better state than this and I don't have the guts to release it even when I always intended to do it in the first place.

"Not that such is bad" I disagree

[Anonymous Coward]

Let's run a thought experiment here. Suppose there's this opensource blogging engine (say like wordpress) and you get all the source, but they ship no skins. Would that be bad? How many people would've been doing wordpress skins, if they hadn't shipped any with their product? Who would even know what wordpress is?

Suppose there was this great opensource game (say like wesnoth), and they ship you the source, but all the content's proprietary. What you say, weswath? what's that?

A game is an amalgam of functional code and assets. Neither the code nor the assets in themselves represent anything much useful. Only in combination they become more then their constituent parts. "Open sourcing" a games source only, is just one step short of license circumvention by a slight of hand. It's a PR stunt.

Re:"Not that such is bad" I disagree

[Anonymous Coward]

The Quake engines serve as a counterexample to disprove your theory. Despite the fact that the Quake assets are all restrictively licensed, the open-sourcing of the Quake engines has clearly been useful: it has allowed games to be easily ported to new platforms, and the engines have also served as bases for new original games with fully open-source assets.

Therefore, the assertion that "code by itself is not useful" is clearly false, and open-sourcing code without assets is not an inherently pointless act.

I think the best part of your comment is where you accuse them of "license circumvention by a slight [sic] of hand". That's just silly and petty. They own this code. They don't need a license to do whatever the hell they like with it. We're the ones who need a license to do stuff -- and, looky here, darn me if they haven't just gone and granted us one!

In-line documentation

[sazim]

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*?

Re:In-line documentation

[sazim]

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.

Re:In-line documentation

[jd]

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

Code Quality in Games

[acid06]

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:Code Quality in Games

[grumbel]

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 complaining that a movie set looks only good from one side, while from the other side its clear that its just painted plywood and styropor. It just doesn't matter for a game to have pretty code, when the actual game itself is good. And from those games I have seen, the good ones end up having a little ugly code, while the ones with the good code hang around in some sourceforge repository and never get stuff done.

Re:Code Quality in Games

[wrook]

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 handed down from one programmer to the next. Kind of like when you look at telecommunications code you are suddenly faced with really long subroutines (long ago it was feared that the overhead of calling a subroutine would destroy "real time performance". This myth is probably still being propagated in some circles). As little as 3 years ago I worked in a respected telecommunications company with a coding standard that encouraged subroutines to be *at least* 200 lines long -- longer was better.

But then, lately I've been despairing of finding *any* application with consistently good code. Unfortunately, I include my own meager efforts in that statement...