The language really depends on what segment of the industry you want to get into. If you want to get into hardcore engine programming, I'd probably start with C# then move to C++. Or if you're more interested in gameplay and authoring interesting experiences, I'd start with higher-level engines, like Unity (C#) or Flash (Actionscript).

Here's a more detailed breakdown:

Native games for consoles and PC:
- C++ for the engine (C# is sometimes making inroads)
- Lua or other scripting language for in-game events and behaviors

Cross-platform toolkits:
- Unity engine: C# and others (mobile, downloadable PC)
- Flash: ActionScript (mobile, web, downloadable PC)
- XNA and MonoDevelop: C# (console, downloadable PC)
(there's probably more I'm forgetting)

Platform-specific mobile development:
- Objective C, but only on iOS
- Java, but only on Android

And for multiplayer games, there are also server side languages, but that's a whole different topic.

Hope this helps!

Not sure a clustering algorithm will do the right thing, to ignore outliers...

You could consider bucketing the positions into grid cells, and doing a mode on the cells instead of raw floats.

Another possibility - since you don't want the average to pull away because of outliers, you could compute the average using a weighted distance. For example, the further away someone is from the previous average, the less their position counts in the new average.

On large teams, producers who get design responsibilities are the worst.   Producers are already in charge of assigning limited resources to fit everyone's needs. To do that, they need to be impartial observers, assigning resources as needed and available. But when they also get tasked with designing and delivering particular features, this impartiality gets sidelined, and with it goes their willingness to protect their resources.

Maybe it's an EA only foible? But I doubt it.

That was some great info! Really shows how much work is needed to hit the major platforms.

And congrats on having GDC release it to the wider audience! Most of the time, GDC talks get hidden behind a paywall on GDCVault.com...

As a single-person development team, do I need to form my own company to use Amazon Payments, or can I simply sign up as an individual and still do business though the service? And, if I need to form a company of some sort, where can I find the best information to do so?

You can probably use Amazon Payments as an individual (or a "sole proprietor"), but in your shoes, I'd incorporate in order to limit liability exposure, in case of lawsuits etc.

There are different types of corporations in the US, but the most relevant ones are probably S-corp and LLC. Googling for them will turn up a whole lot of materials about how they're different - for a one-man operation, they're not all that different, but it gets more complicated if there are multiple founders.

You can in theory incorporate all by yourself, but figuring out all the forms (and all the fees and taxes) is rather time-consuming. There are also companies that will help with it, for a fee (e.g. list out what needs to be done, and have someone look over your forms). For example, check out Nationwide Incorporators, and their website has additional info as well. Hope this helps!

Will this be a German language or an English language event?

I took a quick look at your portfolio site. You've got some neat stuff there, which should be very good for job hunting!

For your original question about a ton of email addresses - it sounds like you're intending to mass-email your resume out, is that right? I'm afraid that's not the right way to approach small studios. Big studios are different, but a small studio will care much more about whether you like what they do, whether you've played their games, whether you like the same genres, etc. So you'll want to research the companies in depth first.

I would recommend starting out with gamedevmap.com or something similar, and start with research. You can still hit up a number of companies at a time, but check their websites for openings, and tailor your emails and cover letters appropriately.

Also, a few quick tips about job hunting, if I may:

1. You have programming experience. Don't start with QA or testing, that's the wrong move here. Apply for a software engineering job, right from the start. And highlight your programming experience, not just games. A well-designed library with a clean API can be worth much more than a game demo, it's a better demonstration of software engineering experience.
2. I'd strongly encourage you to change your portfolio pages around, so that people can see your work on the web, without downloading files. Devs at work (ie. those reviewing your resume and portfolio) will be very suspicious of downloading stuff onto their work computers, because of virus and malware scares - and it may be even forbidden by company policy. I'd recommend showing off your stuff entirely in the browser - animations as youtube or flash videos, screenshots in the pages, code on github or your own blog, etc.

Hope this helps!

Flash/Flixel: Maybe I dismissed it a little too quickly. I'm just afraid that it's not much more flexible than Game Maker. If Game Maker is too restrictive for something I want to do, Flash may have the same problem.

Not sure what restrictions you have in mind, I've never used Game Maker, or Flixel for that matter.

But Flash is a very general development environment. You can make 3d hardware-accelerated games, just as well as old-style 2d games using timeline animations, and hardware acceleration works on mobile too.

Agreed, I would check out Actionscript, especially using FlashDevelop, which is free and really quite good. You can build web, pc downloadable, and ios/android mobile apps from it as well.

If we had a PRNG that only did operations that don't lose information - like bitwise-swizzles, and rotations with wrap-around - then we could reverse them easily to get a backward random number stream. Unfortunately most PRNGs are not like that, virtually all of them do irreversible operations, like mods, or multiplies that drop overflows, or bitwise shift that lose the bits that got shifted out.

I guess one could try rolling their own, using just reversible operations, and see if it has a good enough probability distribution and period...?

OTOH, someone on StackOverflow had a clever idea: you could take a cheap symmetric encryption algorithm, and use that as a reversible PRNG: to get the next value, encrypt the previous one; to get the previous value, decrypt the one in front...
http://stackoverflow.com/questions/2911432/reversible-pseudo-random-sequence-generator

Let me take a slightly different approach. From your post, it sounds like you're completely new to programming, as well as completely new to game development and its practices.

In this case, I'd say - start with whatever will make it easiest to make a game, any game, not just the game of your dreams. Picking a technology stack is hard, it's not just language, but also engines, tools, and questions of platform reach. But for learning, I'd recommend Unity, because it's going to make it the easiest to get stuff working and on screen, and there's a ton of good tutorials online. As a second choice, I'd recommend Flash, which is also very easy to get started with and powerful, but at this point Unity is easier.

But most importantly: set yourself a series of small milestone goals to complete. You stated a goal of a Settlers-like game, but you have zero prior experience. That's like going from a couch potato to a triathlon runner. I mean, it's doable and laudable, but getting in shape is going to take months or years. Set yourself easier goals along the way, so that you're not discouraged. Make a Breakout or a Space Invaders clone first. And plan to throw it away once you're done.

I guess my question was in fact more oriented to why you would need a scripting language bolted on to your game, and the realtime updating concept makes a lot of sense. ...  What kind of examples are there out there to see how other games incorporate Lua? I'm more interested in the pattern of usage than the actual implementation, I can just figure that part out. I want to see what aspects of the game get "outsourced" to Lua.

I worked on some commercial projects that experimented with putting gameplay code in Lua. Typically it would start out with NPC or game logic in Lua, which called into the engine to do any non-trivial work. Then if something got used a lot or if it was found to have a perf impact, it would get moved up into the engine as C++ code, and exposed as a new API call.

The main benefits of Lua were:

• Gameplay code in Lua reduced iteration time to "just save your file and restart". This was a huge productivity boost, compared to C++, since a quick recompile of that codebase took more than 1 minute, and a full rebuild 30+ minutes.
• The Lua interpreter is tiny, so it was good for consoles and other environments with limited memory. Also, it's written in no-frills ANSI C, which made it good for multiplatform game development (e.g. it gets compiled the same way in gcc for the playstation, ms vcc for the xbox, etc.)
• Lua is very malleable as far as scripting languages go - the emphasis on tables as a basic data structure, the "OO-lite" object system one can build with tables, functions as first-class objects, etc. make it easy to extend in various ways

But, it also had down sides:

• No static analysis step meant that simple typos (e.g. "heath" instead of "health") would introduce bugs that you don't find until runtime. This was particularly painful.
• Lack of a standard IDE and debugger (at least back then - hopefully that has changed?) meant that people had to either resort to printfs (ugly!), or invest in hacking together their own inspection and breakpointing functionality (time-consuming)
• There's definitely a non-zero cost of doing a lot of game logic in an interpreted language. I no longer remember what were the particularly expensive parts, but it's just a matter of keeping a watchful eye on perf, and moving stuff into the engine as needed.

All in all, it's not a bad scripting language - especially for large C++-based games, where recompile times can get pretty brutal. For indie games, that's probably less of a concern. Still, downloading game logic as a text file is nice!

PS. A sample list of applications using Lua: http://lua-users.org/wiki/LuaUses
I believe this only represents a fraction of real-world usage.

Jon Shafer's "At the Gates" seems to have done pretty well: http://www.kickstarter.com/projects/jonshafer/jon-shafers-at-the-gates

What really got me, was the "it's going to be like Civ, only different" part of the pitch.

I think I see what you mean. Definitely grouping them in different logical layers would work - and then you can decide which conversion to apply depending on the layer (for the world layer, convert mouse to world coordinates; for UI layer, convert mouse to screen coordinates, etc.)

But also, I personally wouldn't make UI elements into game objects, I'd keep them an entirely different thing (since they don't really participate in the game world), which would probably get around these kinds of problems.

Glad it's working out!

And I know what you mean about the Y axis problems. I like using Cartesian coordinates for my world space (increasing up and right), but Flash works "upside down" (increasing down and right), so the viewport and rendering layers have to do the conversions back and forth... Not pretty, but at least the rest of the game can work in the world space, and remain pretty straightforward.

I'd keep separate coordinate systems for game pieces (world vs screen position), and use just screen coordinates for UI.

For example, for a 2d game, there would be:

• a world position space, which is completely arbitrary, but for convenience, corresponds to real pixel sizes at 1x zoom (e.g. [0,0] is the center of the screen, but it doesn't matter; a 32x32px sprite takes up 32x32 world units, etc)
• a screen position space, which is the actual position and size of each sprite on screen (e.g. using Flash, that's [0, 0] in the upper left, increasing down and to the right)
• finally, one or more camera/viewport classes, which encapsulate converting between those two coordinate spaces

This way game pieces only operate in world space, and don't have to know anything about screen resolution; it's the viewport's job to then display sprites correctly (taking into account panning and zoom), translate mouse movements into world positions, etc.

And then UI lives on top of that, and always lives in screen coordinates. All UI elements are either anchored to particular sides of the screen (e.g. top left, bottom center), or to the screen position of a game piece (e.g. a mouseover tooltip over a game piece). This way, they don't have to know about screen resolution, either.

How about it?

I'm not sure I understand - if your systems correspond to components, does this mean your game entities each have a MouseInputComponent and a CameraComponent?

I'd do multiple cameras/viewports as special global classes, not gameplay entities, that all access the same set of gameplay entities. If the communication is one way (viewports access entities, not other way around), then entities won't need to deal with the fact that there are multiple viewports. And in your singleton input manager, you can have a reference to the "active" viewport, the one that actively converts from screen space to world space - and the active viewport can change depending on whether the mouse is over the game board or over the hud. Does that make any sense?

Also, why would different cameras need to have their own object lists? Presumably they all look at the same world, and maybe just ignore entities they don't care about?

After many experiments myself, I settled on the following design which has been working amazingly well for me:

Components are nothing but data.  The only methods they have are convenience methods to operate on that data.

Entities are a collection of components.  They only have an attach() and a retrieve() method to manage components and nothing more.

Systems inspect entities as they are created and destroyed, and if they contain components that the system is interested in, they add or remove it from their own internal operating list.

That's pretty cool. I'm so used to the other model, where components carry all the code in them, that I don't give it a second thought... but I can see the advantages of this.

I'm curious - how do you approach communication between systems? For example, the scripting system wants to override what physics is doing, and force position, animations, etc. its own way. Do you end up with systems calling each other, or message passing - or do they just set variables in the components, and expect the other system to pick it up correctly (e.g. there's a "bool manualOverride" in the physics component, which tells it that someone else is driving the entity, and it should leave it alone).

I like the 2nd way where a gameobject just has a list of components, but that won't make a difference in the Update loop I've show above.

leaves the third and most abstract way, ( what Geti started talking about too)
I believe that must be the 'best' component system. But my OOP brain is working against  it. No GameObject class ?! what madness !
I would like to see some implementations of that solution, any tips ?

You have a larger problem, which is that you have two major systems (steering and physics) both trying to drive the position. So now you have three types of interactions: 1. only steering is driving, 2. only physics is driving, and 3. both are driving and some piece of code needs to resolve what to do.

I don't think the third way will help with that. I would clean this up by establishing a clear chain of command, e.g. if physics is present, it gets to decide everything, and if it's not, only then steering can go and try to drive.

Also, I'd split up the code, so that the logic lives inside each component (or component-related system), and the update() loop is super simple.

So I guess I'm advocating something that's closer to method #2 than #3. In particular:

1. Update() just tells each component to update itself
2. Each component should only modify its own variables
3. Instead of sending messages, each component can call functions on other components (within reason! ), and those target components get to decide what to do. (This is easier on the garbage collector than sending messages. Note: if you're not writing a high-perf game, this might not matter, in which case send event instead.)

Here's my pseudocode version of your original code:

Code:

public void Update (FrameEventArgs e) {
  for each (Component comp in this.components) {
    comp.Update(dt);
  }
}

// ... now in steering

void Steering::update (double dt) {

  // update local state
  var steeringForce = steering.calculateSteeringForce(e.Time);
  this.applySteeringForce(steeringForce, e.Time);
  this.heading = Math.Atan2(steering.Velocity.Y, steering.Velocity.X);

  if (parent.components.physics != null) {
    // tell physics where to move
    var steeringForce2 = steering.UpdatePosition(e.Time);
    parent.components.physics.applySteering(steeringForce2, heading);

  } else if (parent.component.position != null) {
    // no physics! wah wah. we have to do everything ourselves.
    parent.components.position.move(this.Pos.X, this.Pos.Y);

  } else {
    throw new Error("There's a steering component, but no position component. This is not very useful.");
  }
}


// ... now in physics

void Physics::applySteering (Vector steeringForce2, float heading) {

    // applies a force from steering, if applicable
    this.Body.ApplyForce(
      new ms.Vector2((float)(steeringForce2.X * strength),
                     (float)(steeringForce2.Y * strength)));
    this.Body.Rotation = heading;
}

void Physics::update (double dt) {

  // tell the position component what we decided
  if (parent.components.position != null) {
    position.move(-4 + (float)this.Body.Position.X * 8,
                  -4 + (float)this.Body.Position.Y * 8);
  }
}

// ... now in position

void Position::update (double dt) {
  // doesn't do anything
}

void Position.move (float x, float y) { // called by other components
  this.position.X = x;
  this.position.Y = y;
}

Just an idea...

I really liked these tutorials:
http://catlikecoding.com/unity/tutorials/

Mainly because
1. they take you from zero to building a little endless runner game, and
2. it's all in a web page format, not a video, which seemed to make following it much faster

Hope this helps!