title: Best solution for "level string"?

text:
# Question
Title: Best solution for "level string"?
I have a game that generates a random level map at the start of the level. I want to implement some way to save and load the level.

I was thinking maybe XML would be a good option for saving all the variable, then it would be easy for me to build something that can parse that XML and generate the exact same level.

But XML is probably overkill for my needs. I remember back in the day with the old Sega console that didn't have the ability to save your game (I think the Worms game did it too), that they would give you a bunch of character that you could write down. If you punched in that string later on, it would load the exact level.

Would a "level string" be a good option? Would it be some kind of "base60" conversion? How would I implement this?

# Answer
> 20 votes
Presumably all you need to save is the random seed, which is generally just an int. You could encode the int to base64 if you wanted to make it a bit more opaque, but thats probably not needed.

# Answer
> 24 votes
Whatever format you use for your save games, for goodness sake put a version number in. You'll be able to have backwards-compatiable loads by branching on the version number, or you'll be able to safely recognise saves that are too old to load.

You'll regret it if you don't.

# Answer
> 10 votes
JSON is good, but YAML is better. :) http://www.yaml.org/ and http://code.google.com/p/yaml-cpp/ for one of the nicer-to-use implementations.

YAML is a superset of JSON that adds support for a few nice features, most notably:

* Binary nodes. This is great for serializing the kind of data you might be dealing with for level descriptions. JSON requires you to translate to some intermediate format of your choice, like Base64, before writing / after parsing. YAML has a !!binary node type which tells the parser library to do it for you.
* Intra-document references. If the same object appears twice in the document, JSON will write it twice, and when you read it back in, you'll get two copies. Many YAML emitters can detect this situation and instead of a second copy, output a reference to the first, when can be detected when loading.
* Custom node types. You can flag each map in a list with e.g. !!Player, !!Enemy, etc., and so keep your type information more out-of-band.
* YAML supports more readable formatting.
* Since JSON is a subset of YAML, most YAML readers will have no trouble reading JSON documents.

# Answer
> 3 votes
If you want to serialize all the data in game, I would recommend JSON as your file format, it is why easier to use the XML and the support is very good across many languages.

I have used this library for C++ and it works very well.

http://jsoncpp.sourceforge.net/

# Answer
> 3 votes
XML is a good choice if you're not limited by size and it is supported natively (eg in .NET and Flash) but if you want a slim format you can create your own format and parser quite easy. I normally use 1 character eg. comma to seperate each object. To decode the string do a split on comma. Now each object needs different properties so seperate these with a different character eg semi colon, and use another character to seperate the property names from property vales, eg. Colon. All thus can be decoded easily without regex just by using string.split. Here is an example:

```
id:1;x:5;y:45.2;angle:45,id:28;x:56;y:89;angle:12;health:78

```

you can save even more space by keeping property names down to 1 character, eg h for health. Eg.

```
i:1;x:5;y:45.2;a:45,i:28;x:56;y:89;a:12;h:78

```

Compare to JSON alternative:

```
{"o":[{"i":1, "x":5, "y":45.2, "a":45}, {"i":28, "x":56, "y":89, "a":12, "h":78}]}

```

Also, if you want to get the size of your numbers down, you can encode them using the full set of printable UTF16 characters. This thread inspired me to ask a question over on Stack Overflow of how much data you could pack into one on-screen character. The answer seem to be somewhere over 40,000 values for an integer, if you don't mind having brail, Kanji and chess pieces: ♔♕♖♗♘♙♚♛♜♝♞♟

To get a further size reduction, you can use read/write order to determine which value is which, so the first two characters represent the id, the next two are the x position, the next two the y, then the angle, then health, etc. So:

```
F5DGP@%&002DFTK#OP1F

```

could store all the same information as the other examples.

Tile grids can be stored as just a string with each character representing a different type of tile eg:

```
i789pog5h3kl

```

where I might mean lava, 9 mean grass etc

# Answer
> 1 votes
If you are coding in .Net then XML is super easy to go with, as you can serialize/deserialize your level class into/out of XML with just a couple lines, and then its all in a nicely managed class.

TheMap would be a variable of type Map that you have all of your data loaded into.

```
Dim TheMap As New Map

```

Assuming you have a Map class already built, this would save your map into XML:

```
Dim Serializer As New System.Xml.Serialization.XmlSerializer(GetType(TheMap))
Dim Strm As New FileStream("c:\Map.xml", FileMode.Create, FileAccess.Write, FileShare.None)
Serializer.Serialize(Strm, TheMap)
Strm.Close()

```

This would then load that XML back into your map class, to be used again in code.

```
Dim Reader As New StreamReader("map.xml")
Dim Serializer As New System.Xml.Serialization.XmlSerializer(GetType(TheMap))

TheMap = Serializer.Deserialize(Reader)
Reader.Close()

```

From this point on your XML file is now loaded into your class for easy use.

As for your "Level String" issue, what was stated before would work great, you could just use the Seed number as the "Level String".

Otherwise, you could just pre-generate however many different maps you wanted, and have them all saved with a "Level String" and then use that to pull up the proper map.

# Answer
> 0 votes
I'd use a simple `struct` or similar device (depending on your language) to store all game state in a central place. If you want the protection of setters/getters, you can wrap the struct in a `class`.

If you feel up to it, make use of bitfields or simply do bit manipulation yourself using bitwise operators.

Be aware that in some languages, the rules for struct padding and packing may be a bit complicated -- but it may also not matter much for your case if you have a byte or two of padding.

You may also be able to use a `#pragma` (such as `#pragma pack(1)`) or an `__attribute__` to closely pack the struct, eliminating padding. This may or may not work depending on your compiler and target architecture.

Note that use of bitfields and pack pragmas or attributes can reduce portability. Across hardware architectures, the struct field endianness (byte order) may also change. So you may want to avoid this if you're trying for portability.

(For e.g. Pac-Man, this struct might naively contain a map id or map seed, a Pac-Man x and y position, four ghost x and y positions, and a large bitfield for the presence or absence of 32-64 pellets, whatever the maximum is.)

Once you have your struct, pass it to something like an xxencode function:

```
encode_save( char * outStringBuf, size_t outStringBufSize,
             const SaveStruct * inSaveData, size_t inSaveDataSize )

```

Writing this function is a bit error-prone; you need to shift and combine bytes as necessary to get e.g. 6 bits at a time, then translate into an appropriate character. I'd personally try to hunt down someone else's code, unless I was doing this for "fun" (and I'd probably want a test suite for it).

Never underestimate the power of the old-school `struct` in the right places. We've used it a ton for GBA and DS games here.

# Answer
> 0 votes
XML is good for arbitrarily structured documents(elements can appear in different levels of the tree) or foreign format embedding(like putting svg in an xhtml page). If you don't have those requirements it's a really inefficient format, and something more simple like csv or json is preferable.

---
Tags: software-engineering, random, levels, procedural-generation
---


# Question
Title: Algorithm for drawing asteroids from, er... Asteroids game?
What would the algorithm be for generating/drawing the asteroid shapes from the original Asteroids game? Is it even an algorithm? Or would they be hard coded shapes?

Here is a screenshot to jog your memory.

Screenshot from Asteroids game http://www.heinzwerner.de/emu\_asteroids.jpg

**EDIT** \- Also found this:

alt text http://www.next-gen.biz/files/images/feature\_article/2009/05/asteroids4.jpg

from the article Edge - The Making of Asteroids. Interesting read, but does not mention any specifics.

# Answer
> 8 votes
I can't say I have any inside information, but given the finite number of shapes (note how even in your screenshot two of the large-asteroid shapes are repeated), I always assumed it was hard-coded. You could certainly reproduce it that way if you were going to build it today.

# Answer
> 6 votes
Asteroids was a vector based game, so shapes were most likely described as 'turn left 30 degrees and move 10 forward'. As in the Logo programming language. So you draw your shape as in the sketch, convert it to a series of vector commands, set a scale, position and rotation and start the drawlist. I guess you can reproduce it pretty much like that by drawing line-lists. Oh yeah, I assume they're hard-coded, as, like others noted, the ones in the game match the ones on the sketches.

# Answer
> 4 votes
I also expect them to be hard-coded as a list of points. The machines back then were not powerful enough to waste any CPU time and memory on dynamically generating asteroid shapes.

If you want to generate Asteroids dynamically, here's what I would do:

* Choose a random angle (higher than the previous, up to 360°
* Add a point at a random distance from the center

In other words, imagine drawing several circles from around the center of the image with various radii. Then pick a random angle (direction) and a random circle, the intersection of the line and the circle is going to be one of the shape points. Repeat until you made a full 360 sweep. You'll end up with a list of points that connected create an asteroid shape.

# Answer
> 4 votes
My algorithm was: For each of 8 equally spaced angles around a circle, choose a random distance and draw a point at that angle and distance from the center connected to the previous point.

# Answer
> 2 votes
It appears that the four asteroid types you have posted drawings of do match the asteroids in your screen shot (if you look at the red lines of the drawings as the correct lines).

It also appears that the lower-left "medium-sized" asteroid is an example of asteroid drawing #2, and that drawing also appears as the two left-most large asteroids.

So it looks as if there are four asteroid images which can appear at 3 (?) scalings. Nice sleuthing.

# Answer
> 1 votes
Another possibility to generate asteroids dynamically would be to take a predetermined form from a set, and modify a random number of times the edges: you take an edge, choose a point on this edge (near the middle), and move it along the perpendicular direction, towards the outside or the inside. You replace your initial edge with the two edges resulting of the use of the point:

`A---------B` become

```
A--     --B
   --C--

```

You can do this a number of times, on initial or resulting edges. This is a simple fractal/recursive modification of the edges. (As with all recursive modification, the size of variation should go down with the depth.)

---
Tags: graphics, algorithm, procedural-generation, graphics-programming
---


# Question
Title: Anti-Cheat for MMOs issues and solutions?
Most online games suffer for this problem and there are some software companies out there to cover this but recently from what I've seen most companies are trying to avoid those programs creating their own system (blizzard with warden, aion with their own checking, etc...) but it is a very difficult case to prevent such ...

Just wanted to say i made another question topic as community wiki specific for posting applications and it is features and the ideas behind this question here is not to list those but instead to know more about what were your attempts, issues along the road and possible solutions, piece of codes if application and so forth.

**What sort of protection do you guys use in order to (try to) prevent such acts:**

1. **Anti-cheat Software ?** (please state which, why and possible problems you faced, for example aion stopped using GameGuard at beta stage due to a huge amount of compatibility problems and complains from their users)
2. **Your own code ?** (what sort of verification do you usually run to make sure of the bad-faith players, for example speedhack, verify new location against speed+last location, etc...)
3. **None, i dont care ?** (any personal reason or input you did like to share ?)

Any interesting piece of code related to the issue you would like to post ?

Feel free to rework my text my english inst that great ?\**

# Answer
> 23 votes
Unfortunately it's really hard to stop people from cheating, which is why software like Punkbuster was created to try to catch some of them.

For an MMO, the biggest thing you can do is to just **not trust anything the client sends you**. The client should not be able to tell you where the player has moved to, how much damage they have dealt to whom, etc. Instead, you should send control input to the server, validate that it is practical (pressing the "attack" button 1000 times in 1 second, for example, is not valid), then update the simulation on the server. You would then send the relevant parts of the new state of the game back to the client.

While you are validating user input, it is also possible to look for trends in their input. If you don't allow macros, you could catch them here by noticing that the user has clicked the same button at the exact same pixel coordinates in perfect 1 second intervals for the last 30 minutes.

The client itself is the main place people can cheat, so programs like Punkbuster can cut down on wallhacks, aimbots, etc. Other than that, not trusting the client and validating anything sent to you by the client will help cut down on cheating.

# Answer
> 9 votes
Logging. Everything that happens on the server should be logged, and ideally everything that comes from the client. The client is inherently untrustworthy, but even logging untrusted data can be illuminating.

Once everything is logged, cheat detection becomes a matter of analysing the data. Some cheats will be obvious (values out of acceptable ranges, for example being able to move between points far faster than the avatar normally allows), others are more insidious (like aimbots allowing pixel perfect targetting within artificially short timeframes). Some are even harder to detect (like wallhacks), but recording as much as possible allows both automated and manual detection. There are various articles on it, but generally cheats are very easily spotted in automated detection because they are so predictable/repeatable, in exactly the way that human players aren't.

Since recording absolutely everything is most likely infeasible, tiered logging is useful. For example reports of cheating by users, or simple basic logging that detects the possibility of cheating (score which are way above the statistical curve), would be enough to flag a particular client/account/CD-key for more verbose logging, which could then be used to prove beyond reasonable doubt that a cheat is in use.

What you do when you detect a cheat is another matter entirely. Account banning after the fact is good, especially when you have an automated detection mechanism that is sufficiently reliable. Banning early both alerts the cheats that they are being detected, and also runs the risk of false positives due to inconclusive detection mechanisms. Banning too late runs the risk of ruining the game experience for others. This is a very grey area, and requires the developers to make the judgement call.

# Answer
> 2 votes
Assuming all important work in your game is occuring server-side, there should be little or no cheating possible. If you want to restrict macroing or make it obnoxious for people to packet-edit, have your program periodically scan for modules active in its process. If you find for instance WpeSpy.dll, you'll know they have WPE attached. Do so for the other common tools. This can be got around, and is an arms-race and a lost cause, *but* if your game is relatively small, you can very easily cut the number of people screwing around by about a factor of ten... and that may be good enough for you.

---
Tags: mmo, anti-cheat
---


# Question
Title: Blender For Game Development, Pros And Cons
Blender is one of those applications that you either love or hate. I know it is great for 3D modeling and and animations and there is a lot said about the UI and its steep learning curve.

I am more interested in how Blender stands out as far as Game Development goes. So my question is, what would be the Pros and Cons of choosing to use Blender to develop a high performance 3D game?

# Answer
Blender is great if you know how to use it. (I suppose you mean as a modeling software, not the GE)

Here's some reasons:

* It can export to many file formats out of the box, and many you can find, and many you can write your own scripts for importing
* You can usually find a lot of free models to build on or use as placeholders
* It's free (as in speech)
* Due to the Python interface, you can find a lot of extra features implemented by someone, and build your own collection tailored to your needs
* You get a huge community for support.

Of course, these are reasons Blender works, not reasons Maya or 3DS doesn't.
> 11 votes

# Answer
I have worked in various companies that used blender extensively for their game development. Most of them used their own exporters, but the reasons for that start to diminish, since blenders collada exporter is becoming better.

If you are talking about GameBlender ("running games in blender") I like it for rapid prototyping, but not for final products (due to the plugin dependency).

If you just want it to create assets, then it doesn't matter where your data comes from, since your engine will make the difference.
> 3 votes

# Answer
If you want to use Blender as a game development platform, check out the GameKit: http://code.google.com/p/gamekit/

Created by Erwin Coumanns from Bullet (and others), it features tight integration with IrrLicht/Ogre3D.

It's still in the early stages, but it does look promising! :)

The basic idea seems to be to create a scene in Blender, and then directly load that blend file into your engine (powered by either IrrLicht or Ogre3D).
> 3 votes

# Answer
I've never been terribly impressed with the Blender Game Engine (though I haven't worked with it enough to have a strong opinion), but as part of a content pipeline for a game, Blender is great.

I've been using it for nearly 4 years and it's a fine piece of software. It's free, and while the interface is a bit menacing at first, it's very efficient once you get a feel for it (and 2.5 looks like it's cleaning it up a lot). The python scripting API is great, and allows you to automate all sorts of things, write exporters/importers and so on. I've even used it as a simple map editor for a project or two, with a script to export to the appropriate map format.
> 3 votes

# Answer
If you want to see how you can use Blender to make a next-gen game, check out Project AfterShock.

Start by reading issue 21 of Blender Art Magazine, page 31: http://issuu.com/blenderart\_magazine/docs/blenderart\_mag-21\_eng

Then visit their site: http://www.liquidrockgames.com/

And browse the showcase topic in the Ogre3D forum: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=37377&start=0
> 1 votes

# Answer
Blender can be easily extended via python and so it fits in virtually every content creation pipeline. You can write your own custom exporters, or even add your own UI-elements for tweaking game-specific properties. With version 2.5 the UI has got a major overhaul and is much more intuitive now.

On the con side, many existing game engines don't provide really good exporters for blender, especially the commercial ones (but then, you can always write your own).
> 0 votes

# Answer
I have seen a lot of Z-Brush artists use Blender for unwrapping UVs. It seems particularly good at things like creating the seams on low poly characters
> 0 votes

---
Tags: tools, blender, blender-game-engine
---


title: Checklist for finished game?

text:
# Question
Title: Checklist for finished game?
I and a couple of friends are doing a game on our spare time and we've finished about 80% of the game.. so all the obvious stuff and core mechanincs. We've done a couple of games before and we always have problems finishing.

The problem isn't that we're not passionate enough about the game, it's rather that no one of us sees those last details that need to be added, we've become blind somehow with the game. It's really frustrating. It can be stuff like.. "maybe we should have a pause function?" "Uhh, yeah, of course, why didn't we think of that earlier?"

Sometimes even though it takes a long time to realise the need, afterwards it's really obvious that it needed to be done/added.

Do you use any kind of checklist to force a finish or do you rely on your keen senses to know when it's done?

A checklist would be nice to have when estimating project time as well..

# Answer
Get Testers. (Though this might not be a direct answer to the question)

Really, asking for a checklist is imo too game/genre specific as it could be answered in such a generic way. However, I do recommend getting as many testers as possible and as much feedback as possible.

It is actually completely normal (imo) for a developer to somehow overlook completely simple but neccessary stuff for your games; testers on the other hand will most likely notice such things right away (at least that's what I have experienced).

So anyways, as for a rough sketch for a "checklist" (though I hope you understand as to why asking for a checklist with this few information is kinda pointless).

* Polish. Even as a developer you will always notice if somthing is missing, because it just feels wrong. Though it's not always the important stuff, you can get your atmosphere right by polishing your game.
* Is your game user-friendly? Can you abort your actions? Maybe even do some stuff via keyboard? Do your on settings?
* Overall feeling. Does your stuff fit together? Gameplay, atmosphere, etc.
* Help. Do you provide easy ways for the player to look up stuff, how something works, what he has to do (your current mission, objective, quest, pick something...). Can he see/read what exactly his skills/units/power ups do?

Though, as you may see in my list, it really is very genre and game specific.
> 21 votes

# Answer
I think my checklist would be:

* Is it fun?
> 9 votes

# Answer
I second testers. Serious testers. Log the bugs and missing features properly and handle them in priority order. Regression-test your resolved bugs so you don't re-break things.

Also, set yourself deadlines: sometimes you just need to stop. Set a date for feature-complete, then set a date for release. Don't be tempted to squeeze features in after you've gone feature-complete, no matter how amazing they will be. This is not a polish phase, it's for bug fixing.

And remember that last 20% normally takes 80% of the time.
> 6 votes

# Answer
As they say: in game development the remaining 10% is where 90% of the time is spent.

The closer you get to the end of the game the harder it is to make a checklist (and the longer it's going to be). The crucial part is taking a step back, look at your project, find everything you can right now which is absolutely essential to get the game out, and work only on that. Write down everything else as notes. Then get it done and get it out there.

You're making an Indie game (I suppose), so no one is going to expect it to be 100% perfect. The important bit is to get it out there. Then collect the feedback, and make updates.

I think the core of your problem may be that, like many other Indie/Hobby developers, you probably didn't do much planning ahead of time. Issues such as "Oh, we need a pause button" are a sure sign of it. If the obvious things have slipped your collective minds, you haven't done a real good round of sitting back and writing down all the things you need to get done. Use as many related games for reference as you can while doing so.
> 5 votes

# Answer
Some other "end-game" bits that people generally overlook: installer (use NSIS), error reporting/bug reporting, menus, dealing with low-quality networks (if it is a multiplayer game), cheating, game updates.
> 4 votes

# Answer
In terms of making sure your game is polished, checking out what other AAA games do is always a good idea - you can get a lot of checklist items just from observing one really well put together game.

In terms of making sure your game is solid and you're ready to ship on your target platform, there are certification checklists out there for each platform. Many of the console developers have to meet such a platform specific checklist; Sony has the Technical Requirements Checklist (TRC), Microsoft has the Technical Certification Requirements (TCR) and Nintendo have their own process. Unfortunately, not a lot of this console checklist information is public without becoming a registered developer, signing NDAs etc.

Here are the requirements to meet "Games for Windows" certification, which are public:

In fact there are tons more of these kinds of articles from MSFT. A lot of this is dry and probably a bit silly, but some it contains really good advice:

Microsoft also hosts a conference every year called Gamefest. The Gamefest presentations cover a LOT of certification issues, but sadly you need to be a registered developer with an xds account to access them:
> 1 votes

# Answer
You might want to start using bug/issue tracking software. This will help coordinate your efforts and give you a place to add tasks (e.g. "Add pause feature") as you think of them so that they aren't forgotten. If you identify an issue that you think is common to most games, add it to a list (maybe in a wiki) so you'll have a reference for next time.

Two (free!) examples of issue tracking software: Redmine and Trac.

Joel Spolsky has some helpful thoughts on this as well.
> 1 votes

---
Tags: planning
---


# Question
Title: How to implement SSAO in Shader Model 3/ DX9?
Ive read a few articles about SSAO, and i would like to implement it in to 3d engine at work, which runs on top of DX9. Can you give me an tips on getting the simplest implementation possible up and running using shader model 3, and how would you upgrade this implementation over time to tackle artefacts like haloing?

# Answer
Check out this simple fragment shader implementation with explanation on why's and how's http://www.coniserver.net/wiki/index.php/Screen\_Space\_Ambient\_Occlusion\_Shader Although it is fragment/GL and not D3d9, it's simple as it gets, so you should be able to understand what you need to do.
> 5 votes

# Answer
A talented programmer (Iq from from rgba) has written good articles:
> 6 votes

---
Tags: graphics, shadermodel3, directx9
---


title: What happened to COLLADA?

text:
# Question
Title: What happened to COLLADA?
A few years back it was looking like COLLADA was going to be quite a big thing, maybe at last a fairly standardized format for getting 3D assets from a DCC package into the tools pipeline of a game. And it looked like a good option for an indie developer that didn't want to lock themselves into a single 3D package by writing custom export plugins.

But I've not heard much about it recently. And Feeling Software, who had supported the format with their Max/Maya exporters and FCollada lib appear to have withdrawn any free versions of those tools.

Is COLLADA seeing much use these days? Are there any free/inexpensive libs/tools to assist in dealing with the format, or are people just reading the raw XML themselves?

Or is there a better option these days - say for an indie developer that wants to get models/animation from potentially Max, Maya, or Blender into their engine? - FBX? Something else?

# Answer
Concerning the tools, my experience is that the popular solution to access .dae files is collada-dom. It only parses the xml and give you access to the tree structure. Originally developped by Sony, it is now an open-source project (and the reference implementation).

Recently, opencollada seems to get some attention, but I've never used it. It comes with plugins for 3DS, Maya, Blender, and an SDK.

COLLADA Refinery is a tool to process `.dae` files (eg, triangulate surfaces).

Concerning its adoption, most mainstream creation tools (3DS, Maya, Houdini, Blender, Sketchup) support it by default. However, it is possible to have bad results when importing an exported model between different softwares. You also have to be careful with the various concurrent versions that exist in the wild (1.3, 1.4, 1.4.1).

FWIW, the official twitter account for COLLADA often makes announcement of tools and applications that got COLLADA support. This can give an idea of the support in the industry.

In my experience, it's a good-enough way to *exchange* data between systems. From a gamedev point of view, I don't think it's a good out-of-the-box solution. It depends on what you do, but at this point, an importer that process the file (or the DOM) for your engine is likely to be necessary. I've also witnessed really slow importers, so for a game engine, I would go with a COLLADA converter, rather than an importer.
> 5 votes

# Answer
COLLADA was over-complex in my opinion. Suffered from the designers trying to make it handle every conceivable combination of 3D asset; e.g. every possible vertex/index format and configuration.

Sounds great but in practice this placed a huge burden on any piece of software that needed to read the format.

It didn't help that every supposedly compatible tool had its own ideas about things like winding order, axis handedness etc. Trying to use it as an interchange format between DCCs plunged you into a world of miniature upside-down geometry, busted UVs, you name it.

What we need is a simple designed format that covers 90% of needs in a single, canonical way.
> 10 votes

# Answer
I think COLLADA would/could be much more useful if it actually had a standard and open implementation for reading and writing the format, in addition to the fairly scary XML definition.

Its power is also its failure - the ability to describe almost anything, and in a multitude of different ways, sounds great from the point of view of *exporting* but is a PITA to import and make sense of.

However if you persevere, you do get a format which represents pretty much anything you're likely to need, is supported by quite a few tools, and can be extended.

It's all too tempting to go with a simpler format, and then half-way through your development you'll realise you need some extra data, and there's no way of getting it.

Also, if this is for use in an internal production pipeline, rather than for general release, you can whittle down the definition and only support what actually comes out of the package(s) you're using, rather than trying to be overly general.

So yeah, it's flawed and complex, but it does work, and there aren't that many options out there.
> 2 votes

# Answer
I know this topic is flagged as 'solved', but IMO you should look into FBX. Autodesk is using that format, and it's the exchange format of all the major 3D programs.

So don't bother with Collada.

It's bloated, unintuitive - and not backed by the major players.

Which is Autodesk - they're are buying pretty much every 3D app out there.

Autodesk FBX SDK: http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7478532
> 2 votes

---
Tags: assets, tools, 3d-meshes, collada
---


title: Gaming glossary

text:
# Question
Title: Gaming glossary
On one question I saw users using the word "mobs" - I have never heard this term, and got me thinking - is there glossary of game and gamedev terms that anyone has come across?

ps. what are mobs?

# Answer
This holds a pretty nice list of what you are looking for: http://mmoterms.com/full-mmorpg-terms-glossary

There are still game specifics, etc...
> 1 votes

# Answer
A mob is a "**mob** ile" unit. It was popular at least in the DIKU and derivative MUD's, but may have been used elsewhere, too.
> 1 votes

# Answer
This is actually a fairly significant issue. A few years ago I was working on an MMO where most of the engineering had played one MMO, while most of design had played a different MMO. There wasn't a lot of people who had played both. As such there was a lot of terms that one group or the other assumed were rather common but were specific to that one game/genre. Without the common language and common dictionary talking about design is much harder as so many concepts can be shortened to a quick abbreviation. Anyone who has played an MMO with an aggression system will instantly know what you mean by 'taunt' even if the MMO doesn't use that as a term. If you come from a JRPG background though, the concept is fairly meaningless.
> 0 votes

---
Tags: glossary
---


# Question
Title: How do I calculate an inverse bind-pose matrix for COLLADA?
I want to port a rigged mesh from a custom format to COLLADA. The bones I have define a position for the bone (local) and a matrix that transforms the child-bones' positions into the next-higher coordinate space. (The position of the root usually is {0, 0, 0}.)

How can I convert these to the inverse bind-pose matrices used for COLLADA?

# Answer
> 4 votes
Concatenate (multiply together) your local transforms to get a world transform for each joint. Invert each world matrix.

---
Tags: 3d, mathematics, collada
---


title: Is there any level design copyright?

text:
# Question
Title: Is there any level design copyright?
I am planing to develop a game, in fact a puzzle game, I have changed the graphics but the level design is all the same. For example, the original puzzle game have five aliens as the obstacle in the human way to airship, the aliens spit fire on human. So here I have changed the alien to chameleon, with same positions(the aliens position never change so as the chameleon's ) and exact strike range(stick its tongue out to catch) and exact measurement(tile) and also converted the human to honey bee. So my doubt is that will there be any issue on this, for I am rendering the exact level design? ( I have searched, but didn't get a precise answer for my doubt)

# Answer
> 5 votes
First: **I AM NOT A LAWYER, THIS IS NOT LEGAL ADVICE.**

Second: I recommend checking out this question:

I think it is important to note here that 'They' can sue you for really whatever they want in terms of Copyright. Of course, you can get a frivolous case thrown out, but all they need is reasonable belief that you infringed upon their intellectual property to file suit at that point it becomes your legal department against theirs.

When you copyright something, you copyright the execution. Either way, it seems that you would be straddling nicely on the bounds of a lawsuit.

Of course, there is also the Copyright and Trademark office's new-ish stand on being able to copyright game mechanics. So like all legal questions, the best advice I can give is that you **GET A LAWYER**.

Oh and remember, even if the game mechanics can't be copyrighted, they may still be patented. Likewise, they could also have a design patent on how stages are set up.

Links:

# Answer
> 0 votes
You may possibly. I am not entirely sure, but to be completely safe it could be good to alter the positions as well.
Then there is no way there can be any legal doubts, since you're just developing a game similar. ;)

# Answer
> 0 votes
I don't think they can sue you over positions. They don't own those pixels and as long as you're not using any of their code/assets/names etc you are fine.

# Answer
> 0 votes
While the other answers support the idea that the legal issues are a bit vague and you're probably fine, there's another issue here. Ethically, this may be plagiarism. If you're doing this as an exercise to improve your skills, or replicating a game that is no longer available, it might be fine. But if you're making a game for general release for love or money, this is a bad idea.

The players who would like your game are likely to have played the original, and if they liked the original, they're probably going to think badly of you for having copied it. If they didn't like the original, they won't like your game anyway. It's far better, in my opinion, to expand on the original game with your own level designs and maybe some new gameplay elements. From an ethical perspective, it's also a better idea not to lift so directly from another person's work.

# Answer
> 0 votes
Any good answer would require discussing the precise nature of the existing work as well as your intended use. The three types of legal protection you should consider in the US are copyrights, patents, and trademarks. Trade secrets should not worry you unless you are truly a badguy and have stolen inside info, for instance by hiring away a former employee / consultant of your competitor and pumping them for it.

Game graphics, text, music, and the like are subject to copyright in most jurisdictions, including the US. Original computer code is always copyrighted, without any further action on the author's part. Affixing an original work to a medium is all it takes to create a copyright in the US -- registration is helpful for various purposes (such as to document a security interest for a loan, or to fix a date for litigation purposes) but not necessary. A game *design* may be patentable if it is sufficiently novel and non-obvious, but a game design or mechanic is not automatically self-protecting as such without a patent application. Very few computer game makers seek specific patents on individual game designs, although an increasing number of major companies are patenting generally useful game-related mechanisms (wiimote-related stuff; gesture controls; etc.). Interestingly enough, board games are quite frequently patented, and in fact it is easier to patent a board game design than it is a more free-form computer game. Trademark protection could apply to distinctive characters (Mario & Luigi) and the game's packaging itself (the look of the "box" or website delivery and advertising scheme).

You can avoid running afoul of copyright protection by making sure to, among other practices: *never* use code from another game without a license, and always vet your third-party / outsourced code with a plagiarism detector; always write your own music or license it officially; create your own art assets or license them; if you are including referential material, make sure it is clearly a satire/parody or otherwise fits within a legal exception. For patents, unless you know of a patent that reads into your area, you should probably use your instinct as to whether your game mechanic is ripping off another developer. For instance, just b/c Donkey Kong pioneered the platformer mechanic does not mean that all future platformers had to license the idea; it is safe to assume that game design involving jumping and dodging is not in fact patented or patentable. The reason that most people do not conduct an exhaustive search for infringed patents before building something is that there is a huge sea of patented material out there, and if you *knowingly* infringe on another's IP, you can be subject to a claim for treble damages, whereas if you unknowingly happen to infringe a patent that you were not aware existed, you are only liable for 1X damages and therefore a license negotiation will be much more favorable to you. Finally trademark -- avoid using art assets in the game, and external marketing / packaging, that is confusingly similar to your competitors'.

I see a lot of amateur legal advice in response to these kinds of questions in forums, and it is usually hit or miss. At the end of the day, if you are really concerned (and it sounds like perhaps you should be) you ought to discuss the specifics of your case with a knowledgeable lawyer. If you can change a few things so you are not so closely mimicking another game, then perhaps that will be easier and cheaper than hiring a lawyer to analyze a close call scenario.

Hope that was helpful.

Zeke Vermillion

---
Tags: legal
---


# Question
Title: How to prepare for a game development competition?
Ludum Dare 18 is coming up and I'll be participating in it. I've done a couple other short-term game competitions in the past but this is my first big one (and my first solo one). I am REALLY excited for it, but I'm wondering if there are any tricks to preparing for this sort of thing, and any advice on what to do while in the competition. So...

**How do you best prepare for, or participate in, a short-term game competition?**

Your answer can be specific to Ludum Dare but I'm really talking about any game competition, as long as it's **short-term** -- not the month-long ones where you casually develop your game and release it; I'm talking high-pressure, finish-in-time, pull-an-all-nighter type competitions. The Global Game Jam fits here as well, if you participated in that earlier this year.

Also any tips in the context of a group of people (each working on their own solo game) would be great; I will be with the game development club at my school for most of the 48 hours (only a few other people, not a huge group).

# Answer
As both a game jam organizer and participant, here are some tips from my experiences:

* Familiarize yourself with the tools you'll be using. You want to be using a development environment that you're already comfortable with; you don't want to be learning anything new on the fly if you don't absolutely have to.
* Corollary: if you're allowed to start with some pre-written code (libraries, game engines, etc.) - whether it be something you've made yourself, or from a third-party source - familiarize yourself with that as well so.
* Short-term contests require physical endurance, so don't neglect your physical side! Eat well, exercise regularly, get plenty of sleep, and in general make lifestyle choices that keep you as healthy as possible. In the short term (i.e. a couple days before the contest starts), make sure to catch up on your sleep so you're starting fresh.
* Know your limits. From your own experience, how long can you develop in a continuous stretch before you start to see diminishing returns on your time? How long and how frequently do you need to take breaks to maintain optimum performance? What's your sleep tradeoff curve (that is, if you stay up late developing, does that make you MORE productive for the extra time spent, or LESS productive because being tired slows you down)? If you don't know these things about yourself but you have time to "test" yourself in advance of the contest, do so.
* Prepare all the mundane stuff in advance. If you're participating from home, make sure you've got pre-made meals, snacks and drinks ready to go, and have shortcuts and bookmarks right on your desktop for everything you think you'll need that you want easy access to. If you have any favorite reference textbooks, pile them next to your computer. Think of other tools you might want: pencils/pens, graph and standard paper, maybe some dice and index cards and such for physical prototypes, etc. If you're going somewhere outside your home (as with a typical "Game Jam" event), pack a bag in advance with everything you want to take with you, and have that ready so you're not waking up early or scrambling at the last minute.
* As a longer-term strategy, build your development skills; there is absolutely no way that being a stronger developer can hurt you. There's also nothing stopping you from doing your own "private game jam", challenging yourself to make a game in a week (or a weekend) as your personal schedule permits. The more of these kinds of projects that you do, the better you get at them.
> 15 votes

# Answer
I've done Ludum Dare twice, my first attempt failed pretty miserably, but on my second go (LD17) I did fairly well, and made 7th place overall.

Just some random bullets (specific to LD mainly, but probably applicable elsewhere):

* **Sleep**: This is *very* important, LD16 was my first 48 hour compo and I tried to go too long without sleeping and wound up taking a 10 hour "nap" through the deadline... For LD17 I slept both nights for 6-7 hours and it all went a lot smoother. I worked for less total time, but not being half asleep the whole time definitely helped.
* **Changing Plans**: Last LD I completely changed my idea about 10 hours in, scrapped most of the work from that time and moved in a different direction. It seemed totally hopeless since my initial plan was just not fun; but I came up with another idea, slept on it and it eventually all came together. So don't be afraid to change directions if your initial approach isn't going anywhere.
* **Timelapse**: This seems irrelevant, but being able to play back the 48 hours as a timelapse really helps you get a feel for where you spent too much/too little time. I also found that recording the timelapse was sort of an incentive to keep working and not slack off as much...
* **Community/IRC**: A big part of Ludum Dare is the community, it's a lot more fun if you participate in the whole process; make timelapses, take food/workspace photos, hang around in IRC and most importantly, vote and leave feedback for everyone.
* **Middleware/framework/whatever**: Some people prefer to truly start from *scratch*, but the rules do allow openly available middleware and custom-made middleware (as long as you release it open source prior to the compo). Given the number of gamemaker and Unity entries, I don't feel so bad about writing a quick framework using a few bits of middleware (I used Ogre and Bullet last time) the week before.
* **Audio**: I personally have very little experience with audio stuff, so this has been a tough one for me, but a little bit of audio goes a long way. Last time I did manage to have a simple bit of (very repetitive) music (made with LMMS) and sound effects generated with sfxr.
* **Post Compo Version**: I'd encourage you to keep working on your entry after the competition; I added online leaderboards and a few tweaks to my entry from last LD as sort of an afterthought, released it on moddb and it's been surprisingly successful (the leaderboard has over half a million ~20-25 second 'runs' recorded and apparently there's going to be a small article about it in a French games magazine).

That's all I can think of for now, Good Luck!
> 7 votes

# Answer
I competed in a game jam last year and just making decisions before the competition really made things go smoother. For example, you don't want to be deciding on an engine when you should be coding.

Build/collect everything you can ahead of time. In the game jam I participated in, we were lucky enough to have some art assets provided, but we failed to get everything we needed so we wasted some time looking through the libraries for certain assets we needed. We also ended up doing most of the sound on site, which we could have handled before the event.

Try to anticipate some of the coding challenges you will run into. We were building a basic shooter game and one of the biggest challenges was trying to get the enemies to move toward a moving player in a realistic way. This was a challenge we could have predicted if we spent more time discussing before the event.

Finally, if this is a team competition, make sure to go over these ideas with your team members. You don't want to show up with many different ideas and spend time debating which to implement.
> 2 votes

# Answer
Get your system down. Right now, get all the tools you may be using during the competition, and put yourself through a pre-competition dry run. You don't have to make a complete game, but see that you are familiar with getting things together (this includes every aspect, gameplay, art, music, etc.). This is the only "trick" you need. If you have a workflow up and running before the competition, then your prize is the ability to concentrate on the actual content of the game while the clock is ticking.

You can also publish this pre-compo game/experiment as a warmup ... the LD community likes it, and you might get feedback before the competition begins!

For something like Ludum Dare, there is nothing you can do content-wise beforehand, and the actual gameplay will probably be different from what you practiced ahead of time. But if you know you will use the XYZ platform, and it will be a 2D sprite-based game (for instance), then being able to get to the content/gameplay part as quickly as possible is crucial.

I learned this the hard way. LD16 was spent trying to get things working. LD17 was spent enriching the world.

I look forward to seeing what you come up with. Good luck!!
> 2 votes

---
Tags: competition
---


title: Connect 4 Iphone game

text:
# Question
Title: Connect 4 Iphone game
I'm new to game development and development in general, I want to make a Connect 4 game. I have made a few simple game tutorials and I decided I wanted to make my own game now. I figured a connect 4 game should be a simple start for me, can anyone help me out how to go about with this please?

Should I use Cocos2d or write it in ObjC?

Thanks David H.

# Answer
Cocos2d is written in Obj-C, maybe you meant UIKit. Either way is ok for a simple connect-4 game. After working more than a year with cocos2d i can say you will be better off doing the game with it.
> 3 votes

# Answer
cocos2d-iphone is a great way into game programming without learning the lower level aspects of game programming. I would recommend trying it out first.

cocos2d-iphone has many examples that come with it, which can give you a great head start.

The question is a bit confusing since cocos2d-iphone is written in Objective C :)
> 1 votes

---
Tags: iphone, objective-c, cocos2d
---


title: Open Dynamics Engine

text:
# Question
Title: Open Dynamics Engine
Has anybody used this library before? What were your experiences? Pros/Cons?

# Answer
Here is a great, high-quality blog post about the reason for Wolfire's switch from ODE to Bullet:

http://blog.wolfire.com/2010/03/Comparing-ODE-and-Bullet

The biggest paragraph is most likely this one:

> When I tried dropping four hundred boxes on the Overgrowth "desert fort" scene, Bullet performed the simulation twice as fast as ODE did, even without Bullet's optional performance features like multi-threading and OpenCL. One of the factors in its speed is its use of Sony's newly open-sourced SIMD vector math library, which you can find here if you'd like to use it separately.
> 3 votes

# Answer
I've personally never used it, but I think this article gives a good idea of pros/cons: http://blog.wolfire.com/2010/03/Comparing-ODE-and-Bullet

To summarize the article, it looks like ODE is well documented and stable, but doesn't quite have the cutting edge features and efficiency that some of the more actively developed but less documented alternatives have.

(I have used Bullet and I can vouch for it being a rather nice piece of middleware, though as the article suggests, the documentation is a bit iffy).
> 2 votes

# Answer
Bullet didn't exist the last time I used ODE (via PyODE, which I will say is a very nice API wrapper) so I can't comment on that. The biggest issue I had with it was stability. It tends to be a very jittery simulation if you don't tune it juuuust right (which takes a lot of poorly documented voodoo). If you use big units that isn't such a big deal, but I made the mistake of using smaller numbers. The joints system is very flexible once you start to think of your system in ODE terms. Also a decent annoyance, it uses a bitfield for collision groups, so you can only have 32 of them.
> 2 votes

# Answer
Bullet is derived from ODE. When I first saw ODE, it was a bit too poor, in my perception, after playing a bit with Havok and PhysX. The only reason why I was searching for alternatives was that I needed 64 bit double precision float, for a real-size space multiplayer game. Bullet on the other hand had more coming from the box. It has a great community, and lots of developers working on plugins like something to manage concave shapes (they had 2 alternatives - approximation to convex compound objects and simulation of the original trimesh), CCD implementation, model import, etc. It also had wrappers for some of the 3D engines (don't remember exactly which, might be Ogre3D and XNA). It was very much ahead of ODE, and OpenSource.

This was 2 years ago though, much may have changed. But right then, in the same simulations, nVidia PhysX showed much better performance, and was richer in functionality. So if you plan on using 32 bit single precision float, I'm not sure whether you'll find anything better than PhysX.
> 1 votes

---
Tags: physics
---


# Question
Title: How do you get useful data from playtesters?
There are a few types of feedback you can get from playtesters, and I wonder how to best gather data for each of them...

1. Crash Reports. When my C++ game crashes while someone is playing it, how do I best make sure that I know about it and even better... what caused it? Even getting something as simple as the file and line number which caused a crash would be incredibly helpful.
2. Design Feedback. When a play tester is playing the game, how can I figure out if they are having fun, why they are having fun, why they aren't having fun, and what we should spend time adjusting?

# Answer
I'm assuming you're talking about on-site playtesters and not internet beta testers.

Rule #1: **Don't help them**. Frustration should be the top thing you should be checking for. The ideal situation would be a two way mirror with your team on one side and the playtester on another with one video camera on their face and another on the screen. Obviously this isn't feasible for most people, so do the best you can. Just having your designers sit and watch where people get stuck is very useful information. You're not going to be standing over their shoulder when they take the game home, so you giving advice on how to pass certain sections isn't going to give you the information you need. *Edit*: another way of putting it is this: **Don't think they're "Playing it wrong"**

Rule #2: **Don't give them what they want**. After a playtest session you have some kind of questionnaire that they fill out. The specific suggestions they have are usually not wise to take at face value. Usually there's some root cause that is triggering most responses and they just don't know how to express it. If you can figure that out, you'll be better off doing it. Although at the moment I'm having trouble coming up with specific examples.

Rule #3: **Data is king**. If you can (and this is really another wishlist item, honestly), track everything you can. Track where players die. Track where they run out of ammo from a specific gun. Track what pickups they miss. Track what upgrades they buy. Track what enemies do damage to them. Obviously these are FPS-specific examples, but I'm sure there are domain specific ones for whatever game you're doing. If everybody's doing something or not doing something, those are usually areas that you should spend a little more time looking at.

Basically, you don't care what player's *think*. You care about getting raw numbers for what players *do*. You need virgin eyes to see your game and tell you what makes them frustrated and what they're being led to do.

---

For crashes, investigate minidumps. They're not perfect, but are a very useful tool to figure out where crashes are.

Also consider a built-in bug reporting tool. Something where the user can take a screenshot , add a description, and email it to someone automatically from inside the game. Ideally with a snapshot of the world (i.e. quicksave or some kind of memory dump) if your game supports it.
> 31 votes

# Answer
To expand on the **data is king** sentiment a bit (+1 to Tetrad!):

Investigate **recording and playback**:

* If your game is deterministic and frame-based you may only need to store an initial random seed and a tuple of `(key/button state, joystick/mouse coords, frame #)` any time the input state changes. Playback is as simple as redirecting your input to this stream. (We've done this for many platform-jumping games in the past.)
* If your game has well-defined APIs or message systems for performing actions (a turn-based strategy game, a card game, a board game, or the like) you might be able to just harvest API calls or messages at a certain pinch point. (We did this for a card game for a handheld platform.)
* It's harder on some systems (less deterministic, threaded, or arbitrary timestep systems can be a pain) but it may be worth recording the data anyway; you can get "close enough" results for some uses.

A "replay" system based on these methods has a bunch of advantages:

* use it to reproduce crashes in a debug or otherwise instrumented build or environment;
* load replays under a profiling build and get performance or resource usage data;
* wire it into the game to provide "instant replay" functionality, maybe with a different camera or time step;
* set up an "attract mode" demoing gameplay if the user is sticking around doing nothing on a menu;
* put it on your build system as a smoke test: if I can play through this replay without crashing, it's more likely a good build;
* watch examples of people playing to see what they did and didn't do.

**Wire in random input** rather than a recorded stream, and you've got a great *monkey test* that you can leave soaking overnight or whenever your development machines are idle.

Next, do some **event recording**. For a hypothetical FPS, start with something like "time T: X killed Y at point Z with weapon W": put it in a log.

Once you have some data being collected, figure out how to **automate collection**. It doesn't have to be elegant during development:

* connect to an SQL server and insert rows,
* fire and forget UDP packets at some simple syslog-ish server,
* e-mail the log the next time the game boots,
* just wrap the executable in a shell script or batch file that renames and copies a .log file to a common shared drive,
* (later, for production builds) use Windows Error Reporting or a similar service to collect crash data...

Doesn't really matter, as long as you can gather data.

Now extend it: gather crash dumps, stack traces, and input or event recordings. Add more events, and more data sources:

* sample the player position or hand every 10 seconds, plot it on a map -- "hey, no-one's using this corner that I spent a week modeling, time to put a powerup there"
* `getFreeMemoryBytes()` every half-minute
* `getFPS()` periodically
* take a photo or a video of what the user is doing via a webcam (great for automated usability testing -- only with user permission and understanding, of course)
* grab system info (again, with user permission)

The "plot it on a map" thing can get really awesome after a while: envision an aerial view of an RTS or FPS map. Put a slider on it, representing time since start of game. Select an event type ("got gold", "killed someone", whatever). Select a data set: maybe one game, maybe 500 games over the last few months. Start pulling the slider to the right and watch the activity pop onto the map.

And if you can't find good libs to help you with this stuff (there are quite a few here and there, though!), consider rolling your own: it's a good learning experience, and it doesn't need to be particularly elegant to be useful.

Get the data, you'll figure out what to do with it. =)
> 13 votes

# Answer
Ofcourse this depends a lot on... a) what kind of testing you want to have done, and b) what kind of game you are testing, and c) what kind of testers and infrastructure you have available...

It also differs a lot if you are testing for a) functionality, b) balancing c) game-design

But in general you might want to consider these aspects...

**\*a) Choose the right person for the job** Sounds too simple to mention, but i've seen it many times and just have seen it live again. As always, there are significant differences between people in regard to how good they are at different jobs. Some people who are willing or maybe eager to do testing might not be playing thorough enough to find unusual (or even simple) bugs. Some are not good at describing the bugs. Some are better at testing balancing issues, some are more attentive to visual weaknesses, some are more creative in playing the game in unusual ways and finde hidden/rare bugs, some are more attentive to technical or visual quality, some are better in understanding aspects of the game mechanic and may be even able to suggest meaningful changes (if you want your testers to do that ;).

**\*b) Use an Issue-Tracker / Bug-Tracker Software** These tools can not only help in organizing your issues but also in increasing the quality of the output of your testers by giving them a frame to work within and by learning from feedback they get from developers about their issues. It helps to improve the quality of the output of your testers a lot faster than if you work without it. (It also helps a lot with remote testers) Typical software used by game studios is i.e. Mantis, JIRA, (and ofcourse lots of others..) See Wikipedia for a general list and also this post on SO.

**c) Add ingame testing tools** Typical are Shortcuts to test specific levels or sections of the game. Displaying extra information during the game to the testers so that they can add this to bugreports. This could be the position in a level, the number of active objects in a scene, the amount of texture-ram or palettes currently in use, anything helpful to the developers.

**d) Combine experienced testers with fresh blood** Always a good thing to have testers who are very experienced with your game and have learned what the typical problems are and how to (re)-test them. At the same time you want new "virgin" players once in a while, especially for balancing.

**e) Have a Test Manager** Someone who coordinates the process and tailors it to the game at hand, the current priorities and the available testers and testing environment.

**f) Have a Testplan Document** This would be worth an extra post.
> 5 votes

# Answer
As Tetrad mentioned, get as much objective data as you can. Putting in hooks to store certain events and dump those all to a .csv isn't very hard. And once you've got it in Excel, you can study, graph and plot until the cows come home.

Also, have specific questions you're looking to answer. Scientists don't just sit down, fire up some experiments and "do science." They have specific, measurable questions they want data about. You'll often get the most out of playtesting if you take the same approach. Trying to figure if your game is "good" is very hard to quantify. But figuring out if the simple tutorial mission is only taking the 5 minutes you expect, or if the testers are struggling to solve a certain puzzle, can actually be evaluated.

Sometimes, the most effective way to test is iteratively in short bursts. Have a couple of testers go for an hour or so in the morning, make some changes to the issues they identify and go again with new testers the following morning. Obviously you have to be looking at a feature small enough to improve in an afternoon. But for a problem that's been particularly stubborn, this method can be very successful.
> 3 votes

# Answer
Definitely Agree with Tetrad's Rule #1. Do not help them. I would say a caveat is to explain to them that you will not be helping them, and if they need help to please ask. This way the player doesn't end up being frustrated.

The Questionnaire should ask open ended questions, instead of ones that are simple yes/no, depending on the age and number of testers these can be forms they fill out, or you can ask the questions. Its also important to ask questions about their history and their familiarity with the genre of game you are having them test; this will add context to their specific answers about your game.

Fortunately when my game crashes it gives me a dump of information regarding the error, so I can take a picture of that and make a note of what the player was doing. Normally I test younger age groups so when we get a crash I have to remember to explain to them that they are doing a great job -- they can get upset after breaking the game. Playtesters have really proven to be great at finding obscure bugs that the dev team would never come across playing the game the "right" way.
> 3 votes

# Answer
It's possible to write code that catches crashes and logs the call stack. That can help a lot with bug reports. Having a useful log file generated helps too. You can prompt the user to send these files the next time they play, or have a standalone tool that runs after the game is closed or crashes if you like.
> 2 votes

# Answer
For crash reports, you should be relying on paid QA staff, not playtesters. QA is someone you hire specifically for their ability to find bugs and report them in a meaningful way, and a good tester is worth their weight in gold (and costs only a tenth of their weight in gold, compared to programmers!).

If you're worried about "oh, what if they accidentally discover a crash, we wouldn't want to miss out just because they're not testing for that"... this is what logging is for. A sufficiently good logging system should be recording enough elements of play to be able to reproduce a crash exactly.

For design feedback, there's no substitute for having your game designers actually watch them play (or use a video recorder if you must, etc.). Don't rely on playtester memory or opinion, both of which are notoriously poor. But if you're watching them play in real time, it is patently obvious just by looking at their face and body posture whether they're engaged, bored, or frustrated.
> 1 votes

---
Tags: debugging, playtesting
---


# Question
Title: Should independent game developers outsource?
Simple question: What are the pros and cons, as well as overall opinions, of outsourcing work as an independent game developer? (For example: paying an artist to draw characters, or a composer to write music, etc.)

In particular I'm interested in the case where the developer (be it an individual or a team) can still complete their game to an acceptable standard without hiring somebody. (For example: maybe they're "ok" artists, or can use music from a free library.)

(Ideally I'm looking for answers from people with experience in this area.)

# Answer
> 8 votes
I've sometimes worked with composers and sometimes used free music or created my own ambiences. I usually do my own art, but I'm starting to work with an artist for one of my upcoming projects.

I've had very good experiences with the composers; I offer a percentage of the sponsorship amount (I make Flash games), payable on publication. For the most part, this has been great, although one project has taken so long to develop that I offered the composer a (non-refundable) advance, since he'd done quite a bit of work and I didn't (still don't) know when the game would be finished.

Working with composers is great when you need a specific esoteric feel to the music. For Exploit, my cyberpunk puzzle game, I wanted a certain kind of music that was difficult/impossible to find from free sources. My composer, Evan Merz, was able to put together some amazing pieces. On the other hand, my artsy reading game Silent Conversation needed experimental classical music, and I was easily able to find some with an acceptable license on Jamendo. Likewise, my atmospheric adventure Looming needed creepy windy ambience with unexplained voices, and I was able to record that myself using Audacity.

As for art, I'm usually able to put stuff together myself: usually pixel art. However, I find that my own art gets mixed responses; I've got an amateur art background, but not enough that I consider myself on par with a lot of the work out there, even in Flash games. My upcoming game is going to be bigger and more mainstream than most of my previous work, so I'm trying to work with an artist to get art that's higher-quality and more likely to appeal to broader audiences.

I've found that it's an issue of quality, much more so than time savings.

In short...

**Outsourcing**: You get exactly what you want, but you have to pay for it and run a slight risk that the person you're working with will flake (I haven't had any trouble).

**Do-it-yourself**: It's cheaper and often quicker, but it's harder to find the perfect asset from free sources and programmer/amateur art has a higher risk of turning some players off.

# Answer
> 5 votes
From my own observations, working with outsourcing is fraught with problems.

A good outsourcing team or individual can be a godsend, taking pressure off the core team and getting extra custom content into the game that would otherwise have had to compete for project resources with other key areas.

However there can be many problems with getting to this point. Communication is the key difficulty, in all senses of the word.

Physically, your outsource partner will not be working in the same building as your team. On a practical day to day basis, this makes is harder to check on progress and keep an up to date impression of how the project is proceeding. It also makes it harder to convey to the outsourcer the underlying philosophies of the game, your design principles and the nuances of your design which influence what you want. They will also likely be unfamiliar with your working practices and your pipeline for content, possibly providing you with assets in a format that requires conversion work on your side to get into the game.

Culturally, your outsource partner may be in a different country and speak a different primary language. This exacerbates the problems mentioned in the first point. Neither are dealbreakers in any general way, and it may well be that an indie team works in a distributed and collaborative fashion anyway, but both points make it harder for everyone on the team to be on the same page and to all be working towards the same goals.

Managerially, if you have an outsourcer, you have to make sure they are managed effectively. They may well have many projects they are working on simultaneously, and not being on your "staff" you have no direct control over how quickly, or to what quality they do their work. Someone on the team will need to make time to liaise with the outsourcer on a regular basis to review progress, to discuss problems and proposed changes. One of the more difficult aspects will be signing off on a particular resource. As a separate entity, your team may have very different expectation in terms of quality from your partner. Remember that polish and final tweaks can take up a disproportionate amount of time. I have seen examples where outsource work that was submitted required extensive "touch up" work to ensure that it felt consistent with internally produced assets in game. Overall the quality was not bad, but it was different enough to be noticeable, and in the end as much effort was put into correcting this as would probably have been taken to generate the content from scratch.

Obviously, most of these points boil down to recognising the difficulties of working with someone outside your team, and ensuring good management and the agreement of appropriate specifications and goals before work begins.

Indie development is generally very content bound, small teams are usually unable to produce the quantity of content as a larger traditional team (depending of course on the type and style of game). Outsourcing, while potentially expensive and coming with potential management headaches, can provide a way to help overcome this to some extent, producing extra high quality assets for your game.

---
Tags: productivity, outsourcing
---


# Question
Title: Updating OpenGL ES 1.1 based iPhone game to use Open GL ES 2.0
I'm fairly new to anything OpenGL in general. I've made an OpenGL ES 1.1 based 2D iPhone game by working from sample code. I'm under the impression that OpenGL ES 2.0 is substantially different from 1.1. So what does updating 1.1 code to 2.0 entail?

I'm accustomed to the kinda basic drawing pattern of "push matrix, translate, rotate, draw 2D texture, pop matrix". What's the "equivalent" in 2.0?

# Answer
OpenGL ES 2.0 is *very* different from ES 1.1. You don't have a fixed-function pipeline anymore, so your familiar "push matrix, translate, rotate", etc are all gone.

Instead, you have the concept of shaders: vertex and fragment. They're little programs that get executed for each vertex and each pixel. That's where all the transformation and other effects happen. Your code will prepare the vertex data, tell OpenGL how it's structured, and hand it over to the shaders.

But not all is lost: Some parts of OpenGL haven't changed, like setting different states (blending modes, depth comparisons) or creating textures.

To use OpenGL ES 2.0 effectively you need to master the basics of 3D computer graphics, so get a good intro book and learn the principles. Then you can move on to OpenGL ES 2.0 and start writing shaders. This is a good OpenGL ES 2.0 book.

Finally, don't assume you *have* to move to OpenGL ES 2.0. Unless there's something specific you need that you can't do in ES 1.1, you can continue using ES 1.1 because newer devices are all backwards compatible.
> 9 votes

# Answer
I have ported my 3D Engine from OpenGL ES 1.X to OpenGL ES 2.X because i love shaders. The renderers are distincts and don't share any code.

You can translate easily:

* textures management
* framebuffer objects
* blending

More difficult (Need shaders):

* fixed pipeline transformations (rotation, scale ...)
* fog
* lighting

To port your code, i recommand you:

**Step One**

* learn GLSL 1.2: you can read WebGL tutorials
* try to write some shaders shader toy

**Step Two**

* list all material you have (or rendering technics)
* list all vertices informations as vertices coordinates, normal, textures coord, color informations you need for each material

With theses informations, you will know which GLSL Programs (vertex + fragment shaders) you must write.

**Step Three**

* write your shader compil functions and log each informations
* implement a minimal program OpenGL ES 2.X with a quad (two triangles)
* implement and test your GLSL programs one by one

**Step Four: Optimize**
> 7 votes

# Answer
OpenGL ES 2.0 **is not** a new revision of OpenGL ES 1.1. Or in other words, OpenGL ES 2.0 is not a better OpenGL ES 1.1.
*Well no duh, they changed everything.*

The import of that simple statement is easy to overlook. Consider:
OpenGl 2.0 **is** a new revision of OpenGL 1.5. OpenGL 2.0 **is** a better OpenGL 1.5.

This means If you're using OpenGl 1.5 and want to maintain forward compatibility you should move to 2.0.

The same is not true of OpenGL ES. 1.1 was not superseded by 2.0. They are different standards. The confusion might have been eliminated if they had been named:

* OpenGL ES fixed
* OpenGL ES shader

NOTE: technically this isn't perfectly true. The reason being, you could implement the 1.0 series with the 2.0 series. You'd just have to set the fixed pipeline functions as shaders.
> 3 votes

# Answer
As an aside to the other answers here, I recently found gles2-bc, a C++ library 'which makes the non-backward compatible OpenGL ES 2.0 API backward compatible'.

There are some known limitations and I haven't used it myself, but thought I'd post the link for reference.

http://code.google.com/p/gles2-bc/
> 2 votes

---
Tags: iphone, opengl-es
---


# Question
Title: How to demo Advanced Game AI as a portfolio piece?
Basically every Game company wants to see a portfolio that exhibits your skill set. If you're specializing in **AI** though, what and how should you show off your skills.

**Some thoughts**

* Is nice graphics in an AI demo a must(get past nontechnical HR that don't understand AI, think 3d verse 2d)?
* Demo multi-featured AI or a single focused example.
* Fundamental skills like path-finding, hfsm, planning, etc are critical AI components but does it really impress as a portfolio piece?
* Single AI entity, multiple entities, or large populations, is more always better?
* Also as a portfolio piece ideally there would be an executable, and videos which should show off whatever is trying to be shown off within only a few minutes.

**Examples**

I would say any of the skills exhibited in this video would make for a great portfolio piece but are game companies really expecting this from a single person.

AI Sandbox is another great example but this was made from the work of many many people.

Any examples of good AI portfolios would be great.

# Answer
At my school we have some masters students studying AI, and they do so using the Unreal engine. They pair up with an art student who makes some 3D models (they certainly don't have to be fancy) and then they work their AI magic in UnrealScript and the Unreal editor, and end up with something functional which can be studied and played with. This is the end goal of AI, after all: an actual game or prototype which demonstrates the AI concepts. Because anything less is just a concept, not a demonstration.

I would imagine you could substitute any engine for Unreal; Unity of course is very popular, and Valve's Source engine is also doing some great AI things. I think the end result is that you need to use all the middleware you can, so that you can get past the foundation and quickly get to actually testing AI concepts.

Many of your questions are very much case-by-case basis. You may want multiple examples of one AI concept each, or you may want one big AI sandbox world with all sorts of AIs running around interacting. It really depends on what exactly you're doing or showing.

> Also as a portfolio piece ideally there would be an executable, and videos which should show off whatever is trying to be shown off within only a few minutes.

This isn't a question, so: yes! Also I'd recommend getting a personal website so that you can hopefully direct them to it, or even show it to them in an interview if there is a computer in the room. Make sure the website is as standard as possible; use HTML5 video and Flash (whichever one the browser is compatible with), and have screenshots in case the computer is so locked down that none of these are available. Also if you have a portable video-playing device (iPod, phone, etc.) load up videos of your portfolio and bring that! There might be nothing more impressive in an interview without a computer, than pulling out your *insert device here* and actually showing the interviewer your work.

Also, one final note: there is a big difference between pretty and polished. It doesn't have to have stellar graphics; but the graphics that are there should at least look finished, not placeholders, no glitches or bugs, etc. Just because it doesn't need to be fine art, doesn't mean it shouldn't look like a finished prototype ready to present.
> 7 votes

# Answer
To answer your specific questions:

1. **Graphics are totally unimportant**. So long as people understand the difference between say actors and static world objects you'll be fine. The demo's will be critiqued by the programming team and they know what is important from an AI programmer.
2. Multi-featured vs single focussed is a tough one, see my general rules below
3. **Fundamental skills - These are a must**. Don't go to advanced and forget to show off your basic understanding of core AI behaviours. Unfortunately, for many companies AI is still low on their priority list. At least initially they will be looking for someone with core knowledge that can get the AI to a basic level
4. **Definitely have multiple AI entities/actors**.
5. **Executable is preferable** as it shows the behaviours as well as the fact you can do it in a real-time environment. Videos are good for showcasing specific AI behaviours and adding annotations to explicitly state what is happening.

Some general rules:

My biggest suggestion is **visualisation**. While pretty graphics are not important, visualisations of the actors is crucial. Turn on every piece of debugging you can and leave it on for your demos. What you want to do is show all the behaviours/decisions/data the AI is using to the viewer. This can be simple things like showing the current state next to each actor (eg idle), the "field of view cone", current path, etc. Without this, the viewer may have no idea how advanced you AI is.

As for exactly what to show, this depends entirely on what company you want to work for. My suggestion is to pick your favourite company (or top 3) and look at the AI in their games currently. Tailor your examples to fit with the style of these games (eg FPS vs RTS). Also, look at the technology they are using. If you're applying at a company that uses unreal, you're in a much better position if you use unreal to show off your demo. It shows you have both knowledge of AI and implementing it in their current tech.
> 8 votes

# Answer
As a 16 year veteran in the industry, in my opinion you *shouldn't* need to make it look pretty in order to demonstrate good AI skills. On the other hand I think you *should* it make pretty because:

1. Presentation is very important in the game industry, and it is a way to make it clear that you "made an effort", even if you spent many more hours on the underlying technology.
2. Your demo may get seen by a hiring manager, HR person or programmer that doesn't know anything about AI

If you get someone else to make it look pretty for you all the better, because it shows that you care about making a good impression, but also that you can find people to help you, and co-operate with people. Very important skills on the job.

Regarding using an API like Unreal or Kynapse; I think it's much more valuable to show that you can build an AI engine up from nothing. Demonstrating enthusiasm and problem solving. Once you're on the job you can spend a few days reading an API and documentation, but a deeper understanding of what lies beneath the API is a far more valuable asset.

Hope this helps and good luck!
> 6 votes

# Answer
As much as I love to say that graphics don't matter, it's just not true. Not matter how amazing your AI is, the presentation is what's consumed by your viewers. As things being equal the prettier presentation will win out.

That's not to say that you have to present an amazingly detailed piece, just one that looks clean and finished.

You'll also want to pay attention to the erratic movement of your graphical models; even if your path target changes 180°, you'll want that change to happen gradually on screen in order to make the movement look natural.

I'd suggest pairing with a good artist, and make sure to represent that fact if asked during your presentation. The artist may also want a video of your demo to show potential employers what their art looks like being used "in-game".
> 3 votes

# Answer
Anywhere that is letting non-technical human resource people judge technical demos sent by candidates is not somewhere that you want to work.
> 2 votes

# Answer
* Since you're basically showing off agent behaviour and nothing else, the answer is no. If you can, try to use simple textures (perhaps none at all) and simple models consisting of plain joints and limbs.
* That depends on your taste, I personally prefer starting off simple and adding new agents to show off more features as the demo progresses, building up complexity and various emergent behaviours.
* Not really, most will take that for granted and look for something beyond this, mention it but don't focus on it. The main interest here is your potential optimizations to the already established algorithms and/or novel approaches to those problems.
* See 2.
* I agree, providing both is a plus. (some people like to experiment with demo executables for themselves, if they feel sufficiently interested)
> 1 votes

# Answer
With the way money is with many companies I'm sure you will get pulled into a number of different things and not just AI - for this reason I would say you should show good overall skills as well.

Consider the scenario where two amazing people demo their work; they both show the same AI, have the same qualifications/experience and are very similar in every way - but one uses triangles for actors and boxes for static and the other shows his demo with models loaded from file. I personally would hire the one who (a) took more effort (b) shows that they can do work outside their comfort zone/speciality.

As someone else mentioned for your speciality you shouldnt need to show good graphics but I dont think it would hurt either.
> 1 votes

# Answer
Yes it should look pretty (or not ugly), but don't underestimate siplifying graphics. A 2D city with 2D blobs moving around is fine, if you're demonstrating collision avoidance.
> 0 votes

---
Tags: ai, portfolio, demo
---


# Question
Title: How were 8-bit and 16-bit games developed?
We have a lot of information on the internet out there on plenty of engines, SDKs, fancy IDEs, etc. But how did people manage to develop games in the past? Are there 'famous' tools? What was the most used programming language? how were they deployed into cartridges?

# Answer
Assembly and C were the languages often. For example: RollerCoaster Tycoon was written by 1 guy in assembly.

You can look at this Nes Dev site that goes into the development of homebrew NES games. I even found this Source Code for an old SNES game
> 25 votes

# Answer
On both 8-bit and 16-bit platforms I'd generally use a combination of a macro-assembler to compile my code (always assembly!), and some kind of monitor cartidge to debug it.

Those cartridges were awesome development tools.

For the first game I wrote (on the c64), I first wrote my own macro-assembler using the monitor cart. I had smooth 60hz scrolling in the text editor(!)

On the Amiga the assembler of choice for me was DevPac.

The more professional folks (who had money!) had cross-development set-ups where you'd hook the target machine up to a PC and use that to dump code across to it.

For graphics I started off drawing stuff on graph paper, and later wrote my own character and sprite editors. Obviously on Amiga it was DPaint all the way.
> 15 votes

# Answer
As for the famous tools question, DPaint (aka Deluxe Paint) fits the bill on the art side.
> 8 votes

# Answer
3 words: **Serial Port Debugger**. I feel unclean even thinking about it.
> 4 votes

# Answer
If you have an iDevice, take a look at the apps "2600 Magic" (1Up article discussing it) and "Dragster Magic", both by David Crane. They are a fun peek into Atari 2600 programming.
> 4 votes

# Answer
Edge ran a story on how Gauntlet was made. All the art was drawn on graph paper and manually programmed in!
> 2 votes

# Answer
With great difficulty...
> -2 votes

---
Tags: game-industry
---


# Question
Title: Compile time error handling for single programmer games?
Hey.
My input system has a GetKey() method that returns a key in a map. Simple enough.
However, I want to know if the key is not available - be it a typo, or misuse of wording, or something else.
I am the only person working on this project; would it be a good idea to simply set some compile time throw to see if it catches one? Is this even possible?
What I'm meaning is:
`if(entry is not found) { throw something("couldn't find key"); exit(); }`
Rather than an approach of
`if(entry is not found) { try and compensate somehow and continue }` And then go through the code and find where I've made a mistake. Of course, for a large project I would want real error handling like the second. But I can just get rid of these errors, since there's no modding. But I'm the only one working, so is this probably the easiest way to do it?
Well, it's this or make some kind of BLANK key and check it every query.
EDIT: I am using strings as my keys, so no translate functions would be easy.
Double EDIT: I bind commands (strings) to keys (wrapper over an enum value). It means it's more understandable to check if "move\_left" has been pressed than if keyCode::A has been, as well as being more changeable.

# Answer
When debugging, it's great to throw an exception. When the user has the program and encounters something that you missed, it's not; you might want to silently log the error, or ignore the call and just return from the function, but you probably don't want to throw an exception and stop everything just because there's a bug in your code unless it's a showstopper.

C and C++ support assertions via assert.h; I like to use those, and this would be a good place for one. For example, at the top of the GetKey method, do an assert that the key is found.

However this is also a good place for using an enum rather than a char or whatever you're currently using. That way, the programmer must use a value from the enum and there's not really a possible way to feed it anything else.
> 5 votes

# Answer
You can't do anything like look up a string key from a hash table at compile time, because that would involve executing code.

However you CAN use something like static\_assert (Visual Studio or Boost)to do things like check for enum values. static\_assert lets you check any const expression, and can be very useful for setting up certain safeguards. For instance if you had two enum structures that are independent but should be related to each other, you can static\_assert that the two enum values are the same. You can also static assert on sizeof, offsetof, and other compile-time functions.
> 2 votes

# Answer
Why not make a translate function that always gets called? That way you'll only have to look in one place. If you, instead of actual keycodes, use an enum the compiler will complain by default when you enter an invalid code) - the translate function can convert that enum to its actual keycode and is in charge of what input is valid.

Edited to add: abstracting the input out to one location will also make it a lot easier to make your keyboard layout redefinable.
> 0 votes

# Answer
While it's more elegant to transform the problem so that you can utilize the static checking mechanisms of your language or existing tools (e.g. enum + lint or higher warning setting), you *can* roll your own tool if you're not able to do this.

* If you have a centralized list of valid key values, and
* you always use a reasonably consistent syntax where you're using them (e.g. `getKey("foo")`), and
* you're not using more complicated logic to build key strings before use (e.g. `keyString = "move_" + directionString; bar = getKey(keyString);`)...

...then you might be able to use a simple `grep`-like mechanism in \<insert-your-scripting-language-of-choice\> to make a list and scan your source files.

It's possible to get some false positives and false negatives here. Too many, and maintaining the tool starts to become more of an effort than it is worth.

We have used a tool like this for a localization system, checking that all of our "string ids" actually match up to real strings. These string ids are used in c, cpp, and lua sources, and also in json, xml, and other "baked" forms of data. It's not perfect; it gives up when the string id was piecewise constructed by earlier code rather than being a literal.

One other nifty thing you can do with this is turn more expensive string literals into less expensive unique IDs or hashes as a pre-precompile step. If you don't control your build process this can get to be a pain, and if the tool is slow at all you get slow builds (which I loathe with the burning passion of a thousand fiery suns -- but that's another answer)... but you may already be doing some pre-preprocessing for e.g. swig or similar tools. This has the advantage of mandating a consistent syntax, and it'll fail your build if there's anything wrong.

(There are definitely tools out there that do this latter thing; look around a bit!)
> 0 votes

---
Tags: input
---