Show us the code then.

Pop it on pastebin.com or something.

Your state management should be in a specific component - say, PlatformingPhysics. It should drive changes in other components as required by sending them messages in a fairly general purpose format, eg: AnimatedSprite start playing animation "x", SoundEmitter play sound "y".

Either that component responds to player input directly, or you set it up to receive messages from another component which responds to player input and drives it (or could, hypothetically, be running AI or cutscene logic).

A component system tends to have one component per type of entity which contains all of the special case logic for that type of entity and cannot be re-used with other entity types. That's OK! You just want to bundle as much of the logic up in general-purpose components as possible.

Imagine a game where you invade an area instead of defending it by strategically placing towers (Tower Defense opposite) where you strategize enemy troops.. Anyone encountered such a game?

Gratuitous Tank Battles.

Your camera has a tracking position, right? Like, the "camera position" actually means where the top left corner sits, or where the centre of the screen sits.

Here's a simple way to think about it. When you're changing scale:

1. record the mouse's position, in pixels, relative to the camera's tracking position
2. move the camera by that many screen pixels (before changing scale) so it ends up at the mouse's position
3. zoom in or out
4. move the camera back by the same number of screen pixels at the new zoom level

Because we cancelled out the mouse's position before zooming in or out and then reapplied it, the mouse cursor will stay at the exact same world position - rounding errors notwithstanding.

Think holistically. Develop all of the elements in concert.

No-one paints portraits by getting the hand perfect before starting on the face.

Just gotta note one thing: simplicity in design isn't really a way to add design elements, it's a way to remove them. It's an approach which condenses and refines complexity and renders it intuitive. It is both harder and more rewarding than complexity, because it lies on the other side.

- Determine the core values of your concept and what players are engaging with and aiming for at various levels: second by second (combat, puzzles), minute by minute (level progression, tactics, equipment management) and hour by hour (story, strategy, replayability). What's important? What can you afford to cut for the sake of simplicity?

- Cull everything which is of little value to that core. Be merciless. If it doesn't significantly add to the core of the experience you're creating it is worthless, however cool it might sound in isolation.

- You can also merge weak or redundant elements together to form stronger, more distinctive elements. Look for ways to merge entire systems such that you're left with a single, richer system.

- If two design elements don't interact much, find ways to make them interact or consider cutting or changing one of them. Rich interactions between different systems are a great way to get depth without apparent complexity.

- Rather than adding new elements or systems, look for ways to develop or exploit nuances of existing elements and systems which can make the game richer in an intuitive way. That's OK.

Here's something concrete. Stop adding content which has different statistics or parameters; that's easy to do but it's boring as hell. Instead, add content which has different rules. It's more work, but your players will likely find this easier to grasp - and more fun! Instead of a gun that does more damage but takes longer to reload, you can have a gun that's powered by sunlight and sets people on fire... and so on.

With Zelda, I could very easily believe they started out with sword combat and monsters, added an absolute ton of crazy stuff - immediately rejecting anything which was boring, or just changed stats, or whatever. Then they kept hammering at it until every single thing either ended up balanced, intuitive and unique or got cut.

A lot of it would have been cut. Polish like that is ultimately about being willing to throw away a lot of your work.

btw, the core of a game can be ridiculously simple and unimpressive. There are tons of successful games about just moving and jumping, or moving and shooting, or pressing buttons in time with music, or steering a car. There are major successful games simply about throwing stuff. Foddy's made multiple games about moving your legs. You can make games about typing, or brewing coffee, or swimming. Anything goes.

If you want to make a simple idea strong or interesting enough to be the core of a game: make that simple idea in such a way that it's fun to engage with and rewards mastery, then add progressively harder, varied challenges related to that simple idea. That's all you need.

[You need to model longitudinal and lateral friction separately.]

You need to model longitudinal and lateral friction separately. This is the main reason your car feels like it's on ice. Tyres on tarmac resist sideways movement, hard, but will happily keep rolling forwards or back unless they lock up under braking. This is the effect that, for example, allows cars to carry speed around corners.

Also, skidding friction shouldn't be proportionate to your speed. It should absolutely be linear. On the other hand: cars also experience rolling resistance forces which are proportionate to speed, and air resistance which is proportionate to speed cubed.

Here, replace all your friction code with this and tweak as needed:

Code:

// assumes deltaTime is in seconds
// assumes velocity/speed etc is in metres per second

// split velocity into components
forwardsSpeed = velocity.x * Math.cos(rotation) + velocity.y * Math.sin(rotation);
lateralSpeed = velocity.x * Math.sin(rotation) - velocity.y * Math.cos(rotation);

// lateral friction: scrub off 7 m/s^2
// you may want to reduce this effect when accelerating at low speeds to get some basic powersliding and low speed manoeuverability
if ( lateralSpeed > 0 )
  lateralSpeed = Math.max( 0.0, lateralSpeed - 7*deltaTime );
else
  lateralSpeed = Math.min( 0.0, lateralSpeed + 7*deltaTime );

// combine components back into velocity
velocity.x = forwardsSpeed*Math.cos(rotation) + lateralSpeed*Math.sin(rotation)
velocity.y = forwardsSpeed*Math.sin(rotation) - lateralSpeed*Math.cos(rotation)

// air resistance; screw it, let's just stick with what we had
velocity.multiply(Math.pow(FRICTION_NORMAL, deltaTime * _maxFPS));

That's just the start, but it should make a big difference to non-skidding handling. I'm sure you'll want to experiment with changes to lateral friction to see how different approaches feel.

If you really want to get some life into your skids I'd recommend simulating longitudinal and lateral friction independently at each tyre, simulating rotational momentum of the vehicle, controlling the rotation of the car in response to forces at the wheels and simulating wheelspin/skidding by reducing lateral friction on tyres that wheelspin or slide at an angle greater than their maximum slip angle. This'll give you understeer, oversteer, spins, all that cool stuff - but will be a fair bit harder to tune and drive than something like this where you point the car in a direction and press forwards.

Wow, did I pick the wrong career. That's how much the construction manager of a hydroelectric dam gets where I live or the CIO of a medium sized company.

$200/day for a contractor (who manages their own office space; pays additional taxes; and has to fund holidays, illness and hunting for work out of pocket) is equivalent to maybe $30-35k a year. That's roughly entry level pay for a games artist in the US or EU. I think salaries are a bit lower in Japan.

Jonathan Blow spending $200k on Braid included his living costs during development.

A lot of that 200k was spent because I didn’t want to live in a shack somewhere... It doesn't require $200,000 to make a game...

It requires a PC, a dev kit and enough money to live on for the time it takes to develop, plus extra time because it will always slip. If you can live for three years at your Mom’s house, you can make a game for free.

• Monsters/Creatures (10-15 items), maybe even animated like .gif file or something (I belive it would be like 2x-3x times more expensive)
• Items like swords,shields,helms, etc. (30-50 items)
• Background objects walls, doors, grid, trees, mountains, etc (~30 objects)
• Skill icons (~30) - http://1.bp.blogspot.com/-ZUJm-O61fF4/Tka4Y4mjFLI/AAAAAAAAAOU/h3z_-abK9Gc/s1600/dredmorskills.jpg
• Main Screen/Desktop Wallpaper (1-3 pictures)

Could someone enlighten me or give some tips of how much investment I should expect? 

For the above, depending on the level of quality you were shooting for, I'd guess around $6k-$15k. A professional freelancing artist should expect in the region of $200/day and that's quite easily a few months' work.

Kinect doesn't intuitively map to actions very well at all. Your actions are at such a level of fidelity that dissimilarities are very clear. The most common issue is that there's zero tactile feedback, and we rely on touch a great deal.

As for further reading... I've dug up a few things for certain points.

- Responsiveness

This is plain old cognitive science: how close do an action and a result have to be in time for the brain to assess them as a single event? The Perception of Cross-Modal Simultaneity.

- Significance and empowerment



. It's very easy to see this at work in casual games - say, PopCap games - but it's just as present in any game with really powerful sounding guns and cool-looking explosions.

As for empowerment, this runs deep. Since the dawn of gaming we've been mowing down armies, coming first and kicking arse all the way, and the balance between empowerment and realism defines the spread of entire genres: Bulletstorm to ArmA, Need For Speed to rFactor, THPS to Skate,

to Fight Night. (Though, even games towards the realistic side generally grant you peak human physical competence, knowledge and status to play with as a matter of course.)

- Intuitive mapping of interface to effects

This is just design, not really game specific. It relates to affordances, to immersion, and to the controller as metaphor.

- Edge of predictability

For an example of someone explicitly applying this principle see Tuning Canabalt.

- Context and surprise

Nothing specific here, but adventure games are generally huge on this. They have all these verbs and all these nouns and they want you to play around with them all, but there's nothing intrinsically fun about pressing buttons and getting an "I can't do that" non-response, so they shove comedy everywhere for you to find so you're motivated to explore the possibilities. Psychonauts definitely has this mindset too, what with Tim Schafer moving over from adventure games. There are loads of cool little interactions specially added just to make things feel fun and reactive.

Here's a challenge: check out Super Mario Bros (NES) world 1-1 and count the interactions available. Including the secret block and the secret area you can descend into I count 20 different ways things respond when you jump into them, jump on them or simply move into them. All of that from left, right and jump. That's context.

I've found that 48-hour jam games take me a couple months to finish.

If you haven't finished a game yet, literally start with the smallest, simplest game you can think of and make that. It may well end up taking the timeframe you're suggesting.

Some factors that may help:

- Responsiveness.

When you apply an input, the effect should be immediate. Delayed effects feel sluggish and disconnected from your actions.

- Significance and empowerment.

Effects feel better when more happens. Sounds, particle effects and dramatic punchy animation all contribute to significance. This single aspect is most of the "juiciness" concept and is all about locking in on that feeling that your actions have had consequences.

In any realistic scenario, people will generally prefer control response which flatters and empowers them rather than the reverse (though feeling grounded in reality is necessary for that empowerment, so there's a balance to strike; see Tony Hawk vs Skate). Crackdown doesn't have particularly great controls but you can jump up the side of buildings and throw cars; that's fun. Driving and shooting games routinely apply the same logic, even "simulation" driving games with their various assists.

As a side note, survival horror games struggle with engaging controls in part because they're thematically incompatible with empowerment.

- Intuitive mapping of interface to effects.

The Guitar Hero guitar and steering wheel are good examples; so is the Steel Battalion controller. However, arrow keys and control pads can also achieve this.

In Mario 64, you push the stick in the direction you want Mario to move. In Katamari Damacy each thumbstick is one of your hands, pushing or pulling the katamari. In Skate the thumbsticks become a gestural interface, each movement corresponding to part of a trick. In Smash Bros., slamming the thumbstick violently to one side is a component of especially violent actions. In Metal Gear Solid 3, grabbing a human shield turns into snapping their neck if you apply a bit more pressure to the button. In Forza, the joypad's right trigger becomes a pressure-responsive accelerator pedal. In Call of Duty it becomes the trigger of a gun.

- On the edge of predictability.

If controls aren't predictable, the game's unplayable or mushy and random. If they're too easily predictable, they're no longer inherently interesting. Engaging controls need to be predictable but get away from you slightly, requiring constant focus and attention and rewarding increasing mastery with increasing precision. This knife-edge balance can come from the timing of snappy, volatile response; the nuances of subtle, intricate motion; the unfolding layers of combo systems; or all three. Either way, the gap between success and failure should be hard, clear, and stand on the limits of human capacity.

- Context and surprise.

Though controls should be predictable - pulling the trigger should always shoot - they should also ideally have enjoyable and possibly surprising consequences based on their current context. Your fist can punch many things, but each reacts differently. Your gun can shoot many things but some ping off, some explode and some fall over. Your Katamari can pick up different objects, but each makes a different noise.

The tool remains the same but the situations they're applied to change dramatically. If you can surprise and entertain players when they apply the controls in new contexts, they'll look forward to experimenting with new possibilities.

Magicka is a great example here, but so is simply interacting with people in Psychonauts. So are the different songs and riffs in Guitar Hero. In Mario, it's usually about how stuff reacts when you jump on it.

---

If your controls are responsive, have clear feedback, map intuitively, are on the edge of predictability but reward mastery and cause significant things to happen in an empowering way... you're probably on the right track.

Conversely, "bad" controls in many of the above respects can be aesthetically valid (as in survival horror, or in the ending of Shadow of the Colossus), and unintuitive controls can open the way to interesting mechanics.

Activate The Three Artifacts And Then Leave

[scenes]

How do you properly code a commercial game architecture? How do you organize it?

Commercial games aren't any different from other games. The constraints of AAA console games necessitate a range of different approaches and advanced optimisations, to deal with bumping up against the machine's limits in terms of memory, media read speeds and CPU/GPU power... but in general, there's little applicable to commercial games of moderate scope which isn't equally useful for freeware or even 48-hour jam games.

Here are some concepts you might find generally useful:

A game consists of one or more scenes. One scene is active at any time. Each frame, the main loop updates input libraries, then advances and renders the active scene. On request, the main loop will change the active scene to another. (This responsibility can also be handled by a separate Scene Manager class).

A scene consists of multiple layers, representing - for example - the world, the UI, and menus. The scene is responsible for advancing and rendering these layers, and occasionally for requesting a change to another scene - such as beginning the game or moving to another level.

Each layer contains a number of entities. Entities can have all sorts of data associated with them. They can be characters; they can be lights; they can be trigger zones; they can be entire levels worth of static data; etcetera. Layers are responsible for advancing and rendering these entities, and can do in specific orders. For example, a chase camera entity might need to be specifically updated after the player entity, to ensure that it doesn't trail behind the player by a frame when updating.

There are a few different ways to encode the various kinds of entity. One of the simplest is a hierarchical entity system, in which all game entities derive from a base "Entity" class, specialising and expanding it in various ways. For example, you may have a Character class which inherits from Entity; then an Enemy class which inherits from Character and adds AI; then a FlyingRobotEnemy class which inherits from Enemy and adds specific movement and behaviour functionality for flying robot enemies.

This approach is trivial to implement, but to prevent duplicate functionality from popping up at various points in the inheritance tree in any non-trivial game, functionality tends to gravitate towards the base classes making them monolithic and unwieldy.

Conversely, one of the most versatile kinds of entity system is a component-based entity system. In such a system, each entity is simply a bundle of components capable of accessing each other. Each component contains both data and code necessary for performing its job. Typical components may include:

• the entity's transform (position and rotation);
• render data for the entity;
• physics data for the entity;
• game logic for the entity (scripting, a player control component, or AI).

Generally, each kind of entity uses a bunch of standard components (for transform, render data, etc) and one or more components which are written just for that entity. For example, a flying robot class of enemy may have both a "FlyingRobotMovementComponent" and a "FlyingRobotAIComponent", but it'll also have a standard transform, physics and render components.

If you choose to implement scripting, a "scripting component" that loads and executes scripts for that entity is a versatile and effective way of adding it to the game.

See Unity for one example of a component-based entity system's implementation. Regardless of the system the player is simply one entity amongst many, albeit one the camera entity follows and to which the scene pays special attention.

How do you make it not become unmaintainable spaghetti code?

Up-front design and/or refactoring. With time and experience, you'll find it much easier to design code so that it turns out okay; you'll recognise in advance when you'll need to restructure code so it doesn't end up a mess; and you'll learn to recognise when it doesn't matter if code ends up a mess.

While you're starting out, just be aware of when things are getting rough and put the effort in to refactor and fix bugs.

What specific things to keep in mind when building this, codewise?

It's good that you're concerned with design issues, but don't get stuck on them. Don't be afraid to dive in and hack stuff together and fix it later. Don't be afraid to get things wrong on this project, either; you can learn from experience and do better on the next.

a) Please tell how do you code your own game projects. What is your thought-process when designing the architecture?

My main considerations when starting off with a project are a) its scope, b) performance requirements and c) target platforms. A graphically intensive, competitive, networked multiplayer game across several platforms will require a significantly more robust architecture than a simple Flash game, but in either case the general structure I'd use would be as above.

b) Recommend books, blogs, tutorials, videos or anything else on how to organize a commercial video game.

With decent sized projects of any kind, it helps to have a passing familiarity with design patterns. It'll give you more tools to play with when structuring your code, though learning when they're applicable takes practice and experience.

c) Give hints and tips on do's/don'ts when building a game, codewise.

• Have fun;
• keep learning;
• finish it.

Definitely not true these days! Maybe there are people who feel like this, but they're elitists and you don't need to listen to their opinions.

If you're interested in programming work for a major console game or PC game studio, it still makes a lot of sense to focus on working in C++.

Everywhere something moves, show it moving. When a new block appears on the bottom bar, can it slide into position instead of just popping into existence? Can the blocks move and rotate from the bottom bar into position rather than snapping? Can they fall and thud satisfyingly into place in the track? Can they be transparent instead of wireframe while they're waiting? Can they stay yellow after they've dropped into place? When a line's filled, can it be shown to fuse solid in a way which carries positive connotations of success?

This continuity, physicality stuff isn't just "polish" - it'll make the rules and mechanics of your game much clearer to new players.

Become passionate and knowledgeable about:

1. Games.
2. At least one thing other than games. Your choice. Film production and robotics, for example, are both fine.

Let your passion inspire you. Let your domain knowledge shape and apply that inspiration.

Don't worry about the actual process of being creative; anyone who claims they've got it totally figured out probably works in marketing. Just soak up as much interesting material as possible so you have lots to work with.

Isn't the realization that your great idea is "lousy" just a way to give up on solving tough problems?

It's a way to solve tough problems. Problems like "how the hell do I build a decent game around this flawed idea?"

Motivation wise, I'll second breaking tasks down and tracking them properly. I've also found having a burndown chart really helpful too - every time I finish a few hours' work my ship date gets a few hours closer, and I find it really motivational having this graph of measurable progress to prove it.

I've been using FogBugz for task tracking and it generates burndown charts etc automatically. It's $25/month per user, but easily worth it to me 'cause I'd never do all this stuff by hand.

The majority of games on portals are 10MB or under. I'd expect a little more leeway for a music game, but it might be worth cutting sound quality hard or maybe splitting the game into a few separate games if you have a lot of tracks.

Currently your best option is to package with AIR, which gives you full control over things like full screen and right click, an installer, an update system, etc. AIR's a bit of a pig to work with but it beats just shipping a projector version.

- someone decompiling the exe, getting the .swf, and publishing it to websites

Sitelock the game to only run locally and run it through SecureSWF or similar before packaging with AIR.

- performance issues

Well, it's Flash At least it's likely to run better than it will in a browser.

- full screen: even though I'm publishing in
- Is an installer necessary if I it's a small game?

AIR provides an installer and full screen functionality.

btw - AIR also lets you read and write files on disk, which you should use for save games as browsers can wipe the Flash shared object cache and delete your save games etc when you're not looking.