Heh. "Inventors" and "masters" maps well to the old marketing truism: be first or be best. Course, the problem with going for "best" is that there are usually studios with 20+ staff and multi-million dollar budgets chasing that particular rabbit.

Cobralad: You missed a tier. Many of the best developers draw inspiration from life and personal experience, not just second-hand from other cultural artefacts and certainly not just from other games.

Yeah, I'm pretty sure downvoting doesn't actually count against a game's approval - though if I was Valve I'd have set it up so that games which are heavily downvoted disappear off the front page.

haha, that's true.

I'm sure things will get a bit clearer when the leaders emerge. Currently it looks like Project Zomboid and Slender: Source are way out in front.

You say that, but I've had 10,000 people look at my game overnight. They may not have left Steam, but even if the game doesn't clear Greenlight the exposure's good (and the feedback's helpful, too).

Sweet, I didn't realise Routine had gone up. Upvoted.

I'm the main developer on Cardinal Quest II though, tametick passed it on to me after CQ1

I am curious if the huge difference in unique visitors between the two games I have listed is actually the result of some weird algorithm shuffling causing one to appear way more often than the other. Not entirely, I'm sure, but I don't know if there is any effect.

I'd hazard it's due to lots of people finding the "Science Girls" image interesting but the "Date Warp" image less so. Hardly anyone's going to look at every single game, so the branding image can make a huge difference to traffic - just like on FGL etc.

I've been browsing it since it launched, it's super fun I think it just crossed 300 games listed. It's like one big indie party.

There are a few "collections" that highlight some of the best stuff on there, like the indiegames.com collection. (and I'm super chuffed that they included CQ2 ). But the funnest way's just to go through and click on random stuff!

As for the percentage, it seems to me like everything's stuck at 0% for now. Maybe Valve are keeping things there and will start things rolling properly once the traffic stabilises.

Working when statically initialised and not when dynamically initialised or initialised on the stack suggests that some variables are not being initialised correctly when the object is created, thus the way the memory has been initialised before construction is affecting the object's behaviour.

Are position_, angle_ and scalar_ initialised in the Quad constructor? Is the Quad constructor being called? (If it takes any arguments, it won't be.)

If that's not the issue, I'd suggest stepping through Render() and possibly LoadImage() in the debugger in both situations (once with the TexturedQuad statically created so it works, and once with it dynamically created so it doesn't) and checking to see which values are different. Go through, take notes and compare. Something will probably jump out as obviously weird, and then you can trace things back to figure out how it got that way.

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.