I think you meant to reserve your praise for pure functional languages like Scheme or Haskell, which I don't think are necessarily harder, but are definitely a bigger jump from the norm, particularly for making games.

Just for the record: Scheme does allow destructive updates, just like Lisp, and is therefore not pure.

But, yeah, as much as I like Haskell, using it for something as state-heavy as a game scares me a little. Increpare did a few things with it though, this link should produce some of those with source code: http://www.increpare.com/tag/haskell-programming-computers/

This sounds like a really nice thing, do keep us updated. Since you mentioned Wesnoth, what is your stance on randomness in the game? Also, I guess there won't be a single player mode?

Muku, I think OGRE by default uses OGL's ordering. Can't swear to it, though. As usual, answers from there aren't really forthcoming.

That's what this page says too. And it also says you should multiply matrices from the left. Shouldn't it be like the code below, or am I missing something?

Code:

    VECTOR2 mousepos = gui::System::getSingleton().getNormalisedDeviceMouseCoordinates();
    near_pos_h = inv_proj * near_pos_h;
    far_pos_h  = inv_proj * far_pos_h;
    near_pos_h = inv_view * near_pos_h;
    far_pos_h  = inv_view * far_pos_h;

I've done this before (not in Ogre though), it's fiddly.

Code:

   VECTOR2 mousepos = gui::System::getSingleton().getNormalisedDeviceMouseCoordinates();
    near_pos_h = near_pos_h * inv_proj;
    far_pos_h = far_pos_h * inv_proj;
    near_pos_h = near_pos_h * inv_view;
    far_pos_h = far_pos_h * inv_view;

Just checking: shouldn't you multiply the matrices from the left? Not sure which convention Ogre uses.

This looks neat. Though I can't help but remark that C++, with its rigid edit-compile-link-run cycle and dog-slow compilation times, wouldn't be my first choice for what they call "creative coding". Fast, if possible even instantaneous feedback is what you want when you do this kind of experimentation.

Well, I guess neither of you have to hand this in...

That sucks. What's wrong with her? By the way, don't you use some source versioning system? Just go back to the old revision.

Addendum:
I would also like to add that if you're using C++, binaries may not even be an option.  Differences between compilers in areas like name mangling and object layout will not just tie your binary to the compiler it was built with, but maybe even the specific version of the compiler it was built with.

Yeah, that's a nasty point. One way around it is to write the library in C++, but provide a C interface to it.  The ODE physics library does it like this, for instance.  As a nice side effect, this makes it very easy to create bindings to other languages.  My Cosyne library, which is written in D, uses the same approach.  Of course it depends on whether the design of your library allows it; if it's heavily inheritance-based or templated, this is probably too much trouble.

[becomes a part of the program]

why do you want to require OpenGL 3.1 or even higher? It seems that would exclude a large portion of the indie developer and player base who don't keep their machines at the bleeding edge...

Actually, 3.1 is supported by hardware as far back as ATI HD2000 series and NVidia 8 series cards.  Believe it or not, those cards are approaching 4 years old.  I would not consider those "bleeding edge".

My main desktop PC has a Radeon 9500. My laptop is a Dell with an Intel graphics chipset which doesn't even handle multisampling. Need I say more? A 3 years old graphics card is quite recent by my standards. Still, I can play most if not all of the games which are posted on TIGSource without problems. Indies aren't tech-heavy typically. I think it's foolish to "follow the new standard" for the sake of it if the game doesn't make use of the new features. Anyway, as far as I recall OpenGL was seen as a huge disappointment in the game development community since it mainly pandered to the needs of the CAD crowd.

Yes, I would release the source.

Fine, then Linux should already be no problem: just tell people to install the development packages for SDL and let them compile from source. I have no experience with Mac OS X, but I would hope that it should be similarly simple? And for Windows, provide your library as a DLL and include the SDL .dll with the binary distribution.

Are there not other options, such as installing SDL in a non-standard location, renaming files, running them through some kind of obfuscator, or simply telling the user that it will overridde any version of SDL installed in a standard location?

Installing it isn't really the issue... once you link statically, the library becomes a part of the program. I guess you could play some foul tricks with the preprocessor to give the statically linked version of SDL some unique prefix in order to avoid clashes, but really, that's all very hackish. The nicest solution should be dynamic linking, by and large. Go ahead and read up on the distinction between static and dynamic linking, it should clear some things up.

Oh, did you know Mac doesn't have right-click either? My goodness, their users must be incapable of doing anything!

I resent Mac just as much :D

Let's just say I'm not surprised

And I find it amusing how you seem to state that simple Flash games are invariably crappy. I guess good gameplay is directly dependent on processing horse-power.

A simple game by definition lacks depth and is therefore crappy.

Have you by any chance tried Go? The rules can be explained in a few minutes. The game is incredibly deep.

No simple game could ever hold the interest of a complex PC player like me for long. I'm sure more casual gamers can entertain themselves on Pong and Tetris for years and years...

So you concede that many people entertain themselves perfectly fine with web games, but since those don't suit your taste, you proclaim categorically that "the web is not a gaming platform"? Man, that's unpleasant. I know it's hard to swallow, but you are not The One Arbiter Of Good Taste And Final Truth. Leave it to people to decide for themselves what they like and what not.

2. Link with SDL dynamically, i.e., include the SDL DLL with the distribution of your library. In that case, I guess it's easiest if your library is a DLL as well, though statically linking might work...

I wouldn't make a library specifically for Windows.
I would probably develop it on Linux or Mac, and I would make sure it would be portable for all three.

That wasn't the intention. I meant DLL generically (though from an admittedly Windows-biased view) as a shared library, whether it is a .dll or .so or whatever it is on OS X. While the implementations differ between the platforms, the basic concepts of dynamic and static linking are the same.

An important thing which you haven't mentioned yet is whether you plan to release source. This might change your distribution strategy, as on Linux the easiest thing is generally to let the user compile.

By the way, this is off-topic and strictly out of curiosity: why do you want to require OpenGL 3.1 or even higher? It seems that would exclude a large portion of the indie developer and player base who don't keep their machines at the bleeding edge...

Basically you have two options.

1. Link with SDL statically. Because of the LGPL license, this means you have to make your library open source as well. Besides, if you choose this route, the user of your library could be in for a world of pain if they choose to use SDL too, for other functionality, so you should be very sure that that will never be the case or is not problematic.

2. Link with SDL dynamically, i.e., include the SDL DLL with the distribution of your library. In that case, I guess it's easiest if your library is a DLL as well, though statically linking might work...

I always thought coder was just a more slang term for programmer, and any difference in meaning is just personal interpretation... In fact I've never seen huge discussions on that subject, seems odd to me.

Might have to use this.

Would be cool, that's what I made it for

Anyway, if you have any questions regarding synthesis in general, I'd be happy to try and answer those too. I racked up quite a bit of knowledge on the subject while making this, browsing the Music DSP archive, reading Julius O. Smith III's online book on filters and countless papers...

The only difference in that version I can spot is that the guy moves faster. The awkward pause between keypress and response is still there.

By the way, if just holding up is an easy way to beat your game, I think you should redesign it so that this no longer works instead of crippling the control scheme. Put some obstacles in the middle, or encourage the player to pick up some objects which lie off the center.

The movement is extremely wonky... when you press a direction key, the guy first moves a little bit in that direction, then stops, then starts moving again. Evading crates is basically impossible with that kind of delay. So I found the best strategy was generally holding up and hoping that nothing would cross my path

Uh... where's the link?

I don't see why it couldn't or shouldn't be. By the way, have you heard of a thing called Newgrounds, or Kongregate?

I have, and they prove my point. Any game implemented in Flash would be better if it were not.

I think your zealotry clouds your judgment. Care to actually give some arguments? There are lots of small games for which the web is a perfectly fine delivery platform.

As for your approach of "opening executables directly from the browser", well, that's essentially what Flash, Unity and other plugins do, minus the hassle of making the user choose a download location etc, plus some basic security guarantees. They download not native binaries, but some bytecode representation, but I don't see how that's necessarily a disadvantage; in fact, the portability that this approach gives you beats native-compiled desktop applications hands down. Few other platforms make it so easy to deploy for Windows, Linux and Mac at once.

To get an idea of what would be possible, let me point out that the video below was made with Java.





So with javascript and WebGL on a decent browser...

It should be pointed out that that was made with Processing, so it's entirely possible that it was rendered offline. In general, though, Java isn't really slow anymore; it has gotten some of the world's best JIT compilers. In these micro-benchmarks, Java is within a factor of 2x-3x of C++:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=javasteady&lang2=gpp
(Memory usage is a different story of course.)

By the way, Javascript is also getting a nice speed boost with V8 and Tracemonkey, the new JS engines by Google and Mozilla. Combined with WebGL, this is starting to sound really interesting. Probably it will take some years to mature and attain wide adoption though...

when i said random i meant in general. Like you could make it anything. unless there is a generally accepted value that most people put it on, in games the value is randomly chosen?

No, it's not. I just tried to explain this above: by changing Bz, you automatically also change the field of view, which has a very distinct effect on the final rendered image. Take a look at this page (left column):

http://strlen.com/gfxengine/fisheyequake/compare.html

That's what happens when you play with the projection distance/field of view angle. So adjusting this parameter is often a conscious design choice.

Wrote a HLSL shader, but had a weird bug. But it still looked so cool. Although it is a bug, it is probably the neatest looking bug I've ever gotten. And that makes me happy 

I recorded a video of it:

Whoah. You should make a glitch 3D shmup where every level is based on another buggy shader.