The Grand Game Design Thread

[diordna]

Starting point: a physics-heavy platformer. Since it was between this and the Incredible Machine knockoff, and the first option was rather similar to this one, I made an executive decision. I hope no one minds too much.

My proposals/ideas:
-Main character is like the guy in one of my 24-hour contest entires (http://www.thebiggerbox.com/files/Whizbang.zip) (3.6 MB, quick launch, easy gameplay, you should totally try it.)
-Bullets have mass, so recoil if the character is on wheels, and objects are pushed away on impact
-Some structures are made of blocks, and if you knock out a few supports, they fall over
-Should be graphically simple. Lots of regular-looking solid-colored polygons with medium-thickness black outlines

Post your character designs here as well if you have them.

[ThemsAllTook]

Some crazy and not-so-crazy ideas:
-Completely seamless world. No modal loading dialogs or sharp transitions between game levels/areas.
-Most/all puzzles and gameplay based on physics in a significant way.
-Use the mouse; perhaps the character could have some sort of telekinetic ability that lets them throw things around? (within reason, of course)
-Have levels flow predominantly right-to-left, just to be different

[Duane]

I vote a platformer, with a flexible main character (metroid, anyone?) that aims via mouse?

Still, I don't really want shots to be affected my gravity in such a way that I have to think about it and it detracts from the enjoyment of playing.

But, players, for sure. Enemy projectiles for sure.

[diordna]

I vote a platformer, with a flexible main character (metroid, anyone?) that aims via mouse?
The problem with flexible characters is that they need art, and we're notoriously short on artists. My robot-with-wheels thing needs a body, two wheels, and a number of still-image guns or attachments. (If an artist wants to chime in about making a lot of frames for a flexible character, please do.)

I think that we should first implement the ability to make a completely puzzle-based game, because it's very simple to make puzzles based only on a physics engine and a simple object library. Projectiles can come later - not much later, though, because they won't be too hard to code either, assuming we're using Chipmunk or similar. The final game should have both action and puzzles.

[skrew]

idea for the protagonist:

- have the IDG robot
- move with WASD
have two primary attacks:
- the first where he shoots laser beams out of his eye activated by the space bar
- the second would be his arms which can be activated with the left and right mouse buttons, his left arm is a grappling multi-purpose hand which can grab enemies and throws them around impaling them on the environment, which also doubles as a way to move around the world, and his right arm acts a lot like a harpoon spearing enemies left and right
- Have his body completely destructible except his head, which of course has his brain. so if you loose your legs you can navigate about with your arms, or if you loose your arms you can jump about shooting enemies with your eye laser
- When crouched our IDG robot could either turn into a ball sort of like metroid, or act like a pit-droid in star wars and creep through tight spaces, if you go with the pit-droid idea, you could use that as a defense against explosives, where, when crouched, our robot takes almost no damage, but is blasted backwards(or forwards) quite a ways
- have the robot gain experience which goes towards health, length of arms, and strength/recharge time of eye lasers

sound alright?

[diordna]

Perhaps we could start with something simple and implement the insanely complicated arms and transformations later.

[wyrmmage]

Sorry, but...is this going to be 2D or 3D? Probably mentioned, but I missed it...
I'd personally prefer going with keyboard controls instead of the mouse, but thats mainly because I have a laptop, and mouse games can be hard to play with the traditional keyboard pad. The fact that most mac mouses only has one button would pretty much eliminate multiple weapons if we're going with mouse (might not be a problem, but hey).
-wyrmmage

[diordna]

2D for sure. Unless a lot of people have an opinion otherwise.

[BeyondCloister]

Ensure that the game can be played on a laptop without an external mouse.

[backslash]

I like the way thinking seems to be going here. I definitely agree that an official iDG game should star the iDG robot (assuming the copyright owner approves). Skrew's ideas are very interesting (although many of them would logically go some way down the to-do list). And if the primary weapon is a laser then it is obviously immune to gravity, thus keeping Nayr happy. Presumably there would be some way to replace missing parts. How about collecting money and using to buy repairs and upgrades?
I also agree with wyrmmage abd BeyondCloister that the controls should work well on laptops, given that such a high proportion of Mac sales are laptops. Is there a reason why nobody seems to like cursor keys?

[unknown]

Ensure that the game can be played on a laptop without an external mouse.

If it detracts from the game, I think thats not a restriction worth imposing.

[skrew]

I was just thinking along the lines of the classic abuse, where you run around and shoot stuff, aiming with the mouse, it gives the game a lot more fast paced action. of course this wouldnt be so ideal on a laptop.

[BeyondCloister]

If it detracts from the game, I think thats not a restriction worth imposing.

If I understand you correctly you are saying the game should be designed so that it does require a mouse and thus cut out a lot of the potential players?

Design is very much an important part of the project. Also understanding your target audience is very important and writing off such a large number of potential players is not a good practice to teach people. Or is the next design decision going to restrict Mac owners without high spec graphics cards?

My apologises if I have misunderstood you and you are respecting laptop owners in the design process.

[Joseph Duchesne]

There is absolutely no reason that a 2D game shouldn't run on any new mac hardware, GMA or not.

Also on the mouse issue: laptops are outselling desktops 3 to 1 where I work. However, everyone I know that has a laptop has an external mouse. Like most games, they're easier with a mouse, but we should at least stick to the one mouse button design (by default), otherwise the game would be unnecessarily hard on laptops.

[skrew]

yeah, I just thought it would be pretty cool to have control of two arms seperately, but essentially you could have a system where the arm has different switchable attachments

[Blacktiger]

Some thoughts:
- We could design the game to be modal and seamless so that new sections of the game world are loaded dynamically and it can be added to and modified in sections/pieces.
- Once we are hooked into Chipmunk (you know we will, no one objects to it), we could make parts of the level destructible and or movable for that extra level of interaction.
- Typically, sprite based games use several frames for animation; but what if instead we design a 2D 'model' with scripted animation. I'm thinking ragdoll masters, but scripted for actual movement instead of just sort of floating. And each part would have an image instead of being a stick figure ;)

[unknown]

If I understand you correctly you are saying the game should be designed so that it does require a mouse and thus cut out a lot of the potential players?

Design is very much an important part of the project. Also understanding your target audience is very important and writing off such a large number of potential players is not a good practice to teach people. Or is the next design decision going to restrict Mac owners without high spec graphics cards?

My apologises if I have misunderstood you and you are respecting laptop owners in the design process.

No, I didn't mean "It should require a mouse", I meant that you shouldn't have restrictions like this if they can decrease how good the game would be otherwise.

[BeyondCloister]

No, I didn't mean "It should require a mouse", I meant that you shouldn't have restrictions like this if they can decrease how good the game would be otherwise.

There are definitely many great ideas that can be placed into the game and still allow it to run on a laptop without mouse. There is a flaw in the overall design if a good game cannot be created without a mouse.

[Blacktiger]

You could also do an abuse style game that doesn't require a mouse, so long as the player has more time to decide what to do and react since using the keyboard would be much slower.

[AnotherJake]

I would avoid the mouse aiming entirely if it is a platformer. Simple up, down, left and right seemed to work fine for the hundreds (thousands) of platformers made over the years.

On the 2D/3D thing, it is really easy to mix 2D and 3D objects in a 2D scene. For instance, you can have scrolling tiles for the environment be purely 2D and have the main character and other objects be 3D but using 2D movement, physics and collision detection. OTOH, for simplicity's sake you could just limit all graphics to 2D and be done with it.

[ThemsAllTook]

If we were careful about how we used the mouse, and didn't generally require it to be used too precisely in too fast-paced of a situation, we'd still be fine on laptops. It's not as if they have no pointing device at all, and really, trackpads aren't that difficult to use. As long as we make sure to playtest with both mice and trackpads, I don't foresee a problem.

As for the character animation, I was imagining something a bit more sophisticated than static bitmap animation frames. A simple 2D skeleton system isn't difficult at all to implement. I did it for memset 0x801, and we could easily do something more advanced here if necessary.

[AnotherJake]

A simple 2D skeleton system isn't difficult at all to implement. I did it for memset 0x801, and we could easily do something more advanced here if necessary.

That seems pretty reasonable to me.

[wyrmmage]

On the 2D/3D thing, it is really easy to mix 2D and 3D objects in a 2D scene. For instance, you can have scrolling tiles for the environment be purely 2D and have the main character and other objects be 3D but using 2D movement, physics and collision detection. OTOH, for simplicity's sake you could just limit all graphics to 2D and be done with it.

I'd say limit to 2D, since it looks like we're going to be using chipmunk, and it would be unneccessarily complex to have drawing routines that were for 3D objects outside of the chipmunk library.
The 2D skeletal idea sounds pretty cool, and would certainly allow for some interesting possibilities...especially when combined with destructible terrain :D
-wyrmmage

[AnotherJake]

I'd say limit to 2D, since it looks like we're going to be using chipmunk, and it would be unneccessarily complex to have drawing routines that were for 3D objects outside of the chipmunk library.

I haven't used Chipmunk but it cannot be any more complex than 2D since you'd be specifying a 2D collision primitive no matter how you cut it. Drawing routines for static 3D objects are dead simple, and even easier to deal with in a 2D plane. Even a fairly robust static 3D object drawing routine, optionally using VBOs, is only two hundred lines total! .obj loading code can be found basically everywhere. There really is no complexity to it. Indeed, one could argue it might be simpler than 2D sprites since there would be no pre-rendering step involved and could look better at the same time.

But there is no particular *need* to use 3D objects. I'm just saying it would be technically feasible and easily achievable even for this project.

[wyrmmage]

But Chipmunk doesn't support 3D objects in its collisions, does it? I don't know for sure, having never used Chipmunk, but that's what I thought it said somewhere...
-wyrmmage

[OneSadCookie]

2D physics with 3D graphics is what Jake was talking about, I believe.

[AnotherJake]

2D physics with 3D graphics is what Jake was talking about, I believe.

Yes!

I thought I made that pretty clear, but it appears I need to work on my communication skills a little more... My bad.

[Duane]

diordina: the flexible thing doesn't necessarily require art; a stick ragdoll is about as flexible as can be!

2.5d, anyone? Actually, I just want a yoink revival, but whatever...

[skrew]

Another cool idea would be to use the laser to solve puzzles by using it against reflectable objects to trigger switches and doors and the like, but instead of making it too easy by just shooting the laser at a certain angle and having it set off a chain reaction of reflections, have it so that the player has to align the reflectable objects at the correct angles and in the right sequence with the detachable arm.


For clarity I have provided a graphical representation of the idea (which, however does not reflect my artist ability :p ):

http://hl.udogs.net/files/Uploads/%20User%20Uploads/skrew's%20Uploads/lasers.jpg

[wyrmmage]

Yes!

I thought I made that pretty clear, but it appears I need to work on my communication skills a little more... My bad.

eheh...I read the post late at night...after re-reading it, all is clear :P

skrew: that could be kind of cool, but seems like perhaps it should be a different mode almost? Side-scrollers usually don't require you to stop annd solve puzzles that way; could work though :)
-wyrmmage

[AnotherJake]

For clarity I have provided a graphical representation of the idea (which, however does not reflect my artist ability :p ):
I played a game like that several years ago. It was actually really fun! I dug through a bunch of old disks to find it again, and the name of it is: Uncle Martin's Laser Factory. Unfortunately it's Winderz based, but on the positive side it was written in OpenGL. It's just a little amateur game but the game-play is great. I don't know where you could find it now. The only good site that showed up for me on Google was some weirdo Russian joint.

[Bjoernke]

Side-scrollers usually don't require you to stop annd solve puzzles that way; could work though :)

I thought this would be a platformer, not a side scroller... On second thought, there are side scrolling platformers, but these normally annoyed me greatly. But you probably all know by now that I'm not an action gamer at all.

The laser idea is great, and I also like the idea of different weapons... I do however not like the need to change weapons in the action (or multiple weapons at the same time), so I suggest to make it a per level base. One could have a kind of outfit screen, where the player chooses a weapon for the robot (and other stuff?), and then has to stick to it for the whole level. Of course one would have to either disallow unsuitable levels, or make sure that a certain weapon wouldn't make it impossible to solve the level at the last part (because that's highly unfair).

As a means to control the robot, I suggest wasd/arrow keys for movement, one jump button and mouse aim and click for shooting/arm actions. Basically copy dark castle, it worked great as long as you had the time to stand around and carefully aim (again, I don't like twitch action). If there's no need to always be on the outlook to not get killed, one could make an outfit screen available during the game too, maybe with a limit/cost for certain changes?

On a site note, does anyone know ninjah (http://www.evildrbin.com/ninjah/) (win/linux only)? It basically kills the little guy if he touches the wrong coloured level part, making you use a grappling hook, bullet time and the recoil of a gun to fly around. Although its somewhat fun, it's devilish complicated to use three different weapons, sometimes at the same time. It's also quite high on the I-make-you-fail-because-you-suck scale (at least there's infinite lives).

[BeyondCloister]

The 1986 Commodore 64 Dan Dare computer game had a level kind of like that. You had to go and set the mirrors on the various platforms before firing a laser to destroy things. The mirrors had to be set in various combinations to destroy everything on the level.

It was good idea then and a good idea now over 20 years later.

I did try and find a screen shot of it but I could only find ones from other levels.

It had another nice idea for replacing the player actually getting killed. When their energy dropped to zero they were captured and put in a prison cell screen. It was easy to get out again but you were no where near where you were before. The game was a race against time which added to the problem of being imprisoned.

[skrew]

The laser idea is great, and I also like the idea of different weapons... I do however not like the need to change weapons in the action (or multiple weapons at the same time), so I suggest to make it a per level base. One could have a kind of outfit screen, where the player chooses a weapon for the robot (and other stuff?), and then has to stick to it for the whole level. Of course one would have to either disallow unsuitable levels, or make sure that a certain weapon wouldn't make it impossible to solve the level at the last part (because that's highly unfair).



I think that could be a really cool idea. But instead of having the player pick the weapons involved. Let the level designer choose for them. Then we could have levels for everyones tastes: faster paced more action orientated levels and slower puzzle based levels

[Blacktiger]

Personally, I like a more well-rounded approach. Have each level contain puzzles as well as more action oriented elements. If we are going to use destructible terrain, then shooting certain things (ie the rope attached to a chandelier) would be one way of getting rid of a bunch of enemies without fighting them directly.

[Nick]

I haven't chimed in for this yet, but I think sticking with more puzzles over action would be a good thing. There are plenty of 2D action games whereas a cool 2D physics based puzzle game is interesting enough to garner some attention. As mentioned, perhaps shooting a rope to make something fall could be part of a puzzle, or bouncing things off other things. I also think that if we go primarily with a puzzle base, you can more easily use a trackpad and one button mouse as you essentially cut out the frantic parts of 2D action games.

[Duane]

I might point out that the point of this project (or so I thought) was not to garner attention, but to teach. Now, it may (probably will) be that a puzzle-type game ends up teaching more, but let's keep our goal in mind here.

Actually, forget that. Most people looking to learn want to make mmorpgs, so we'd have to make one to best serve the community.

[wyrmmage]

hmmm...I almost think that the point should be to attract people to the site, and to show that cool mac games can be made by indie developers :cool:
-wyrmmage

[AnotherJake]

I thought it was just for fun! I don't do well on projects with mission statements attached to them because it reminds me of work...:sneaky:

[Bjoernke]

We could make a what's-your-motivation poll, but diordna would prolly just put in the same option three times. ;)

Seriously I'll keep this in mind, and we can make a motivation/mission statement wiki entry, where everyone can put in their own personal motivationional speech.

I'm in the fun group, btw.

[Duane]

Perhaps another poll showing the direction this platformer goes?
e.g.:

Puzzle Plaformer
Keyboard-Action Platformer
Keyboard/Mouse Action Platformer
Action/Puzzle Platformer
Just steal yoink and pretend we've done something

[wyrmmage]

I don't know...I'm kind of against having another poll; I think we might be better to try to work the options together, which would be easily done if we had different levels, anyway. (for that matter, we could just have different modes: action/puzzle)
-wyrmmage

[BeyondCloister]

I think it may be wrong to try and fit everything into this one game.

If for a second we stop thinking as developers (just because we can make every level a different play style does not mean we should) and think like the end user.

Imagine the player is an action platformer fan.
3 levels in the game suddenly turns into a puzzle solving game
On level 6 they discover they need a mouse which they did not bring with them on this trip.
One disappointed player.



If everything works to plan then it should be simple enough to (for example) do the first game as a puzzle platformer and then a follow up game as an action platformer.

It should even be possible to produce multiple games at once with each being a different type but using the same core engine.

[diordna]

Well, I mean, the old Mario games were as much puzzle games as they were action, I think. Make the player think, but also make them shoot things.

I don't mean Myst-like puzzles. I mean little quick things you have to figure out how to get around. Like block stacks that fall over at the slightest bump.

[skrew]

Imagine the player is an action platformer fan.
3 levels in the game suddenly turns into a puzzle solving game
On level 6 they discover they need a mouse which they did not bring with them on this trip.
One disappointed player.


This problem could be easily solved with a non-linear level progression. using a similar system as they do in the flash action-puzzler N (www.harveycartel.org/metanet/n.html)
But instead of having a column based system, which in the end, as a player for me in N made it impossible for me to finish the game, as in one of the columns, which held 50 levels, in 10 episodes, i could never beat the first episode and therefore missed out on the other 45 levels.

What could be cool is a system where every level beaten unlocks every other level adjacent to it on some sort of overhead progress map, and if you wanted to have some sort of ending to the game then you could have it so that there are multiple ways, either by puzzle or action, to reach the end of the game

[diordna]

Screw, you haven't sent me your contact info yet. I'm sorry to keep intruding into threads like this, but I'd like to have a complete list. I'll put up what I have later tonight as a zip on my server, linked from the wiki hopefully.

[Blacktiger]

Well, I mean, the old Mario games were as much puzzle games as they were action, I think. Make the player think, but also make them shoot things.

I don't mean Myst-like puzzles. I mean little quick things you have to figure out how to get around. Like block stacks that fall over at the slightest bump.
That's what I was thinking. If you look at some of the successful shooters, like Marathon, Half-Life, or Halo, you'll find that the puzzle elements of the game are relatively simple. Keeping the puzzle elements relatively simple while integrating them into the main action of the game makes that action more interesting.

[diordna]

I agree completely, and this is what we should aim to do. You have to shoot things, but you also have to figure out obstacles.

[Nick]

I agree completely, and this is what we should aim to do. You have to shoot things, but you also have to figure out obstacles.

That sounds good to me as well. The main thing that should be considered is whether or not we are going to be using a mouse for control. This would affect the puzzles a little bit. If we are using, say, the arrow keys for 8 angles of aiming, our puzzles cannot rely on having angles in between to shoot or hit things. If we use the mouse, though, we don't have to worry about any angle issues. My vote is to create the game with a mouse in mind, but only using one button by default.

[ThemsAllTook]

My vote is to create the game with a mouse in mind, but only using one button by default.
Yeah, definitely just one button. Though, you could always have keys that act like secondary mouse buttons, and the option of mapping them onto mouse buttons if they're available...

Maybe we could try to design a way to play with the mouse and a way to play with just the keyboard? Though depending on what we'd use the mouse for, that could get really tricky to do without handicapping one mode or the other.

If the mouse issue turns out to be too controversial, we might be better off scrapping it and moving on with keyboard controls only.

[AnotherJake]

I guess I agree that going with a mouse is okay, especially one-button. I'm not up with mouse platformers in general but I don't think it should necessarily be specifically avoided either. If it makes for good gameplay then why not?

FWIW, I know few really care about Wacom mouse problems but I am trying to cook up a solution for that too along the way.

[skrew]

Well, I had most of the day off today, and in my boredom i came up with a cool idea for the premise of the game so check it out and tell me what you think :

http://hl.udogs.net/files/Uploads/%20User%20Uploads/skrew's%20Uploads/storyboard.jpg

So basically what happens is, its really easy to get into this place, letting the player get familiar with the controls. Then when the tutorial levels are over he finds himself in a room with a whole bunch of doors. After he takes his first step, the door he just came through slams shut.

This is where the game starts.

The player can then choose to go through one of the many doors which leads to a different section of the complex. We could have checkpoints a long the way through each section, so if the player gets bored or stuck, he can make the choice, at a checkpoint to warp back to the main area and then go through a different door to go into a different section. Then if he chooses to go back to an area he never finished, then he will be automatically transported back to his last checkpoint. We could then have some sort of endgame where if all sections are completed, the central door opens and he either fights the grand master boss, or simply finishes the game.

edit: none of the names i used are permanent, just the first things that popped into my head

[AnotherJake]

I really like it! :D

For some reason it totally reminded me of an ancient game back in my Mac Classic days called... what was it? 3n3? That was a total puzzle game and very plat-former-esque. There were some crazy-awesome simple puzzles in that.

[Nick]

I like it as well. It's pretty simple and allows for some great user experience. I like the idea of letting players who get stuck in one area go to other areas knowing they'll start that area right where they left off when they come back.

[DaFalcon]

Okay, allow the master* to step in here. :ninja:

I love where this game concept/design is coming from, and I love where this is going. This game absolutely has both fun potential and the potential to really work as a community project.

Who am I? :cool:
I've been deeply involved in the creation of a few games, including the original Inkubator game, Hooptie (where I was 'lead artist'.) I've also worked through plenty of level design issues with Snake Quest and more recently Midnight Mansion (which is a puzzle/action hybrid platformer). I like to think I have a good grasp about how to design games and specifically how to design levels. Now that I've laid out my credentials... :bored:

*tongue in cheek

[DaFalcon]

First Problem: :\
Level designers need to have SOME control over what weapons/etc. players have in a given area or it becomes too difficult to prevent game breaking strategies. You want to provide as much choice as possible for the player, though this will often be done by creating the illusion of choice (done well, this works). An item selection/purchase screen adds an extra layer of complexity that may be overkill for this game. Certainly if you let the level designer arbitrarily enable or disable weapons/features for a given level then this will only serve to confuse and frustrate players. The solution?

Robot Parts: :???:
As the player progresses through levels, she will encounter interchangeable robot parts. The community should decide how to break this down, but here is an example...
Head - Unchangable, or at least only upgradable through 'leveling up' (in one form or another.) These are your brains, if they go kablooie, you die. Your main laser weapon is attached to this part.
Torso - (1) Normal, this is what you start with and usually use. (2) Lightweight, you can float in liquid and have to deal with greated recoil and possibly wind effects. (3) Heavyweight, lesser recoil, you're heavy enough to fall through flimsy ground tiles from a decent height, sink in liquid, not subject to wind effects.
Arms - These are your weapons -- one should probably always be a form of grappling hook, one should be more of a swiss army knife of things allowing for weapons like rocket launchers, glue guns, mirror shields, weed whackers, keys, punching bags, machine guns, etc.
Bottoms - (1) Wheel base, subject to more recoil, quick moving on most surfaces. (2) Tread base, prevents recoil, slower movement but can handle some terrain that wheels cannot handle. May be heavier, though for simplicity all weight differencial should be based on Torso. (3) Rocket base, fly around super speedy ... until you run out of fuel. Great for getting to far away places or certain zones, but these are strategically placed by designers and can only be used where we want them used.

:love: To "use" a robot part, you just run into it and it swaps with your present robot part. For example, you see a rocket base on the ground, wheel on over to it and as you run over it, it becomes your new base and you zip around for a while until it runs out of fuel. You fall in place and have to grappling arm your way around to the tread base at the edge of the screen, right next to that buzz-saw arm that might be just what you need to cut through that tree you saw a ways back.

[DaFalcon]

Second Problem: :shock:
The control scheme has to be usable on any modern mac, including laptops without needing an external mouse. Fact is that Apple is selling tons of laptops, and we should account for that. The scheme should be easy enough that Bjoernke can have fun playing the game while still allowing for some level of strategy/puzzling and action/shooting.

Requirements: :blush: (probably not all inclusive, though such a list should be made)
We have to be able to (a) move the character around the screen, (b) fire the laser beams, (c) aim the grappling hook, (d) fire the grappling hook, (e)maunever while on the grappling hook, (f) aim the other arm/weapon, (g) use/fire the other arm/weapon, (h) crouch/crawl/roll-into-a-ball, and (i) jump

Limited Flexibility: :)
(a, h, i) - First of all, WASD should be standard for robot movement. Maybe allow arrow keys to work as well at the player's discretion? When the robot is standing, pressing down once should allow for a crawl, double down puts the robot in a crouch (press up to uncrouch), moving side to side while crouching causes the robot to perform the roll manuever. Press up while standing to jump, or while running to jump in the direction you're running (as the game is physics based, you don't have Mario control to change direction while in the air, unless it is absolutely needed for gameplay reasons). You cannot jump while rolling (nor can you use laser beams or weapons unless we choose to include something akin to Samus's bombs.)

(b) There is a key to fire your laser beams from your eyes. Your head never tilts, so you can only fire a straight line in the direction you're facing, at eye level. There should be ramps and the like in the game that the robot can stand on to change the angle that the robot is facing. This limitation is intentional to allow for differentiation between the weapon arm and laser, and to fascilitate puzzle design.

(c - g) Now for control of the arms... - To allow for the right mix of simplistic controls that lend themselves to both action and puzzle/strategy level design, I propose using the mouse/trackpad in a simplistic fashion, with a prefs option to use the keyboard as an alternative. The mouse/trackpad would be used to select/set crosshairs in one of 8 positions around the robot. Up/up-left(diagonal)/right/down-right(diagonal)/etc... If you flick the mouse up and to the left, the crosshairs settle into that position (or more likely the robot arms move into that position). Press the fire-grappling-hook or fire-weapon-arm button to fire in the direction the arms are pointing. Note that if the robot is attached to something via the grappling arm, that arm does not move with the mouse/trackpad flick, instead the WASD controls let you swing left/right and reel in/let out the grappling arm.

[Bjoernke]

:love: To "use" a robot part, you just run into it and it swaps with your present robot part. For example, you see a rocket base on the ground, wheel on over to it and as you run over it, it becomes your new base and you zip around for a while until it runs out of fuel. You fall in place and have to grappling arm your way around to the tread base at the edge of the screen, right next to that buzz-saw arm that might be just what you need to cut through that tree you saw a ways back.

This sounds boring, and has been done in every second platformer since mario. Frankly, I'd rather have a unchangeable robot, then this mechanic to change him.

(b) There is a key to fire your laser beams from your eyes. Your head never tilts, so you can only fire a straight line in the direction you're facing, at eye level. There should be ramps and the like in the game that the robot can stand on to change the angle that the robot is facing. This limitation is intentional to allow for differentiation between the weapon arm and laser, and to fascilitate puzzle design.

The problem here would be the physics puzzle parts. To cut trough stuff you'd need to aim the laser (or a boom-weapon) very precisely. Because of that, I still think that one weapon at a time, aimed by the mouse is the best approach.
You talk of the two arms & weapon at the same time idea, and I just can't see that to be simple enough for the majority of mac gamers (although most ppl on iDG prolly could handle 5 or more at the same time with ease ;) ).

Seriously, didn't anyone ever play Dark Castle? I think it's control scheme would fit very nicely. (Looking for it on the web, I am once again baffled by the cheap looks a classic b/w game got when transformed to colours)

[DaFalcon]

The problem here would be the physics puzzle parts. To cut trough stuff you'd need to aim the laser (or a boom-weapon) very precisely. Because of that, I still think that one weapon at a time, aimed by the mouse is the best approach.

My design goal was to eliminate the very precise part -- it's difficult on a laptop, and not necessarily easy with a full mouse. By limiting position-states, you allow the designer to know exactly which of seven places the robot will be standing when he shoots off the chandelier with the boom weapon. This also reduces the tendency of the designer to create twitch-reaction situations, which limit the audience for a platformer. The laser beam is a weapon that's limited but always available to the player, encouraging use of other weapons but always providing a way out of a situation if all that's left is the head and an attached grappling arm.

And I think there is a way to make interchangable parts fun, interesting, and fresh feeling -- but its just an idea. :)

[BeyondCloister]

The problem here would be the physics puzzle parts. To cut trough stuff you'd need to aim the laser (or a boom-weapon) very precisely. Because of that, I still think that one weapon at a time, aimed by the mouse is the best approach.

The very precisely part is the thing which can easily alienate players and making them give up on the game in frustration.


Think about this scenario:

Bad Design
To solve a puzzle the player has to shoot laser at 34 degrees from 96 pixels from the target.

Player thinks that maybe shooting a laser at it would solve it and then fire at 33 degrees 100 pixels from the target.

Because the player did not aim precisely nothing happened. Now do they try again at one of the other 359 degrees they have not tried or do they think they have the wrong solution and go off to try something else?

Maybe they get lucky at get that 34 degrees in the first attempt but then when they play the game again and attempt the same puzzle but their previous solution does now not work because they are out by a couple of degrees they then think the game is behaving inconsistently.

Good Design
Laser can be angled at 8 different positions.
To solve the puzzle the laser has to be shot from position 4 anywhere between 150 and 200 pixels away from the target.

Player tries at position 5.
Simple for them to try at position 4 and get it. Easy to remember for next time.

Golden Rules
Games stop becoming fun when all the rules of the real world begin to apply. After all is not escapism from the real world one of the reasons for playing games?

Think as a player not a coder - just because we can do it in code does not mean it should be done like that.

[Bjoernke]

Generally I agree with you, putting in trap like situations which only annoy and hinder the game play are certainly evil. On the other hand, making a physics heavy platformer somehow implies to me a rudimentary similarity to the real world.

To me, the problem lies in the implementation: Allowing only a small target area to be clicked on exactly is bad. Allowing a laser to be freely targeted at levels that react upon being hit on the other hand has "way cool" written all over it in my opinion.

Note that I don't mean that someone should click onto a defined target. One clicks, and the laser shoots into the direction of the mouse, where only the vertical direction was put into the calculation (I guess) . One could even have an indicator of where the laser would hit, a kind of cross hair.
Dark Castle had this, via letting the player character raise it's arm in the general direction the shot was going to, if one clicked. That worked really well, but Dark Castle of course lacked destructible terrain.

As a final note, I personally think that the way the player interacts should be fun or intriguing on each level, be it level design, physics, or game play mechanics. To me this implies to be aware of the platform specifics, and having locked targets reeks of console to me, where one has to find ways to work around the lack of a proper mouse.
Always assuming that the mouse is not gonna be used as twitch device of course. Because then, freedom becomes quickly annoyance. :sneaky:

Either way, maybe you should put your concerns and ideas into the relevant wiki (http://bjoernke.com/idg/wikka.php?wakka=GameDesign) page.

[Bjoernke]

Back to the question of graphical style, I'd love to see enemies based on the squarlies smilies that have been an original staple of these forums for so long, provided that we can receive permission from the original artist and from Carlos. Maybe the squarlies would be the heads of opposing robots or organic creatures, or they could even be creatures that need to be saved by the robot (the ultimate goal being to save all 22 of them, each appearing only once in the game).

I really like the Smilies idea from a gameplay point of view. Although only one of each seems a bit harsh (and all 22 possibly redundant), I'd love to catch them all. :lol:

Other possible uses:

As a weapon: "Fly my square ninjas, fly!"
As powerups: "...but then I found the sleeping squarely, and just put the boss monster to sleep..."
As Graffiti on the wall: "Defeat the squarilies sprayer!"/"Be the sprayer!"
As story elements: "The LOL squarely has been kidnapped: Cmd-R to the rescue!"
As helpless vermin to be squished under your mighty steps (but gameplay irrelevant)
Just as icons in text :)