[It may sound easy and simple, but it will make your code more complicated and harder to read in the long run.]

Hey, and welcome.

There's a perfectly adequate mechanism for storing data in C++. It's called "member variables" and they're a hell of a lot faster than string lookup on a map...

Generally, you should be storing entity data in components. Data which is common to all or almost all entities, you can store on the game object class itself. Taking the example of a position Transform, you could either have a TransformComponent which stores a Transform variable, or store the Transform on the GameObject. You might have a PhysicsComponent which stores velocity, acceleration, etc., and is responsible for basic integration and collision checking. Your AI component would store AI state data while also manipulating and acting on that data.

Components which need to access other data simply communicate with the components that hold it. One useful abstraction is to allow multiple components to implement a given interface, which can then be accessed by other components - meaning that different component types can provide the same data or functionality to other components. For example, you may have a few different types of physics component, but all of them might provide velocity, etc.

Don't try to store all your data in one generic place without strong typing. It may sound easy and simple, but it will make your code more complicated and harder to read in the long run. Without any explicit declaration of variables or their types somewhere in the code, you're quite likely to run into situations where you accidentally use the same variable name to mean two different things, or forget what type a variable is meant to be. Without tight, explicit ideas in your code about data ownership and access control, you will have no real idea which components are dependent upon which other components to function. You'll end up in situations where a variable is not what you expect, anything in the entire codebase could have changed it, and you won't even have a good place to set a breakpoint since the data write goes through a generic "write to named variable" method.

Good programming means making what things are and how they interact explicit, such that the amount of code which could be affecting each given bit of data or section of code is both minimal and clear. Working with this objective in mind will make your code simpler, easier to read, easier to debug and easier to improve or extend.

Damn. Somebody tell Valve they've been doing it all wrong.

The Cabal: Valve’s Design Process For Creating Half-Life

Student projects tend to hit serious problems no matter how they're run. They're not good places to assess whether given methodologies have merit. No approach to something as complex as design or production is a silver bullet, and you'll always hit problems to start with.

...none of them seem to work for java because of it's co-ordinate system, which 0,0 starts at the TOP of the screen.

Subtract the mouse's Y co-ordinate from the screen height in pixels minus one. Hey presto - you now have a Y co-ordinate with 0 at the bottom of the screen.

If you hate your tutorials, put the work in and make a good one.

Teaching people through play is a fundamental skill for a game designer. It takes a lot of work, a structured approach, genuine design skill and a bunch of playtesting, but it can be done.

Portal 2 teaches new skills all the way through. The closest it gets to explicit instruction is a handful of button prompts at the start telling you what the keys are, and even these are couched in tight, perfectly-judged comic narrative.

It isn't so much about teaching people things as giving them opportunities to discover them.

Dwarf Fortress and Minecraft could absolutely teach people everything they need to know without boring tutorials, a manual or anything like that. DF falls at the first hurdle by not even offering basic affordances; the interface is so unintuitive you need a tutorial just to figure out what the hell is happening and how you do anything. The first step would be giving it a graphical, mouse-driven interface. All the tools available should be presented visually. Then I'd adopt the "advisor" system from Civ, with social, economic and military advisors recommending various courses of action you could take (or totally ignore) to get your dwarves happier, richer, or better defended. A handful of short goal-oriented challenge scenarios would both show players what's possible in terms of fortress construction and drive them to learn necessary skills. Achievements would drive discovery, encourage people to explore the systems available and hint at hidden depths. A searchable in-game manual/codex hotlinked across the interface would precisely explain the rules for those who wanted to know. None of this would alter or simplify the game in the slightest and there wouldn't be a tutorial in sight.

Enabling people to access even the complexity and depth of DF in an interesting way is a challenge but it's not impossible. DF doesn't fundamentally need to have a steep learning curve; it's that way because the developer has other priorities (and perhaps rightly so).

Minecraft starts off well - you're given tools which suggest you should cut down trees and dig into rock. It falters because crafting isn't explained and crafting recipes are extremely difficult to discover without tabbing out to a wiki. The only thing it really needs is an in-game index of the things you can craft, telling you things you can craft with the resources you have and hinting at valuable resources you haven't found yet to get you digging. Everything else is easy enough to discover.

Using penetration depth is usually fine. Swept tests are nice but get very messy if you introduce rotations, different shaped objects, etc. If your game just has axis-aligned boxes colliding with axis-aligned boxes, doing swept tests shouldn't be too complex.

The problem with using penetration depth to separate objects after they've moved is when you have very small or very fast-moving objects which move further than half their own length or so in a frame. That can lead to the above, and also to "tunnelling", when fast-moving objects can fly through thin walls or objects in a single frame without ever realising they should have collided.

If you run physics steps often enough that objects move slowly relative to their size, there's no real problem. In that illustration above, for example: if the box was also tested halfway along that path, or several times as it moved along that path, it would resolve correctly. That'd be the outcome if it was moving slower.

Hey - it happens. You probably spent less hours working on games every week in the past than you do now, officially studying game development; and you probably just did the "fun" stuff, rather than seriously buckling down and learning useful skills no matter how dull the process might be. If you end up spending too much time on a hobby and taking it too seriously, it's natural to want to do something else with your free time.

The fact is, lessons are just less interesting than playing around with tools and technology when you've got something cool to work towards. Also, if you've been working on this stuff yourself, you might find the material in the first year or two of the course very easy.

You may also feel complacent about 'becoming a games developer' now that you've got on a course that says it'll make you one. (If that's the case, you might find it interesting to ask what percentage of graduates go on to work in games. It won't be 100%. Some people will drop out along the way, and some people just won't be good enough when they graduate. Some of your friends on the course probably won't make it. You might not.)

Anyway, however it happened, the reason you had to make games has disappeared. You've got to find a new one. I don't know if it'll work for you, but consider taking part in challenges like Ludum Dare 48 to see how you measure up to other game developers, including professionals. That'll give you a chance to test your skills and see how far you need to go to match up to the best. If you're at all competitive, give this a shot - it might motivate you.

Something else that'll help is to hang around people who make games all the time. Whether it's on this forum, on IRC channels (like the Ludum Dare channel) or anywhere else, the more time you spend talking about making games with people who make games, the more you'll feel inclined to do so yourself. It's a simple trick, really - we're social creatures, so we adopt the norms and expectations of the people we spend time with.

Finally, just go looking for cool things you could make and reasons to try them. Do you like thinking up game ideas? Who doesn't, right? When you come up with one you like, try bashing out a prototype over a weekend. If you think of a way to improve a game, try modding it in. You don't have to commit lots of time to this stuff - you can knock out basic cool things in a couple of evenings, or a weekend.

In the long run... game development probably will never be quite as much fun as it used to be. But as you work on game ideas and so on, occasionally that old passion will flare up and take over. It's not gone - it's just sleeping, waiting for you to get back on track

In the tutorial Nix linked, which is what I was suggesting modifications to:

(centerx,centery) is the cursor position.
(_x,_y) is the ball position.
(x,y) is the vector from the ball to the mouse. It's used to calculate the force to apply to the ball.
(xp,yp) is the ball velocity (speed).

I stuck with those variable names for my changes.

They're horrible variable names, though! Here's the whole thing, including my changes, rewritten with more sensible variable names. The whole thing's untested though, so you might have to play around with the constant values before you get sensible behaviour.

Code:

// Variables provided every time the function's called:
// mousePosX, mousePosY

// Variables stored from frame to frame:
// ballPosX, ballPosY
// ballVelX, ballVelY

// Spring constant.
// Higher values will pull the ball towards the mouse faster.
springConstant = 0.1;

// Inertia.
// On a scale of 0 to 1.
// With low values, the ball will drag slowly like it's moving through treacle.
// With high values, the ball will happily bounce back and forth for a while.
inertia = 0.9;

// Prediction.
// Measured in seconds. Default: 0.
// How far ahead to predict the ball's movement, for the purposes of slowing it down.
// Low values will let the ball bounce back and forth past the mouse.
// High values will make the ball jitter and take a long time to reach the mouse.
predict = 0.2;

// Tangential inertia.
// On a scale of 0 to 1.
// Low values will force the ball to only move towards or away from the mouse.
// High values will allow the ball to sling around the mouse in circles.
tangentinertia = 0.7;

// Calculate a force from the ball's predicted position towards the mouse.
forceX = mousePosX - (ballPosX + predict*ballVelX);
forceY = mousePosY - (ballPosY + predict*ballVelY);

// This block is optional and the rest will work OK without it.
// You may as well get the rest working, then add this in after.
{
  // Split the ball's velocity into a "towards mouse" component and a "sideways" component.
  forceLength = sqrt( forceX*forceX + forceY*forceY );
  towardsComponent = (ballVelX*forceX + ballVelY*forceY)/forceLength;
  tangentComponent = (ballVelX*forceY - ballVelY*forceX)/forceLength;

  // Reduce the ball's sideways velocity.
  tangentComponent *= tangentinertia;

  // Convert the components back into X and Y.
  ballVelX = (towardsComponent*forceX + tangentComponent*forceY)/forceLength;
  ballVelY = (towardsComponent*forceY - tangentComponent*forceX)/forceLength;
}

ballVelX = ballVelX * inertia + forceX*springConstant;
ballVelY = ballVelY * inertia + forceY*springConstant;

ballPosX += ballVelX;
ballPosY += ballVelY;

Altitude bars shouldn't be necessary to convey something you should be able to just see. Remove em

Widen the field of view (and shift the camera closer to compensate). This exaggerates perspective effects, so characters further away from the camera will be more obviously distant.

Shadows. Your people are a long way up, but you could add shadows on clouds.

Fog. Moderate fog will make differences in distance from the camera more obvious.

As a last resort, you could simplify vertical movement into sliding between multiple horizontal planes which are spaced far enough apart that differences in current plane are obvious.

The main thing is scale, though. If you don't want to use a wide field of view, another trick is to directly scale characters based on height/distance from the camera - so low/distant characters are shrunk, and high/near characters are larger. Be careful with this effect. Applying it too heavily can make things behave in counter-intuitive ways, like appearing to move a lot faster if they're further away.

std::shared_ptr

Circular references.

I was seeing what kinda of technical advice/insight/opinions on what platform is the best to make a game in?

If you have to ask, you probably want Unity, Flixel, Flashpunk or Game Maker. It doesn't really matter which, except that Unity is for 3D games and the rest are for 2D. Just pick one and get started.

Don't worry about picking up new languages. 90% of programming skill is entirely transferable. A new language will be second nature within a few months - and then you can say you know how to program in more languages.   That said, you can script in C# in Unity.

XNA is fine but does kinda limit your audience, especially compared to web-based stuff like Flash or Unity. Literally ten times as many people will play a web-based game compared to a download game, and many people who'd download a game won't play an XNA game. This may or may not bother you.

But don't worry about that stuff too much. The main thing is to jump in and start making something! Just as you can switch to a new programming language pretty quickly, you can switch to a whole new platform for each game without too much trouble; the key skills all carry over. You'll soon learn for yourself what you like and what you don't.

-- funnily enough, given what Richard says... I use C++ and HaXe, but I wouldn't recommend either to someone getting started as they're both more technically demanding than the options above. Unless you're doing this for a living, you won't really benefit from using them and they'll just slow you down. If you get to that point, you'll understand if they can benefit you and you'll be able to pick them up whenever you want.

(one caveat: if you want a programming job working on AAA and console games, you should start learning C++ immediately and use it as much as possible. You will need programming skills the other languages mentioned don't require to even get an entry level position.)

Jasmine: "The game got too hard, so I gave up"? That's what you want people to take away from your games? Arcade games, sure, but I don't think that approach is generally applicable.

But yeah. Playtesting and analytics. Rather than trying to work out some precise measure of difficulty - honestly, don't bother, it's different for every person and it's certainly not one-dimensional - the two things you're concerned about are when people get stuck and when they get bored. Difficulty, poor signposting and poor affordances are big factors in the former but the latter's as likely to be due to excessive repetition, a lack of mechanical depth, or even just not engaging with the fiction.

This is where the research you're interested in is being done. Not on dry, academic theories of difficulty but how to run objective playtesting sessions and interpret them, because that's what's useful.

If your narration is entertaining in itself, well acted, well paced and never (or very rarely) repeats itself, then yeah, chuck in tons of it. Everywhere. If it isn't, then you better cut it back to the bare essentials.

Bastion's narrative is actually reasonably sparse, but it always has it where it counts. Bastion's a 'total information' game, you can see everything you need to know about on screen, so the narrator isn't required to explain anything. Much of the narration isn't discussing the on-screen action but filling in background, adding character, foreshadowing and so on. Every sample is triggered by a simple event or location and then never plays again. It's a game you play once, maybe twice, so that's fine.

Portal 2's dialogue is set up in much the same way, though obviously to different effect.

For another approach, see Left 4 Dead 2. L4D is a complex, chaotic first-person game where you need audio cues to tell you what's going on. There are points where the characters stop and chat to deliver characterisation and backstory in the same fashion as Bastion's narrator, like in elevators and saferooms and quiet moments, but most of the time they're directly signalling game events like reloading, being on low health or spotting particular special Infected.

Coupled with the game's heavily replayable/partly procedural nature, that means a lot of repetition. Check out the dialogue files some time - literally, open them up in a media player and play through them in order. You will notice they recorded tons of variants of each line, even fairly rare lines, and many variants are just slight changes to performance. The sheer quantity of written and recorded dialogue means you get running coverage of the action without repetition.

Another example: Starcraft/Starcraft II. Every unit type has its own range of dialogue or sound effects for when it's selected and when it's given an order. Despite this coming up every few seconds at times it doesn't get old because their barks are short, well produced and highly varied. (Yep. It's a game involving lots of attacking stuff, and you get an audio response every time you select something, move something or attack something. It doesn't get old.)

In short, how you should approach this depends on the game you're making. An essentially linear game like Bastion or Portal 2 can have specific, extensive narration with little or no variation written for one-off events as you progress through. Anything procedural, open or replayable benefits from tight, repeatable event-triggered barks with lots of variants available. You can mix the two approaches - GTA's mission-specific dialogue is often lengthy and will have only one or two variants whereas open world pedestrian reactions are highly varied, and L4D2 has a couple of lengthy chats between characters which are long and happen in specific places during missions but have several variations. In a game with limited information like L4D, on-the-nose dialogue pointing out gameplay events has a gameplay benefit; if you can see what's going on as in Bastion, then it's crap.

Avoid true randomness as much as possible. True randomness has a way of doing the wrong thing, like repeating the same sample twice in five seconds and then going silent for ten minutes. Your system needs to be smart enough to never do the wrong thing. Look at smarter ways to achieve the same goal, such as setting things up so you can directly set the delay before a narration/dialogue trigger will activate again, or to follow Bastion's example, picking occurrences of that event throughout the game that give you something new to say and using each one just once.

Quality of writing and delivery are critical. If you don't have them or can't afford them - and on the delivery front that likely means an experienced voice actor with a clean recording setup - I think you're probably better off keeping narration to a functional minimum.

Finally, don't neglect pacing. Delaying a line by a tenth of a second more or less can mean the difference between it intruding unexpectedly and sounding completely natural.

Here's another possible issue, then. Am I right in thinking the portal's co-ordinates are numbered:

0: bottom right
1: top right
2: top left
3: bottom left

...so that when you form new planes from those vertices, you'll get RIGHT/TOP/LEFT/BOTTOM in order?

Reading through clipToPlane(): if the right hand vertices are outside the RIGHT clipping plane and the left hand vertices are inside it, then clipVertices will be built up such that vertex 0 is the top right (generated from the intersection), vertex 1 is the top left, vertex 2 is the bottom left and vertex 3 is the bottom right of the newly clipped area.

If the top of the portal is also outside of the TOP clipping plane but the bottom vertices are inside it, this will happen again and vertex 0 will now be the top left corner of the clipped portal. And so on.

This rotation of the portal means that the clipped frustum's planes (as generated at the bottom of Frustum::compute()) won't be as labelled, to say the least. The RIGHT plane may in fact be the top, left or bottom plane, depending on how the portal was clipped.

Replace:

Code:

linePlaneIntersection(plane, v1, v2)

with:

Code:

linePlaneIntersection(plane, v2-v1, v1)

or change the implementation of linePlaneIntersection to match usage.

For player/NPC control, I recommend abstracting their control out to a Controller interface. This interface has functions like "shouldFaceLeft()", "shouldMoveRight()", "shouldJump()", etc - including ways to trigger special animations. The player's actor normally has a Controller attached which interprets keyboard input as specific signals. NPC actors have Controllers attached which run AI and fire off control signals. The actor code itself simply interprets these input signals - it doesn't care whether it's being controlled by a player, AI, or script.

During a cutscene, you override the normal controller with a dead simple one that lets you switch control signals on and off manually from code/script. You can add slightly more elaborate functions like "move left until x = blah" later.

You restore control to the player/AI by reconnecting the normal controller. I use this setup in all my games now and it makes switching between player/AI control and various kinds of scripted behaviour a doddle.

For actually lining up cutscene events... an action queue/timeline is a good approach, but whatever you do, take into consideration variable length events. This can involve things like moving an actor to a required position from an unknown starting position, letting players fast forward dialogue, or having dialogue stay up until players press a button.

As for having to watch the whole thing and iterate to get the pacing and everything right... there's literally no way round that (though for sanity's sake, for cutscenes over 30 seconds or so, I'd suggest implementing a method of fast-forwarding to key points by simply setting all actor positions/states). If you can't launch your game and start a given cutscene in a few seconds, you either need to get your game launching faster or you'll have to build in a scripting language and support reloading scripts at runtime to get iteration times down.

I'll probably prototype the changed game in a week. You'll see a mention on your Twitter feed when I'm done.

Cool

Also, way to go randomnine busting out the art! Having recognizable pieces makes the rules so much easier to remember. Out of curiosity, where'd that art come from? Did you just make it?

Yeah, though the infantry sprite is from a game I did about 7 years ago, heh.

Here's how I'd make it more intuitive.

Axemen -> Rocket Troopers
Lancemen -> Tanks
Swordsmen -> Infantry

Units of different kinds can't stack, as stacking both makes things more complex to display (so less intuitive) and reduces tactical complexity by blurring the lines and allowing general-purpose forces.

- Squares and circles all become Towns. If a unit starts and finishes a turn on a town without splitting off units, it gains 1 strength up to the maximum.

- Triangles become Flags or Towers.

Mechanically, here's what I'd change:

Armies have a maximum strength of 5. You start with one army of each kind, of strength 3, in one corner of the board at (0,0), (2,0) and (0,2). (If the maximum/starting strength is too high, then splitting off single units to capture stuff becomes too safe.)

Each turn, players may move all or part of every single army they control. (Moving one at a time makes the game less interesting by preventing coordinated actions, while also making AI writing more complex.)

If an army moves into a friendly army's location, they swap places.

It takes five turns to capture a flag/tower. (This is so that, if someone rushes to capture flags too quickly, the opponent can take a few turns to reinforce/get into position and then guarantee winning the fight.) Once captured, a flag/tower remains yours even if you move all units off it.

The flags/towers should be spread out, not concentrated in the centre. I'd have three along the diagonal of the board (at 1,1; 3,3; 5,5). Spreading them out and making it take a while to capture something makes it harder to rush in for the win (your 'puma') and harder to have strong armies hovering around all of them at once.

Win condition: Every turn, each army occupying a flag/tower that you've captured gives you 1 point. The winner is the first player to, say, 20 points.

Combat mechanics: Defending units do damage before attacking units. Armies do 3 damage to the kind they're strong against, 2 damage to their own kind, and 1 damage to the kind they're weak against. Defending units take no damage if they kill the attacking unit. If an attacking unit destroys a defending unit, it moves to the defending unit's old location.

(Optionally: A unit can only defend against one attack per turn. If an army of 5 tanks is attacked by rocket troopers and then by infantry on the same turn, it does 1 damage to the rocket troopers and 0 to the infantry, while taking 4 damage itself.)

I'd also reduce the number of towns substantially to 4 or even 2 on each side. (Not 3. The number of towns should force you to unbalance your army.)

With this set of mechanics, I think you have to react to the unit types your opponent is making more of, rush to capture points ideally just before your opponent does, and play tactically to win combat. I'd have to prototype to figure out if it's a good direction, but it feels a bit easier to get a handle on and I think it definitely has interesting strategic problems in. I mean... it's really easy to see what's going on here, right? But... what's a good opening move?

Even putting a 2x2 grid of perfectly square tiles onto the surface of a sphere is mathematically impossible. Any parallel lines drawn on a sphere will eventually cross over.

You'll have to find a compromise that gives you an acceptable level of distortion given the nature of your game. One projection that avoids huge distortions is to start with a cube, draw a regular grid on each face and then expand all points of the cube outwards until it looks like a sphere - but obviously the corner points of the cube will end up with three squares around them instead of four.

If you start with a shape which has more than six facets, that'll reduce the distortion but you'll need to use non-rectangular tiles in some places at least.

I still can't find anything on making Xbox 360 games in C++, no matter how I alter my search terms. Other than rolling something of my own, like what I suggested in the happy programmer room the other day, what ways are there to get to work with C++ in one way or the other?

Studios that want to make non-XBLIG titles for the 360, in C++, need to get on Microsoft's Registered Developers Program or similar. All studios with access to the C++ APIs and to devkits are required to sign NDAs and not discuss details of either in public. This is why there's nothing on Google.

There's no real harm in rolling your own stuff, and if your goal is to find employment at a large studio then getting your hands dirty with low level tech occasionally will help

Finding answers to the questions you're asking is the foundation of the entire discipline of project management. People devote their entire working lives to this. Not only are the answers to these questions complex, nuanced and often situational, but there are several schools of thought as to what those answers should be.

Game projects pose additional challenges. Firstly, software development is notoriously hard to predict. Secondly, it's often hard to tell whether a change will make the game better or not until you try it. So... you pretty much have to make educated guesses about what's worth doing and what isn't.

You can put those guesses in context, though.

As you're working on a project, imagine what it'll look like when it's done and map out a course of action to get there. Estimate how much work it'll take. Refine those estimates based on stuff you've done before.

When you're considering embarking on a big chunk of work, step back and look at it from the perspective of the project as a whole. Consider how much work it'll add, total. Consider whether it'll genuinely improve the game in proportion, or if it's just a nice touch that isn't worth the effort.

If it seems sort of reasonable, then drop it. Any work you add to a software project makes it harder to build on, harder to debug and harder to test. It also makes the project longer, which means you'll be doing this one game for ages instead of shipping several and learning from them. Value keeping projects tight and efficient, finishing them and getting them out there.

Some books you might find helpful:

- Software Project Management for Dummies as a general project management primer
- Software Estimation: Demystifying the Black Art is a pretty good guide to figuring out how long stuff will take

I'd also suggest finding a primer on an Agile development (Scrum, Kanban, Lean, XP), but not at the expense of learning general project management concepts.