[GD-Design] Ideas for a short game coding party

[Aras P. <ne...@in...>]

Hi,

I'm planning the next LTGameJam party, and some interesting ideas for the
games/engine are needed. We've though some, but more would be welcome :)

Short description of the party: LTGameJam (http://jammy.sourceforge.net);
which is in turn similar to IndieGameJam (http://www.indiegamejam.com/), is
a short game development event. Someone prepares a small specific "engine",
invites a bunch of game programmers/designers, and over two days they try to
make small games. Of course, two days to study the engine and write a game
is a very short time, so main focus should be on original ideas, etc. We've
made two Jams already, first being direct IGJ0 clone - "100k game units!",
second being "physics, cars and stuff". Now, it's time to think of the idea
for the next one...

If anyone has a crazy idea and is willing to share it, you're more than
welcome. Anyone willing to participate is welcome also, though so far
LTGameJam was in Lithuania (hence 'LT'), and only Lithuanian programmers
were participating (but noone enforces that :)).

Here's a short list of ideas currently "in processing":

1) Old maze-like games. This is simple and easy, but not very original or
interesting. Basically, it's 2D maze at logic level, with engine providing
pathfinding, collision, entities, particle effects, camera etc. The
participants take this "2D maze" thingie and write some game logic.

2) "guess the packet" network games - there's a server that basically just
broadcasts packets. And there are clients. The twist is, that while client
games use the same server and same physical packet structure, they don't
know the packet semantics. So, every games interprets the packets in it's
own way. To keep at least some control, something is known about the
packets - eg. a packet is bunch of bytes with known small range. This could
turn out totally unplayable, though. The problem is, what the engine should
provide, except networking? Possibly some 2D games stuff (sprite renderer,
2D pathfinding, etc.)?

3) "microphone is the input". Nothing much more is known, except that, well,
microphone is your input device :) The problems are the same as 2) - what to
provide except the input?

4) "vehicle building". Basically, you don't write a game, but rather code a
vehicle - assemble it from pre-made components, add input processing,
auto-aiming, whatever. In the end you end up with vehicle "plugin" that is
plugged into premade networked game. You don't write AI for it - it will be
controlled by human. This idea is a strange one, as it's not "game
programming" anymore...



Aras Pranckevicius aka NeARAZ
http://www.gim.ktu.lt/nesnausk/nearaz/