Sunday midnight as in "The midnight between Saturday and Sunday"
or
Sunday midnight as in "The midnight between Sunday and Monday"

I heard some confusion about this in the irc.

Asked and answered before:

End Date: Sunday, February 27th, Midnight

Are we talking 00:00 Feb 27 or 23:59 Feb 27?

the end of sunday.

I won't make it by the way.

By now I've got a working input system, but I'm not really happy with it. I'll probably redo it some day, but I feel I should get the whole game into a working state first so I have some results that keep me motivated.

Now the only thing I need, besides gameplay, is a menu/hud system. I don't really know how to approach this, though I kind of know what I want to have in the end so I guess writing those requirements down would will be a good start.

I don't think I'll get this done in time, so why don't you play some LoveDeathZombies, my Mini Ludum Dare 24 game made in 3 hours which happens to fit the "versus" theme, too.

Today I added the console where I can execute commands, set variables etc.


I also had the idea of using php & mysql for a masterserver. That's nice because while I don't have a root server I do have a webserver with php and mysql. And that seems to be working well.

The next thing I'll do is to create binds, i.e. high level input, and a testapp for the masterserver - so far I've only got the server code, now I need to do some website loading in C++. (SFML has built-in support for that as far as I know )

Some sort of deathmatch game where you can't see your opponents. The only way to find them would be to watch bullets, items being taken, bombs going off, etc.

Working on it: Invisibility
Based on just that idea, but with some changes. Nowhere near done yet.

I like the concept. I'm imagining spot lights scanning the level, searching for players.

Nice idea! Well, first I'll need to get the basic game up and running, and I've got less than 4 weeks left... Well, I plan to finish this anyway, even if I don't make it in time.

Haven't done much recently, fixed some font-related problems and added tab support. I edited the shot above to reflect that.

--edit--
I've started work on the console and wrote a word wrap algorithm, see the now updated screenshot above.

I added font rendering to the engine, that will probably be useful.

Wondering if there's still time to make a simpler game.

Almost a month. Go for it. Nothing wrong with keeping it simple

I've added milestones/current progress to the first post which I'll update as I make more progress so you have a better feeling of what I'm currently doing and how long it will be until you see some results.

Building basically a whole engine mostly from ground up in C++ and Lua is quite some work, but I think the outcome will be worth it.

To anyone who's got experience making some decent tiles:

Can you give me some help on how to not make these tiles look so tiley/boring?

I have no experience in that myself and thus recently searched for articles on the matter. I found this one interesting, you might want to take a look.

Also, just thought of a cool idea: when you are using your bare fists, and if the other player's health is low enough, you can lunge at them, pin them down, and suffocate them (to death). This is accomplished by entering a button mashing minigame where you must both push your respective action buttons faster than the other player in order to either a)force your attacker off or b) end your victim's life.

It could be very intense.

I don't like button mashing, how about a quick time event (like in Dead Rising 2's Terror is Reality multiplayer)? The one who gets it faster/more accurate wins

Just ran into an interesting design problem: limited keyboard input.

For whatever reason, several different keyboards have a limit on how many keys they can output to the computer. With two players holding down on the shoot, walk and jump/jetpack buttons (on one keyboard), the game will be nigh unplayable. I'm thinking of a control scheme that can circumvent the problem for these people.

Maybe have all the controls act as boolean variables... press the left key once to keep on walking left, press it again to stop walking left. Press the jump key once to jump, press it again to jetpack until you run out of energy, press it again to stop jetpack-ing.

Just pondering how these folks would play the finished product. 

It's got to do with how keybords work internally - I don't know the details, but there's a limit to how many keys in a row/column can be at the same time or something like that.
Maybe it will work if you use different keys? And having two players on one keyboard makes things even worse...

probably someone else with the same ip range as you was banned

I already tried twice, on different days (i.e. with different IPs)...
For some reason removing chatzilla from my hostmask seems to have worked, though other chatzilla users don't have the same problem... Maybe all chatzilla users in my IP Range are banned? Whatever, I'm in now.

Interesting concept, kinda hard to test alone. Well, it's a versus competition^^

I experienced a bug in the collision detection: The ball spawned at the upper end of the screen and no matter how high I moved the paddle, I couldn't hit it (it seemed to go through the paddle). It kept respawning at that height, too, so there was no escape.

Does the channel have a whitelist or why am I supposedly banned, never having been in the channel before?

Interesting concept, but I don't think I'd enjoy playing it... With all the betraying and backstabbing.

whatever you do, don't run this through a german translator...

Don't need to, I'm German.

I've just come up with this: on a closed area (no too big but with many obstacles) one player is a seeker and other players are lurkers. Seeker is visible, lurkers are not (a lurker doesn't see other lurkers). Goal of the seeker is to find all lurkers within a given period of time. Goal of the lurkers is to remain undetected. Seeker is equipped with a kind of a booby trap-like spray weapon which he can use to reveal lurkers. Lurkers can use obstacles (or other lurkers if they're lucky) to shield themselves from spray.

It's a kind of a tag game crossed with hide-and-seek, I think.

Hmm... it's quite different from the other gamemodes, but still sounds nice. May try it out, but I'll start simple.

Thanks for the feedback!

Very nice idea. I would consider the possibility to hear enemy player(s) footsteps (without own team footsteps, that would be tooo much noise, I suppose). Also there could be possibility to mute your own footsteps by switching to some kind of "discrete" mode (walking instead of running?). Of course enemies could use the same tactic.

I thought about doing a motion detector (which would work like footsteps) first, but a proximity warning may be better against campers. If you hear the beeping you know someone's nearby so you may think twice about revealing yourself.

I like the idea of such a detector... I'll try it out if I can.

You could have not only footprint paint-traps but also directed booby paint-traps that - when triggered - would spray everyone in range making their whole figure visible (thus showing what kind of weapon they carry).

This seems like a very powerful trap, but I may check it out. Given I finish this, but I'd really like to.

Another idea would be some kind of sand-marks (if there is going to be sand) disappearing over time (but showing the most travelled routes).

Would work much like water in revealing your position, though you may choose to follow someone else's footsteps so you're not revealed... I like that.

Do you have any ideas for different gamemodes? With traps an ordinary Deathmatch may be possible - there may not be a reason to reveal yourself, but that won't be necessary if you can reveal your enemies

Another item could be a radar - place it down and it will have this rotating line that reveals enemies (and allies, including yourself...) as it passes them.

You're right, there are many possibilities. I'm afraid it will need some balancing to be fun... But that shouldn't keep me from giving it a try.

[Milestone 1: Basic Framework - Pong]

After hearing about the competition I started trying to come up with a game concept. I asked some people for ideas and thought myself, but there were no appealing ideas.

But today I realized that I already have it all planned out, even posted on GameDev about the idea and started a (fruitless) attempt of doing it using the UDK. But when that didn't work out as planned, probably mostly due it being my first UDK project, I kind of forgot about it.

By now you're probably thinking: "That's nice and all, but what are you talking about?" Let me briefly tell you about the game.

• The game is a top-down 2D mp shooter. Run around the levels with WASD, aim with the mouse, click to shoot. Possibly collect weapons and ammo.
• The core idea is that all players have permanent invisibility.
• Shooting makes you visible (and thus a target) so you better be careful.
• Becoming visible is potentially rewarding, depending on the game mode. Here are some ideas (have you got any more?):
  
  • Capture the Crown: The player with the crown constantly gets points but is visible (Or only the crown is?). When you die, you loose the crown.
  • Capture the Flag: Two teams. You can see members of your own team and enemies carrying the flag.
  • (Team) Deathmatch: Not that simple, because camping is encouraged. Needs testing.

I'll definitely need some testing, this may need a lot of tweaking, but sounds promising to me.

Some more ideas I've had:

• You're not invisible, it's pitch black. Shooting creates light, revealing your position. Problem: How to make the level visible?
• Players get an "enemy detector" that beeps increasingly fast as you get closer to enemies. Should be especially useful when guarding in CTF.
• Things like puddles of water may reveal a players location.
• Items. Enemies will see the item vanish as it is picked up. Ideas:
  
  • Healthpacks
  • Paint traps: After they've been placed they'll release a puddle of paint once triggered, making the victim (and other players walking through it) leave footprints for some time (or until he walks through water)
• Every couple of seconds every player's position is revealed for a moment - like radar

I'm not sure whether these will work, but I might try them out.

I will code in C++ using SFML. If I go the quick route, not caring much about reusing my code, that will suffice. Or I may also use PhysicsFS, zlib, minizip, Boost, Lua and Luabind and work with my WIP game framework. The latter would take more time (it's far from finished) and I'm not sure I'd be done in time, but I may do it anyway... I'm not sure yet.

What do you think? Please comment.

--edit--
Am I even allowed to reuse code? The rules state you have to start your project after the beginning of the competition, but I don't think that extends to custom libraries. I don't think it extends to ideas, either, since that'd be a problem.

--edit2--
I've seen others write down milestones and thought that I should do the same. Here's what I came up with:

Milestone 1: Basic Framework - Pong
I'll use a framework that I've been working on for a couple of weeks. May not give results as quickly but the product will be of use to me in the future. It's far from done, so my first priority is to create all the missing core components:

• window, basic graphics (sprites, text, shapes) - done - provided by SFML - done before competition
• Low-level input / event system - done - partially SFML Event System, partially DirectX & XInput (for controllers) - done before competition
• FileSystem - done - Using PhysicsFS, has mod support - done before competition
• Lua + Luabind - done - Setting up Lua, making it work with PhysicsFS etc. (Since most code is in Lua for moddability (important in future projects)) - done before competition
• Console commands & variables - done - much like in the Quake 3 engine, key presses will execute a command string and settings are saved via "CVars" - 2010-01-20
• Instruction interpreting - done - Basically a little compiler/executer that interprets strings of commands (including setting and printing cvars) - 2010-01-27
• Font rendering - done - Reading Jedi Academy's .fontdat file format and drawing strings, optionally colored - 2010-02-0104 (done for real this time?)
• Logging - done - Logging via cout, ingame console and logfile. - 2010-02-06
• Console - done - Easy way of using console commands and variables (hence their name), much like in Quake 3 - 2010-02-06
• High-level input system - working temporary system - Binding instructions to buttons/keys and axes. 2011-02-19
• Menu System - not yet started
• Sound - not yet started - I can probably get away with sfml's sound system
• Pong - not yet started - To make sure everything I've programmed so far works, a little game seems appropriate. Let's do Pong.

Milestone 2: Core Gameplay
Once I've got the Framework I can start writing the actual game

• Multiplayer, basic Server/Client stuff - not yet started - I may just create a networked version of Pong to begin with...
• Map - not yet started - probably top-down (easier than isometric(?))
• 2D collision detection/physics - not yet started - May take a look into Box2D and other libraries as a shortcut, once again using Pong as a prototype
• Player & Movement - not yet started
• Invisibility - not yet started
• Shooting, dying, respawning etc. - not yet started

Milestone 3: More
Once the basic game is done I can start adding more to it.

• Additional game modes - not yet started - ctf, capture the crown etc.
• Balancing - not yet started - the game must be fun!
• Leaderboard, rounds - not yet started
• Traps/items - not yet started

Optional/Additional
These things would be nice, but I don't really need them. Yet.

• Level editor - not yet started - I will probably need one myself, writing levels in plain text seems unpractical
• Command line argument parsing - not yet started - for example starting a server or connecting to one etc.
• Security - not yet started - protection against cheaters/hackers/..., not important yet
• Additional Weapons - not yet started - I may add more weapons later, but I'm not sure I need to.
• Nice art - not yet started - the game probably won't look very good. I'm a coder, no artist. I may keep it abstract? Lines and Circles?
• Music - not yet started - See "Nice art".
• Porting to Mac/Linux - not yet started - I don't have a Mac and I haven't taken the time to port to Linux yet. Shouldn't be too much work though, thanks to SFML.

This list is intimidatingly long - I don't know if I'll be done in time. I'll try. (Yeah, "Do, or do not. There is no try." I know. I'll do my best. Better?)

Wow. Yesterday this site was recommended to me and minutes later a competition starts.
I've always wanted to do multiplayer some time, this seems like a nice reason to start. A simple competitive game.

My final exams in school will start on the 28th - luckily the competition will be over by then. :D