TIGSource Forums

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?)

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. ;)

The idea of paint traps is quite prospecting. 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).

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).

The possibilities are really huge! :)

The idea seems to be very interesting. Look forward to it.

Thanks for the feedback!

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.

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

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.

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.

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.

The idea sounds good.  Lots of playtesting should reveal some interesting designs for you to try.

Best of luck!  :)

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

(http://www.mrwonko.de/images/screenshots/invisibility/fontrendering.png)

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.

Today I added the console where I can execute commands, set variables etc.
(http://www.mrwonko.de/images/screenshots/invisibility/console.png)

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 :) )

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 (http://www.ludumdare.com/compo/minild-24/?action=preview&uid=3631), my Mini Ludum Dare 24 game made in 3 hours which happens to fit the "versus" theme, too.