text:
Tools for creating 2d tile based maps
What are some tools I can use to create 2d tile based maps?
Please provide the information below, and try to limit to one tool per answer.

Name
Link to website
General features
Export format
Anything else you deem noteworthy

Tiled Map Editor
From the website:

General purpose tile map editor with XML-based map format
Supports orthogonal and isometric maps
Custom objects can be placed with pixel precision
Full undo/redo and copy/paste support
Add custom properties to tiles, layers, objects or the map
Automatically reloads tilesets when changed externally
Resize or offset your tile map later as needed
Efficient tile editing tools like stamp and fill brushes
Supports input/output plugins to open and save files in custom formats

If you are going to use this with XNA, I'd suggest using TiledLib. The library comes with a full content pipeline extension project that will parse and build the .tmx file along with a runtime library that allows access to the data in the map file.
http://tiledlib.codeplex.com/

+1. This is an excellent tool. You can write your own map exporter plugin, if you so wish, + it's open source so you can tweak it to your own/team's needs.

Here's a video that helped me get started using "Tiled" map editor https://www.youtube.com/watch?v=ZwaomOYGuYo  .  Particularly of interest .. as it is not clear when you start for the first time .. it shows the step for adding images into a tiled image file .  Solt. .. there is the "new file" icon in the "Tilesets" widget/window on the bottom right; use that to add images into the tile .tmx file.

The Best of the Pack
Tiled Map Editor
http://www.mapeditor.org/
Mappy
http://tilemap.co.uk/mappy.php
TME - Tile Map Editor
http://tilemapeditor.com/
TileStudio
http://tilestudio.sourceforge.net/
tIDE (Tilemap Integrated Development Environment)
https://colinvella.github.io/tIDE/
Gleed2D
https://github.com/SteveDunn/Gleed2D/wiki
Tile2map
http://www.tile2map.com
Worth a Try / Alpha Versions
TaT Tile Map Editor
http://kotisivu.dnainternet.net/ttilli/tilemapeditor/main.htm
Simple Tile Map Editor
http://devlinslab.blogspot.com/2007/11/simple-tile-map-editor.html
Flan Map Editor
http://flixel.org/forums/index.php?topic=225.0
Tile Map Editor VB.Net
http://sourceforge.net/projects/tilemapeditor2d/
Abandoned / Unfinished
JEngine Tile Map Editor (no description, no screenshots)
http://jenginetilemapeditor.codeplex.com/

Ogmo Editor
From the website:

Here's How It Works
After deciding to use Ogmo Editor for a game, the first step is to write up a "project file" for that game. A project file is just an XML file defining all the tilesets, objects, layers and settings for a project. Once you've got that done, you open it in the editor and you're good to go - you can start creating, editing, saving and re-opening levels. If you need to, you can add new tilesets and objects to your project along the way and all your old levels remain compatible, so you aren't required to define every asset you'll eventually use right away.
Getting Your Levels Into Your Game
Exported levels are just XML files, and the format is largely defined by you in the project file. Ogmo Editor was designed with Flash in mind, but most modern programming languages have robust XML support. If you're lost, check out the tutorials section - there might be an article on using Ogmo Editor with your language or library of choice.

My old favorite was Deluxe Paint (that dates me). I currently use Paint Shop Pro which has a handy 'convert to seamless texture' feature. Not as good as a true tile-symmetry editor, but good in a pinch.

Nothing beat Deluxe Paint! It was the best pixel pusher ever.

It might be worth creating your own level editor and integrating into your game - then you can also allow players to create their own levels.

Cosmigo's Pro Motion is one of the old-school favorites, even though it's more of a paint tool than a level editor proper.  Great for sprites as well as tiles; lots of "grid" functionality.  Their features page details a lot of this, and talks about new tile map functionality:
* RGB channel depth can be selected from 222 to 888
* 16 color PNG support
* Optimize tile based graphics for hand held systems that have a limited number of colors per tile like Gameboy Advance etc.
* Support for tile painting to create endless textures
* Tile map editor with auto optimization, mirroring, felxible export
* AnimStrip files can be created containing frames side by side in a bitmap, PNG/BMP

Tume. http://en.wikipedia.org/wiki/TUME
Worth it if just for watching their tutorials on how they approached certain problems (they use layers in many more ways than for tiles, which is very smart as it allows you to be game agnostic without forcing a paradigm on the user). Interesting features, used for numerous commercial games back in the day. No parallax editing (would be hard anyhow, as the parallax layers are generally driven by logic - you'd need your game as a plugin - which brings me to the following point - your game makes a great map editor. I have always done in game editing, it allows you to "live preview" and sets you up for user generated content to boot.

Minimal Javascript Tile-based Map Editor
http://samlancashire.com/mapeditor
I made this for my own game, but decided to polish it up a bit for general use. It's very simplistic, but will get the job done.
Exports map as two-dimensional javascript array. The array items contain the coordinates of the tile relative to the tileset. For example
map1[x][y] = '0,0'; //would be top left tile in tileset

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/2.5/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Cross platform low level graphic API
When creating a system abstraction is better to have the platform different APIs hidden by a common interface at the lowest level that makes sense.
Taking in account the different modern (with no fixed function pipeline) native graphics APIs: OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM
If one was to create a stateless low level graphic API to sit on top of them all, what would be the best way to go to make it as thin and as fast as possible?

The requirement for the API to be stateless is interesting. OpenGL, for example, is stateful, and I think a stateless API that wraps it would only make sense if it were much higher level, so that it isn't, for example, having to push and pop the same matricies for each and every surface it renders.

Avoiding useless state changes could still be implemented at a higher level, like by sorting the render calls based on their state before submitting them to the device. And by setting the state only if it's different from the current one.

That's not stateless though. Maybe I'm wrong, but what I think of when I think of stateless, is an API where each call does not depend on previous calls at all. That means that any information that would normally be stored in state somewhere has to be passed in every call that that needs that information. For OpenGL, for example, these would be matricies on the stack, lighting, z-buffering and normalization options.

Yes, for every draw call you would need, the mesh data, the blending state, the textures to bind, the sampling states etc..
Optimizations could be done later, without changing the API tho. Or maybe I'm reading your comment wrong..

The lowest level that makes sense from my point of view is something that talks about the resources involved in rendering - vb/ib, render surfaces, textures, shaders, state blocks, etc.
The problem here is that some of these need to be in different formats, depending on the API - that's where it gets a bit tricky. The easiest way around it is to pre-process static resources for the respective API. For dynamic ones, use only shaders to generate them - that makes it fairly straightforward to stay in native formats.
All you then do on the higher level is set up pipelines with attached resources and hand them to the GPU. You'll find that not everything can be abstracted out nicely in that way, especially if you take advantage of hardware-specific tricks. But it's a good start.
(Sidenote: if you treat platform-specific tricks as a special kind of resource, you can push this whole concept quite far. )
So in a way, you'll create two things: A hardware resource manager, plus a toolkit to set up a DAG of these resources.

I never thought about treating platform-specific things as resources. It sounds like a very good idea! Thanks.

Given the broad range of APIs you wish to cover, the typical wrapping approach is likely to be inefficient and prone to difficulty in mapping API concepts across several other APIs which may or may not support particular functions to varying degrees.
As a result, the most sensible approach would be to create a feature-centric API. While this approach prevents the API user from utilizing all available functionality, it greatly simplifies the implementation of each backend, and enables backend-specific optimizations that would not otherwise be possible.
It also greatly simplifies management of unsupported functionality for the API user; they no longer have to check if function X exists, and determine which features are affected, but instead need only query the feature itself to see if it is supported with the current configuration. Even if you support partial or limited modes for features, the context provided makes it much easier to manage.
In terms of creating a stateless (also known as submission-based) renderer, typically  a 64bit key is used to pack and submit commands for rendering. From that point there is a great deal of flexibility in terms of how to execute commands and what information to submit depending on what features and capabilities you want to support.

This is actually a good Idea. And it is part of the design I'm trying to create, but what I had in mind was to implement this features on top of a common low level API. But it might be the case that for some features you'd still need to deep into the native API for some more particular cases.

Part of the idea is to avoid building a common low-level API, and having to deal with wrapping with a lowest-common denominator approach. By moving the level of abstraction up a notch, you do restrict the feature set somewhat, but you also gain the ability to exploit each platform.
To handle the occasional need for deeper access, I prefer to provide a header that exposes the platform headers and some internal helpers; it might break version to version, but it's there if you need it.

To start with, each API does things differently so it should go without saying that wrapping all of the above APIs would be difficult. That said, it is sometimes necessary to do so: at some point a game simply needs to run on more than one platform regardless of how hard it is to do so.
I think the best way to go about doing this is to come up with the functionality that can be implemented on all of the underlying API's and abstract that and only that. If you are developing a multiplatform game, you wouldn't implement every obscure piece of functionality that each API supports, you would only implement what you need. This also helps to keep the API small and fast.
To avoid the clutter of each different API's implementation being packed into the output, compiling should be done with platform neutral header files and platform specific code files. Then, the code file specific to the target platform would be the only one compiled keeping the API small.

There is an article on GPU Pro about this, by Emil Persson (Humus)
http://gpupro.blogspot.com/2009/12/making-it-large-beautiful-fast-and.html

A cross-platform interface for rendering. The advantages of having one, and how we crammed DX10 into a common interface with DX9 consoles and maintained good performance.

You might want to check out the SDL library or Allegro. Both of them are low level, highly-portable game libraries, which have a way to plug them in an OpenGL context so you can render your graphics there. SDL has the fame of being used by he defunct Loki Games to port some popular games from the 2000s to Linux, and Allegro has a lot of time running on and has a great community of amateur game developers.

This doesn't really answer the question, not to mention that it is very much possible to wrap both OpenGL and DirectX (see Ogre3D, Irrlicht, etc.).

Consider the games you've played. How many of them have options to use DirectX or OpenGL? That's how many create wrappers for the two libraries to be able to support either one. You have a limited imagination. :-P

I recognize that there are some games that allow you to choose whether you want to render graphics with OpenGL or DirectX, but the question is about a cross-platform API, so I think the answer is adequate, I'll edit the first paragraph, though.

the question is about a cross-platform stateless low level API. SDL  and Allegro have nothing to do with it.

@NocturnDragon - the question title is a bit misleading.  At first glance I expected the question to be about the choices of API available, and I assume this answerer did as well.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/2.5/


text:
How do you gather and collate information you need to make a post-mortem?
After the game is done (either shipped or the project was canned), what is the best way  to make the post mortem, so that it maximizes the chances to never make the same mistakes again?

How do you gather all the needed informations from the team?
How do you condense them in the final postmortem?
How do you avoid to make the same mistakes in the following project?

You're gaining valuable insight as you work through the process. For any good business man that works on a project it's fairly easy to tear your project to pieces when analyzing what you did wrong. Figuring out want went right is a little harder.
How I would approach a thorough postmortem
Get All Perspectives in Writing
Ask each team member to write a few pages on project observations. Instead of randomly laying a trail for them to fulfill I would ask exact questions that you want to know about. You can supplement this with a meeting, but I rather get someones sole attention without distraction.
The most obvious questions would be

List your top 5 items you feel went right with the project?
List your top 5 items you feel went wrong with the project?

I would supplement those questions with specific questions relating to the team and project that you personally want to know from a management position.

How did you feel about working with Box2D instead of Chipmunk? Would you use (x) again?
Do you feel the project management was able to do x, y, and z for you?

Fail Early, Fail Often
Well, it is pretty hard to 'fail early' when your project is out of the door. Hopefully the feedback you gain from the above will shed light on processes that may have been pretty dark to you.
There are problems that you will run against that will sting pretty bad. It'll be pretty difficult to just forget those.
To make sure that you don't forget the problem areas it could be handy to write a 'Core Value' type list that you keep at arms reach. Keep them available for others to see and for you to see. When the your next project starts I might be inclined to bring some of these to the table to get other people's perspectives. If you have new eyes on the project you might get feedback that could shed new light on solving a particular issue.
As long as you're aware, and you keep your problems in the light, you're bound to solve those issues.
Write It
Grab all of the writings and bring it all together.

Introduction to the project, goals, and anything you feel like sharing about the project process
Top 5 - What went right?
Top 5 - What went wrong?
Conclusion... Bringing it to the end.

+1 for the "what went right?" It's too easy to break what you did well when trying to fix what you did badly.

Very good answer! :)

Most of the postmortems I've read seem to follow a format of:

What we did
What went well
What could have gone better
Conclusion (what was learned, and will be applied next time)

I'd get all the people involved on the project to toss in their $0.02 and see what they have to say about those things, then compile everything into one big, exciting to read document.
I guess in answer to your questions:
1. How do you gather all the needed informations from the team?
Ask them.  Email, sit down and chat with them individually and as a team.

How do you condense them in the final postmortem?
Lump together common responses.  Chances are you will be able to recognize general trends (ie: people having the same issues).  Focus on the big/important ones.
How do you avoid to make the same mistakes in the following project?
That's a bit of a tricky one.  Maybe write up a single 8x11" sheet of paper to pin in your cubicle as a reminder to avoid those specific previous mistakes?  I've got a few sticky notes like that just below my monitors, and they seem to do a decent job of reminding me to do certain things.

How do you gather all the needed
  informations from the team?

I like to have everyone write down their list privately first. On the last project I did a post-mortem for, we had four sections:
1) Things that went right, because we did things in an awesome way
2) Things that went wrong, because we screwed up
3) Things that went right from our partners (outsourcing houses, publishers, etc.)
4) Things that went wrong with our partners because THEY screwed up
The first two help us to adjust our own behavior. The last two help us to pick better partners (or manage our existing ones better) next time.

How do you condense them in the final
  postmortem?

Have everyone email their lists to one sucker^H^H^H^H^H^H volunteer, who then condenses and anonymizes the lists. The collated list is then sent to everyone and discussed.

How do you avoid to make the same
  mistakes in the following project?

In my experience, you don't :)
In seriousness, when I start a job at a new game company, the first thing I take a look at is the previous post-mortems (if they have them on file somewhere). Usually I see common themes throughout all projects, which tells me ahead of time what kinds of challenges to expect on the current one.
If I were running my own studio, my first instinct would be to start the kickoff of each new project with a re-reading of previous post-mortems, and a discussion of how not to do the same dumb things a fifth time... and then re-visit the hot-button post-mortem issues at each milestone in the project.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Assets Management, database or versioning system?
While developing the assets for the game, (meshes, textures, sounds, videos) ho do you manage them?

Keeping them together with the source code
inside the versioning system? (perforce, git, etc…)
Or having a central back-upped, database
dedicated to the assets and having
the editors always work liked to it?
(PostgreSQL, MySQL, etc…)
Other?

What are the pro and cons of each, and why one should choose it over the other/s?

Good question. I'm pretty interested in hearing how others approach this.

For info on version control: http://gamedev.stackexchange.com/questions/480/version-control-for-game-development-issues-and-solutions and http://gamedev.stackexchange.com/questions/245/what-version-control-systems-work-best-with-games-closed I don't think this is a duplicate as it's specifically about assets

For many of us - especially working on smaller games - you absolutely should have assets in the same repository as your source.
The suggestion that assets belong in a separate repository only makes sense for very large sets of assets, or for somewhat-large sets of assets when there's a clearly defined engine/data boundary. Unless there's a specific technical reason for it - it's bad advice!
You want your version control to behave like version control. You want to be able to rewind and fast-forward and branch and merge revisions and still have your game working. And your code and assets will depend on each other.
For example: Your code might expect to be able to set a parameter on a shader, and that shader might depend on a texture being there. Or maybe the data format of your levels might depend on a particular version of your game code.
It almost certainly will get messy. And you have better things to do than to try and keep it tidy.

Now, as Mike Wagner commented (on this answer) - you don't want or need all the "in progress" versions of your assets under version control! Just the final/working version, as used by your code, will do - often this is what you export from your tool.
(Although if you do want to version-control the in-progress versions of assets - that's fine. And well suited to a separate repository. I personally find that good folder organisation and a proper backup system suffices.)
That being said - it's sometimes nice to have the option to just stick "in progress" assets under version control. Typically this involves having a content pipeline that can handle any 'export' steps for you - for example: flattening a multi-layer image to a single texture.

The suggestion that assets belong in a separate repository only makes sense for very large sets of assets,

How large? >1GB?

Back in 2010, when this answer was written, maybe. These days I'd say that it's something that you'd only even start thinking about with many 10s of GB of assets. And then, you'd probably look into version control schemes that let you store bulk data externally, long before considering taking them out of version control entirely.

Also, to add additional commentary to my answer: These days I put almost everything into version control, including source files for art, music, etc (pre-export). Anything that would make its way into the final product. Having versioning for art is great. (I'd probably draw the line at video that isn't actually going to ship with the product -- a trailer, for example, might be safely be considered a separate project.)

what VCS do you use?

Versioning system.
With a roll-your-own approach you'd effectively end up rolling a versioning system, so better to use an off the shelf one that's already had years of design/code/test cycles.
Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain (though disk space is cheap, retain it all whenever feasible. Individual textures don't change that much over the life of a project).
Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts.
If you can, arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.

Agreed on keeping the art assets and code assets in separate repos. You may also find that the artists are more reluctant to check something in than the coders, and not necessarily because they find the system intimidating. They may have 30 rough outlines of a concept and not want to submit until they've narrowed it down to something they like. Factor this into the production pipeline. If there's a technical director breathing down their neck to check in everything they'll spend more time in the repo than roughing things out.

On marking XML files as binary: If your VCS allows separate diff tools, ask it to use something that specializes in XML diffing for XML files.  This may help avoid weird broken markup.

+1 on this. :)
Assets belongs in their own repository - if in a repository at all.
Maybe using a dedicated asset repository software? Specifically created for that purpose, instead of trying to make it fit into versioning control systems designed for mainly textual content.

Everything in one repository, if you can afford it in terms of size. I've heard of Subversion repositories in the vicinity of 1 TB. We are currently a bit below 400 GB.
Also, artists much check in everything, including the 30 rough outlines of a concept; we use separate folder trees for "source assets" and for "exported" - the ones that go into the asset build script. If your artist is hit by a bus tomorrow, you need to be able to have someone continue work on his assets the next day, only looking through the repository (no archeology on his personal machine). Once upon a time when games were 2D and sprites were prerendered from complex animated Max scenes, we had to ship a bunch of units in an RTS game with a bit crappy, and very inconsistent look (vs. the rest of the units), even though it was a matter of re-rendering with slightly different lighting and antialiasing settings - because the original artist had quit, and we didn't have his original Max scenes. Don't let this happen to you.

Upvote for mentioning "bus factor" )


text:
How to determine the amount of experience needed for leveling up
Related questions under this topic might include:

How should I base how much experience points it takes to get to the next level?
What factors are involved in this?
How do I keep the player not entertained long enough till he levels up?
How can I vary the way the player gets experience points?

Why the down vote?

+1 as I have spent a lot of time trying different things here.

I downvoted because I thought it was way too vague a Question. Look at most of the Answers - "there isn't a single formula", "you can make it however you want", "it depends on the type of experience you want to create for the player". Gee, can you possibly be more ambiguous? But, apparently no-one else agrees with me, so there it is...

@Cyclops: Its like this so we can determine the things involved in experience points. Would you rather have a ton of experience point based questions each time an individual asks about their game or would you rather have one reference that talks about all various aspects you need to take into account. I accepted coderanger's answer because it is a great starting place.

Generally speaking these are done as vaguely exponential curves. http://kol.coldfront.net/thekolwiki/index.php/Advancement#Advancement_Requirements_Overview shows the formulas for Kingdom of Loathing, which are pretty standard for the MMO genre.

Nice! I had no idea there was an actual equation!

There isn't a single formula everyone uses, but those should be a place to start from.

It's important to consider the XP that you get per encounter, as well, since that's going to play an equally important role in how long it takes to level.

I actually cover this very topic when talking about numeric relationships in games:
http://gamebalanceconcepts.wordpress.com/2010/07/14/level-2-numeric-relationships/
You can make it however you want, although typically it's on an increasing curve (so each level requires more XP than the last), because encounters/quests tend to give more XP as you progress.
The key isn't to concentrate solely on the XP-Level curve or the XP-per-encounter curve, but to compare the two of them. If the XP-Level curve increases faster than XP-per-encounter, the player will notice they are gaining levels more slowly over time, which is pretty standard for the genre. However, the danger is that if level ups get TOO few and far between in the endgame, then the player's last memory of your game will be a colossal grind, which you probably don't want either. So figure out how many encounters per level-up are acceptable in the end game, and how many encounters per level up you want in the early game, and interpolate from there.
Also, I should mention that you CAN have overlapping reward systems other than just XP/Levels. Some RPGs have job points (so you have multiple leveling/advancement systems), so that it might be awhile between (say) leveling up your Fighting skill or your Healing skill, but with enough different things leveling up you're always just a few minutes away from increasing SOMETHING. Other RPGs have random item/equipment drops, so every new encounter doesn't just give XP, but also a small chance of generating some epic loot, so you get some additional random rewards just for playing.

I'd say it's dependent, at least partially, on the type of experience you want to create for the player. Consider two examples, the first of which is a classic turn-based RPG, the second is a Gradius III-type shooter, in which you'd like the player's power to scale based on progress since his list death, not on powerups (not to say that's a good system, just an example).
In the case of the RPG, your system probably operates on the assumption that a player never loses experience. Similarly, it will probably want to act based on the assumption that it's relatively easy to gain some level of proficiency in something, but difficult to master it (like most things in the real world). In this case you might want to develop a formula (like coderanger suggested) that is exponential in some regard. Where the amount of experience required to reach the next level is somehow exponentially based on your current level. Important to consider, however the rate at which your player will be receiving experience while playing. For instance, a player killing a level 63 Fire Demon would expect to receive more experience for his kill than if he had killed a level 2 Lady Bug. So when designing your formula, be sure that you take into account your XP system. Particularly since if you do not, then killing the lady bug will be just as profitable as killing harder enemies.

Example 1 (Likely not a form you would use):
XP_TO_LEVEL = ((CURRENT_LEVEL + 1) ^ SCALE) * XP_BASE
Example 2:
XP_TO_LEVEL = (XP_BASE * CURRENT_LEVEL) ^ SCALE
Where XP_TO_LEVEL is the XP needed to reach the next level.
CURRENT_LEVEL is the player's current level.
XP_BASE is an arbitrary number to decide how much each level is "worth" in XP.
SCALE is the exponent determining how fast to scale the XP needed to level. If SCALE is 1 then each level will take XP_BASE experience. If SCALE is less than 1 then each level will take less experience than the last level. If SCALE is greater than 1 then each level will take more experience than the last level.
The following table assumes a SCALE of 1.1 and an XP_BASE of 100 using example 2.
Current Level   XP Needed   Increase from Last Level
1               158         0
2               339         181
3               530         191
4               728         198
5               930         202
...
10              1995        218

Example 3:
XP_TO_LEVEL = ((CURRENT_LEVEL * SCALE) ^ 1.5) * XP_BASE
Where SCALE is still determining how fast to scale the XP_TO_LEVEL, but it operates a little differently.
The following table assumes a SCALE of 22 and an XP_BASE of 10 using example 3.
Current Level   XP Needed   Increase from Last Level
1               28          0
2               80          52
3               146         66
4               226         80
5               316         90
...
10              894         130

In the case of the Gradius clone, you might take a different strategy. You may want the player to level up consistently, say about every two minutes. In addition, after a play has lost a life and consequently lost all of his gained powers, you may want to help him along by leveling him/her up faster until he reaches an appropriate level for his progress through the game. In this case your formula will likely be more linear, especially since the user doesn't get to see how much experience he's getting per kill. Something like, it takes 50 XP to reach a new level and each enemy is worth 1 XP. This works great providing you are supplying him with a relatively steady stream of enemies. But, when the player dies, he loses it all! What do you do now? Each enemy should be worth more than 1 XP to meet your goal of catching him up so that the game is fair again.
Example:
XP_FROM_EACH_ENEMY = BASE_XP + (CURRENT_LEVEL - DESIRED_LEVEL)
Where XP_FROM_EACH_ENEMY is how much XP an enemy would award when killed.
BASE_XP is how much XP an enemy is worth by default (could vary per-enemy type).
CURRENT_LEVEL is the level of the player
DESIRED_LEVEL is the level you think the player should be at.

Personally I use.
C/(A x B)
Where:
A= Time for an encounter/kill (average easy, normal and hard enemies)
B= Exp per kill. (average easy, normal and hard enemies)
C= Time spent for the player to level up.
Note: All these are relative to pace and point in the game.
I think it may be very simplistic but note that you also set the other elements. By using a simple equation you can easily adapt to changes midway.


text:
OpenGL optimization tips
What tips or tricks do you have when it comes to making the OpenGL more efficient?

Use VBO rather than glStart()/glEnd(). This saves cycles in transferring the data to the GPU's memory.

More than that, glBegin and glEnd were deprecated in later revisions and were completely removed (and therefore will not work) in versions 3.x and above. If you request an OpenGL 3.x context you will be unable to use them completely.

DirectX actually forces this upon you, it doesn't have an equivalent of glStart()/glEnd().

@SAHChandler I didn't know that. I didn't realized it was deprecated.

@SAHChandler: That sucks! I learned all my drawing with glBegin() and glEnd(). Noooo!!!

The standard tip of profile, profile, profile applies just as well here, although the tools are slightly different.
gDEBugger is great at helping you see exactly what's going on under the hood.  It's expensive, though.

Just wanted to add that it is now free.

These are from Apple's documentation references on OpenGL but every little bit helps right? ;)
OpenGL Performance Optimization : The Basics
Optimizing OpenGL Data Throughput on OS X
(This last one is a sample application)
Vertex Optimization
There are also a very large number of videos available on the subject (Also from Apple) that talk about OpenGL extensions. Some of them are OS X specific, but a few others are more generalized and could most likely be applied to Windows and Linux.
You can find the videos here. You do require iTunes and an Apple account to view them however (but they are free! :D)

Well, it really, really depends on what you're planning to do, but here are the basics:

Your CPU is very precious while your GPU is a hungry beast. Offset as much as you can to the GPU. Nowadays you can do this with excellent libraries like OpenCL, CUDA and Thrust.
Do your lighting in a shader. Not only will this help retain your sanity, but it allows you to very cool things like toon shaders and deferred lighting.
Particles suck. Even when using OpenGL point sprites.

That being said, you should calculate the MVP matrix on the CPU, as calculating the MVP on the GPU for every vertex is extremely inefficient when it can be pre-calculated on the CPU once per frame and passed to the GPU via a uniform.

Minimize your state changes.  On a lot of platforms, each state change potentially flushes the pipeline.  It's much better to batch similar items together and change state once.

glEnable(GL_CULL_FACES);

Simple one liner that applies back face culling. This is excellent for trimming down polygon count. Also look into Frustum/Occlusion culling for reducing poly counts.
Another thing to look into is SIMD for your vectors and quaternions (mostly used in camera rotations). If you don't want to mess with ASM then check out libSIMD which is a great library for handling SIMD in C.

Don't use glGet* when you can access local variables, e.g.:

Don't query textures size from OpenGL, store them on loading in variables
Don't query line widths / points sizes from OpenGL when you can store the changes in your application

These calls are really slow
Move unused stuff outside of glBegin - glEnd clause (be it glColor or glNormal or anything else) if it does not changes inside. OpenGL is a state machine, it uses the last value.

Minimize OpenGL commands is the key. So you must batch all drawing commands. For 2d games, it is a good idea to use Altas Texture and draw all sprites sharing the same texture in one opengl command.

Be careful. Less and bigger batches are useful, but depending on the target platform "too big" batches will decrease performance.

Batch, batch, batch!!
(Ab)use the GPU to render as much as possible in each draw call.
Games are mostly limited by the amount of state changes, not so much by the amount of triangles.


text:
Box2D Get Bounding Box of a Body
In Box2D, I was curious if it's possible to get a bounding box of a body already created in the world.
So basically, the Body is created, it's interacting with the world and such. And I needed that Body's bounding box. Is it possible?

In Box2D, bodies don't have bounding boxes associated with them, fixture do. So you need to iterate over all the fixtures and generate a new AABB. Something like this:
b2AABB aabb;
aabb.lowerBound = b2Vec2(FLT_MAX,FLT_MAX);
aabb.upperBound = b2Vec2(-FLT_MAX,-FLT_MAX);
b2Fixture* fixture = body->GetFixtureList();
while (fixture != NULL)
{
    aabb.Combine(aabb, fixture->GetAABB());
    fixture = fixture->GetNext();
}

Is this really correct. In the box2d I am using, fixture->GetAABB() does not exist, but a fixture->GetAABB(int32 childIndex) does.

are upperbound and lowerbound the topleft and downright corners ?

just using the fixture aabb also includes the shape radius - if you want to get the real aabb without the radius of the shape, do it like this:
b2AABB aabb;
b2Transform t;
t.SetIdentity();
aabb.lowerBound = b2Vec2(FLT_MAX,FLT_MAX);
aabb.upperBound = b2Vec2(-FLT_MAX,-FLT_MAX);
b2Fixture* fixture = body->GetFixtureList();
while (fixture != nullptr) {
     const b2Shape *shape = fixture->GetShape();
     const int childCount = shape->GetChildCount();
     for (int child = 0; child < childCount; ++child) {
            const b2Vec2 r(shape->m_radius, shape->m_radius);
            b2AABB shapeAABB;
            shape->ComputeAABB(&shapeAABB, t, child);
            shapeAABB.lowerBound = shapeAABB.lowerBound + r;
            shapeAABB.upperBound = shapeAABB.upperBound - r;
            aabb.Combine(shapeAABB);
    }
    fixture = fixture->GetNext();
}

Why would you not want to get the shape radius? I originally copied the source from this answer, thinking it was more thorough than the other answers, but now I've found that it's not correct for my case, and am curious about which scenario this code should be used in.

I see that this uses the newer Box2D API, though. That's one reason to  prefer this answer. However, related to what I mentioned above, I had to comment out shapeAABB.lowerBound = shapeAABB.lowerBound + r; and shapeAABB.upperBound = shapeAABB.upperBound - r; to get the behaviour that I wanted.

Really, a for loop is usually better for iteration. Taking @noel 's answer:
b2AABB aabb;
aabb.lowerBound = b2Vec2(FLT_MAX,FLT_MAX);
aabb.upperBound = b2Vec2(-FLT_MAX,-FLT_MAX);
for (b2Fixture* fixture = body->GetFixtureList(); fixture; fixture = fixture->GetNext())
{
    aabb.Combine(aabb, fixture->GetAABB());
}

The expression fixture, taken as boolean, is, I understand, equivalent to fixture != NULL.

This is what I generally use:
Rect aabb = someNode->getBoundingBox();
DrawNode* drawNode = DrawNode::create();
drawNode->drawRect(aabb.origin, aabb.origin + aabb.size, Color4F(1, 0, 0, 1));
this->addChild(drawNode, 100);

Where this is some parent node. I've even added this to the node itself (e.g. someNode) and that also seems to work, just make sure your z-index is high enough.


text:
What is involved for a simple UDP game?
I once tried to write a simple game with UDP in a week as a throwaway test. It went horribly.
I threw it away early. The main problem i had was restoring the game state of all players/enemies/objects to an old state and fast forward the game to the point of time the player is playing (ie half a second before a jump. A little early or late can make the player miss the jump)
Maybe this method is not the easiest way? i suspect it to be but i designed it wrong from the beginning and realized at the end of 2nd day. (so i didnt learn too much or wasted that much time)
For myself and others, What is involved for a simple UDP game and how do i write one? Or how do i solve the prediction problem restoring to state properly.
I'll mark this as CW bc i know there will be lots of helpful answers.

Glenn Fiedler has written an excellent set of articles on this, which covers pretty much all of the basic concepts.

The Floating Point Determinism article blew my head. Its too bad Synchronizing State isnt done because thats the one i wanted to read. Although Floating Point Determinism does answer lots of questions.

None of those articles go in depth about state-synchronization, which is what he's asking

Rolling your own can be educational, but you often get more done if you can leverage an existing implementation (or at least start from there).
I've used both ENet and Raknet.  I only used Enet in a simple game but it did what I needed.  Enet uses a lower level API than Raknet.  Raknet was used in a larger project.  Raknet is extremely powerful, but wants to make you structure your game around Raknet's framework.
Enet:

Connection Management
Sequencing
Channels
Reliability
Fragmentation and Reassembly
Aggregation
Adaptability
Portability
Freedom

Raknet:

Object replication
Autopatcher
Secure connections
Robust communication layer (basically all of Enets features rolled up in one item)
Remote procedure calls
Voice communication
NAT punchthrough

+1 for ENet, I've been using it for a while now for clients and they like it.

He is asking about state synchronization - this answer has nothing to do with that

-1, same reason as BlueRaja

If you have the time and energy, you could download the Quake 3 source and study it.  It's fairly easy to comprehend if you're comfortable with C, and equally easy to tinker with.
Which other multiplayer games have source available and use UDP?

There's an article that describes the code too.  http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

If you go homebrew (as I did) you're going to learn tons - also about stuff you didn't want to know. Like NAT traversal. According to caspin, Enet is missing out on that, but you could always find some open source STUN code that works in most situations.


text:
How to allow character to keep moving after it hits a wall
I am developing an iPhone game. There is a fountain that the user should not be able to walk through. Now, this question is about checking circle-point collision or anything like that. I am checking collision with CGRectIntersectsRect(character1.frame, fountain.frame).
But, here is the problem: If I prevent the person from moving; he will never be able to move. So, I tried combatting this with following:
    if (character.center.y > fountain.center.y && CGRectIntersectsRect(character1.frame, fountain.frame) && g == false) {
        g = true;
        character1.center = CGPointMake(character1.center.x, character1.center.y-0.1);
    }
    if (character.center.x > fountain.center.x && CGRectIntersectsRect(character1.frame, fountain.frame)) {
        character1.center = CGPointMake(character1.center.x-0.1, character1.center.y);
    }
    if (character.center.y < fountain.center.y && CGRectIntersectsRect(character1.frame, fountain.frame)) {
        character1.center = CGPointMake(character1.center.x, character1.center.y+0.1);
    }
    if (character.center.x < fountain.center.x && CGRectIntersectsRect(character1.frame, fountain.frame)) {
        character1.center = CGPointMake(character1.center.x+0.1, character1.center.y);
    }

This should check what side the character1 is intersecting the fountain and then make it so it is not intersecting the fountain by incrementing or decrementing the x or y coordinates of the characters it. But, this still gives weird results. It will move it diagonally across the fountain if keep holding down on the the top side of the fountain and also, it will keep moving it left other wise on the top of the fountain.

Speaking generally, the way this is handled is by moving you backwards along the collision normal. You find the axis the collision took place on (normal is a physics term, just think of it as the vector indicating the direction you penetrated the other object. Then you figure out how far you have to move back on that vector to no longer be colliding. See gpwiki for more information.

I would check for the collision before the character is moved to the new position. So that when you update the position of the character you know that it's valid.

This is okay for slow moving objects, but anything that can move a sizable amount in a single frame will look weird.

This isn't suitable for all types of game, but it is for many 2D games where characters move at constant speeds. It's certainly the easiest thing to do.

Great points, I was just trying to make it simpler for his case.


text:
Sending a struct containing a string over network
I'm trying to send structs as neatly sorted packets using iPhone Game Kit..
I have a struct which looks like:
typedef struct {
   int coolStuff;
   char playerID[100];
} MyStruct;

Then I'm using strncpy() to copy the NSString I want into MyStruct.playerID. However, I would like to be able to send a playerID (string) of any size and possibly multiple strings per struct. Any suggestions?
There is a chance I'm  making this more difficult than it actually is..

Google's Protocol Buffers is a project designed to help with this kind of thing. Makes it somewhat easy to move structs around between memory, network, disk, et al.

Maybe I'm a little out of my element here.. but does this work with IPhone GameKit?.. I mistakenly left that out. Sorry!

http://code.google.com/p/metasyntactic/wiki/ProtocolBuffers looks like it will do exactly that, but I can't say I've used it or had heard of it 5 minutes ago.

The fundamental thing you need to do is just have code on one side that knows how to serialize data, and code on the other that knows how to deserialize.
So, for variable length strings, just send the length first:
   n = strlen(playerid) + 1; // for NULL terminator
   sendto(server_sock,&n,sizeof(n),0,0,0);
   sendto(server_sock,playerid,n,0,0,0);

and then on the receiving side get the length, and read that many bytes.:
   int n;
   char *s;
   recvfrom(client_sock,&n,sizeof(n),0,0,0);
   s = malloc(n)
   recvfrom(client_sock,s,n,0,0,0)

Of course, what you should really do is gather up your communication into packets, and then send blocks of data at once with headers, have type info in a debug mode for safety, etc. but that's the gist of it.
Google protocol buffers look like they are a way of turning data into something serializable, so in that version of this example send and recv would be an XML string, which is great for general servers, but you may want more explicit control.

Protobufs are significantly more compact than XML, and have both a text (JSON-esque) and binary form. Otherwise, I agree, it's good to know how this stuff works under the hood.


text:
What kind of databases are usually used in an MMORPG?
Do people write their own DB for some reason?

We did, hopefully Ben Z will give a better explanation of the reasons than I can since he was actually the original author of our database. The short version is that relational DBs are not very useful for games because they cannot efficiently store heavily structured hierarchical data, which makes up the vast majority of data an MMO needs for normal operation. We choose to build a custom object database and part of a distributed transaction processing system, which is now in production and powering our two live games.
As for if you should do the same? Probably not, at least not at first. I would still advocate avoiding SQL, but there are now many more options in the "NoSQL" world that didn't exist a few years ago.
That said, most MMOs do run on SQL (relational) databases. I know Eve runs on a SQL Server installation sitting on top of a few multi-TB RAMSANs (I will probably never in my life have as much money as those things cost).
EDIT: Hopefully he won't mind me posting this here, but this is a blog entry with some links and comments about the presentation we gave at GDC'08 about our database.

+1 I'd imagine that most people ended up writing there own database. But it's cool that the NoSQL world is growing now.

Even if you end up heavily customizing something later on, there is probably at least one DB out there you can prototype on.

coderanger has it right. I wrote a custom database for an MMO.
If I were to do it over again in todays world I would probably look more closely at adapting existing technology, because as he mentions that world is more active than it was 4 years ago.
Many MMOs do in fact run on SQL, some of them well and some of them not very well. Max shard concurrency (as opposed to max zone or continent concurrency) is low for those games.

"because they cannot efficiently store heavily structured hierarchical data, which makes up the vast majority of data an MMO needs for normal operation" - that's even more true in applications development than it is in game programming.  Unfortunately, we're stuck with what we've got, and since the performance (and availability of DBAs) for NoSQL solutions currently can't match that for RDBMS's, we've got to smush and smudge our data into a form workable for RDBMS's.

That might have been true several years ago, but there are now a number of off-the-shelf databases that offer the kind of performance characteristics needed.

Okay this answer is more of an observation.
Full disclosure I haven't worked on MMORPG. I have worked at what was one of the top 10 most visited sites back in 2009, and I have worked at game engine company that thought they were making MMORPG tech (I don't know if shipped).
If you look at companies that have achieved massive scale (Google, Facebook, Twitter, etc., I know they are not game companies, but they are worth looking at in this space) there are two things that I think are important.

They started by grabbing whatever was cheap and easy to get themselves going
They ultimately had to roll a lot of their tech on their own. (And sometimes hardware)

A big mistake is to grab some expensive turnkey thing and expect it magically scale for you. It doesn't work that way. The key to scaling up is dealing with each new challenge appropriately. You need flexible easy to use solutions that you can move in and out easily.
So my advice to you would be if your starting out, just get what seems least headache to deal with.

Basically, there's a whole range of approaches, and I think they're chosen based more on the experiences of their developers as much as the properties of the database.
At one end, many MMOs are using standard relational databases - eg. Dark Ages of Camelot used/uses (are they still going?) MySQL, FreeRealms use a modified Postgresql, etc.
Moving along the scale, you have Guild Wars: they use SQL Server, but they stick their data in there as a single BLOB. This means they get the benefits of their usual binary formats with some of the benefits that a database provides. Needless to say, you can probably see some disadvantages of this approach too, but for a company used to working with flat files, it's probably still a step up.
Then there are probably some places using the various formalised NoSQL approaches, although it's still early days yet. Farmville uses membase, which they made for the purpose, based on memcached apparently. This shares many features with the likes of MongoDB, CouchDB, etc. Again with these approaches you're typically rolling your own storage formats but get the benefits of distribution, caching, redundancy, etc.
Some are rolling their own NoSQL entirely: Cryptic said they did something similar but also said they weren't using it in production. (EDIT: but see comments below.)
And then you come to people who are using flat text or binary files - as I understand it the older games like Ultima Online, Everquest, etc all went down this route, and for a company with game development experience but little database experience this works well too.
Note also that you almost never get around writing your own database in some loose sense of the term - in games you'll always have bespoke data that you need to manage either in-memory or on-disk in ways that don't lend themselves to generic software. You can't do SQL queries every time you want some data so you will need to be mirroring a lot of your information in the code no matter what back end you use.

Cryptic is now using it in production with extremely high shard concurrency compared to other MMOs (except Eve, but Cryptic did it on much more modest hardware than Eve).

Good to know. (Although, I don't think DB access is all that relevant to concurrency. The 'SQL considered harmful' presentation demonstrated that Cryptic wanted to hit the database for things most other MMOs just keep in memory instead, so it was a self-imposed bottleneck really.)

If you keep them in memory, you need to implement a database in-memory, or you risk item duplication / loss (as an example) when trading across zones. "Keep them in memory" only works as long as all your players are within the same memory space all the time.

It's quite easy to keep most things in memory as long as you are clearly aware of which aspects require transactional semantics and which do not. eg. There's no need to be persisting time online, hitpoints, and location with ACID guarantees, except in a tiny number of edge cases which can be handled safely in the same way you might handle trade.

While that's true for time online and hitpoints, neither of which was guaranteed ACID in Cryptic's DB, it is not true for e.g. quest milestones (5/10 wolves killed) or XP rewards, which can still occur many times per second per player.

These still don't need transactional database semantics. Which is why few in this area are feeling the need to implement their own database like Cryptic did.

Great examples, +1.

Those don't need transactional semantics if you're fine dealing with users who lose their quest progress if the server happens to go down. In the case of XP rewards, that can mean losing a level, and when a game crashes and you lose a level, the next step is usually to stop playing.

XP very much needs to be transacted. One of the specific exploits that lead to the creation of the CrypticDB in the first place (trust me, I wrote it) involved XP gain on multiple servers at once and a failed syncing that was user interruptible. Anything that is critical to the progression of a character really needs to be transacted, otherwise players will find some way to exploit.

Joe, the best solution to xp loss when servers go down is to stop the servers going down. ;) Obviously that is idealistic but pushing to the DB more often doesn't fix the problem anyway, just merely reduces it. Obviously it makes sense to force a write in situations that the end user is sensitive to, such as when they level up, but that doesn't require that all XP gains need immediately pushing out to hard storage.

Ben, That's specific to your game design. Other MMOs work fine in this regard by ensuring there isn't the possibility of XP gain to the same character on multiple servers at once.

what form would these flatfiles approaches take?

@expiredninja: that's a very open question. But by 'flatfile' it just means "arbitrary serialisation to disk". Game developers would often write out each field with fprintf, for example.

On Pirates of the Burning Sea, we stared off with MySQL (though honestly I would've preferred Postgres) and when it started falling down under load, we switched to Microsoft SQL Server. Honestly, though, I probably won't go that route again in the future. Most of the PotBS data is pre-serialized before it's persisted anyway, so a large portion of what's in the DB is nothing more than an overgrown key/value store. On top of that, to get better performance out of our persistence layer, and better control of how data was cached in memory, we ended up writing a caching server that sat in front of the database.
So Kylotan's very right, you're not going to get around rolling your own on some level. SQL relational database servers aren't designed for the way games use data.  Instead of assuming relational DB servers were the end-all of databases, we really should have thought more about what benefits we were looking for before choosing a tool.
Next time around, I'd look more into things like BerkleyDB or some of the other NoSQL-style DBs.

One other thing to note is that if you have a (relatively) static data set, don't store it in a database! There's no really good reason to store your spell definitions, item definitions, maps, etc. in a database. You're rarely querying them except by name. I see a lot of people jump into game development storing these things right alongside persisted player data, and it's a totally different class of things.
You need a data store, like a filesystem, for these. Outside of development, you don't need ACID, you don't need CRUD, you don't need a database for that kind of data. Inside of development, you need a database, but you also need a VCS anyway, and your choice of VCS will make that choice of database for you.
(If you're working on a game where players can create custom spells or items or quests, well, then that data is the same sort as player data, and you do need a database again.)

I've used MongoDB (NoSQL), it's a very fast document store that can be accessed over TCP. Give it a try! It's awesome!
Writing your own DB is a daunting task. I suggest you first explore what's already out there and if you can't find any thing that matches your specific set of criteria, build your own. Oh, and don't forget to open source it. :)

MMORPGs are intensive apps and are a huge undertaking. If you are starting off with game development I strongly recommend you do something smaller.
That said you will need two squeeze top performance out of your setup. You are obviously going to need a server farm/hive. Because network communication is relatively expensive (and most MMORPGs are realtime) you might want to replicate your central database to each of your game servers (the equivalent of realtime low-latency replication in your database of choice).
If each of your servers are serving a specific segment of the game world (like WoW works); something like Distributed Partitioned Views. DPVs allow you to segment rows of your database across different servers; according to the the constraints on the columns at each server. Both MSSQL and Oracle are smart enough to only talk to the server that contains the data that falls within your WHERE or ON clause. I am not sure if any of the open source offerings have DPVs.
The net result of this all is that it doesn't matter what DB you use, just use one with a good name: MSSQL, Oracle, MySQL, PostgreSQL. Write your database in ANSI SQL and see which system works the best - that's the only way to find out.
The NoSQL route might also be a good idea because it's designed for high concurrency. Pranny's suggestion might do the trick.

I guess it depends pretty heavily on what kind of data you need stored, and under which form.
I think most people out there use "standard" SQL databases for "dynamic" data like player informations, be it SQL Server, MySQL, PostgreSQL.
However, "internal" data (state of the world, content, ....) can be stored under any form, and my guess would be that most company write at least partially custom databases systems for that part, suited for their specific needs.

Well, it actually depends on your application - that's the bottomline. I work, where we develop social RPGs and we use Google App Engine as a backend

This question is rather old but my Idea of how to handle it is as valid as it was asked as it is today.
If you're using a relational database you need to reduce the load on it so this idea should help.
Store all public info on a local DB on each client system as well as in the servers DB.
Store all tables with items on the client database. Instead of the client looking to the server when you mouse over that weapon for stats, the client just checks the local database for stats. The server has its own database for pulling stats when calculating and just forwards damage and health remaining to the clients.
Worst case with this idea is that everyone can see the stats to all weapons if they manage to get into the clients database. it doesn't matter though cause even if they change the values, the database values on the server are what does the calculating in the game.

Once you are storing all that information locally like that, it need not be in a database at all.


text:
What are the hot dev positions in game industry?
What are the hot postions which are hard to get in game industry?
Client/Server/Game Engine/Networking and database or else?

....hard to get when looking for a job, or hard to fill when you're a company?

This is something that's going to change over time, due to simple supply and demand, so be aware any answer of what's "hot" right now might be completely invalid in six months.

Technical artists are rare as hens teeth. That is, someone who is primarily an artist, but who can also script/code and understands the shader tech underpinning the art stuff.
Also, good shader graphics programmers are still pretty rare, i.e. someone who can create some of the more impressive visual effects, and optimise the rendering performance.

Hehe. I changed from working towards the goal of being a video game artist to video game programmer at age 19.  I still have some art skillz though. You think an artistic programmer can be as useful as a programming artist?

Probably. Depends on the art skills I suppose, there's a whole spectrum between "has-trouble-drawing-stick-men" (like me), through "can-make-something-that-doesn't-offend-the-eyes" to "wow-that's pretty". Generally you'd have to be at the top end to be a professional artist, and while a technical artist could get away with being lower down the scale, it wouldn't be by much. If your skills are more programmery than arty, then shader programmer is probably a better bet.

Don't forget that you should enjoy working as well - if shader programming isn't your thing you'll most likely get miserable after a while. Money isn't everything!

@Zolomon - Doubly true in the game development world, since if you're good enough to be a game developer, you could probably make twice as much with half the stress being a web developer or something.

Good audio programmers seem quite rare.  However this may not be a hard job to get because most game studios undervalue audio.

Any programmer who knows that this is not a const pointer:
const MyClass* myObject = getObject();

Is a hot property.
Seriously: good programmers are hard to come by and there's a lot of inexperienced guys in the videogames industry.

I do agree with you, but IMO the differences between a const pointer vs a pointer to const are subtle but very learnable by a good developer.  Finding the developer who can learn but doesn't know yet is hard...

Good point nicely put, Rick.  Unfortunately a lot of devs spend too much time crunching for deadlines to spare any for mentoring.  We can definitely do better.

I say the hottest and hardest is to be a Studio founder, and to be a successful one at that.

Just create ONE successful game, improve and extend it in the next two versions and then, bring out a new version every year, that is just a assembly of the features of the first three ones.

"Just create ONE successful game" ... easier said than done.

@Dave O The first million is the easiest, right? :-)

Coding positions seem to be becoming less exciting/creative and less respected with each passing year and increase in team size :(
For each 'exciting' dev position (e.g cutting-edge graphics, or gameplay coding on a big title), there's about 10 coders needed to to fairly dull work (front end, TRC/TCR compliance, tools, porting to the lesser platforms)
You won't make big money coding games unless you really get lucky (right place at the right time). The only real money is in founding a studio and selling up to a megapublisher. Or creating an unexpected big hit with a very small team.
As a career, games programming seems somewhat dead-end unless you have what it takes to start a studio of your own, or are willing to give up coding and aim for a management role...

I would say that that the "Hot position" when it comes to programmers is probably Lead Architect, Lead Engine, or any other name to the same job. Essentially the guy who gets to decide what to implement and how. It's often a person with very good knowledge regarding programming, someone who probably has one of the best overviews of the code in the company. I don't think that it's something that you often get recruited to externally, but instead most likely internally. It requires a lot of experience and often have a tendency to be the best "general" programmers that make it there.

In addition I hear CEO and CTO are great positions, but also hard to get.

@Joe Wreschnig: Indeed. The CTO is sometimes the position I'm trying to point out - not always or neccessary though.

I think, that it is any dev position with good project profit share :)...

a person who's got patience and the quest to learn when new technologies arrive.. he'd get the job  he always wanted..be it a game graphics programmer or game programmer lead. i believe u can build a house only after u've bought the first brick :)
going up is a slow and very much desired process.


text:
Why do we use scripts in development?
In my current project, Lua scripts are called by the C++ functions on the server side.
After that, the scripts again call the C++ functions still in that solution.
Why should we do such things and not call the C++ function directly?
What are the situations in which scripts are needed?

Scripts are usually compiled at run time, while the host language will be compiled at compile time. This means that we don't need to recompile if the script changes. Recompiling a full game can take minutes to hours, which implies a big productivity hit.
Usually, the critical code or backend code will not be scripted. This code should run fast and often memory management is crucial.
In games, game logic and configuration are typically contained in script files. These scripts can easily be updated by non-programmers (like the designer) to tweak the gameplay. Script languages are easy and act in a forgiving manner for that purpose.
Often, a script language is also used to do scripting at real time. This comes in handy for tweaking some gameplay elements or even for debugging. Many games provide a console for this (mostly in-house) purpose.
It is very well possible that you create a game using an existing game engine, just by scripting. The game engine layer is thus fully decouple from the game logic layer. Modern engines can usually be used to create FPS or RTS games easily like this, but it is not possible for any genre. An MMO would probably require another type of engine.
So the bottom line is decoupling. The benefits listed above often outweight the extra work to create or integrate a scripting language.

+1 for saying that scripts are usually easier to update by non-programmers. Designers aren't always programmers, and they don't have to be.

I feel like I'm repeating myself in every question about scripting - if your workflow requires non-programmers to program (which includes scripting), it is going to bite you in the ass later. Designers aren't always programmers, but as soon as they write non-trivial scripts (e.g. as soon as they try to define a function or use a loop) they're pretending to be one. If they don't have training in programming, that's going to end in tears and wasted time for everyone.

To put it another way - if your professional value as a programmer is being able to write good C++ when everyone else can only write good Lua, you're not going to last long. Being a programmer means knowing so much more than just another stupid imperative syntax.

Joe - that doesn't invalidate the argument, it just means that you have to decide where to decouple the "programming stuff" from the "design stuff" and the dividing line will be different based on the technical expertise of your designers (or lack thereof).

It does invalidate the argument; you're making a different argument, which is essentially that worse programmers do less damage in simpler languages. But even good programmers are worse programmers after 24 hours awake, a heavy lunch, a breakup, etc. It has nothing to do with designer accessibility; it's just a good mantra to keep everything as simple as possible, regardless of who will be in charge of it.

I'm pretty sure that any self respecting designer is well taught in at least one language. To clarify things a bit, I would like to nuance the term "non-programmer" as somebody who's profession is not that of a software engineer. I regret using the term, thanks to Joe I see it's ambiguous. I believe there is a broad range of programmers, from those who write simple XML to hardcore assembly to math heavy signal processing. I hope this solves the "non-programmer" duality issue.

At my place of employ, the designers' "scripting" sandbox is visual.  Essentially they're hooking black boxes together with triggers and timers.  The UI isn't great, and the designers sometimes wish they could just type it all out, but doing it visually allows the tools to tightly constrain what they can do and to make it "impossible" to make mistakes.

BTW- I believe that the power in scripting languages, be it Lua or Python or whatever, is that the programmers can use it and be many times more productive, simply due to getting out of the change, compile, execute loop.  ...although I guess depending on your implementation you may require that for scripts too, which then makes them less valuable.  :)  However- having a "scripting" console in-game is an amazing tool.

There has been much debate about this from both sides but I am on the side of having (some) designers write scripts. Raph Koster summarises this well (http://www.raphkoster.com/2007/11/02/using-scripting-languages/) by saying that design is not just about content but about systems, and thus designers need good tools to edit systems. A high level scripting language is one such tool.

Just to be clear, I am not against scripting languages. I strongly encourage scripting in game engines. I am against pretending that people who program are not programmers. Your job title might still be "designer", but there's a guy with that title who is actually a writer, and a guy with that title who is actually an architect - you're the guy with that title who is actually a programmer. And just like if you ask a writer to build a level, if you ask non-programmer designers to write a script, you're going to get crap.

I didn't hear anyone suggest that designers should be writing complex, mission-critical scripts for production.  However, designers with a modest understanding of programming could still tweak some scripts experimentally (and then hand them off actual programmers).  They could certainly write simple ad hoc scripts from a console at runtime to facilitate their own testing.  I imagine designers might want to leverage basic scripting in order to prototype new screen designs (even if they're nothing more than semi-functional, interactive mockups).  Plenty of non-production code needs writing.

You asked the wrong question. The real question, I think, is why do we put up with "non-scripting" languages like C, C++, Java, and so on? And the answer is one reason: performance. (And maybe inertia, but that inertia is there because of performance, and anyone who can write good C/C++/Java can write at least passable Ruby/Python/Lua/JavaScript.)
We use "scripting" languages (which really means, very high-level, garbage collected, and usually some form of looser typing and dynamic compilation) because they're generally easier languages for anyone - programmers included - to write code in. There's less stupid stuff like remembering to free after you malloc or make sure your code is exception-safe, or remembering to make all your destructors virtual. If our computers were infinitely fast, we would be using "scripting" languages for everything.

I like this argument so much better than "so designers can program." It's a very bad idea to dismiss the value of rapid development and being able to experiment with changes without recompiling everything.

Scripting languages for game logic is a very good example of the software architecture pattern Alternate Hard and Soft Layers.  There's a good discussion on that site (and others I'm sure) on the benefits of doing so.

Each new lua class is two lines. Each new C++ class is pain.
No whining about types when all you want is shuffle values around.
Garbage collection.
Script code is nicely isolated in virtual machines, away from all those nasty wandering segfaults and array overflows.

Script changes are easy to deploy. For example, you can keep scripts in a database which means that instead of a full binary redeploy and possible service restart, you just issue a single SQL UPDATE statement, possibly followed by a signal to your running service to reload the script.
Also script languages are often simple to understand and easy to program in so you don't need the 'hardcore' devs (the ones dealing with Memory Management/Pointers and cpu-level optimizations) for the majority of code (if a large RPG, the scripts for AI, Spells, Item Effects and the world itself are often bigger than the engine code). Script languages allow a lot more focusing on the 'what' rather than the 'how' due to Garbage Collection (in case of Lua) and a higher level of abstraction.

One scenario where the scrips are useful is when we want our engine to be extensible by plugins/addons. These extensions are created in many cases by non-professional people (like advanced gamers and enthusiasts). Scripts are safer and easier for this purpose. By using scripts, they don't need to use compilers, and don't need to be aware of pointers...
A great example of this is the game World of Warcraft. It has thousands of addons created by the community. These addons are written using LUA + XML.


text:
Good 2D Platformer Physics
I have a basic character controller set up for a 2D platformer with Box2D, and I'm starting to tweak it to try to make it feel good. Physics engines have a lot of knobs to tweak, and it's not clear to me, writing with a physics engine for the first time, which ones I should use. Should jumping apply a force for several ticks? An impulse? Directly set velocity? How do I stop the avatar from sticking to walls without taking away all its friction (or do I take away all the friction, but only in the air)? Should I model the character as a capsule? A box with rounded corners? A box with two wheels? Just one big wheel? I feel like someone must have done this before!
There seem to be very few resources available on the web that are not "baby's first physics", which all cut off where I'm hoping someone has already solved the issues. Most examples of physics engines for platformers have floaty-feeling controls, or in-air jumps, or easily exploitable behavior when temporary penetration is too high, etc.
Some examples of what I mean:

A short tap of jump jumps a short distance; a long tap jumps higher.
Short skidding when stopping or reversing directions at high velocity.
Standing stably on inclines (but maybe sliding down them when ducking).
Analog speed when using an analog controller.
All the other things that separate good platformers from bad platformers.
Dare I suggest, stable moving platforms?

I'm not really looking for "hey, do this." Obviously, the right thing to do is dependent on what I want in the game. But I'm hoping someone somewhere has gone through the possibilities and said "well technique A does feature X well, technique B does Y well, but that doesn't work with C", or has some worked examples beyond "if (key == space) character.impulse(0, 1)"

Here is an extremely detailed Sonic The Hedgehog physics guide. I would recommend reading it over, if not actually copying parts of it mostly-verbatim.

It's quite tricky to implement, say, 'Mario-like' physics using a real physics engine.
Last time I tried this, using Chipmunk, I modelled the player as 2 circles - a 'body circle' on top of a 'feet circle'
The 'feet circle' had some friction, was non-bouncy, and fairly small. The 'body circle' was larger and frictionless, to avoid sticking to walls/steep slopes
The object was constrained to not allow rotation - it would just slide around
If the 'feet' are touching something, or were within the last few frames (to allow falling down slopes), the player was considered as on the ground (may have had a surface normal check, too)
It's a while since I looked at the code, but the behaviour was along the lines of:
When on the ground:

Apply 'additional gravity' (downward force to help with running down slopes)
Apply ground friction (larger amount of horizontal damping)
Apply left/right movement force, based on the controls.
(Scale down the left/right movement force as approaching a maximum run speed)
If jump is pressed, apply upwards impulse

When in the air:

Apply air resistance (small amount of horizontal damping)
Apply regular (or reduced) gravity
Apply left/right movement force, if you're allowing in-the-air control

You've got to be a bit careful with switching between the two states - remember that when running down a slope, you may leave the ground for a couple of frames - you probably don't want to switch states/disallow jumping at that point
A few other things to watch out for, though... 'jump-up-through' platforms can be hard to implement, and when you start doing fun stuff (moving platforms, rotating worlds, etc), you have to be careful to make sure the player can't get trapped/crushed by any 'animation driven' moving object.

I know this is a pretty old answer but I have some questions on this. 1) How do you solve the "keep same speed whatever terrain slope you are on?" 2) If you're using a little circle for feet and a bigger circle for body, wouldn't the player get hung on edges some times? I'm really interested in your aproach.

Honestly I don't think using a physics engine is the right approach for something of that size domain with super strict requirements.
Just write it all yourself.  You'll get much better results by saying "move character up by x units in this parabola shape when holding down jump button for length y" than by having a bunch of knobs to tweak.

I've done this several times in the past. It works to a point, but you always end up throwing something else out because it's "too hard" to do the physics right with a hacky controller. In this particular game I'm hoping to involve some spring/rope mechanics for the player's movement, and that crossed into the realm of "I'd rather hack down a real physics engine" rather than "I'd rather hack up a box mover".

I'd rather hack up a box mover, at least it can't get instable, whereas a physics engine tends to explode if you throw too many forces on it because you need to constrain movements to exact specs (and physics engine constraints ain't rigid, they can only try to comply so much). Also, applying forces to solve one undesired issue tends to influemce everything else, leading to tweakers hell.

I wrote a series of articles about building a platform game from the ground up using modern technologies and it includes how I handled the simple physics:
http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/
However if you want something more high-tech it's entirely possible to approach this using full a physics engine. Here's a technique you can use (from Little Big Planet) which makes the player character a fully integrated part of the physics engine:
Instead of applying impulses or setting velocities to move the player around as 'external inputs' to the physics engine, you can develop a constraint which controls the character.
So this constraint will have the player's desired speed and direction as an input (from the game) and will model things like the player's maximum strength and speed. The constraint will try to move the player according to its inputs (and obeying the maximums), and because its a constraint it will apply a equal and opposite force on the object the player is standing on, thereby allowing the player to stand on moving platforms and to affect the things he moves over.
Doing things like this means can you have the player totally naturally be able to deal with situations like being under a huge pile of boxes, or jumping across several moving platforms because he is now a core part of the physics engine.
Hope that helps!
Cheers, Paul.

The link to the article is dead. Here is a link to the wayback machine: https://web.archive.org/web/20120505065915/http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/

This question has seen significant discussion on the Box2D forums.  Reading though the discussions about character movement, jumping, or platformer and you'll come across every possible issue.  However, the issue got complicated enough that the collision filtering system was updated and a Test Bed example created solely to show how it should be done.

Use Box2D
Follow the Character Collision TestBed


text:
How do you come up with ideas for new games?
What is the best way in your opinion to find new ideas for games? I want to invent something really new (like Gish, World of Goo, Crayon Physics etc), but I'm having problems coming up with new, creative ideas.

Consider that there is no NEW ideas, only different combinations of old ideas.
Make lots of games
The best way to get really good ideas — ideas that will become great games — is to make lots of games. You should brainstorm up lots of stuff and make prototypes. You will not make good games without lots of trying things and failing with some and iterating on what works. World of Goo and Crayon Physics both started out as small, quick prototypes (not sure about Gish).
Prototype
Prototyping allows you the freedom to try out wild ideas, figure out how to make them shine or figure out that they don't work, and not spend years of your life doing it. The years of your life come when it's time to make a real game.
Prototypes come in various forms. The two big ones I see a lot are quick and dirty videogame prototypes and paper (or boardgame) prototypes. Do the simplest, smallest thing possible and make that. See whether it works and what needs to change. Iterate. Then go and do the same exercise with a new idea. Eventually, you'll have a prototype that you MUST MAKE: something you feel really strongly about.
Make that.
Keep in mind that a prototype need not be a vertical slice of the entire experience. More likely it is just some simple aspect of an unpolished product, like some new mechanic that needs to be proved to be feasible and fun. Therefore, the time to prototype an idea can easily range between an hour and a month depending on the complexity of the idea and the skills and tools you can leverage to get it done.
As a reference,
Kloonigames — Experimental Games, from Petri Purho, the creator of Crayon Physics, was "the experimental monthly game project". The projects always used SDL+box2D, always just a few hours/days. It eventually created World Of Goo.
Work with other people
Most idea generation techniques can be done by yourself, or with a group. When in a group (even when "group" means "you and a partner") you have the opportunity to feed off each other, and come up with more unique ideas because of the different perspectives. Don't underestimate other people, even "non-creatives" can have great ideas.
Observe the world around you
One informal way is to observe the world around you. Watch the kind of objects and interactions you have every day. See what makes people happy or what captivates them. Is there any way that can be used as the basis of a game? Or can you add it to an existing game in a way that makes something new? Mull it over, try playing a mini prototype in your head. If it doesn't have potential, move on. If it does, make a real prototype.
Spend a lot of time thinking and observing. Eventually you will have a lot of ideas that aren't good enough and some that are.
E.g. Shigeru Miyamoto has got his inspiration for Pikmin from watching ants.
Hit Wikipedia's or a dictionary random page
A solution is to hit the random page link on Wikipedia or select a random word from a dictionary a few dozen times until you find some amusing topics and then build something from that.
Another approach with this is to try to come up with 10 bad game ideas for that topic. Usually after 5-8 bad ideas you will have a really good one. Then try to implement the essence of that idea over 2 or 3 days, setting a strict deadline before you start. Toss the result away and do it again. From there on it's just execution...
Turn off the computer, leave home
Some take their inspiration from things completely unrelated to games.  It's better to go out and do stuff: travel, watch movies, read novels, do sport, just walk around downtown, etcetera. E.g. Shigeru Miyamoto's inspiration for Legend of Zelda was when he used to play in the woods as a kid.
Carry a notebook and a pen
For some, the best ideas come when they are not trying to think about them: in the shower, while commuting to work, having a nice walk in the park, or when sleeping. Always have a notebook and a pen with you, wherever you go, whatever you do. Then when you're sitting back in front of the computer the ideas will be there with you in your notebook.
Attend game jams
Taking part in game jams and participating in activities like The Experimental Gameplay Project can help: sometimes placing restrictions on your design or building a game around a theme will yield some interesting ideas. How would a game about candles play? What would a game in which you could only use black and white look like? How can you exploit that restriction in terms of a game mechanic?
Take game design classes, read game design books/articles
Many universities offer classes in game design (though make sure they are really teaching what you want to learn, as the term is misused a lot).
Improve aspects of a game you like
Many highly successful games are simply refinements of previous games, figuring out what makes players enjoy a certain playstyle and then enhancing or providing better gameplay. WoW is a great example, taking cues from previous MMOs and tweaking things for the "common" gamer, and even casual gamers.
WoW took from Everquest, which enhanced ideas from MUDs, which were taken from adventure games mixed with old school paper and pencil Dungeons and Dragons which took from J.R.R. Tolkein. Basically, all the old things are new again in the right hands.
Take an idea or two that you like from games and think about the process that might make a game better that would use those ideas. Plot out what a player would do in order to start playing the game, and what kinds of things would be fun for a player to do. Many new designers simply take ideas and steal them directly, not giving much thought to what the player is supposed to do that differentiates their game, or why they should be fun. In order to stand out, you must improve on the gameplay that you decide is part of the core fun.
Other idea generation techniques
This also known as Ideation:

Brain-storming sessions
Mindmapping
Problem Solving
Metaphorical Thinking
Thinking Hats / Ego Alter
SCAMPER
Using Random Media To Stimulate Thoughts
Forced Associations
Changing Perspective Or Place
Collaborative
Experimentation
Vision Circle
Just keep playing games of all kinds

Also see

Creativity techniques
creatingminds.org - Ideation Tools
Game Design Concepts
Game Developer (formerly Gamasutra) section on game design
Good game design books?

Words of caution

For some, the more time they spend in front of their computer, the less creative they become.
Taking inspiration from games can lead to only think of derivative clones of those games, harming creativity.


text:
Where to look for team mates?
Where is a good place to look for people interested in creating games online? I'll be using XNA.
I'm going to start the project later this week, but I'm definitely commited to it. I'd like to find people who won't hit it and quit it after a month.

http://gamedev.stackexchange.com/questions/2791/finding-other-programmers-to-help-on-a-project

actually I have got the same question. would be great to get some advise on this topic.

A much better question to ask is "How do I pick the right teammates/project?"
This is an excellent article on the subject
How to Pick Indie Game Collaborators: 11 Things to Watch Out For

... The first groups I joined taught me most of the items I hope to pass on to you in this article. They all had heart, and lots of dreams, but very rarely did they have sufficient talent, dedication and management. I spent easily a year and a half spinning my wheels, going from group to group, before I found a really good one...


text:
Problem with box2d at beggining
I have problem with simple box2d physics: I have two bodies : 1 - static box , 2 - dynamic box. I only want to this dynamic box fall on this static, and lay. But now it looks like that at end , starting from  . This is code, which bases on box2d HelloWorld:
#include <SFML/Graphics.hpp>
#include <Box2D/Box2D.h>
#include <cstdio>

int main(int argc, char* argv[])
{
    B2_NOT_USED(argc);
 B2_NOT_USED(argv);

 b2Vec2 gravity(0.0f, -10.0f);
 bool doSleep = true;
 b2World world(gravity, doSleep);

 b2BodyDef groundBodyDef;
 groundBodyDef.position.Set(0.0f, -10.0f);
 b2Body* groundBody = world.CreateBody(&groundBodyDef);
 b2PolygonShape groundBox;
 groundBox.SetAsBox(50.0f, 10.0f);
 groundBody->CreateFixture(&groundBox, 0.0f);

 b2BodyDef bodyDef;
 bodyDef.type = b2_dynamicBody;
 bodyDef.position.Set(0.0f, 300.0f);
 bodyDef.active = true;
 b2Body* body = world.CreateBody(&bodyDef);
 b2PolygonShape dynamicBox;
 dynamicBox.SetAsBox(3.5f, 3.5f);

 body->SetTransform(b2Vec2(0,100),30);

 b2FixtureDef fixtureDef;
 fixtureDef.shape = &dynamicBox;
 fixtureDef.density = 1.0f;
 fixtureDef.friction = 0.3;

 body->CreateFixture(&fixtureDef);

 float32 timeStep = 1.0f / 60.0f;
 int32 velocityIterations = 6;
 int32 positionIterations = 2;

    sf::RenderWindow app(sf::VideoMode(800, 600), "BOX/SFML");
 app.UseVerticalSync(true);
 sf::Shape shape = sf::Shape::Rectangle(-3.5f,-3.5f,3.5f,3.5f,sf::Color::Green);
 sf::Shape groundShape = sf::Shape::Rectangle(-50,-10,50,10,sf::Color(100,40,120));

    while (app.IsOpened())
    {

        sf::Event event_;
        while (app.GetEvent(event_))
        {

            if (event_.Type == sf::Event::Closed)
                app.Close();
        }

  world.Step(timeStep, velocityIterations, positionIterations);
        world.ClearForces();

  b2Vec2 position = body->GetPosition();
  float32 angle = body->GetAngle();
  b2MassData m;

  body->GetMassData(&m);
  printf("m %f\n",m);
  printf("%4.2f %4.2f %4.2f\n", position.x, position.y, angle);

  app.Clear();
  shape.SetPosition(position.x+400,-position.y+300);
  shape.SetRotation(angle);
  app.Draw(shape);
  groundShape.SetPosition(0+400,10+300);
  app.Draw(groundShape);

        app.Display();
    }
 world.DestroyBody(groundBody);
 world.DestroyBody(body);
    return EXIT_SUCCESS;
}

I looking for any advice for solve this problem. And another problem, why mass of dynamic shape is 0 ?

somebody please clean this post up.  Change the image links to embedded images and use consistent indentation in the code.

I've found I hate SFML when dealing with Box2D.  It's concept of inverted-y and pixel based coordinates is great if you want to draw a quick box.  It's horrible if you need to tie its coordinate system into another library (which you will need to do in any game that's not an SFML demo).
My recommendation: use Box2D's debug rendering.  That way when you see an object in the middle of the screen you know it's actually there.  The sf::Shapes could be way off of the underlying b2Body.

Thx, I find that I use another angle unit for SFML's rotate. But I still don't know why mass == 0 .

You can use an sf::View to solve the issues with pixel-based coordinates. But yes, inverted-y and its insistence on degrees for angles drives me nuts.


text:
Help making a visual transition with pygame and NumPy
Perhaps this could be better answered on Stack Overflow, but I thought it would be worth posting here. Right now I'm trying to make visual transitions with pygame's surfarray module which uses NumPy. I'm using Cave Story's diamond-checkerboard transitions as a model right now (you can see them in this video http://www.youtube.com/watch?v=mJbAs-sSX4A).
I'm new to NumPy and I'm a little bit over my head. Is there an easy way to accomplish this, or are there any tutorials I should be following? Google brought up a bunch of general NumPy tutorials which I didn't find very helpful for my specific needs.

You can easily do regular checkerboards by using numpy to copy parts of an image (array) onto another array, like this:
# Let's define two arrays to work on. They should be replaced with your surfaces
a = numpy.ones((640,480))
b = numpy.zeros((640,480))

a[100:110,200:210] = b[100:110, 200:210]

Obviously you can mix it up, copy from multiple sources and different locations if you need it for your effects. Since everything is handled by numpy (without coming back to python after every pixel) it is quite fast.
The only limitation is that the source and destination must be the same size (or obey the broadcasting rules, but that's not what you want here).
Update
I had completely forgotten about choose(). It is the missing piece you need to do the transitions "properly". What you need is something like this:
diamonds = [ ... ] # List of arrays containing 1 and 2 arranged in enlarging diamond patterns, say 100x100
for diamond in diamonds: # you probably want timers and events rather than a tight loop
    for x in [0,100,200, ...]:
        for y in [0,100,200 ....]:
            screen[x:x+100, y:y+100] = diamond.choose(screen1[x:x+100,y:y+100], screen2[x:x+100,y:y+100])
    # Pause for transition effect
    time.sleep(0.01)

This should get you the required effect. Post if you get into trouble.

Excellent, this was just the hint I needed to figure the rest out!

The basic way to do this is with choose. You need surfarrays of both sides of the transition, and then make a set of arrays for each step of the animation.


text:
How do some games save without creating data files?
I downloaded a game called Brain Exercise with Dr.Kawashima. It contains only one executable and no data files. However, it's still possible to save the game!
Where does the save data go?

Is it even possible to modify you own exe for game saves?  I'm primarily a Linux/Mac guy so I don't know what Windows allows in this area.

caspin, yes it is possible! Check out LockNote (http://www.steganos.com/us/products/for-free/locknote/overview/) for an incredibly useful example of saving data into an executable.

@Ricket - that's bolting an executable onto existing data, sort of like self extracting archives.  I suspect that they're not actually modifying the file itself, rather recreating it on "save".

You may want to be careful it's not picked up as a virus.

I would suggest downloading Process Monitor to verify that the program in question is in fact writing to it's own executable. I think you will find that it is writing to other files or the registry.

@dash-tom-bang What's the difference? Sounds like the same thing to me.

@Benjamin Manns Your comment may apply to the original question, but no, LockNote does indeed save into itself. You can have multiple locknotes by saving them as different names, and they're 100% portable because indeed the text is encrypted and saved into the exe.

It may be making saves in the Registry or somewhere under your %APPDATA% folder, or in your homedir's "My Documents" or "My Games" subfolders.  Or anywhere else on your hard drive, for that matter.  It is unlikely to be modifying its own exe to save, although I suppose that is possible (if a very bad idea: see AttackingHobo's comment below for a sample of the reasons why).

When looking into this kind of thing on Windows, I tend to use tools like Sysinternals Process Monitor (aka procmon.exe), which will display filesystem and registry activity (among other things, it is verbose -- spend some time filtering down to what you want to see).

It is really really bad practice to even attempt to change the exe. First off you run into the problem of not being able to modify files that are open.
Secondly after you have worked around that problem, if you are saving to exe and there is an error, or something crashes, you are going to have a corrupt game exe and users will be comfused.

And if it wants to communicates with the internet, some desktop firewalls will constantly ask again for permission because the checksum does not match.

I don't have data to back this up, but a self-editing .exe might even be interfered with by antivirus software. That said, Window's shadow copy service allows you to do some cool, somewhat non-intuitive things with locked files. http://en.wikipedia.org/wiki/Shadow_Copy

On Windows Vista or 7, elevated privileges are needed in order to modify files in the Program Files directory. It is reasonable to run an installer as admin, but running the executable as a normal user will not allow this type of modification. (Just strengthening AttackingHobo's comment.)

While it's perfectly possible to modify the executable (it's what viruses do all the time, and you can append whatever you want to an exe and read from the end of the file - not sure how windows user levels interfere with it, haven't done it since the golden days of MS-DOS) I'd indeed suspect the registry is used.
Copy the executable over an install on another system and see if it has your savegame, if it does you know it's the exe being modified.

While it might not have been that common when this question was originally created, some games today store their savegames on a server connected to the internet in The Cloud™. This usually requires that the user authenticates itself with a username and password. When the game itself has no account management, a digital distribution system can provide this. Steam, for example, offers an API for storing game data on their servers.