Edit 12/4: Is actually fixed for real now.

– Changed flying controls: Was able to move around anywhere, now ship is always moving forward, and you can only move side-to-side, up-and-down. (always facing in the positive z-direction)
– Added timer for door closing to address no visual feedback that you were/were not going to make it out in time
– Limited amount of boost (no longer infinite) to create need to conserve it and use in a good area
– Began increasing level design complexity to provider better/longer experience

http://www.prism.gatech.edu/~jnakano3/CS4455-P3/CS4455f12-P3.html
WASD, Space, mouse look, right click, left click, and CAPS Lock for picking up boxes.

[WP_UnityObject src=”http://www.prism.gatech.edu/~jnakano3/CS4455-P3/CS4455f12-P3.unity3d” width=”640″ height=”480″/]

The player will have to use a combination of brakes and boost to maneuver about objects and enemies while trying to escape as quickly as possible. The player might also need to use its lasers should an enemy be in his way. Sets of glowing orbs, placed by an unknown ally, may be collected to gain power-ups (Extra boost, Health, etc.).

Prototype Goals (whoops, missed that!)
Player/ship movement including turning (while flying forward) in 3d space, braking, and boost. Polish effects will be used to emphasize the ships movement, such as fire from the thrusters.
I will create a basic portion of what might have been a much larger and more complex level. The ‘cave’ idea has been ditched for a set of passages, each getting you one step closer to safety.
The fun will come from learning to mastering the flying movement, which will prove key to escaping alive, avoid fire from and shooting enemies, and the overall immersion in the game world.

Expanding on the idea of “at home in the air” may be better worded as having more movement capabilities while jumping, gliding, or in a controlled aerial descent. This would be juxtaposed by a slower moving around pace on ground. This creates a tension between moving on the ground and moving while in the air.

The player could possibly still be able to throw coal while on the ground, but their effective coverage would be significantly less than when in the air.

When I said rescued, I had planned to have the player carry the presents to a top some tall building that would require hopping from various other obstacles and buildings to be able to reach the safe zone where points would be awarded. There would be multiple ways to reach to top such that it would not create a boredom feeling of having to do it exactly one way. This is also another reason why I did not want to allow the player to simply fly around the entire time.

It would be interesting to see how I might be able to create a time warp feel effect. This could be done in short segmented bursts where the player can speed up or everything else slows down…just an idea for latter down the road.

Zip archive (fallback, I doubt you will have any trouble downloading a zip file):
https://t-square.gatech.edu/access/content/group/82206.201208/P3-files/amead3/Dream%20On%2C%20AA%20Demo%20Video.zip

Mp4 file is on Tsquare in the resources folder for project 3 under “amead3”:
https://t-square.gatech.edu/access/content/group/82206.201208/P3-files/amead3/Dream%20On%2C%20AA%20Demo.mp4

Screen.lockCursor = true;
Screen.showCursor = false;

You can then use a key press, say ‘esc’ to trigger

Screen.lockCursor = false;
Screen.showCursor = true;

which will allow the user to move the cursor around the page again. Hopefully this helps some people wanting to use the mouse.

The prototype will demonstrate this stomping down and the 2 modes with some interaction with Martians!

As for controls, the above suggestion of metaphor would shift control to the arrow/joystick, thus making it more friendly for web browsers.

As for the feel, yes I should have specified that it was pulse to push, which then continues to propel the bot. When a bot is in range of an element and tries to pull at it, it has the same sort of acceleration on it, starting off slow and building speed as force is applied and then slowing down gradually when none is applied. This also gives a rebound effect to obsticals too. If an object collides with another, including yourself, it does a semi-elastic bounce (handled by Unity physics) .

For the prototype, I will do is a few separate sections. Probably separated out by border walls. The first thing to prototype is the movement style, bouncing off of walls, and checking everything with the physics, along with the switching between the camera mode and bot control mode. Next would be to get a simple key and getting the key feel set up, mostly with thier movement. Then, IF i have time, trying to set up a series of defenses and the interaction there of. I mainly want to focus on the feel of the world first, and getting the objective prototyped.

Game Description:

You play as a farmer who’s trying to grow as many flowers as he can before the day ends. You grow the flowers by giving them a certain required amount of water. However, your garden has a bug infestation! Bugs will come and try to eat your plants before they reach (bur-resistant) maturity. To stop them you can either spray pesticide on your flowers which will temporarily kill all bugs that step within the radius of the spray or you can squash the bugs by jumping on them. The game ends after a time limit.

As the game progresses, there could be more flowers that require different amounts of water and are eaten by bugs at different rates. Each level will have an increasing level of difficulty requiring an increasing number of flowers be grown.
Goals:

Grow as many flowers as possible within a time limit.
Prevent bugs from eating as many flowers as possible.

Skills:

The player must strategize and decide when to water flowers and when to stop the ever increasing threat of bugs.

Pesticide sprays are limited so the player must decide when to use them or when to just stomp on the bugs.

Controls:

WASD to move the farmer around.

Spacebar for jumping.

J for spraying water.
K for spraying pesticide.

Prototype:

The prototype will be based on one 3 minute level. At the end of the Level it will be displayed how many flowers grew.

There will be a few random bugs that will eat try to eat the flowers and the player must be able to stomp them out.

The pesticide functionality will be tested in the prototype.

Having a prototype where you implement these, can toggle between and test them, would be great. Don’t think about limiting which mode the character can be in yet (ie. eventually, you might want to limit the more powerful modes, for example, with some sort of energy) but right now I’d say focus on implementing them so you and others can play with them and try them out.

But, you need to be much more specific about (a) what these would be and (b) what the game is! Both are omitted above. The player wakes up and needs to explore … why? What are they doing? What is their goal? Answer the “why” question, and that can help you figure out what the different abilities are and how they interact.

You’ve only described a vague framework above: one input -> multiple outputs; when one skill is primary the others are still there faintly, etc. But, what does that mean? Can you give a concrete example of what the game would be and how you would leverage this?

You’ll also want to be careful with the use of the mouse you describe, as this will cause problems when trying to play without being full-screen.

I’d like to see you be more specific about the feel, but the prototype plan seems good (to test and refine that movement, especially the movement in free space).

Thank you!

I would say the one big thing missing is the motivation of the player: if it was “me” in this situation, wouldn’t you just get away as fast as possible? Why not take it a step further: you have this ability and have been hiding out of town (BTW, how do you survive/eat/drink? some metaphor needed there), but something is threatening the city that only you can destroy, and so you are trying to do that with minimal collateral damage? So, you are forced to be in the city, but must minimize your damage while destroying something else?

Prototyping the movement and actions, and how the destruction would work, is a good plan. I would like to know more detail of what kind of controls you are thinking about, what kinds of movement and so on, so we can judge success!

Instead, create some sort of skill based movement (ala starwars pod racing) that the player has to master, while they travel on a pretty well defined course.

That will all be tied in with your movement and controls.

Since you didn’t give a prototyping plan, I’d suggest resolving this “no maze, please!” issue, figuring out what the challenge and controls will be, and experimenting with them!

Think what the end goal on some of this is (4 spells means you can just pick between them with the keys, for example), but aiming is an issue.

Why not use two xbox controllers instead? Much more flexible, can shoot in any direction while moving, etc.

For the prototype, I agree with focusing on the movement and shooting! Perhaps put in some different spells (even if they are just different colors of the same one) so you can test the spell switching (if you have multiple spells)?

The thing I’m not seeing, which is going to be the crux of the thing, is how the movement works. Given the whole setup, it seems clear to me you could have some pretty fun movement mechanics based on this. I’ve watched squirrels attach our relatives feeders (and ours, back when we tried to have one) and they are amazing at jumping, hanging on, swinging, etc. It seems like you can almost do a super-hero style game (able to wall-jump, swing, etc in amazing ways) but couched in the context of the evil seed-stealing squirrel.

So, I would have liked to see that touched on in the game description.

I also don’t have any sense of what it would mean for the squirrel movement to be more difficult when it’s got too much seed. But, as you flesh out the super-moves (assuming you do), that should become clear.

For the prototype, I agree than the squirrel movement is key. So, focusing on that, with a single complex feeder to scale, would be the right thing to focus on!

Regarding the game description, you haven’t given any specific ideas on how the player controls work. I think, given the limited number of elements (<4) and the need to rapidly move and shoot in different directions, this would be ideal with either
- an XBox controller, using the two sticks for move and aim, and the buttons to select things, throw, etc.
- a combination of keyboard (WASD, 1-3 to arm the chemicals, other keys to combine or activate effects, Space to throw) and mouse (target the throw).
It matters, of course, since these two would feel really different.

Regarding the "reaction" to the players action: I don't think the crowd reactions are really the most important thing, but rather the direct reactions in the world. What are the changes in input/appearance/sound/polish when the player moves through chemicals, grabs, throws, bumps the wall, etc. I suspect you are thinking about this, or if not, you should be!

Finally, for the prototype: no,no, no! Do not aim at a full level. Ignore the enemy, for example. You want to refine the movement, targeting, etc. Have a screen that randomly creates regions of chemicals so you can move through them (or just throw and then move into it); randomly create objects to grab, so you can test that. Focusing on just the movement, the reactions to the movement, the polish effects, etc., is MORE than enough. Focus on doing a small set of things EXCELLENTLY, not a bunch of things mediocrely. You have a lot of decisions to make, input and control tuning, and some simple graphics to create. That's more than enough to occupy you! Time spent on the rest is time wasted.

Implementation-wise, perhaps there is a way to make the slime a nice dynamic animated character. I wonder if you can use some sort of physics-based springs-and-joints animation to control the bones of an animated blob, and then have a skin around it? Hmmm. If so, you could create the slime entirely with code.

I think you are focusing on the right things in the prototype. You could even just use hot-keys to switch the size of the slime, if you prototype the feel at multiple levels.

And thank you for the suggestions. Time dilation and camera movement was something I hadn’t put into full consideration, but I’ll keep these in mind when I add in polish effects. I really like the idea of a time dilation such as slow-down or speed-up to emphasize speed.

One big question: are you thinking 2D top down (original Metal Gear), 2D side view, or 3D (Mirror’s Edge)? 3D will be challenging (again, see Mirror’s Edge), so I have assumed as I read it was 2D side view (otherwise wall jumps don’t mean much). Which is it?

I think your prototype plan is fine; focus on demonstrating as much of the character movement as you can, through a representative space. Don’t worry about enemies; if anything, just put targets in the room (perhaps this could become a “training level” in a real game … heck, why not just make it the dojo?) I’d encourage you to really think about some of the more special ones (fast movement, wall-jump, etc) and how a combination of camera movement, visual effects and perhaps time dilation, could allow a sense of greater speed while still giving the player control.

– platformer: if the only purpose of the platformer is to move through the maze, this will get annoying really fast. You need to be doing things and interacting with the world as you go, otherwise it’s a core task you are doing (running jumping) that is not really related to your main task (figuring out the maze), it’s just making it take longer and making maze exploration tedious. Perhaps you have other things in your mind that aren’t written down yet? Is all interaction done via the character somehow? Is that what you are saying with the “switches”? There are fixed switches that rotate the maze in fixed ways, so you don’t really have to “figure it out” … rather, Rubik’s cube is just an analogy for the kind of motion?

– rubics cube motions. Unless there are ways to step back from the cube, examine it, and rotate it directly (not via the avatar), these rotations need to be really trivial (I need to rotate 1 or 2 times per level) or this will become insanely hard fast. I don’t see what you are thinking here (but, see above: is this just an analogy to explain the motion?)

– 6 sides of the cube. Are you implying the sides are platformers and the top is a non-jumping maze? (i.e., fixed gravity). What about the bottom? or is the bottom the inside, that the player does the last bit on?

– I don’t see the fun from your description. Mazes without secondary goals tend to be pretty boring. Mazes, in general, are not fun in games, but usually end up being frustrating and tedious things in the way of you doing the real fun (shooting, collecting, interacting with things in the world). Why is this maze fun? How does the character interaction with the maze make it fun?

For your prototype, you need to think more about what the player is doing and why? Are they avoiding things? You say there are no enemies … is there anything challenging or skillful about navigating the maze? I think I see what your motion is for the character, and the steps (enough of the level to demonstrate the various modes of character movement) are reasonable.

Aside from that, the puzzle example you give (the bird thing) is not a puzzle: a puzzle would have clues that would give you as the player some way of figuring out things. What you describe would feel frustrating and random: there is NO WAY a player could guess what the right behavior is there (release the bird), because it’s based entirely on an unintuitive inference drawn from a cultural stereotype. More critically, it doesn’t feel like these puzzles are integrated into the game play. You describe the fun as interacting with the world, finding things and seeing what they do. But, the success metric is entirely divorced from that (I went, I interacted, I worked, I acquired the bird, and now my “score”/”success” is based on one trivial thematic decision). This is exactly what Swink talks about when he says all actions/reactions should be derived from player actions, no seemingly unrelated external reactions. And it’s what we talked about in the design lecture on having win/lose actions only a result of actions the player can perform that they know what they are doing. A random guess that impacts the players success is never a good idea in a game (e.g., open door A or door B, with no information about what’s behind; pick between two choices based on a cultural structure that may or may not make sense to the player).

If you consider games like the Mario games, where the female “protagonists” with goofy personalities (the little stars in Mario Galaxy, Princess Peach, etc) issue quests, the quests are explicit and fun, independent of whether you think of the metaphors and stereotypes. There are lots of people who find the black-and-white stereotypes in the Mario world a bit annoying, but still like the games, because the stereotypes can be completely ignored and buying into them and having to think through puzzles based on them is not part of the game.

Now, as for your claim of the fun. Those two things (interaction, puzzle solving) could indeed give fun. BUT, you haven’t given any examples of what fun interaction would be. Ignoring atmosphere, what are they doing that’s fun? What’s in the environment? What are the goals and the actions that they need to learn and master than would give a sense of fun? As for the pleasure of puzzle solving, or the pleasure of “Experiencing the environment” (the comedy, the sounds, etc) the things you actually describe are mostly environmental (voice actress) and not what we want.

Assuming the game fun was based on puzzle solving, you’d still need to think of some real puzzles. I have been dissuading folks from focusing on puzzle games because you don’t want the success of your game to be based on creating good puzzles: you don’t have time to create/build/test/refine/balance clever puzzles, and that whole activity is tangential to the goal of the class (game architecture and building pleasing in-game interactions).

Finally, your last sentence should have been a red flag for yourself: the assignment explicitly says your game must be one that satisfies Swink’s definition of a “game feel” kind of game. By definition, if the fun of the game does not come from the avatar interacting with the environment, then it’s not that kind of game. You haven’t really given any specifics of what the “fun” would be (except the cultural stereotype jokes embedded in the metaphors).

You need to rework this so the game fun is based on the players actions and play!

For the prototype, focusing on the movement and how the character interacts with the world is good. Slightly refining your thoughts on your proposed game structure would be good, as I think the interactions and movements could be very different under slightly altered game structures. You need to tell us more specifically what “at home in the air” means, vs the ground. Why would you ever go on the ground, if your mode of attack is throwing coal from the air? Why not just skim the ground to grab presents? Since Santa and his minions have amazing time bending abilities (e.g., visiting every kid on earth in one night) perhaps much of this would happen in weird Santa-Time space … could give you very fast bullet-time-style movement, but then doesn’t explain how the naughty kids move in real time? (That’s why I was thinking of multiple phases).

Also, make not of the post on suitable controls for embedded web player games; having a mouse that provides direction will result in the mouse often being outside the window, which in turn will make clicks bring up other windows. Similarly, right click brings up a menu!

Beyond the metaphor a control layout, how does the game “feel”? Floaty, in water: that’s a start. How will you manifest this? Is the bot swimming (each press of WASD sends a pulse to push?) or is it continuous “thust”? Does the bot have a front (AD turn, W accel, S slow) or 4 thrusters in opposite directions?

Finally, you didn’t provide a prototyping plan. What do you want to prototype, how will it work, what is your target feel so that you can judge success or failure?

However, it does not really satisfy the 3 criteria of game-feel that your P3 proposal should have. There is no avatar that is interacting with a simulated world, such that you get the sense of the world through its reaction to you.

Also, what is your prototyping plan? What are you testing? How?

In your description so far, though, you have focused almost entirely on the setting. That’s fine for that part. But, I have no idea what the actual interactions are like. Is the audio theming purely metaphorical (i.e., under the hood, this could be any other side scroller, with you needing to avoid things or get things)? Presumably it’s not just that: the audio sources would have range effects (e.g., the ((( ))) you describe would, I assume, be circles, and when you start getting close, you would start having your Jam reduced at a rate based on your closeness?). That is a bit different than the binary “hit it or not” of most platformers.

But, even with that, I don’t have a sense of the interactions, and how they would feel. Is it “just” Mario? Are the interactions solid and simple with smooth motion? You should really consider how you can leverage your setting to make the player “feel” the music through what they are doing. Even in B.T.R, which appears to play like a simple platformer, there is a bit of this hidden in there, because the obstacles seem to be spaced such that if you succeed you “do” something (which causes a note to be played) at times such that the note fits the music.

How about this? Have your avatar get progressively more “In the Groove” as the Jam meter goes up, with corresponding animation (flip-book-2d-art). He starts bopping, spinning, grooving. Now, his abilities leverage this. If you jump when he’s crouched, you get a more powerful jump; if you cross the street when he’s spinning, you cross faster. In the eventual game, you could have a variety (perhaps 4 or so different moves) for each action, depending on what the kid was doing when you hit it. The goal would be that he could jump higher if he’s grooving, and get over a sound source cleanly, where a small jump would have him pass through the bad sound region, reducing his jam. Perhaps doing these in-sync moves would also increase the jam a little, thus making it possible to push you jam up even if you aren’t collecting things. If you really set the level well, you could even add sound for his actions (like B.T.R) that blends in.

In some ways this is making me think of Tiny Wings, where a lot of what you do as a player is about timing your actions to get the bird into a groove (of speed). You do this by hitting the valleys (slides), collecting coins, hitting the blue acceleration powerups, and avoiding hitting the ground poorly. The birds reactions, the sound, and the speed and scale all work together to heighten the sense of speed and tension when you are going fast. You could create something similar, yet I think calmer and more mellow, here. And, you could avoid the worst part of Tiny Wings, the fast-to-zero effect when you hit a valley wall badly; rather, your character, it seems, would have a more gradual reduction in “Jam” based on how close they get to the bad things.

And add sound he makes (“oh, yeah, boom ba boom ba boom”) when his Jam hits a certain level.

Also, think about the music experience: perhaps only play the bad sounds when you are in their region of influence, so their negative effect corresponds to their volume. Use unities sound filters to restrict sounds to their region. I think making the range of the sounds visually obvious (via visible sound waves that reach a clear extent) will be vital.

As for the prototype plan, I disagree that that polish will be the most important part. First, game-feel “polish” (vs environmental/background polish) is about those things that happen in direct response to the users actions; much of the sound you describe is happening in the environment. By contrast, how the character moves (see my suggestions above, which are just one idea off the top of my head) is critical; I think the thing that will separate this game from the crowd of platformers would be how the character moves and how you need to leverage it in your interactions. Think that out more, and say what you are trying to achieve in the feeling of the prototype, so we can judge it. What is success? What is failure?

That said, you have only described the structure of the game, but not talked at all about what the bowling interaction feels like. If you want to convince us that this game satisfies the definition of game feel, then the player would have to get a real sense of the physical characteristics of the simulated space simply by the manner in which they throw the ball, and the way that (as a result) it interacts with the space. This is no simply physics: how will you convey the materials, the physical (or synthetic) characteristics of the objects, by virtue of the throw. A “simple realistic physics model” probably won’t convey anything compelling, especially since it will be almost impossible to make it feel real.

The prototyping plan doesn’t address this: what is the feel you are trying to achieve? How will you know if you get it or, more importantly, haven’t gotten it? Any game designer that uses a physics engine must have a really clear picture in their mind of what they are trying to achieve with the simulation. Otherwise, you don’t know what to do when it “doesn’t feel right” … and, when you are learning to use physics engines, it’s pretty much guaranteed it won’t. So, please tell us what you are trying to achieve.

Beyond the needs of P3, I recommend against puzzle games for the final project. Good puzzles are hard, and take a long time to balance once you come up with them. For a project that must be done in such a short time, you don’t want the success of the game to hinge on something you are unlikely to have the time to achieve. That’s one of the big reasons I’m requiring folks to focus on games that have the 3 characteristics of game feel: they tend to be real-time, direction control interactive games, rather than puzzle or strategy games (although they can have those components).

I would skip the “time permits” ones, and enhance what you are trying to do by describing the feel of the speeder in more detail. I’d focus on making if feel really good; sounds, smooth motion, effects.

What are the levels like? Is it “pod racing” from star wars, tunnels and pillars and so forth … if so, what happens when you bump things? Or, is it a big open bowl (the crater) with nothing really to bump into? This probably makes a big different to the controls you want.

Also, while the obstacles would be appearing and moving in accordance with the music, that does not necessarily make it a rhythm game. Games like Audiosurf have obstacles that appear in accordance to music, but the player themselves does not move with the music.

As to how I would do 2D movement, I put together a quick pre-prototype that shows the various ways of controlling your character I was going to consider for the game:

http://www.prism.gatech.edu/~nwatson6/WebPlayer4.html

Controls:

1,2,3,4 keys: switch between the different controls

Control 1: Move mouse to move, object follows mouse exactly, click or shift to slow down

This is what I was thinking about going with before I made this pre-prototype, but its kind of inexact and jumpy in practice. And, as you said, a bit arbitrary.

Control 2: Move mouse to move, has a stabilizer, click or shift to follow stabilizer more exactly (faster, but more jumpy), right click or ‘Z’ to display stabilizer

This one is what I would like to go with if I can create the game as above. It’s a lot smoother, but this one is also admittedly somewhat arbitrary to implement.

Control 3: Moves like you are rolling a ball with the palm of your hand, touchpad recommended, click or shift to brake

This one might be a bit inexact for dodging obstacles, but it could make an interesting game if I decide to go with the path-following game instead.

Control 4: Moves like the stage is being tilted

Like the 3rd one, it might also be worth looking at if I go with the path following game.

Let me know what you think. I’ll have bullets to dodge in the prototype on Thursday, so I’ll see if I can make the game predictable. If you think that the character control is too simple for the assignment, let me know, and I’ll try to think of ways to spice it up (or maybe do something else).

You prototype plan sounds more like an alpha implementation plan: you just list a feature set you are trying to achieve, but are not telling my WHY you are doing it and what you hope to SPECIFICALLY demonstrate learn from the prototype.

If we imagine that you are building something with more direct interaction, focused on your character. What are the interactions like? How does it feel to simultaneously interact with the world (avoiding things, hiding, casting spells) while simultaneously having to issue commands to control the rest of the team? There are plenty of models for the control aspect (every StarCraft style game) but not for simultaneous indirect control and direct interaction. So, create something where you are just issuing commands (perhaps you just have targets pop up that you need to tell someone to “go” to, even if there really isn’t anyone there) while you have to move around and fire a spell and avoid getting hit. Can you build that and make it fun?

The control scheme seems like a pretty reasonable way to start trying to do what you want. You’ll want to think more about how the movement will work in terms of the movement between points: do things start and stop immediately, or is there a bit of smooth (even if very quick) easy-in-easy-out acceleration.

As for managing the bounciness I think it will be important to factor in what the ball collides with. If with another relatively light object such as another ball, there wont be as much force created on the reflection bounce as if it were to collide with a much greater force. I am envisioning more subtle interactions between the balls (since they will be relatively mass-less) but the obstacles and the players special powers which create a more substantial force which will be creating this very fast popping around dynamic.

Out of all the questions I have, I agree with Blair that the physics is the core. How do you balance between the bounciness and the sense of control for players?

In most rhythm games, such as DDR, Rock Band, and Dance Central, there are clear visual cues of the next action and feedback on whether a player misses a beat or not. This tight action-feedback loop and the support for players to observe and prepare for the next action is essential to rhythm games. Try to improve your game design along these two directions.

But what’s really difficult (and rewarding) for your game is to design for the sense of accomplishment. Avoiding something seems to be a more passive goal than the tight action-feedback loop. Give your player reasons to go through the scary journey. Provide intermediate goals rather than just one final safe spot.

The slides from Left4Dead creators may be helpful: http://www.valvesoftware.com/publications/2010/GDC10_ShaderTechniquesL4D2.pdf

Beyond that, your prototype goals is a list of “features” with now description of what exactly you think you are doing. What is the movement _like_? What does it feel like/what happens when you hit walls? obstacles? Is it smooth sliding on edges, is it a 2D side-scroller like the games I mentioned above (which you are just moving within a range?). I have no sense of what in that spectrum you are proposing!

What is your prototyping plan?