Graphics are in and I've tweaked various gameplay elements so it's properly playable. Still no meta-stuff like menus, restarting the game, and such though.

Download here: http://www.secondintention.com/files/gasbags-v2.zip

To run it you'll need:

* DirectX
* VC 2010 redist

It looks like this now:



[Edited to change the static image to an animated GIF as per Hempuli's awesome examples]

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

You can reconfigure the keys in config.ini

The idea is to destroy the other balloonist's basket with bombs, but because they bounce of the balloon, you usually need to deflate their balloon with caltrops first. When that happens they crash and you have a window of opportunity to bomb them.

If you're the one that gets deflated, hammer your up key to re-inflate your balloon and get back in the air.

There aren't any constraints on bombs and caltrops yet so it's a bit spammy, but I think it's becoming fun. I've also left the wind out in this version until I can put in a way of visualising it.

Have fun!

Will

hehe - that's a nasty one

Put together some very simple silhouette graphics in PS, so I thought I'd throw them together into a mockup before I go and try and put them in-game.



I'm not convinced that colour is the right thing to do - I was considering silhouettes against a greyscale or sepia tone background, with some scratchy movie filter over the top. But I'm not sure if I'm going to have time for that, and the above is at least somewhat presentable, and gives me something to edit and refine.

Hopefully the airmen from the previous post will get involved as simple stick figures!

Will

There are certainly people doing things publicly with it - e.g. here:

http://cellspe-tasklib.sourceforge.net/

The instruction set has a good mix of float and integer instructions, with support for 32 and 16-bit integers and a handful of bytewise instructions too. It's also easy to mix float and integer processing since the registers are untyped and conversions (cflts/csflt et al) are straightforward.

Will

I like the first one - the second has the "faux 8-bit" fonts which are neat, but look weird given the higher resolution of the sprites and other UI elements.

Will

Works well here - I didn't have a problem with seeing the swords but maybe adding a "ting" or shimmer animation to the blades would help?

I think it might be worth adding a faster step, either as an option or replacing the existing step - fencers move pretty fast (think biding time vs. explosive movment) and while the sidling animation is really funny, it seems at odd with the speed of the lunges.

My 2p.

Cheers,

Will

Nice impact - I like the flat side where it's splashed against something/someone.

Thanks for the heads-up! I checked (briefly) for derived quantities which needed to be updated and didn't spot any, and I guessed that with an iterative solver it's likely to be able to cope with objects starting in slightly non-physical positions.

If it all goes horribly wrong, is the right way to destroy the fixtures and create new ones?

<snip interesting discussion of light cones/slow data acquisition>

It would make perfect sense in a space combat game as opposed to a deathmatch one. There's some great combat design in Elizabeth Moon's novels involving light lag, incomplete scan data, and short/long range FTL jumps.

I've often thought that would make an interesting game - I have pages of notes on how it might work and whether it would be fun. My gut feeling tells me it'd be obscure, but if you make the simulation rich enough fun might just emerge.

Sublight was supposed to be a step on the road to this, but I never found time to work on more pieces for it. Ah well.

Thanks for your earlier description of the event tree - I think what I wasn't getting was whether it was fully discrete, or whether events could come in at any point in time - so you jump -10s, but you can start from any time rather than at 10 second intervals.

The latter would make it possible for the tree to grow very large, but since you have a limiting factor in that players only make so many decisions per second, it's probably not a huge deal?

How do you store player movement in the event tree?

Cheers,

Will

I'm happy because I can rescale my (Box2D) physics bodies between frames. At the same time I can also fix up the local anchors of any joints connected to the body so they stay in the "right" place relative to the rescaled body.

It's neat, and appears to work, but there's a nagging feeling that I might be breaking the laws of physics

Will

Messing about with Scientific Balloonists:



Will

The thing with modern computers is that you usually can't know enough about the machine state - there has to be an intermediary since they are too vast and complex to comprehend by yourself.

If knowing everything is really important, you might really enjoy working on retro platform - up to about Amiga/SNES level you can have a lot of control, and work with an assembler rather than a higher level language compiler.

Will

Speaking of that, when I use an inline function, the code will be inserted there and all parameter that are not references will be created as "local" variables and used there instead of getting pushed on the stack, right?

Keeping stuff in "local" variables is a language-level idea, they don't mean much at the CPU level. There are a certain number of registers, and data is loaded from memory into these registers, acted on, and stored back to memory. The stack is just another piece of memory.

On x86 CPUs there aren't that many registers to play with, so data spills to memory quite often. On other CPUs the register files can be much larger and more data can be held in registers. But it's always going to memory at some point.

So if I use references there, it shouldn't (possibly) consume anything cause it should be logically the same as inserting the code by hand and using the referenced variable directly?

I guess that's one way of looking at it. Watch out for sizes though - data which fits in a register should be passed by value as a rule. And making assumptions here can hurt as well - if you have a platform with SIMD registers (SSE, etc.) then passing e.g. a 4-float vector by reference might be *worse* than passing it by value.

squeeze every bit of parameter out of my sourcecode. Or atleast to make as minimal and performant as possible without wasting any time you'd use otherwise.

I hate to say this, because I think performance is important (I have to for my day job) but have you profiled the changes you're making?

Inlining willy-nilly is a mug's game - if you're lucky the compiler will ignore your hints and inline those functions which make a difference, as determined by its own analysis. If you're unlucky then you'll just end up with bloated code, which puts more pressure on the instruction cache and may run more slowly as a result.

Inlining key functions as used in inner loops *may* help in critical cases, but profile before and after to make sure of that. Don't just measure FPS - that's pretty meaningless, but time the code over multiple runs with meaningful datasets using a high resolution timer (e.g. QueryPerformanceCounter on Windows) and see how many microseconds you're shaving off or adding on.

There are good structural reasons not to inline unless necessary - it tends to force dependencies which you could otherwise avoid, which makes compile times longer and hurts your productivity.

All that said, if squeezing performance from code is what floats your boat, then by all means do it - it can be really fun - but keep an eye on the timings to make sure you're going the right way. It's best if you have some meaningful performance target to achieve as well (my game will run in X ms/frame with Y entities on Z platform) or similar.

My 2p,

Will

I'm guessing this is a bigger deal than it sounds, what with time vortexes and causality and all that?

call by reference in C++ doesn't require any address variable on the parameter stack?

Too many possibilities to predict:

* Call could be inlined, the compiler could leave all parameters in registers if it had enough. Note that the inline keyword may not have any bearing on this.
* Ditto when code generation is deferred to link time, with a broader set of functions.
* Calling convention could pass some parameters in registers and some on the stack.
* Compiler *might* spot that a reference parameter is unmodified by the callee and pass it by value.
* Call could be to an out-of-line function, in which case the object address has to go somewhere.

References aren't magic, they're (for all practical purposes) addresses with some compile time restrictions. If a function needs to know where something is, someone has to tell it.

I can't see that it really matters apart from:

* Idle curiosity.
* Writing glue code to e.g. call native functions from script and vice-versa.
* Writing really super-optimal code in the tightest-of-tight inner loops.

And in the latter case you'd probably be more worried about inlining (to make the call and associated parameters go away) than you would about how references were passed?

Will

I like the animations - those little feet are adorable.

Will

I like it a lot too, charming graphics and neat effects - the physics-ey rubble is particularly nice.

Similarly to OneMoreGo I found there isn't much protection against digging down a long way - I went down outside a section of metal-walled high-tech rooms and couldn't find any way to get inside them - they only let me in at the top. So then my alternative was to dig steps and climb back up - slow going.

Maybe some kind of emergency escape would be good - maybe if you aren't carrying the ball, you can (maybe in some limited way - pickups, once per life, etc.) boost straight up until you hit a non-diggable block. It strikes me this would make digging down a lot more fun, since you wouldn't have to worry about coming back up.

Just my 2p.

Will

Thanks for giving it a try, much appreciated!

I think if you give ever so slightly more control it'll become difficult to control but awesome.

Try changing line 5 of resources/entities.ini from:

Code:

Aircraft {}

to

Code:

Aircraft { m_strafe_rate = 2.0 }

That puts the horizontal control back to "it sort of works" levels. There are other values you can play with on Aircraft as well, with defaults as follows:

Code:

m_strafe_rate = 0.3
m_burn_lift_rate = 7.0
m_vent_lift_rate = 4.0
m_zero_lift_rate = 8.0
m_min_lift = -3.0
m_zero_lift = -0.3
m_max_lift = 2.0
m_force_scale = 8.0

Maybe I didn't really understand how to play it,

It's more that there isn't really a game there yet!

The strange yellow things are just Box2D drawing lines between pairs of objects which are participating in collisions - they don't have any effect on the simulation.

The pulling comes from the big boxes with "wind" blowing in them. One pulls you to the left, and one to the right - the idea was to use those for horizontal movement, so you can control your altitude directly, but not your direction, as per a real balloon. But I think that's not really obvious at the moment.

can just keep dropping bombs and get essentially what amounts to an engine.

Yeah, that would make more sense with limited bombs. Here the idea was that height is important, so you could drop a bomb (or possibly a bag of ballast) to get some quick lift, but at the cost of wasting a weapon. Again, lots to do there

Perhaps you could have air currents that change slowly over time, and that's what would allow you to float left and right

That's what the wind is supposed to do, yep. It just doesn't read right yet since there aren't any visual cues. I think I'll work on proper rendering next and then it should be easier to follow what's happening.

I'm not sure about propellors - I like the winding down/winding up though, that's cool. If I get time to make more than one class of vehicle (balloons, dirigibles, dragons??) I'll definitely give that a try.

Thanks again for the feedback, I really appreciate it!

Will

You could presumably go back in time to before you broke it, and repair in the then-now the now-future time stream? Try not to step on any butterflies though...

I think this is probably the most interesting idea in the compo, it makes my head hurt to think about it. Is the event tree fully "analogue" so you can snap at any time? Does it blow up if players do lots of snaps, or does the 60 seconds put a practical limit on that?

Will

Do a barrel roll!

Great title - it says it all with so little. I hope it comes to fruition.