Here is a timelapse of my entry. It shows some of the game at the end.

Ok, guys. It’s that time of the weekend. Download Put the Ball in the Basket and give it a try. Windows executable only for the moment; linux and possibly OS X builds later this week.

I swear, the hardest part of LD is naming my damn entries. Of course, that’s usually because they’re not worth naming. Here, though, the problem is different. What do I call this thing?

I also tried very, very hard not to use the phrase ‘build the level’ anywhere in the help text. Because by total accident I did LD #9 instead of LD #14…

argh !! the pigs are flooding the sea with the batteries, or cans ?, who knows =)

Been having a bit of trouble with matching up bitmaps to physics objects, so I re-wrote all my renderers to draw wireframes and solid colors instead of gradients and bitmaps. Solid 40fps, and you can switch between quality levels on the fly — a nice side-effect.

Bugs fixed, everything’s in place. Time to start whipping out some gameplay.

Unfortunately, I just spent the last hour reading up on the history of Texas’ annexation, because our sly governor just dropped the word ’secession’ in a public forum. omgwtfbbq. He’s clearly floating the idea for personal political gain, but still…the phrase “We have an excellent union, no need to dissolve it. But…” hasn’t appeared in serious American political discourse in, what, 150 years? An odd notion to even entertain.

I’ve spent most of today drawing some tiles and getting super-realistic-blob-bouncing-physics to work.

Here’s all I have to show for it in screenshot land.

I promise you there’s a game here, I know what’s going to happen, how it’s going to fit into the theme and all that crap. First though I need to add particles… (They are the most important part of any game.)

As the end of day one approaches dauntingly, I’m getting progressively more hopeful that I might have something to show by the end. Saying that, I have very little to show-off at the moment, as there is absolutely no finese to anything I’ve been working on – it’s all just a jumble of quads in various sizes and colours. FUN!

It took me ages to come up with a decent idea (I wasn’t particularly pleased with the ‘roads’ selection) but I’ve managed to cobble together some sort of LittleBigPlanet -vs- Tetris rehash. It’s very hard to explain, but suffice to say I’ve spent a lot of this evening getting Cars and Helicopters working to a decent degree. I’ll start doing some more regular posts over the course of tomorrow (this should be a good-time for time-lapse work shots!). Here’s what my project current looks like, go on. Laugh.

Anyway, my iPod is in the red (battery wise) – so when it dies, I’ll goto bed! Best of luck to those Brits/Europeans out there still working!

I need help with collision code. I want to keep the player from falling through floors, pretty much. Help?

EDIT: Okay, I’ve got some good collision detection, but there’s something wrong with my moving code.

bool checkCollision(SDL_Rect &movable, double &vx, double &vy, SDL_Rect solid, bool move) {
int moveLeft = movable.x;
int moveTop = movable.y;
int moveRight = moveLeft + movable.w;
int moveBottom = moveTop + movable.h;

int solidLeft = solid.x;
int solidTop = solid.y;
int solidRight = solidLeft + solid.w;
int solidBottom = solidTop + solid.h;

int clipLeft = max(moveLeft, solidLeft);
int clipTop = max(moveTop, solidTop);
int clipRight = min(moveRight, solidRight);
int clipBottom = min(moveBottom, solidBottom);

if(clipLeft == clipRight || clipTop == clipBottom)
return false;

if(!move)
return true;

int clipWidth = clipRight – clipLeft;
int clipHeight = clipBottom – clipTop;

if(clipWidth solidX) {
// moving to right
movable.x += solidRight – moveLeft;
} else {
// moving to left
movable.x -= moveRight – solidLeft;
}
} else {
// moving along y axis
vy = 0;
int moveY = moveTop + movable.h / 2;
int solidY = solidLeft + solid.h / 2;
if(moveY > solidY) {
// moving to bottom
movable.y += solidBottom – moveTop;
} else {
// moving to top
movable.y -= moveBottom – solidTop;
}
}

return true;
}

Please help! If you’re interested in seeing what’s happening, here’s the program: http://files.chocoboheaven.com/uploads/Guests/files/85267_PaintWorld.zip

Hello! This is a competition entry. It is a simple game where you shoot cannonballs at a tower. Eventually, the tower will succumb. You get more points for letting blocks hit the ground before the top of the tower does.

Hold SPACE to power up the cannon, release to fire. Up and down changes the angle. That’s it!

Requires pyglet/pymunk. Doesn’t run too fast. All those quads to draw, and all.

Windows Binary.

Source code.

Ok here is my final entry. It is far from being polished but I am up for 17 hours 12 of which were programming… My brains are messy now

So no sounds, no bunch of planed effects and sleek interface… And output codes may not be forum friendly… Not time to test and debug but mostly game works.

Also sorry for English don’t have willpower to go and check if I did some mistakes and ofcourse there are bugs and glitches

But at least I did everything I wanted from mechanics point of view. Enjoy this game and share bugs and replays here plz.

Image

Links:

EXE file

Browser version

Source FLA and AS files

Well source codes. Half of the time I was waging war with interface which resulted in really messy structure and some bad dependencies. Also I go tired of commenting so I am not shore if it will be of any use to anyone

Used Box2DFlashAS3_2.0.1 and some my utilities of my own

I spent most of today fighting with flash and tweaking the shapes and material properties of the cats for maximum stackability. It turns out dense, high friction cats are the most fun. Slippery cats suck, but you already knew that.

(’scuse the weird dithering)

What went wrong

1. Choice of development platform, XNA studio 2.0 Beta. People were having trouble running the game. I knew this before I started but things like Intellisence, love for C# and curiosity of XNA took the upper hand. This was my first XNA game, and my first use of an physics engine. I used Farseer 2d physics lib. Having no previous experience in both fields was challenging.
2. The controls are like standing 100m away from a real helicopter with a remote control keyboard that has a delay of 2 sec. It made the game totally unplayable for most of the people who actually got the game running.
3. Too advanced idea for the time frame.
4. No guidance when flying out of scene.

A lot of these stuff are related to the physics engine and my lack of experience with them.

What went right

1. The editor was whipped up in director’s authoring app very quick. Place and size different rects and run generate() to make the xml level file. Yeah, loading levels were easy too. with xml serialization.
2. Sound effects came out great thanks to DrPetter’s sfxr program. The xna audio framework was a bit confusing at first, but it did the trick. Adjusting the helicopter engine sound along with the thrust was effective for game play.
3. Game play is really fun once you get the hang of the controls. I found myself several times playing around when there was stuff to code.
4. Code. The code is clean and got unusually many comments for a LD contribution.

Porting

So I decided to try to port the game away from xna, to OpenGL, so that more people can play it. The rendering part went fine. But then the physics lib stabbed me in the back again. It uses the xna lib. So I dug out a version that did not. But I failed again. It turns out that that lib also is xna dependent. So I tried to get the source code and remove all dependencies. But failed to grab the source. Not much energy left to de-xna it.

A helicopter physics game, made with XNA 2.0 beta.

You will need a pile of shit to get this to work, here it is:

1. .Net 2.0 SP1 (we are currently uncertain if it ships with Vista)
   • Note you can also use the original .Net 2.0 but you will also have to install the C++2005 SP1 Redist (G4WL will also install this, so this is only needed if you are not also installing that redist)
2. DirectX9.0c
3. XNA runtime 2.0

I’ve had ppl not being able to run the game anyways, Im looking into the problem. Pls tell me if it works for you.

Anyways I hurried with the levels, Yay it was fun to make them I hope to release a map pack soon. Unfortunaly the editor is built within director, so I will have to work on it a bit to enable the community to build their own maps, unless you got director. All sound was made with DrPetters godlike sound effect app, sfxr. Kudos to him!

Game goals: make the red box be within the red rectangle for 3 seconds to go to next level.

Controls: (Xbox360 controller should work, not tested, buttons? test them!)
Arrows <- -> Steer

ArrowUp/Down throttle

Z – Open/Close the CLAW!

X- Turbo (For making panic manouvres)

R – Reset level (Yeah this key you will know by heart)

N – n00b?

Here is bin 440KB

And here is source + editor + bin + other useless stuff 3MB

Yay! I have a working editor! Im using director and layout out sprites and rect at positions and various sizes.

And here is an ingame view of the map, after a little playing

I had some framerate issues, was only stuff intersecting at load (Phew)

Yee haw.  Finally got the physics working.  It’s pretty simple stuff.  Axis aligned bounding boxes, with a verlet/relaxation based solver.  As far as my concept is concerned, the shapes should all be axis align.  Otherwise, your multi block monstrosities would fall over in most configurations.  On to the screen shot.

Next up… I don’t know yet.  I might run out for some groceries (I hear there’s a no tax sale at “Super Stores” this weekend, 5-11PM).  That should give me time to think.

Farseer physics lib woun’t play nice with my polygon collision meshes. I think I will have to redo them as primitives instead. Thus changing the chain-claw thing I had in mind, and perhaps make heli bowling? Man, I made my dev pipeline so awesome! Created paths in photoshop to define the collision mesh. Read the ai file with the object, all was swell.

Those pins just fall by them selvs, thats an easy win. Anyhow, Im off to bed, tomorrow I will be away a few hours on dinner. Yeah, I’ll bring my laptop!

Camera and sidescrolling implemented (not wrapping yet though)

Oh and I made a tripod, a bit small. Fixed the controls a bit by cheating. turning left n right adds forces in those directions not only changes the upforce. Up n down still needs tweeking.

The physics seems a bit unstable, (stuff act strange) I’m not sure my idea with chaingrapplings will work, perhaps I should revise the idea a bit.

I finally got a working claw on my heli! Yay!

The controls are really hard though. Its like… controlling a 1ton heli with a keyboard from remote that has a 1-2 sec response time. I guess I’ll have to fake it a bit.

Finally I have the Farseer physics lib working and showing the geometry of the collision objects.

Now I’ll have lunch and then play with some physics

Perhaps not much of a reaction though. Here is my first sketch, I haven’t decided if I’ll do this yet.

Im thinking of using a physics lib on this one.

Ah, great compo this was. Tons of sweet games. Unfortunately that also meant fierce competition, and I only managed to snag a best position of 3rd in Fun (which is unusual for me, as I normally do better in the technical categories).

Base idea for the game was to have the level be “swarming”, for an unexpected approach. I figured there could be loose platforms drifting around in space and you’d try to jump around between them, doing… stuff. The gameplay part of it was sketchy at best.

I suppose the better part of the first day was spent getting the platform movement and interaction working, and then I think much of the second day I just sat and tweaked it, fixing bugs. The gameplay elements and final graphics/audio were added in the last two or three hours.

Windows download: 128 kB zip (exe, data, source)

Linux port: 16 kB tar/gz (needs above file for data)

Arcade build a’la Lerc.