Revenge of the Titans Source Code

[princec]

Bloggage: http://www.puppygames.net/blog/?p=914
Download: http://www.puppygames.net/downloads/RevengeOfTheTitansSource.zip

Don't complain about it Or ask any questions.

Cas

[krasse]

A very good and generous decision. I will enjoy decrypting it and probably learning a lot!

[Riven]

Bloggage: http://www.puppygames.net/blog/?p=914
Download: http://www.puppygames.net/downloads/RevengeOfTheTitansSource.zip

Don't complain about it Or ask any questions.

Not even report bugs? I see two in IntGrid

Games published by our own members! Check 'em out!

[princec]

Arggh! Where?

Cas

[Riven]

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24

private int getIndex(int x, int y) {       if (x < 0 || y < 0 || x >= width || y >= height) {          return -1;       }       return x + y * width;    }    public int getValue(int x, int y) {       if (x < 0) {          x = 0;       } else if (x >= width) {          x = width; // must be x = width-1; or getIndex will return -1 and you could just as well not have adjusted x       }       if (y < 0) {          y = 0;       } else if (y >= height) {          y = height; // must be y = height-1; or getIndex will return -1 and you could just as well not have adjusted y       }       int idx = getIndex(x, y);       if (idx == -1) {          return fill;       }       return value[idx];    }

[princec]

I just spotted that
It never seems to have had any effect on the game, probably because in this game width/height are never actually exceeded.

Cas

[Riven]

GeomUtil.rectangleContainsCircle( ) is bugged too

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21

public static boolean rectangleContainsCircle(float x, float y, float radius, float rx, float ry, float width, float height) {       // Treat the circle like an AABB and see if it lies within the bounds       float halfSize = radius / 2f;       float boundsXMax = rx + width;       float boundsYMax = ry + height; // snip       // Top edge       if (y - halfSize < boundsYMax) { // should be: if (y - halfSize < ry)          return false;       }       if (y + halfSize > ry) { // should be: if (y + halfSize > boundsYMax)          return false;       }       // All edges ok, circle is within bounding rect       return true;    }

FWIW, I actually rendered it for no apparent reason.

[princec]

I can blame Orangytang for that one

Cas

[badlogicgames]

Neat, thanks a bunch for that.

edit: you really like XML. And your DefaultSpriteRenderer is pretty much the same as our SpriteBatch. We'd probably even out in the big sprite shootout. Glad to know we are not that far away from people publishing on Steam

[Sinuath]

Very cool, thanks for sharing

Games published by our own members! Check 'em out!

[princec]

Neat, thanks a bunch for that.

edit: you really like XML. And your DefaultSpriteRenderer is pretty much the same as our SpriteBatch. We'd probably even out in the big sprite shootout. Glad to know we are not that far away from people publishing on Steam

Haha no I hate XML Fortunately I don't have to do an awful lot of it - Chaz gets most of the miserable drudgery. I was wondering about switching to some derivative of JSON (with less double quotes) instead as it's much more compact.

Cas

[gouessej]

Lol I like your comments:

// For f**k's sake, why doesn't it take the byteorder from the original buffer???

[princec]

That'll be one of the rare, useful, accurate comments

Cas

[appel]

Nice.

That's a lot of code... probably not how I would organize things. :\ but still useful.

[Gornova]

Someone have a look on this source code? Any good ideas to learn from it? I'm ready to share my thoughts too!

[gimbal]

Just want to note that as an alternative to XML you also have YAML. One of the benefits of XML is that it is pretty human readable, but the major downside is that it is so effing verbose and inefficient. YAML is human readable and adds minimal clutter. For a usage example, see how it is implemented in Play framework for example:

http://www.playframework.org/documentation/1.2.3/guide2

(search for data.yml)

[sproingie]

Every extant YAML parser I've seen is a bug-ridden ad hoc mess that's slower and eats more memory than any XML parser.  Stuff like syck that does aim for performance uses direct memory tricks in high level languages that just screams "exploitable".  And when it gets at all complex, it's not even particularly "human readable", or at least all the little quirky bits of syntax you have to dangle off elemen ts aren't obvious in what they do.  YAML needs a stake driven through it.

While I'm ranting: whither JSON?  It was conceived as a clever hack to allow javascript clients to generate it with toString() and parse it with eval().  Except that's not how any JSON parser works anymore, for very good reason.  So why not use real sexps instead?  Inertia of course.

[princec]

YAML looks like the Devil's own format. Quite why anyone would condone it is a mystery. XML is another of the Devil's creations though. Something similar to JSON would probably be quite nice.

Cas

[Gornova]

Other ideas? I've found on puppy blog this:

http://www.puppygames.net/blog/?p=178

I remember some article about handling animations in Titans but forgot where it is

[xsvenson]

YAML looks like the Devil's own format. Quite why anyone would condone it is a mystery. XML is another of the Devil's creations though. Something similar to JSON would probably be quite nice.

Cas

This statement is a bit ironic, considering json is a subset of yaml, which is the Devil's own format
Just saying ...

[princec]

YAML looks like the Devil's own format. Quite why anyone would condone it is a mystery. XML is another of the Devil's creations though. Something similar to JSON would probably be quite nice.

Cas

This statement is a bit ironic, considering json is a subset of yaml, which is the Devil's own format
Just saying ...

JSON without the unnecessary quotes would probably work quite nicely.

Cas

[ReBirth]

Just say thanks!

[Eli Delventhal]

JSON is like. YAML is pretty good. XML blows hard. I like JSON because it's closest to the data structures I expect to see in memory. There are a lot of parsers that will just turn {} into HashMap and [] into Array. Then it's ultra easy to go through the data in code. I also find it very readable. I agree the quotes that can be annoying, especially because in straight javascript you don't even need them ( {key: "value"} is totally valid). I personally wouldn't make my own version of it though because then you can't use convenient sites like jsonlint.com and the sort.

The code looks nifty enough. I personally have never found much benefit from taking code from other people, but who knows. Maybe if I decide to use a VBO I'll look into your approach.

[jezek2]

I don't find alternatives to XML readable. Previously I didn't like XML, but realized it was mostly because of bad schema that isn't human friendly. If someone take care to make it nice (eg. more usage of attributes, no DTD/CDATA and other mess, etc) then it's quite nice actually. The verbosity and syntax also make more obvious what is data and what is the rest.

[princec]

Hm it's subtle but I find this more readable and certainly a bit easier to type and probably parse too than the XML alternative:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41

<animation name="crab2.animation">    <label id="start"/>    <frame i="spriteimage.crab2_01" d="1"/>    <frame i="spriteimage.crab2_02" d="1"/>    <frame i="spriteimage.crab2_03" d="1"/>    <frame i="spriteimage.crab2_04" d="1"/>    <random>       <dest>start</dest>       <dest>start</dest>       <dest>start</dest>       <dest>start</dest>       <dest>start</dest>       <dest>start</dest>       <dest>start</dest>       <dest>start</dest>       <dest>pinch</dest>    </random>      <label id="pinch"/>    <frame i="spriteimage.crab2_05" d="1"/>    <frame i="spriteimage.crab2_06" d="1"/>    <frame i="spriteimage.crab2_07" d="1"/>    <frame i="spriteimage.crab2_08" d="1"/>    <frame i="spriteimage.crab2_05" d="1"/>    <frame i="spriteimage.crab2_06" d="1"/>    <frame i="spriteimage.crab2_07" d="1"/>    <frame i="spriteimage.crab2_08" d="1"/>      <frame i="spriteimage.crab2_05" d="1"/>    <frame i="spriteimage.crab2_06" d="1"/>    <frame i="spriteimage.crab2_07" d="1"/>    <frame i="spriteimage.crab2_08" d="1"/>    <goto id="start"/> </animation>

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40

animation {    name: crab2.animation        label { id: start}        frame { i: spriteimage.crab2_01 d: 1 }    frame { i: spriteimage.crab2_02 d: 1 }    frame { i: spriteimage.crab2_03 d: 1 }    frame { i: spriteimage.crab2_04 d: 1 }    random {       dest "start"       dest "start"       dest "start"       dest "start"       dest "start"       dest "start"       dest "start"       dest "start"       dest "pinch"    }        label { id: pinch }        frame { i: spriteimage.crab2_05 d:1 }    frame { i: spriteimage.crab2_06 d:1 }    frame { i: spriteimage.crab2_07 d:1 }    frame { i: spriteimage.crab2_08 d:1 }    frame { i: spriteimage.crab2_05 d:1 }    frame { i: spriteimage.crab2_06 d:1 }    frame { i: spriteimage.crab2_07 d:1 }    frame { i: spriteimage.crab2_08 d:1 }    frame { i: spriteimage.crab2_05 d:1 }    frame { i: spriteimage.crab2_06 d:1 }    frame { i: spriteimage.crab2_07 d:1 }    frame { i: spriteimage.crab2_08 d:1 }    goto { id: start } }

Cas

[nsigma]

JSON without the unnecessary quotes would probably work quite nicely.

Cas

Quite agree!  The patch script syntax I developed for Praxis is influenced partly by JSON, but more as if it had been called TON - (ie. TCL Object Notation).  The structured string approach of a typical TCL parser means no colons, and no quotes unless the key or value has whitespace.  I find this simple, quick and intuitive to work with by hand - unlike XML! 

Obviously, what I have is useless outside Praxis as is, but the general principle is pretty simple.

[Chromanoid]

I always wonder if a LISP like notation would be nice for games. One could easily combine data with some light logic and one could even precompile data for faster loading. I never used Clojure, I wonder how big its jar is. (edit: the slim version is 840kb)

[kilvati]

Json could also be simplefied to:

1   2   3   4   5   6   7   8   9   10   11

animation {     name: crab2.animation,     parts: [         {name: "start",  d:1, base: "spriteimage.crab2_", frames: ["01","02","03","04"]},         {name: "pinch",  d:1, base: "spriteimage.crab2_", frames: ["05","06","07","08","05","06","07","08","05","06","07","08"]}     ],     loop: [         {item: "start", chance:"100%"},         {item: "pinch", chance:"15%"}     ] }

[princec]

That wouldn't map very well to my internal structures though

Cas

[sproingie]

Here's why XML > sexps (sometimes):  There's a syntax error in the code below.  Tell me which construct got too many close parens:

1	((foo bar (blah (foo (abc def) blah (foo (xyzzy abcd)))))))

Okay, it's contrived.  But the fact is, no matter how meaningful the data, the parser has to get all the way to the end to report that there's a balancing error, and it still can't tell you where it is