Thanks for all your help. LICEcap hit the spot!

Oh, forgot to mention it but I'm a Windows 7 user.

Thanks, I'll check it out!

What tools do you guys use? From recording to gif compression, that doesn't look like shit and doesn't weight a ton.

Thanks!  

This game has mobile written all over it

I played for like 20+ levels and it was very entertaining, and the learning curve is very balanced. Specially liked the slowdown while holding mechanic.

Btw, when you're near walls the enemies just smash against you like a thousand times per second and instantly kill you; it seems a bit unfair.

Congrats! Great game

-snip-

Man, this is fantastic, specially the sky dithering. Didn't like the out-of-focus blur thing, but everything else is just brilliant

[great]

SFML has a great, great interface. Recommended.

Not sure if the best but this freebie works for me: http://freemusicsoftware.org/722

Suit yourself.

I won't be getting a lecture on pride from a person that has a banner as signature on how "popular" he is on Indie DB.

I agree with those bullet points from Paul.

But one thing I want to know. Just how bare-bones do you make the gameplay at first? Like, 'nothing but colored squares' level of placeholder graphics?

It depends, I usually do what Paul mentioned, make some placeholder assets that make sense, at least shapes with minimal animation, not just squares.

E.g. it's a drag having to re-adapt your map design because the tiles or entities are too small or big, so you'd better define the sizes of things to avoid avoid refactoring later.

What I meant was that you don't focus too much on the menues, because they're just there to help you play, but the game they affect must be appealing and engaging first for the user to care about the menues or final control scheme.

Also the game might radically change and you wasted time making an interface to something that's not the same as it was.

Good luck!

I am not sure it's an issue.
There is a difference between latency and throughput.

...

Unless you have a lot of simultaneous entities.

"Bullets" seem like a multiple simultaneos entity situation.

Size has influence in network congestion, fragmentation and packet loss.
A realistic MTU for internet UDP packets is around 500-1500 bytes; so a very bareboned 5 int frame (ID, x, y, velocity x, velocity y) will leave you with about 10-40 entities to be updated per frame.
Larger packets could pile up fragments and increase latency. Depending on the route, fragments could easily be discarded dropping the whole packet.

The minimum size guaranteed to not fragment is 576 for IPv4 and 1500 for IPv6, same as ethernet.

1/2 spanish
1/4 polish
1/4 hungarian

I live in Argentina and speak spanish & english.

A network game should send the least amount of data.

With 64 bits IDs it would take 4 extra bytes per entity on each frame packet.

* Coding up the saves / achievement systems

It's been helpful to me to build an across-projects library in a unified folder for my flash games (using a global classpath to access it)
Lot's of things will need adapting per-game, but it'll save time anyway.

Stupid things like Turning 3x [0..1] color values to hex 0xRRGGBB can take 10 minutes of "not knowing what's going on" if you mistake the precedence of bitwise operators or don't clamp correctly the values. Can easily happen, but that's just an example.
Why not do it with a GfxU.rgb(...) call instead?

So I keep all the utility code around (Formations, inverse kinematics, intersections, graphic operations, files, audio, generic but optimized particle system, etc.) and polish it a bit more with each project I use it. And I use my own conventions so I tend to remember where everything is (documentation on parameters and return values won't hurt thou  ).

* Loading and reloading my game to make sure menus and such are placed just right. (Monster Debugger has been a major asset in making this quicker.)

Don't do this. Focus on the gameplay, everything besides it can wait until there's an actual game to play.

I like the saying "premature optimization is the root of all evil" (which I agree), but I also think "premature beautification is the root of excuses for not doing actual work on the game design and gameplay" .

[2 billion]

You're probably safe just rolling it over if it does run out unless there's somehow a chance that the first bullet is still active in the simulation by the time the last one is fired.

I agree, I wouldn't worry even if it wraps around to zero. Also the "Player ID/Object ID" seems the best way to go; even for 64 players you still have 67 million Object IDs available for each player.

Worst case scenario: Someone could attack the server by spamming with a lot of bogus or repeated IDs, but that's somewhat easy to detect.

If you still need like 2 billion objects there's another solution:
As the server knows who each player is it can just keep 2 31-bit IDs internally server-side, one for the client that created the ID and another server-issued ID for the rest of the clients, remembering to address the object accordingly whenever it sends info.
The 1 bit left out lets the client know if the ID is server-issued or one of their own.

This allows players to reconnect without creating weird scenarios like the server telling the new client where to start with it's ids or having to clean up the objects for the player using that slot before.

Thanks Evan... I used the matrices in the end, because I needed some camera looking (and rotation) besides the perspective.

Some values needed to be tweaked and then it worked ok


EDIT: The following was a great read that helped me understand
http://unspecified.wordpress.com/2012/06/21/calculating-the-gluperspective-matrix-and-other-opengl-matrix-maths/