Oh, this is just awesome. Really great use of the touch screen.

I don't see why not? What I did was just cheap out and say "all level packs live in the same directory as the program executable".

Because that's strongly recommended against on osx (where an app might not have permissions to write to the directory it's in).  OSX recommends that you save all program files to a particular directory that's a bit out-of-the way and so isn't something you'd expect them to navigate to, so you'd maybe be best off setting up a new folder in the user's documents folder and maybe setting up file-associations so they can double-click on the files to open them if you want them to share the things. (this would include registering icons/&c.)  OSX also tends to enforce that there's only one instance of an application active at any time, so command-line stuff wouldn't suffice.  And what if they try to drag a level file onto the application window?  If you store the levels in the binary directory then they'll have to navigate into the package to find them, but if you store them in the application package directory you risk shitting up their applications folder if they have the application in it directly (as do most programs do) rather than in its own folder (which is unidiomatic and against osx guidelines pretty much).

Hm, so let me think about this for a minute.

So as you point out, my way of doing things will fail on os x under a particular situation: Jumpman.app is installed directly in the /Applications folder; and it is run by a non-Administrator user.

Though I could totally imagine this happening, and it hadn't previously occurred to me, this is not a scenario that worries me very much, I don't think. First off, in order for this to happen the user would have to actually be using OS X's multi-user feature. Second off the program would have to have been installed by someone else-- if the user lacks Administrator privileges sufficient to write to /Applications then they obviously can't install the game there either. Finally the program would have to have been installed "wrong"-- I'd have expected the user to install the program by dragging the whole folder (which would come along with its own permissions) into /Applications, rather than just the app. (This last thing wouldn't help in the case of Jumpman specifically because checking the download package only the file owner has permissions to write to the Jumpman directory, but if I'd thought ahead I could have 777'd the directory between zipping it. Actually the problem's a little worse than that, Jumpman will break completely in a multi-user environment because only the application file owner will be able to write to the save-game file. Um, oops. I think I was expecting users would usually be running the game out of their Downloads directories...)

Anyway my solution here would be to look at this as a distribution problem- I think you could avoid this entire scenario if you just distributed the game in a way that makes it unlikely someone would install the app "wrong". One way to do this would be the sort of "poor man's installer" that many OS X applications use. Many OS X applications are distributed by putting the app to be installed into a .dmg along with an alias to /Applications, and giving the .dmg's Finder window a background image that looks like a big arrow-- something like this:


If you do this, you could have the "drag this" file just be the entire application directory. You could then have the application directory contain a subdirectory something like "user files" or "level packs", which you have already set to have the appropriate permissions. (You could also just use a real, .pkg based installer, but that's annoying and it might screw over people who again don't have write access to /Applications).

Failing this, the only really "right" way to solve this would be to set the "levels and such are saved here" directory to be a directory which on windows/linux is the application directory, and on os x is somewhere under NSHomeDirectory(). This would have the disadvantage that the users would have no idea where their files are saved, but you could maybe get around this if your level upload/download mechanism were built into the app-- and if the users never see the files, there would be the additional advantage that users would not feel tempted to expect those files to behave like the files of a normal application (such that you can drag them to the dock, etc). This still seems like overkill to me though, storing files in /Applications may not be what Apple's standards recommend but again I think people expect games to violate OS standards in certain ways.

---

One last thing. Let's compare how an existing game handles this exact problem we're talking about: Braid. In Braid, the way that you run a level pack is that you open up the application resources directory, go a couple levels deep, create a directory called "universes", and then drag the level pack in. Then, you have to launch the program with a --universe command line argument; if you mistype this argument, the screen will flash and the program will silently quit. On the mac, this all means that you actually have to open up the .app package to install the universe, and in order to specify the command line argument you have to actually type it in in a mystery box in the little settings/launcher window that runs before the game itself. I bring this up to observe that using the level editor in Braid is an incredible pain in the ass. But: People do it anyway! There is a healthy third-party levels/mods community for Braid. The lesson to be learned here is that if someone likes a game so much they're using the level editor, they probably like it enough that they're willing to overlook a certain amount of bullshit. (In the case of Braid the mods community actually created their own third-party installer/uninstaller/launcher program for mods to get around the games' issues, and most of the mods online are laid out to be compatible with this installer program...)

Say you want to make a game with a level editor that will let people store and share levels; can you do that without writing platform-specific code?

I don't see why not? What I did was just cheap out and say "all level packs live in the same directory as the program executable". The editor creates them there, the user dumps them there when they download them. I don't have to think about the larger directory structure. Users don't seem to notice how simplistic this is, I don't think people really expect games to be "good citizens" wrt OS integration.

If you want to allow the user to share levels online from within the application, there's always stuff like libcurl.

So what I find is I can do graphics with ES-compliant OpenGL, input and sound with SDL, compile with MinGW for POSIX compliance, add one or two functions for things like filesystem management and hey, stuff works pretty much anywhere. Most libraries I'd want to use can be layered on top of that base. (See also my sig.)

Problems:

1. Base OpenGL is really very simplistic in terms of what it does with graphics. I'm not sure about which libraries to use if one wants to do graphics programming at a high level rather than OpenGL's ultra-low level, the ones I've heard of (OGRE?) sound questionable or like timesinks (I know some people who decided, okay, we're going to make a game, they spent a full year learning OGRE and never produced so much as a playable demo). All the game plans I have involve very simplistic graphics, so this isn't a problem for me, but if I ever want to attempt a different graphical style I'm not sure where to start.

2. The iPhone kinda throws a wrench in things. Graphics and sound code are easy enough to share with an iPhone app, and all the POSIX stuff works out of the box... but: The problem here is it's easy enough to abstract away things like controls or interfaces so long as the medium is more or less similar. Controls can be handled pretty much the same whether the button being pressed is on a controller or a keyboard, I could even imagine porting a game to a Wii or DS and just routing pointer or stylus stuff into the same function that on the PC would handle a mouse click. But the iPhone is just so totally different as a device from anything else it's hard to imagine where to start with cross-platform...ness. On controls you have no buttons at all, you have abilities you don't have with a mouse because of the multi-touch, you don't have abilities you would have with a mouse because the touchscreen is so imprecise and you can't use it without covering up whatever you're interacting with... you need to come up with an entirely different way of approaching controls, and it's probably the case that once you've done that your game design or mechanics will need adjusting. For GUIs, there's this entire set of interface primitives that don't exist on other platforms, and if you don't use those interface primitives your app will seem "wrong" both because of what people expect on the iPhone and because of the small screen. I think what I eventually decided is I can use one codebase, with abstractions as appropriate, for "all platforms except iPhone" but then on the iPhone I just need to maintain a parallel codebase so that I can make fundamental changes to the game if necessary.

There was a time when I believed C++ was a deeply broken language.

Then I tried using other things

...it made me appreciate C++ a lot more.

it's not a structure I was familiar with previously. 

Yeah, it's a little bit obscure.

You can compile Objective C source on Linux and Windows if you use gcc (mingw).

You will of course not be able to use Cocoa Touch classes on those other platforms.

I guess isn't this the exact situation the trie was invented for?

I'm not sure what you mean by "word objects".

[OUT OF DAMSELS]

AND ANOTHER THING: If I'm looking for my, uh, Biplane, why am I collecting Damsels? And why are they still simply a collectable? They could at least give us a wave before vanishing into pocketspace.

Maybe he is building a new biplane

OUT OF DAMSELS

It's immediately fun and has an good hook, but there's not a lot to keep pulling you back in once it starts feeling repetitive. There's never really a sense of tension. Maybe that's a good thing... It's easygoing, I guess? I kept playing longer than I get with a lot of flash games.

It got a lot easier once I figured out how to rocketjump

Goodness, a mac version! There's a pleasant surprise.

Professor Layton.

OH LOOK A PIECE OF TRASH. I'D BETTER GO BACK THROUGH AND TALK TO EVERY SINGLE PERSON IN TOWN AGAIN BEFORE I TRY TO PICK IT UP.

Hey so there is a demo of Machinarium available now and um it's really very good! The demo comes in mac and pc flavors. The game itself is still some weeks away apparently (EDIT: Website linked at the end of the demo says October 16?).





I checked for a thread on this but found only this old thread about the pre-order offer.

MCC is on the money here, you can roll your own low pass. More example code over at the wikipedia article:
http://en.wikipedia.org/wiki/Low-pass_filter#Algorithmic_implementation

Would you recommend this over just using the built in filter functions?

So I don't know much about OpenAL-- I've only used it on one project and in that case I was doing nothing but feeding it preprocessed audio data.

But were I in Glaiel's case and using OpenAL for a game, if there <i>are</i> built in filter functions I would definitely gravitate to using those instead of rolling something myself. OpenAL will have most likely found a way to make their built in functions more efficient than I'd be able to implementing something ad hoc.

If you're going to be working with raw sound values, as in OpenAL, it might be worth it to learn how to do low pass/high pass/LTI filters for real.

As I remember though you can actually do a cheapo low pass filter by doing a "weighted moving average". All you really have to do, each time you write a sample, is average it with previous samples. So do something like this:

#define WEIGHT 0.1
inline float ugly_lowpass(float in) {
static float last = 0;
last = in*WEIGHT + last*(1-WEIGHT);
return last;
}

Then run ugly_lowpass(x) sequentially on every sample you send to the sound card.

As I understand if you sit down and do the math this turns out to be equivalent to a low pass filter done "correctly".

http://lorien.ncl.ac.uk/ming/filter/fillpass.htm

EDIT: Some random thoughts on this code snippet: The closer to 0 the WEIGHT number is the heavier the low pass will be. Also the heavier the low pass is the progressively quieter the output will be. If this isn't what you want may want to compensate by turning up the volume, or adding echo. I think low pass + echo will give you something very much like the cliche "video game underwater effect".

You'll basically need to install XCode even if you don't use it because GCC comes packaged with it.

This is a bit lower level than any of my interactions with IRC have been. But what I would suggest doing is running Wireshark and snooping on the stream between the server and a "real" irc client. That way you at least will have a clear idea of what it is the real irc client is doing to get the server to talk to it.

I've used SDL a fair bit, it's ok for event and window handling, etc. Audio on the other hand, is terrible.

Well, come to think of it I do tend to do audio in a kind of weird way, so I may have a skewed perspective.

What would you recommend for audio, in place of SDL?

Speaking of which, there are surely some libraries which wrap that process (loading of images) up, no?

For PNGs I suggest LodePNG/PicoPNG. It's an entire PNG interpreter/writer in a single source file. Much easier to integrate into projects than something like libpng. There is some sample code for using LodePNG to create textures in my sig.

As for SDL, it's great for audio/input but I can't imagine using it for the graphics layer. OpenGL can do everything SDL 2D can with just a bit of fiddling, if you don't want to do fiddling then there are libraries to do the fiddling for you.

I'm still confused what the actual platform is here.

This is a ... browser game? So is it Flash? Unity? What?

Can you play it on mac/linux? Does it have the performance issues Flash games seem to on macintoshes?