Works nicely here, I didn't manage to get stuck which is a good thing The character art is really cute, although Verne's grimace sort of turns into a smile when he digs - I don't know if that's what you want, but it's quite cute.

I think some kind of graphical depth indicator between the two playfields would be a really good idea - the numbers don't generate enough tension since you can't see where you are in relation to your opponent easily.

Will there be any player interaction? Monsters you kill go and bother your opponent, that kind of thing?

Will

That looks lovely - I like the space plants/towers, although they don't seem to match the perspective of the blocks.

I also want to tell the despots that they're cute, but then they'll hate me!

Not given up yet - although that was a long gap, sorry.

There's now a simple playable demo at:

http://www.secondintention.com/files/gasbags-v1.zip

It's still using Box2D debug drawing:



so it's sort of sparse and busy at the same time.

To run it you'll need:

* DirectX
* VC2010 redist

Player 1's keys are WASD plus Q to drop bombs.
Player 2's keys are Arrows plus right CTRL to drop bombs.

You can only destroy your opponent's balloon by bombing their basket. The two horizontal strips are wind regions which blow you left or right, so most of the gameplay (such as it is!) involves getting into the right wind region and being above your opponent. There is a degree of left + right "air control" but it's not very strong, the wind is what you really need to use.

If you go outside the Box2D world (you can't escape at the top and bottom, but you can at the left and right) then you die. There's no scoring or restarting yet so you'll need to quit the game and restart.

I'd be really grateful for some feedback - I don't think the play mechanics are much cop yet, but I like the balloon control and it'd be nice to know if it works for you, or if it doesn't.

Also if you fancy it, have a play with resources\entities.ini to add more strings and such to your balloons

Cheers,

Will

Is it better? Doesn't look so smooth now though...

I think it is better, yeah, but that's just my opinion Some kind of second-order fade out as it approaches the horizontal would make it look smoother without making it less snappy if that's a concern.

Looks good with the art in too.

Will

I guess, I just don't understand the fetish people have here with rolling their own.

There's the sheer pleasure of it - lots of hobby coders on here, and writing the code can be an enjoyable part of making a game as much as the art + design can be. If the end goal is to make a game, and the code is just a means, then there are maybe better options than C++.

- If you have a very specific need, coding to that SPECIFIC need instead of in a generic fashion can easily be faster than a generic library like boost or box2d

Definitely agree with this one - faster both in terms of runtime performance and development time, since you don't need to make something which handles every use-case in the way STL and Boost do.

Plus if you need something from Boost it can be much quicker (in compile time terms) to isolate it from the rest of the library. I remember being appalled at how much the compile times shot up when I wanted to use boost::type_traits to infer POD-ness in a large project, but if I extracted the concept of that code into my own header it was fine.

I have reservations about boost being over-engineered for a lot of game problems, but that's another topic altogether.

Will

That approach (one bit per object type) works well if you only have a few object types, and at most one of each object in a square.

@stef1a: It looks like you're trying to build a map a bit like the Ultima games, where you build smaller terrain blocks and stitch them together into big maps?  I seem to recall they held objects in a linked list, with maybe one list per block?

It may be worth looking at e.g. Exult to see how they do things?

HTH,

Will

A good place to start (probably *the* place to start) for learning about post-processing is Masa Kawase's paper on the effects in Wreckless/DOUBLE-S.T.E.A.L. He really was the first to bring all this together into one game, and the paper is very still useful and relevant now:

http://www.daionet.gr.jp/~masa/archives/GDC2003_DSTEAL.ppt

There's a good illustration of depth of field by blending between different levels of blur in the paper.

If you want to take it further, there are two main problems with that technique:

1) The filter shape is a Gaussian not a proper circle-of-confusion, so it doesn't look like real lens bokeh. Particularly noticeable with HDR.

2) You get leaks between foreground and background, since the blur isn't depth-aware.

As you've noticed, you can do what ATI called a "steerable blur" (IIRC) where a function of depth drives the kernel radius. That helps with leaks, but doing it properly is expensive: You really have to sample from a point in the neighbourhood based on it's radius not yours, and you only accumulate the sample if its depth is nearer - convolution rendering, effectively. I think in the ATI paper they test the depth, but they have the radius around the centre point not the candidate point?

With this technique you also need lots of points to make the blur smooth, or you have to have a small radius. For KZ2 we used 36 samples. There's a bit about it in this paper, although it doesn't go into much detail so I'm afraid I can't either, sorry

http://www.guerrilla-games.com/publications/GDC09-vanderLeeuw-KZ2SPUsCaseStudy.pdf

I can at least say that writing the "blurriness" into the alpha channel of the source image is a good way to avoid multiple texture lookups.

Hope this gives you some pointers! If you're at GDC and want to chat about any of this stuff let me know.

Cheers,

Will

PS: The Wii is awesome, you can do so much stuff with it.

That's gorgeous Ivan, I really like the lo-fi/hi-fi combination of the flat shading and bloom.

Will

Not a lot done this weekend, but I did add support for wind regions. I also changed the physics setup so that one game entity (the balloon) can be made of multiple physics components, all nicely data driven.

Typical coder mentality - spend time working on engine not gameplay But it's fun, and it should make taking further steps a lot easier.

Will

My Box2D integration is growing slowly but surely. I can now create game entities that have multiple physics components (including sensors and joints) as opposed to have to stick multiple entities together. And it's (mostly) data driven.

Still lots of wrinkles to iron out (collision events for different components, for example) but quite promising so far

Will

Thanks! And the ALT-mode... still acceptable?

Yes, it works fine, maybe it's that it's less fluid/smooth than the normal flying? A bit of noise on both movement types would probably make it all look a lot more real.

So you mean that a it moves more in a shorter amount of time? And... what's "tighter" in this context?

I think possibly I was saying the same thing twice Perhaps what I meant to say was that the accelerations should be a bit higher - so rather than changing the speed too much, you just reach the target speed faster. That usually makes the controls feel more responsive, which is I guess what I mean by "tightness" - that the feedback loop between player action and game response should be tight.

Not that you want this in all games, but because your planes are small fighters rather than weighty great bombers it seems like a good idea. On the other hand, you want to differentiate the player and plane controls. I dunno. Probably the kind of thing where tweaking some numbers makes a big difference in feel.

Thanks to both of you for the explanation about grappling etc. - that'll teach me not to digest the whole thread properly!

Cheers,

Will

Well spotted, C++ it is. Which means uploading binaries is a pain since people need to install the VC2010 runtime and whatever version of DX I'm using I guess I should make an installer.

I have been thinking about gameplay - I was originally intending to have dirigibles, but there is a key advantage to hot air balloons - they don't need to change ends when changing direction. So balloons for the moment.

I want to have some kind of combat - someone else is doing balloon racing - but I'm not sure what form that would take - the problem with balloons is they're really fragile! I was thinking about the following:

1) It's fairly easy to go up and down.
2) It's fairly difficult to go left and right.
3) There's changing wind in the game, in horizontal bands.

So then maneuvering is more about using buoyancy to get into and out of the right wind band.

For combat, I figure that being above your opponent is good if you're in a balloon, so:

4) You can drop caltrops and bombs from your basket
5) Caltrops puncture the balloon and cause it to leak/sink down
6) Bombs bounce off the balloon but damage the player

So the idea would be to get above your opponent and caltrop them until they're on the ground, then

7) They furiously try and inflate the balloon while
8 ) You try and bomb them to death with the basket vulnerable.

If you bomb them, you win. If they reinflate the balloon, they go back up and it carries on.

Things to throw into the mix:

9) You have N (3?) bags of ballast you can drop which give you lots of temporary lift - good for getting out of trouble
10) Maybe when you run out of bombs, you have to pick up more from the ground?

This will likely all change as it gets implemented, but it gives me something to aim for. If this turns out to be fun I'd like to be able to add other vehicle types - dirigibles, planes, dragons, ... But that's unlikely in the compo timeframe.

Cheers,

Will

Well, my work milestone is out of the way so I've had some time to play with Box2D a more:



The basket and envelope are connected by spring joints so there's potential for terribly bad landings. Doesn't look like much, but it's quite entertaining to fly around at the moment.

Cheers,

Will

If you are using POD types, and a decent STL and compiler,

I thought there was mention of console dev going on? There are good reasons not to use some of the console STL implementations - EASTL was built for a reason, after all.

You also get problems with debug builds - where the compiler can't/won't optimise to that level, but you still need a game which runs fast enough to play. All those layers of little inlined accessors can be bad news in debug builds.

Will

Sounds good. I used to fence so I'm always excited to see games which take swordfighting seriously. Will cancels let you do feints and one-two attacks?

Will

Runs fine here, the collisions are quite vigorous though! Two other things caught my eye:

* The split playfield is *really* nice - great job!

* I think the balloon movement would be more interesting if X and Y behaved differently - at the moment it feels a bit like a top down game with side-on sprites, if you see what I mean?

Will

Great video - it looks like a demake of the zero-G bits of Dead Space

Do you always head towards the nearest piece of ground (like in Mario Galaxy) or float until you touch a new piece? I couldn't make it out from the video.

Will

I meant to suggest changing the shoes - so I think they're a huge improvement I think the more "normal" shoes help ground the whole witch-in-school-uniform a lot better.

Statue sketch looks good as well.

Cheers,

Will

Not much to report, but I managed to fix my SVN repository and cobble together some code to open a window and create an entity. No control or anything yet, but some kind of blank canvas exists.

I'm a bit shocked that the last time I used this codebase for anything was the cockpit compo (I think - whichever one was just before GDC 2009).

Feels like there is a lot of aerial games this competition, too... or is it just me?

I think you're right - possibly it's a good topic because it avoids the need to make levels? Aerial games also offer quite a lot of freedom of movement which is good in MP.

I thought there were quite a few Victorian/Gentlemen games as well, which I put down partly to general TIGS preferences, and partly due to the unconscious influence of Derek's compo pic 

Cheers,

Will

That's definitely got the Star Control vibe already - one of my all time favourite games. Can't wait to see where this goes.

Are you planning to have very assymetric ship abilities and strengths? I thought the points mechanic for picking sides added quite a bit, and it was also fun to try and beat large tough ships with less likely ones (Pkunk ftw!)

Will