you could always make the shield shrink/disappear after the player has stood still for a set amount of time. This would force you to keep movin to avoid losing your paddle.
It feels too much like it was made specifically to force the player to move, which is not good game design. You want to make him want to move anyway.
Yes, the player should move because of the danger that lies in being easily punished by the other players instead of being punished by the game directly. So I like my first idea with the canyon and the possibility to push the campers off the gaming area better.
I like the idea of placing power-ups, and making those integral to winning.
I'm not sure whether they should be needed for winning. I'd like it better if they'd just add more spice to the game and more power to that player who uses them best. Sure, by that they will be indirectly turn to be the key to winning, so well, at this point in my line of thought I have no idea what you mean by "make the power-ups integral to winning" because it somehow will be like that automatically.
You could alternatively make the shields shrink at a fixed rate regardless of player behavior, so the players have to at least occasionally chase a 'shield replenishment' power-up that spawns away from corners.
This might be an optional rule but I don't think it should be in the default set of rules.
Bomb-ball: The ball explodes after X seconds or after it has bounced off of something X times.
Love that one, a small number being displayed with the ball could indicate the time or the number of hits left until detonation. Since everybody will be able to see that number it should add an extra layer of tension to that particular game situation.
Homing-ball: The ball homes in on the closest player.
This should be a very rare power-up since it is so powerful.
Mirage-ball: Like split-ball, except the other ball is fake.
An interesting thought but it could be easily mistaken as a bug in the game if a player gets hit by such a ball and nothing happens. Well, maybe the mirage-ball could just travel through players(but not walls) and vanish after a set amount of time.
The Ultimate Ball of Painful Doom: Slow-moving ball that can not be deflected;
I don't like this one. Players should always have a chance to defend themselves.
An idea for bitmap levels..
There will be no bitmap levels but the game should come with an easy to use playfield editor.
Powerups are ok but how about the goal of the game is for each player to collect items, like diamonds of the same color of the player. Every time a player collects their color diamond a new one appears somewhere on the screen and they have to get it, dodging the pong ball all the while.
Every time someone gets hit by a pong ball they lose a point, but no one should gain points for killing people.
This can be made as a different set of rules. The game should support different sets of rules anyway and with polymorphism this should be fairly easy to achieve. There'd be a base class with methods for every game event (like player hit by ball, player collecting item) which the game calls. Each set of rules can inherit from that class and override the event methods to apply different effects to the current game state. That's just an idea though, there might be better ways to handle different sets of rules.
Naw, I prefer the senseless killing TBH.
Me too, if it doesn't go overboard. Because then, any deathmatch game with traditional weapons would be better.
Maybe the diamond setup could be one mode, and make several variants of the game with different targets and objectives.
Yes there definitely needs to be support for different rulesets to satisfy everyone.:)
I think if you can pull it off, I may be able to port it to the DS. I'm not so good at the maths stuff, but I can hack some mean code when I get working.
No problem, I could help with the math. I currently think it will just involve a bit of trigonometry and some linear algebra, which I think I'm pretty firm with (at least up to the level that it is needed for this game:P).
if you don't have a host for this project, I have svn, ssh and webspace open for you for the webspace you have a choice of two servers, my paid, faster server at strangesoft.net (or any address you want to use), and my home server at tomasu.org. Let me know, I'd be really happy to do it.
An svn repository would be cool. Not needed until there's at least a single player "move around" demo ready though. I think the basic system should be already coded before it first gets imported into the svn trunk. The final game will be hosted on my homepage and I'll of course also add it to the depot as I plan to write it in C++, using Allegro. Not sure what to use for the multiplayer code yet. Basically every player should have an arbitrary "controller" attachable, which could be anything from local keypresses to remote commands send by a different computer(player). If you'll be able to provide additional mirrors for the game download this will of course be appreciated. Goes without saying that the final version should come with sources and compile on various systems out of the box.
I'll probably also need help with the coding of the game as we are currently planning and later this year will be programming a quite huge monster of software at work which is going to suck up a lot of my energy. So I'll just have time to work on this project at the weekends and rarely in the evenings. (Because I think I couldn't code eight hours a day at work and then come home and continue coding.) In the end, I wouldn't mind writing all the code myself, it'll just take longer to complete it that way.8-)
I'll start writing/drawing the design document tomorrow and until thursday evening you can still contribute ideas and more brainstorming. On friday, as said before, there'll be feature-lock so any ideas posted after that, even if they're good, will not make it into the first version. (This is to increase the chances that there will be a first version someday and that it will not continue to grow and grow and grow and never come out.)