# Question
Title: How to make a multiplayer game work reliably behind NAT?
Even games that are 100% client/server sometimes have issues when the client is behind NAT. Peee-peer games are even a bigger issues. Some games need to use multiple transports (such as UDP and TCP) or multiple connections (such as a different UDP port for voice).

What are some ways to make sure a game works reliably when running behind a NAT router?

* Peer-Peer: No centralized server exists. Player A starts a game and Player B wants to join
* Client-Server: A centralized server on a well known address (hostname) accepts all incoming connections. Each client only communicates with that server.
* Combo: Where the server is just matchmaking, but game updates are peer-peer. Different peers may see each player with a different IP/port potentially (e.g. some clients are behind the same NAT and some are on a different router)

# Answer
The technique most commonly used is referred to as NAT punch-through. Here's a decent intro: http://www.mindcontrol.org/~hplus/nat-punch.html

There's an OSS project at least for UDP: http://udt.sourceforge.net/index.html

RakNet supports punch-through, too, I believe. It's commercial, but has a free "Indie" license. See here: http://www.jenkinssoftware.com/

Googling for "NAT punch" will get you plenty more reading material
> 10 votes

# Answer
* Don't have a client inform the server or peer of its own address. In other words, don't embed client A's IP in a game packet and have client B or the server reply to that address. Always reply to the address/port that the message originated from.
* Minimize the different UDP or TCP ports used for the game. This makes setting up NAT rules easier.
* Allow the user to override the default port used in the game. This way several servers can be hosted behind the same NAT.
* Document the ports and any rules they follow in your game documentation (thanks for that one Zorba). In Descent 3 I went as far as creating a stand alone test application that would help you troubleshoot your router or NAT configuration by sending packets to a test server.
> 9 votes

# Answer
Along with other answers, use an existing wheel : http://miniupnp.free.fr/ This library battles almost all of the annoyances in function form , giving you control over when and how to punch and pull :)
> 0 votes

---
Tags: networking, multiplayer
---


# Question
Title: Why is the "bind pose" one with outstretched arms?
Something I've often wondered about is the "bind pose". The bind pose for human skeletons is one where their legs are straight, and their arms are perpendicular to their body:

My question is: why? Is such a pose easier for the animators to work with, or the programmers, or both? As far as I understand the math, the bind pose doesn't make a difference to the outcome.

# Answer
> 16 votes
It's easier to model because there's separation between the limbs and body, and the bits that need to stretch when animated are already stretched - so they get modelled and weighted correctly.

Same reason you'd model a hand as open and fingers spread, rather than modelling it as a fist.

Oh, and as far as programmers are concerned, we don't care. It'll still look like something from "The Thing" when we get the skinning code wrong at the first attempt.

# Answer
> 11 votes
As for the reasoning behind the pose. There are three.

1. Any left/right symmetrical pose simplifies modelling time as majority of the model can be built in half and mirrored. Saving asymmetrical details until the end.
2. Same goes from the skeletal data, which can be left entirely symmetrical. Which allows for mirroring of animations if needed.
3. Finally a pose with separated limbs makes the job of the rigger much easier. Rigging is binding the mesh model to the skeletal data, showing which verts on the model are effected by the various bones. While you could rig a model with it's arms down at it's side it would take a lot more time as a lot of the automatic tools would associate leg and chest verts with arm bones.

As to the T-pose vs. 45-degree inverted Y pose.

When you use skeletal deformation for animation you are using bone positions to create deformations in the shape of the model. This approximates the motion of limbs, but it's only an approximation, and the further from the bind pose you get the more distorted the deformation. There are lots of expensive solutions to fix that, creating target shapes that you blend the verts towards as you use the bones to move the model but those solutions get expensive in memory or cpu time quickly.

So why the "T"? Well if you look at the range of motion a human arm can make it goes from a little past pointing straight up to a little past straight down. This makes out to the side exactly in the middle of the two extreme positions. Since skeletal deformations look worse the further they get from the original pose it makes sense to make the bind pose in the middle.

As FuzzySpoon mentioned the static-T pose has been shifted a bit to arms at more of a 45-degree downward slope. The reason for this is that while horizontal is the middle point for the full range of rotation of the arm, it isn't the middle point for common usage of the arm. Our arms spend most of the time either at our sides or as high as shoulder height. So 45-degrees down is right in the middle of the most common positions for arms in animations. The other issue is that as you lift your arm to horizontal your shoulders tend to rise and clothing bunches up, it's more complicated to model the shoulder area when you have to think of pre-bunched up clothing and raised shoulders.

# Answer
> 7 votes
My view is that things are changing often. People get better, and people fall behind. The best place to look for reference are the people who are kicking ass at whatever you are interested in. Lately, the traditional static TPose has been less favoured due to IK/FK and other animation problems when rigging in such a rigid position.

Here is a great reference : http://www.zbrushcentral.com/showthread.php?page=1&pp=15&t=79141

Notice their TPose character shots are all "loose" and far less static. The elbows are bent slightly inward toward the body and it allows a lot more natural flow on the modelling of clothes, and skinning becomes a lot easier for an artist. The legs are a little bent as well, and the shoulders are not high up there they are more natural for when the animation comes in. It allows a much better topology flow to be created without losing the simplicity of rigging in such a pose.

And to answer the question directly : Its for animation and rigging purposes. It's a horrible workflow trying to rig bones in the spine if the character is sitting down. Or even in the knees, if bent. When painting weights for things like materials and cloths you will find this sort of pose to enable a much quicker workflow.

---
Tags: animation, rigging
---


title: List of resolutions

text:
# Question
Title: List of resolutions
I'm looking for some sort of list with most common game resolutions my game should support.

Regards!

# Answer
> 11 votes
A good place to start is the Steam Hardware Survey which includes a list of the most popular display resolution among Steam users. Wikipedia has a list of common resolutions in computer graphics. You can also look at some commercial games and see what resolutions they allow the user to select from.

If you're going to support any resolution and just want a list to show to the user, you can query the list of supported resolutions on the player's PC. How you do that depends on the API, for example in SDL you'd use SDL\_ListModes.

# Answer
> 7 votes
I'm pretty sure on Direct X platforms at least, you're expected to query the platform for a list of available modes (using EnumAdapterModes on the device). That way the platform will already exclude any unavailable resolutions (because the GFX card or OS doesn't support it).

You can further sub-filter those modes to exclude any you don't support (for example if you don't support widescreen resolutions), but you certainly shouldn't be defining your own arbitrary list of resolutions and expecting them to map to the set which is actually available.

# Answer
> 3 votes
Unless you plan to target one machine with one predefined set of resolutions, i'd recommend making your game so that it works on any resolution.

If your game has a high range of resolutions it should support (meaning: from very low to very high) in that case it makes sense to leave out things on lower resolution and also to use different graphics sets (e.g. High def textures make no sense on a small handheldscreen).

---
Tags: pc, resolution
---


# Question
Title: what options do I have for rendering "large" terrains?
I am trying to design a game with some interesting features but one question I have is regarding terrain. I want a terrain that will make for a very large game world, and I want to be able to have such features as "roads" and "rivers".

What options do I have in terms of terrain and what will give me the best result in terms of best looking, obviously I want to also keep the game playable with a reasonable frame-rate, but this game will specifically target higher end hardware.

# Answer
You should stream your terrain from disk; don't load the entire world into memory just to render what's around the player.

Also see "What’s the newest trend / method for terrain rendering?" and "What is 'ROAM' related to terrain rendering?".

Traditionally, a heightmap grid of tiles has been used to represent the terrain geometry. However it doesn't allow for multiple floors or cave-like structures, though you can fudge it by adding meshes that seamlessly integrate with the heightmap.

As you seem to be new to this, you might want to start by playing with a world editor. There are plenty of Google results for terrain editor that you can try; I personally can't recommend any one of them from the rest but perhaps someone can comment on them.
> 7 votes

# Answer
The existing answers give a lot of information.

I also gave a talk a couple of years back on how the terrain system in PhyreEngine works. It's PS3 oriented, but actually fairly similar to the Halo Wars technique in many ways - we also have full 3D displacement, and indeed can handle "bridges" (i.e. complex topologies). This is available here:

http://www.technology.scee.net/presentations
> 4 votes

---
Tags: graphics, game-design, performance, terrain-rendering
---


title: Camera rotation (OpenGL)

text:
# Question
Title: Camera rotation (OpenGL)
I am having trouble with a camera class I am trying to use in my program. When I change the camera\_target of the gluLookAt call, my whole terrain is rotating instead of just the camera rotating like it should.

Here is some code from my render method:

```
camera->Place();

    ofSetColor(255, 255, 255, 255);

 //draw axis lines
 //x-axis
 glBegin(GL_LINES);
 glColor3f(1.0f,0.0f,0.0f);
 glVertex3f(0.0f,0.0f,0.0f);
 glVertex3f(100.0f, 0.0f,0.0f);
 glEnd();

 //y-axis
 glBegin(GL_LINES);
 glColor3f(0.0f,1.0f,0.0f);
 glVertex3f(0.0f,0.0f,0.0f);
 glVertex3f(0.0f, 100.0f,0.0f);
 glEnd();

 //z-axis
 glBegin(GL_LINES);
 glColor3f(0.0f,0.0f,1.0f);
 glVertex3f(0.0f,0.0f,0.0f);
 glVertex3f(0.0f, 0.0f,100.0f);
 glEnd();

 glColor3f(1,1,1);

 terrain->Draw();

```

And the rotate and place methods from my camera class:

```
void Camera::RotateCamera(float h, float v){
hRadians += h;
vRadians += v;

cam_target.y = cam_position.y+(float)(radius*sin(vRadians));
cam_target.x = cam_position.x+(float)(radius*cos(vRadians)*cos(hRadians));
cam_target.z = cam_position.z+(float)(radius*cos(vRadians)*sin(hRadians));

cam_up.x = cam_position.x-cam_target.x;
cam_up.y = ABS(cam_position.y+(float)(radius*sin(vRadians+PI/2))) ;
cam_up.z = cam_position.z-cam_target.z;
}

void Camera::Place() {
//position, camera target, up vector
gluLookAt(cam_position.x, cam_position.y, cam_position.z, cam_target.x, cam_target.y, cam_target.z, cam_up.x, cam_up.y, cam_up.z);
}

```

The problem is that the whole terrain is moving around the camera, whereas the camera should just be rotating.

Thanks for any help!

# Answer
> 5 votes
From your code it looks as though your camera is stationary (cam\_position doesn't change) and you just change cam\_target. This will have the effect of spinning your camera around on the spot. If the only thing in your scene is your terrain then it might appear as though the terrain is rotating around the camera. Are you trying to rotate the camera around the terrain? In that case your camera target should be the center of the terrain and you should be changing cam\_position to move the camera.

Try initializing cam\_target to the terrain position and then in the lines where you currently update cam\_target swap cam\_target and cam\_position:

```
cam_position.y = cam_target.y+(float)(radius*sin(vRadians));
cam_position.x = cam_target.x+(float)(radius*cos(vRadians)*cos(hRadians));
cam_position.z = cam_target.z+(float)(radius*cos(vRadians)*sin(hRadians));

```

# Answer
> 0 votes
Are you actually setting the identity matrix at any point?

What other matrix ops are happening, and in what order?

---
Tags: c++, opengl
---


# Question
Title: How do you make use of all texture units on today's graphics cards?
I saw a review of the GeForce GTX 460 graphics card. It has 56 texture units. I'm not that knowledgeable about graphics effects. But, the ones I know use around 3 or 4 texture units. In this graphics card case, that would leave a lot of texture units idle. How are these graphics cards with so many texture units used?

# Answer
> 12 votes
GPUs generally process a number of pixels in parallel these days, so I expect that it can make good use of all these units even with simple shaders.

# Answer
> 6 votes
56 texture units means that approximately 56 texture filtering operations can occur in parallel in a single clock (throughput) (some operations take longer than others - aniso footprint size, texel size, etc.). The hardware will utilize this automatically since it processes many pixels in parallel. The number of texure slots used per shader does not affect this.

@FuzzySpoon: That isn't the case. Even a single cube will be 56x times faster than a hypothetical 1x texture card, since it is parallelized at the pixel (actually pixel texture request) level. This assumes of course that the bottleneck is texture filtering in both cases.

# Answer
> 2 votes
Remember that bandwidth limitations and the texture cache also come into play. Use as few samplers as you can, then ask if you can use one less.

# Answer
> 1 votes
Aas stated it can handle 56 textures in parallel. That means 56 different textured cubes takes the same amount as of time to process as 1 cube, on a single texture unit card.

---
Tags: graphics, graphics-programming, hardware
---


title: 3D theory before graphics APIs?

text:
# Question
Title: 3D theory before graphics APIs?
I'm a software engineer and I'm hoping to move my career towards game development. I'm reading a book right now on 2D using C++/DirectX. When I get into 3D I know I want to do it correctly. For example, I know nothing about 3d space. So if I learn only an API I might know it but I don't know if I can develop an interractive mini 3d world with it. I wouldn't call myself successful just having a rotating crate with the latest shaders etc. My math skills are up to trig/linear algebra and still in college. I know more math is to come. Should I be reading on 3D theory books before picking up on OpenGL/Direct3D, or any other suggestions? I just know an API isn't going to teach 3D game development and don't want to be lost afterward. I'm very book-oriented so that's fine if there's suggestions there too. Thoughts are welcome. Thanks!

# Answer
> 11 votes
After dissing you on the other site I feel obliged to answer :)

I'm not any professional myself, but I did take a 3D Computer Graphics course in my university and it really helped me understand APIs I ended up using.

Among things I found especially useful:

1. Transformation matrices and how they work, not only for object transformations but also for viewing transformation, perspective projection etc. That's probably the most important thing.
2. The whole theory behind lightning and shadow, especially useful when you start dabbling into shaders.
3. Texture sampling, mipmapping.
4. Color theory and blending techniques is also useful.

And I definitely think that these are subjects that can be picked up from just reading a book or two on the subject, as long as you have the mathematical background.

# Answer
> 9 votes
Start by doing. That way you'll discover what you don't know.

Then pick up a good book on 3D math.

I recommend '3D Math Primer for Graphics and Game Development'

by Fletcher Dunn and Ian Parberry. (Wordware)

Very clear, to the point, relevant - with C++ code and all.

It's very important to know about the basics of points, vectors, transformations, etc.

But that does not mean you should study it all before diving in. :)

# Answer
> 3 votes
I took an Intro to Computer Graphics class in college (1-2 years ago) and the course website is still up. Lots of PowerPoint slides are still up that you might find useful and helpful. Topics cover both 2D and 3D graphics theory.

# Answer
> 2 votes
I'm in a similar boat to you (although I'm technically relearning stuff I vaguely knew in college), and my solution has been to check out several of the books mentioned over in the "Good 3D Math Theory Books" question here. If you're a book learner that may be a good way to go for you. Especially if your college doesn't actually have a good 3d graphics course (mine didn't).

# Answer
> 2 votes
Hmmm, when I had to make my first 3D game some 15 years ago (had to as it was my job, that helps persevering) I had no 3D knowledge whatsoever other than high school math. If you have a fondness for puzzle solving and reading up, you can reason most of it out yourself and with some help from the internet (comp.graphics.algorithms faq). I did read the openGL bibles and http://www.amazon.com/Computer-Graphics-Principles-Practice-2nd/dp/0201848406 (warning oldskool) as they give valid background info. If you do it this way you might start off the wrong way but at a point you'll either dream up, or bump into, a better solution. Most of the 3d problems can be solved if your 2d grasp is good. Add to the general trig, pythagoras, matrices and inverses/transpose (for projection), dot&cross product and what you use em for, quaternions (don't have to understand em, just know how to use them - you can do without but they are nowadays part of the basic vocabulary), and you can solve most problems you come across. As you go you'll bump into better ways, but those few can solve anything. The best way is to set yourself a goal outside your grasp and force yourself to get there. The problems you run into are what you need to learn, and hey, you're on the site where they can help you solve em!

# Answer
> 2 votes
The Wolfire Games blog has had a really excellent series of tutorials on linear algebra for game developers recently.

It really is important to understand the math behind it before you bother starting to learn an API. Otherwise, the order and purpose of the API calls won't make a whole lot of sense to you. You need to understand what they're doing for you on a math level first.

# Answer
> 1 votes
I suggest you enroll at Game Institute, specifically the Graphics Programming with DirectX 9 courses.

You don't need to take part in the interactive classes if you just want to self-learn.

By the way, there is an option to also get printed books for a very low additional amount. They are well worth it.

I did a lot of their courses a few years ago and the courses, although a little old-skool are really quite good and I can't recommend them highly enough - plus Gary Simmons is a really nice guy.

# Answer
> 1 votes
Above all else just try to make stuff. First and foremost jump in. Otherwise you will become an expert at theory but not practice.

If you think that you are truly passionate about graphics, then imagine that you will continue to learn new material most of your life. Its not like you can learn everything you need before you start. It just doesn't work that way.

As you learn more and more about the mathematics of 3D graphics, you will realize that there is no mathematics of computer graphics, there is only math. **Learn how to teach yourself mathematics on your own**. Then you will be able to digest new techniques as they are presented in literature.

As graphics technologies evolve we will borrow different mathematic techniques. What is popular today might not be popular tomorrow.

Here are some things that are going to stay the same.

Right now I am finding the material in Geometric Algebra for Computer Science very interesting, and think that it might be better to start with the approach they layout for computer graphics. http://www.amazon.com/Geometric-Algebra-Computer-Science-Object-Oriented/dp/0123694655

The book explains things like quaternions in a much simpler way, and might be helpful for you depending on your mathematical background and interests.

# Answer
> 1 votes
Don't go for "computer graphics" books. Start with linear algebra - it lays the foundation for everything you need. MIT has a good video course: http://ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2005/

From there, it should be straight forward to pick up any introductory text on computer graphics. UoWashington has a course online (no video, though): http://www.cs.washington.edu/education/courses/457/06au/lectures/

If you're impatient you can start with the graphics course without linear algebra, but believe me when I say it will come back to bite you :)

# Answer
> 1 votes
If you want to understand how a traditional software rendering pipeline works (and things haven't changed that much even with the introduction of programmable hardware pipelines), one book I'd definitely recommend would be Jim Blinn's: A Trip Down The Graphics Pipeline.

Unlike some of the other suggestions, it's not particularly comprehensive, but it is very readable and I think if you're just getting started with 3D, it's a good introduction. And it's written by Jim Blinn, who is one of the founding fathers of computer graphics, and thus is written from the perspective of someone who actually invented/discovered these techniques.

# Answer
> 1 votes
I'm currently doing the same as you, and found CSCI 234 Introduction to Computer Graphics on iTunesU to be really helpful after I read a few books on computer graphics and math.

# Answer
> 1 votes
I was the TA for the graphics course at my university for several years. I set the syllabus, and covered things like software rasterizations and shading, Java3D, OpenGL, etc. Some time after this, in my own time I decided to write a ray-tracer for my own edification. This was an incredible experience - with a frame buffer and a putpixel(x,y, color) routine, in 500 lines I had code to generate an image with spheres, triangles, per-pixel shading, shadows, etc. If I had to redo the pracs for the courses, I would insist that the students do a ray-tracer. It is way to easy to get caught up in the details of a scanline algorithm when building a rasterizer, or feel like you're working through a black box using a 3D API.

For quick, solid access to a graphics sandbox, I recommend writing your own ray-tracer. Obviously, this is a far cry from what is commonly used in production real-time 3D graphics, but it is a really intuitive and compact way to see and learn the theory.

---
Tags: graphics, c++, opengl, directx
---


# Question
Title: How can I make "small" (file size) background music loops/tracks?
I recently purchased some short (approx 3 min) background music tracks. I have the tracks in three formats: AIFF, MP3 and WAV. How can I compress these files such that the quality remains intact (for the most part) and the file size is relatively small?

I'm especially interested in the "before" and "after" file formats. So far I've tried compressing the **MP3** format to **m4a**. This reduced the file size substantially... however the quality was significantly degraded.

I'm definitely open to reducing the tracks to much shorter (approx 20 sec) loops. Also note these background music tracks will be used on the iPhone (need to support back to the 3G). I have access to Logic Express 9 and Garage Band... and I'm open to trying Audacity or other software.

Cheers!

Edit: I'd like the file size to be around 300 Kb. This way it loads quickly on the 3G.

# Answer
The iPhone has hardware decode support for MP3 and AAC (M4A), so you'll want to use one of those formats. In other words, if you play an MP3 or M4A on the device, it will use very little CPU. OGG used way too much CPU the last time I tried it. In my experience, AAC will compress better in general. But it depends a bit on what frequencies are present in the source audio. Unfortunately you'll probably need to just try a few settings until it sounds ok. You can import your wav files in iTunes and right-click to convert them to AAC. Try some of the built-in quality options and see of the files end up small enough. Then, if necessary, start tweaking things like bitrate and quality. A variable bitrate will result in a smaller file usually but it can be difficult to determine how much it will compress.

EDIT: When I was trying to play OGGs on the iPhone, it was via FMOD and it was a 1st gen device. So, things might have changed since then. Still, unless the rest of your app isn't really doing anything CPU intensive, you might as well not spend CPU cycles decoding audio if you don't have to since MP3 and AAC are essentially free.

EDIT2: Also, to clarify the whole M4A/AAC thing, M4A is an mpeg container file that can contain AAC-compressed audio. AAC is the official successor to MP3. According to wikipedia, a 1MB/minute AAC stream (by 128kbps constant rate compression) will give you hi-fi transparency (i.e. nobody can tell the difference between compressed and the original). I'm not sure how accurate that is, but it sounds about right.

EDIT3: Your quality degredataion going to M4A was due to starting with an MP3. Always start with an uncompressed format, like WAV. I believe AIFF is normally uncompressed, but I'm not sure if that's always true.

EDIT4: The AAC compresser that's in Logic 9 might do a better job than the one built into iTunes, but the process will probably be more complicated.
> 4 votes

# Answer
While this is of dubious value with your actual situation, the best way to make small background music is to use a MOD-style format. These are formats that contain a small number of sound samples and the music in a note-by-note format, rather than a gigantic waveform that's been compressed to squeeze space out.

Check out the S3M and XM formats, as well as the original venerable MOD format.

Sadly, there's no practical way to convert MP3 into MOD besides paying someone to do it by hand, and even then you may lose music effects as you're limited by the technical abilities of the format and the player.
> 11 votes

# Answer
You can **reduce the bitrate**; this is most likely what you did (without knowing) when you moved to m4a. This has a direct effect on filesize but does quickly fall off in quality. The bitrate is the number of bits per second that the music plays; as you can imagine, if you allow it a higher bitrate or a higher number of bits per second, it will use those bits to represent more detail in the music and so the music will sound better. It's perhaps synonymous to "resolution" of an image (but if you kept the image the same physical size).

You might also **try the ogg (Ogg Vorbis) format**, it's an open format that is supposed to compress pretty well, certainly better than mp3 but I don't know how it compares to m4a.

Finally, you can try **switching the tracks to mono**; this will halve their size. You can then perhaps use an algorithm to dynamically "spread" it back out to stereo in realtime. Typically, however, this makes it sound pretty terrible. Try it and see what you think.

In any case, **don't use WAV or AIFF files**; they store raw, uncompressed audio waves. You absolutely want to go with a compressed format such as mp3, m4a, wma (yuck) or ogg.
> 3 votes

# Answer
WAV to MP3 should give you about 11:1 compression. I think Ogg Vorbis is pretty much the same. The difference in quality should not be noticable by the human ear. This compression ratio is pretty good. At a decent quality, 20-second loops won't come out over 1MB (I think). There's plenty of open source software that can get your files from raw to ogg.

**EXTENDED ANSWER**

I am extending my answer by recommending you compress the raw audio to Ogg format. This can be done really easily with open source tools or you can write your own converter with the Vorbis encoding library (it's free!). Streaming Ogg files with OpenAL should be perfectly viable on the iPhone.

I subscribe to the OpenAL mailing list there've been quite a few questions relating to OpenAL on the iPhone lately.
> 1 votes

---
Tags: iphone, audio
---


# Question
Title: Draw multiple LINE_LOOPs in one glDrawElements call
The game I'm working on has OpenGL (2.1) vector graphics, and I need to draw up to 1000 enemies, each of which is composed of between 4 and 100 lines.

Each enemy can be drawn as a single line loop, so one strategy for drawing would be to call `glDrawElements(GL_LINE_LOOP, ...)` once for each enemy. This results in too many (up to 1000) calls of `glDrawElements` per frame.

Another strategy would be to separate the line-loops that form each enemy into individual line segments, and call `glDrawElements(GL_LINES, ...)`. This results in a lot of repeated vertices though, which I would like to avoid.

Is there a way to draw multiple line loops in a single call to glDrawElements (or with some other function)? I guess I would need some indicator in the vertex/element array to mark where each line loop ended.

# Answer
> 2 votes
Surely if you're using indices, you're not repeating verts?

You could also look at instancing, where you have a set of primitives being repeatedly drawn with a set of matrices being sent at lower frequency (i.e. a single call could draw 20 lines, repeated with 15 different matrices).

edit:

It occurs to me that you might be worried about the duplication of *indices* rather than verts. I wouldn't worry about that - that's kind of the point of indices. They allow verts to be reused without being retransformed by the GPU.

---
Tags: graphics, opengl, glsl
---


# Question
Title: What skills does a hobbyist gamedev team need?
In the industry, people with various skills and talents all work together on a team. They are most often specialised in their field.

However, this is unpractical for a hobbyist team. All people in such a team need some skill in various fields and people have to wear many hats. Which skills are crucial for an average hobbyist team (without taking any game specific details into account)? Detail some tasks that people with such a skill would be required to do. What other skills are usefull but not necessary? Are there any skills that can more easily be combined (for example, the game designer can more easily do the marketing then an artist?).

A good answer to this question can be used to complete a team, based on missing skillsets or available time of current teammembers, or just to get more insight of the dynamics of a hobbyist team.

# Answer
> 13 votes
When speaking at the hobbyist level, people wear many hats indeed. But the capabilities of each type of member really depends entirely on the individuals. At least, whenever I've looked in the past. I am not particularly successful, but this is what I've gathered.

Here's my 5-in-morning brain-dump on the topic, however. You need most of the following things (these roles might be combined into a few individuals. I've pluralized these, although you might only have one of each role between your team):

* Designers/idea people. A person who comes up with ideas and key concepts that comprise your game.
    + Ideally, this should be everyone in the team, so all players in your team keep interested, and they should each have a say in what sort of game is made in their own way.
    + Be careful. Make sure that people can agree to a general concept, and talk it out until the idea makes sense. Try to get every on board here, since a clear idea is tremendously important in making sure tasks go like planned.
* Artist.
    + You can wait on this (placeholder art or programmer scribbles), but your ability to make certain kinds of progress can be severely hindered without the ability to create the intended visuals in-game. Especially if you require that sort of visual feedback to keep yourself motivated. Also, art is definitely a large marketing point of most games, and good visuals and eyecatching screenshots will pull in an audience.
* Musician/Audio Person
    + This can also be waited on. Arguably audio can be less "important", as is evident by certain games completely foregoing sound, but it still has a huge impact on the feel of the game, especially the musical soundtrack. It is worth finding a capable musician.
* Programmers/Scripters
    + Vital! The game's events and logic need to be programmed to an extremely large degree. Whether this is low-level system control, or a script written in a cookie cutter game maker tool, someone needs to program the scenarios. This tedium is real and necessary. Lack of programming skill bites you in butt, as you are constantly finding yourself limited in what you can do with the tools you can manage.
    + At the same time, having bountiful programming skill can be a curse of its own. Suddenly there's a desire there to overcomplicate simple tasks and worse yet, they might waste time writing engines instead of writing games (speaking from my own pitfalls).
    + Even tools like Construct technically have you "program". Whether you do it explicitly in a language or in some sort of tool that does it for you, you need to control the execution and flow of the game. This is a tedium to be expected of most if not all games.
    + You need balance. Rushing out code ends up in bugs and a mess that cannot be maintained. On the other hand, slowly fleshing out engines and systems for stability are useful, but eventually you need to release something.
    + Pre-existing tools are out there for a reason, but they have restrictions. You might be able to get a way without a "systems" programmer, but you might not. It entirely depends on the scale and type of the project. The closer it is to an existing system, the easier a time you'll have. But to make more "innovative" things, you may find yourself with cheesy workarounds and starting at least remotely from scratch.
* Mathematicians/Statisticians
    + If your game needs math, or needs math and you don't realize it yet, you need someone knowledgeable (or at least know how to use the Internet) to consult about problems. Ranging from geometry and trigonometry, to data compression, to balancing damage distributions and levelling curves in RPGs, collision detection, etc. Depending on what you end up doing, math is required. Not always, but often. Keep it in mind when you run into a problem, don't just run away in panic.
* Writers
    + Depending on the type of game, you may need a competent word-smith to captivate your audience. A person who's good with plot twists and clever prose, to use for scripted dialog, descriptive flavor text, introductions and whatever else you need.
    + A writer for your design documents (if any) might also be nice. This style of writing should be much more explicit and technical as required to avoid ambiguities and problems. This all depends though. Not every team needs this, and you can sometimes dive right into the game-creation parts without writing a document or even a to-do list. Just keep it in mind. This person is likely a programmer.

Keep in mind that one team member in a hobbyist team will likely fill most of these roles.

As a personal rule, I find that I am typically the programmer, and I find assistance with artists and musicans. Occasionally, I'll call on a second or third programmer to help speed up the flow. The writing and design things are handled by every team member. Mathematical people are likely the programmer-types as well. But beware, not every programmer is tremendously good at math, some just know enough to get by. Overlap in design roles is especially critical, in my opinion, to keep everyone on board.

It's best to either not depend on people to do their part, or to only depend on reliable people (with whom you hold great confidence), since projects can fall apart due to one person not doing their part. As has happened so many times to me. This means that you might find yourself wanting to learn things on your own -- however, this leads to lots of time wasted learning skills you wouldn't need to learn if you were in a team (and now they can't be done in parallel). Be careful.

Your own experience is the only true guide for this sort of thing, and your first few encounters with hobbyist development will probably not yield anything (it's disappointing, but as far as I can tell, fact -- but never get discouraged, as you learn valuable lessons along the line).

Well hopefully somebody finds this interesting, I might end up disagreeing with myself later, since I was sort of trailing off midway through writing this, but I kept with it, even though it was 5am. Time for bed.

# Answer
> 1 votes
All non development tasks can be done by anyone. The team must be capable of completing the development. Marketing, licensing and company directing legal stuff are all easy to pick up. A lot easier than games development itself. It all takes time though, so try to pick someone who's going to be done with their part of the development early to take on these roles, and maybe someone who doesn't come in till later to take on the role of company direction.

Hobbyists need resources as much as professionals. However, hobbyists don't need to maintain old code. This is a crucial difference between industry and indie. The difference manifests itself in skills required, but only slightly.

As a hobbyist, you'll likely need to pick up a graphics package as a programmer, and figure out how to create audio too. There's no pain like not having an asset to get something tested. In addition to the digital asset creation skills you must have, you also need to acquire the sense of when to give up. If something is proving to take longer than expected, as a hobbyist, you need to find something else to do to keep rolling. Small teams means there's less chance that all your requirements are covered, and that'll mean last minute research and development before the game can come together. Heed the advice of those who have gone before regarding what not to do and how to do stuff without doing it right. There's time to be wasted doing things right when you could just get them done. Not sloppy coding or bad art, but test driven development way of thinking, do only what you need to do to get it performing as expected.

There is no need to draw a grand backdrop if you're only going to see it through a dirty window, no need to code a physics model if a free one will suffice. We in the industry know that it's fun to do these things, but any company that has pandered to its staff and let them have their head came crying to the banker when the money ran out.

# Answer
> 1 votes
I can write about how I work since what I do could be described as a hobbyist gamedev. We loosely have a 4 person team: programmer, business guy, graphics artists and music guy. The graphics and music guys are contracted do for specific work and are paid per hour/job.

The design for the games comes from the business guys (which happens to also be a programmer who has made multiple games previously) mainly, but with a lot of input from the programmer.

The programmer does the actual programming with the business guy helping with the testing. Once the game is ready, the business guys take responsibility for pushing it on to vendors, try to get deals with distributor/carriers. When new platforms are made available, the programmer ensures that it will run properly and make modifications as necessary. Of course, there is bug fixing as well.

We work in the mobile space, so it is not clear if the concept would work on the PC/Console due to the size of the games produced. We are on track to get 3-4 games out per year. Finally, the programmer and business guy split the revenues.

# Answer
> 0 votes
This question is a bit vague, so I can just give you some similarly vague answers.

a) Many hats. There's no way that you'll have clearly separated roles. Some roles might be easy to assign to one and only one team member. Others will have to be shared. In our team of five (we're not hobbyists but a similarly small team) we've never managed to clearly assign roles because we're still too small for that.

b) It all comes down to personal preference. If you're a game designer and more of the social kind of guy you might enjoy marketing. Maybe your game designer loves Twitter. Then he/she should definitely take over that PR aspect. Maybe she's good in English - she should write the PR texts then. Finding motivation for some tasks can get very hard in a hobbyist team. If you like what you do you'll be more easily motivated.

c) Stay agile. Even if you find the perfect team, there are a number of roles you'll only need at certain phases of a project, e.g. a graphics artist and an audio designer. You can hire those or ask a friend to do it, but you can similarly find someone in your team who's into audio and have him mix your soundtrack and switch back to whatever he did before, afterwards.

d) Persistent communication rules. Use something like basecamp and version control for everything. This way, people can easily reconnect to threads that were dismissed months ago, and keep their information up to date. Also, you can backtrace decisions and have everything documented. This is especially important if you work in a distributed team.

e) Every project needs a different team. Since you don't tell what game you're working on I can't get very specific. But given a little bit of planning and design you'll most likely end up with a list of project roles you're going to need. Additionally you'll need someone to act as the sysadmin (e.g. for servers), research and maintain the asset pipeline and tools, do the PR and maybe budgeting.

PS: I prefer to wear "many hats", as opposed to "many heads" ;-)

# Answer
> 0 votes
The ability to learn things well on a deadline, the ability to maintain a clear vision of what the end is going to be, the ability to go without sleep and work in a closet, and the ability to celebrate victories and accept defeats as a team, with no single person being blamed.

---
Tags: education
---


title: my iPhone app skips the splash screen!

text:
# Question
Title: my iPhone app skips the splash screen!
I have developed an iPhone app. When I have installed it in the device, it worked fine, ie it showed, the logo screen, the title screen and goes to game screen and now I have exited pressing the home button. The problems starts when I relaunch the app, it straightly goes to the game screen, by skipping the splash screens.

While I was working on it the app crashed and when I launched again it showed the logo screen and title screen. But when I relaunched it, the splash screens where skipped.

Could you tell me the possible errors that might have occurred?

# Answer
It's not an error, it's iOS4 multitasking.

Your app keeps running in the background as long as there are resources available.
> 5 votes

---
Tags: iphone
---


# Question
Title: How does one separate the acceleration due to gravity from other motion in accelerometer input?
How does one separate the acceleration due to gravity from other motion in accelerometer input?

# Answer
When working on Wii titles, i found that a low pass filter on the accelerometer reading could be used as a reasonable approximation of the gravity vector component. Subtracting this from the real values then left me with a good basis stream for instantaneous gesture analysis. My low pass was around 1hz (just the average of enough packets of data) but tweaked dependent on the gesture being developed.
> 8 votes

# Answer
That really depends on what you are trying to do.

If you are planning to use the accelerometers for navigation (essentially building an inertial navigation device) you need to keep track of which way is down in your integration cycle. If you device is being accellerated with an accelleration equal to *g* in a lateral direction and you have no measurement history, you have no way of telling which is which.

If you are using the accelerometers as a sort of tilt sensor you can just assume your measurement is gravity, that is your local down vector. Decomposing it along the device's body will yield the orientation.
> 2 votes

# Answer
Several techniques only use the difference in acceleration, not the instantaneous value. In those situations, constant acceleration is removed for you.
> 1 votes

---
Tags: algorithm, mathematics, input
---


# Question
Title: Tools for non-programmers to add new tasks to games
Since graphic designers/end users are not programmers, what are the technique to allow them to add new tasks or change application logic in a game? what are the end user tools? I want some popular examples.

# Answer
> 6 votes
Various scripting languages, both text-based (ones with simple syntax - LUA for example - can be more accessible for a non-programmer), and graphical (Unreal, for example, is very GUI oriented).

Alternatively I've seen people just expose tweakable stuff through an editable text file (sometimes a CSV formatted file usable in Excel), if you expose the right stuff you can give designers fairly powerful abilities to change the game, without them having to actually alter the logic.

Basically the tools I've seen being used are:

* Notepad, or other text editor.
* Excel.
* Some ad-hoc graphical interface to a scripting language, sometimes in-game.

# Answer
> 1 votes
**Unity** is a very popular engine/WYSIWYG editor which allows programmers to expose easy to modify "components" which artists/designers can attach to entities to give functionality within the game. A bunch of components come standard which provide a lot of the basic functionality for games.

From the Unity site:

> **Play, Pause, and Step**
> Click the Play button to instantly run your game. Pause and Step forward to analyze complex behavior in detail. While the game is running (or paused), you can alter values, assets, or even scripts! This means you can do more experimentation and more testing for a better final game.
>
> **Easy Editor Customization**
> Streamline your workflow using simple, Editor-specific scripts. We wrote the Editor using Unity’s own scripting, so anything we can do in the Editor, you can do as well.
>
> **Customizable Editor Layout**
> Choose from one of many built-in application arrangements, or create and save your own. Different tasks might benefit from different arrangements, so use easy hotkeys to switch arrangements as needed.
>
> **Drag 'n Drop Everything**
> Visually drag assets and objects in the editor to assign Textures, Audio, Behaviors, and script variables. Create logical GameObject hierarchies to manage and maximize your game's functionality.
>
> **Prefabs**
> To streamline the repeated use of complex GameObjects, you can turn one or more of them into a Prefab. This Prefab can then be easily placed throughout the game or instantiated at runtime. Any changes to the original prefab are propagated to all dependents, so both major and minor adjustments can be made very quickly to a large number of GameObjects.
>
> *\- unity3d.com/unity/features/*

---
Tags: tools
---


# Question
Title: Why is professional game development harder in Europe?
In comparison to the U.S.A., there seem to be **far less** leading or **successful game companies in Europe**.

The recent salary survey of GameCareerGuide shows that the average salary of a games programmer in Europe is only 46k versus 80k in the U.S.A. While only 378 European developers replied to the survey, 1014 developers from the States provided usable feedback, which might also indicate that there are less people employed in game development in Europe.

What makes it so much harder to develop games professionally, both AAA, indie and casual in European countries?

Note: the total number of game companies in both continents seems to be rather equal (see wikipedia for a complete list, around 117 companies are U.S based versus 106 European). But we have to take into account that, although North America is 2.5 times larger than Europe, there are many more people living in Europe than in the States (731,000,000 versus 309,944,000).

# Answer
There are a number of costs that go into game development beyond salary. While base pay is lower in the EU, when combined with higher taxes, property costs, and Euro vs. USD$ exchange rate fluctuations development costs in EU are often higher than in NA. At least for the big western European nations (UK/Germany) where the salaries are higher then that average. Salaries in East Europe are still very low so places like Croatia or Ukraine are interesting from an outsourcing standpoint because they do offer a lower cost. But outsourcing teams rarely get the sort of higher profile projects that can make them truly successful.

The lower cost of NA development means it's much easier to start a new company in the US, more companies means more chances that one is a big success. There is also a general momentum that happens in the development community. Highly successful teams tend to lead to individuals branching off and building new companies which have a greater chance of forming more successful teams in the surrounding area. Most of the development in NA is based around these sorts of hubs in SF, LA, Seattle, Austin/Dallas and in Vancouver and Montreal in Canada.

Also it should be noted that these things do change. Japan used to be absolutely dominant in the console space a couple of generations ago. Today NA seems more dominant. Some of this comes from a number of long time strong PC developers moving into the console space. Epic, Bungie, Valve and the 2015 core of Infinity Ward were all PC-only teams that have transitioned to building console titles.
> 8 votes

# Answer
The domestic market is huge in the U.S. and thus it's much easier for any company/industry to succeed. In Europe, you have to cross borders to get a market. It's not really directly related to the game development business.
> 4 votes

# Answer
I don't know, but I think it might just be a culture thing. Certain countries specialise in certain industries and are then driven by momentum as skilled people move between different businesses in the industry that are located nearby, or set up satellite companies.

I also think you can't easily compare the USA to "Europe" because Europe isn't one homogeneous state but many different places with different cultures (eg. working hours), languages (23 official in the EU alone), standards of living (the average Luxembourg citizen has a GDP 14x higher than one from Romania), different laws and currencies, etc.

It's also interesting to note that Eidos were a UK company and Ubisoft are a French company, and they have both had a massive impact on the industry, so there's certainly precedent for success in Europe. (Although both had the advantage of being well established in one form or another during the 80s.)
> 3 votes

# Answer
You can't take Europe as one blob and make any meaningful comparisons with the US. The cost of living in e.g. Greece is quite a bit lower than the US, so it doesn't matter if your salary is lower.
> 3 votes

# Answer
Localisation?

No, but seriously, It might be something to do with all the game-dev closures. Now isn't a good time to be taking polls.

I'm probably quite horrible in that I think that this might be do do with who actually fills in the forms. I think that the polls respondents are the subset that wants to divulge their details. In europe, the underdog is more prone to whinge about their state of unfair pay. In the U.S. there's a contingent that wants to boast. Maybe the proportions are right to make a difference to the results?

In any effect, I'm aware that a lot of the people I know (pro game dev) are definitely getting nearer the U.S. pay level, if not over it, so I'm not sure of the validity of the whole thing.
> 1 votes

# Answer
A detail might be that the education quality across US is relatively consistent whereas a fair part of Europe lacks (or lacked) that, so there's just less programmer output. Also, immigration is still a fair step in ones life. Same for access to computers, in the US everyone and his dog had a game system as a kid, in Eastern Europe they're still catching up (fast though).
Also, it's much easier to move from, say, LA to NY for a job, than it is to move from Poland to the Netherlands, as there's the language issue which you won't have within the US. So it's easier to fill positions in US as you can source from a much larger pool (heck most Europeans speak English, but good luck finding a French speaking coder in the US if you have a French office).
> 1 votes

---
Tags: business
---


# Question
Title: What are some good tools for prototyping map layout and design?
I'm curious as to what the best method for sketching out and prototyping a map is, and if there are any tools available to facilitate this.

Pen and paper is probably a good place to start, but I would like to know if there are any worthwhile tools to look into, something akin to a UI mock up tool like Balsamiq

# Answer
> 10 votes
You could try Google Sketchup. I worked at a place where the designers used this to create block models for maps that the artists would then use as reference. A block model is a very basic, untextured version of a map used to test and develop the layout of a map. I think they were importing these models into UnrealEd as well.

# Answer
> 10 votes
Don't blow off pencil and paper so quickly. It iterates faster than any tool lets you, never crashes, and every one of your developers can read it.

Also, I've heard great things about Legos.

# Answer
> 6 votes
It depends on how many levels you have between initial concept and final map rendering. The process I like most goes a bit like this:

If I am working with a writer, or someone who would intimately know more about how the world should be put together than me. I give them a nice entry tool to use, something that allows them to convey their ideas to me in something other than endless paragraphs. The tool I use for this is AutoRealm: http://autorealm.sourceforge.net/

I like this, more than letting them just turn in pencil / pen sketches for a number of reasons.

* It's digital.
    + I like this the most, because if they mess up Ctrl+Z is handy. No nasty erasures.
* It's pretty. (if they spend more than a few seconds working with it)
* It lets them plot places of interest and comment them.

From there, I take out my tablet and draw my own notes over the map (in art-editing tool of choice).

* What needs prototype models.
* My idea of how the level will flow
* What I am vetoing
* What needs improving / can be expanded for dramatic effect.
* What is frill (just pretty & terrain) and what is important (stuff I want to test)

So whomever is doing the terrain gets those files, and I start making quick proto-models in sketchup. I don't focus on getting anything perfect, because frankly someone can do it better and speed / execution of concept in prototyping are my goals.

And that is my path from Sketching -\> Prototyping.

# Answer
> 3 votes
Not to sound trite, but you'll also be better off with a pile of sticky notes. This will help not only with generating several renditions of maps/location-based venues, but makes for more efficient workflows and ui design. Often, it's the low tech applications that reign supreme. Stickies notes are also very effective when working with a team set of various personalities and divergent approaches. For 3d visualization ... have to agree with the rest. Sketchup takes the cake in producing workable solutions especially when dealing with vertical planes and relational environmental setups.

# Answer
> 2 votes
As with most design-related things, I would argue that there is no "best way" to design maps either. You should really just experiment with different tools. But I'll share what worked for me (your mileage may vary).

Personally, I find that tool to use varies on my mood. Sometimes I'll do pen-and-paper sketches. Other times (especially when I want to share my designs over IM), I end up doodling in a paint program. Sometimes, I'll open up a map editor like tiled (or sometimes other poorly-written editors that have lots bugs and I wouldn't recommend to anyone like maped3 but which I have great familiarity with) and use some placeholder tile art, which I gradually refine into a real map with useful tiles (not as useful for more involved maps that are not 2D, however -- but might be a starting point to get a rough layout).

If I'm not in a terribly visual mood, I might even just open up a plain-text editor and describe an area in writing. I've occasionally found myself just plotting out an area in ASCII art. The particulars will be better sorted out when I actually feel like crafting a complete map.

Some people might enjoy using 3D modeling tools, but I personally find them too involved and time-consuming. And I don't feel this sort of encumbrance when doing 2D sketches and tilemaps. After all, these are temporaries, and world designs are likely to change after they've work into a playable prototype.

(Similarly, I probably wouldn't use a specialized prototyping tool for deciding a user interface. But I do use other options. I could draw it out by hand. Perhaps I'd scribble in a paint program. Maybe fire up a detailed mockup from the get-go. Possibly even defer the interface specifics until I have coded an unstructured but working prototype.)

However, find whatever works for you. Keep trying new things, going with what suits your current mood, and while you may never find the "best" method, you'll find something functional, and that lets you at least make steady progress.

# Answer
> 2 votes
Paper is your friend to start with and get some good ideas going.

Chris Howe is right, Google Sketch up is one of the easiest 3d modeling packages to make basic shapes in. Sketch Up's ability to export models as Collada files, that can be easily imported into most 3d game engines, make it great for fast prototyping and iteration. I have done this in Unity 3d to make basic level layouts for testing.

Another great thing about this workflow is you can take the files you tested on and import them into a higher powered 3D application such as Maya for texturing and detail.

The only thing that Google Sketch up does not do well is Spheres. You can create arcs and cylinders but spheres are a pain. If you plan on starting from a sphere or adding on to a sphere do not use sketch up.

# Answer
> 0 votes
MS Paint have done wonders for me during the years (if you're on a windows computer and don't mind digital art).

# Answer
> 0 votes
The best way I've found is to do a quick sketch of the traverseable area of the map on a white board, a sketch or two of what things should look like in different areas on paper, and a collection of 'useful parts' (anything from mechanical bits inside, say, a clocktower level to standard things that should all have the same size, eg, doors) are noted and if needed designed to whatever level of detail necessary (in some cad software, or sketchup will also work for this if the required detail is low enough). Then it's just a matter of blocking out the area according to the runmap, filling in the 'dirt' (or other material that makes up the default 'filler') and from here I add all the details that were decided upon in the above steps- putting in buildings, sticking doors and windows on/in them, etc. The last step to physically create the map in the game is to add 'doodads', little things that make your game more believable. a good set of doodads I've found useful to include are power lines, garbage, graffiti, wall posters, and advertisements, in addition to broken bits from local materials in that particular area of a map, eg, a pile of broken bricks in an area where most of the buildings are brick, or a few broken tiles on the ground in an old public bathroom, etc.

---
Tags: tools, maps
---


# Question
Title: Are there any clever methods of regulating bandwidth usage for voice chat payload packets?
For example, suppose my code can determine that upstream bandwidth is unusually limited. And suppose I'm using a fully-connected mesh topology combined with a UDP-like protocol for voice chat. Is there an established way to reduce the risk of packet loss so that the voice playback will either be solid or muted, but not jittery or choppy? This must be a solved problem in the VoIP world, but I'm not sure where to look.

EDIT: To clarify my abuse of the term jitter: I mean, if two UDP voice packets arrive out of order, the audio would sound jittery in a colloquial sense (i.e. I mean packet jitter, not audio signal displacement). The choppy sound I'm referring to is related, where a UDP packet is lost instead of arriving late and causes a gap or jump in the audio.

When I refer to muting the playback, I don't mean as a function of source input to avoid background noise. I mean on the receiving end of the conversation, if there's high packet loss, just stop playback instead of playing choppy audio.

# Answer
> 1 votes
I'd recommend implementing the Real-time Transport Protocol (RTP), or something similar that suites your needs. It includes Quality of Service (QoS) monitoring with the RTP Control Protocol (RTCP) for minimizing "jittery" and "choppy" effects with audio streams.

Even if you don't need all the features of the protocol, it is worth investigating to see an example of how the issues you are experiencing are solved. However, you'll likely have to weigh the choppy/jittery effects against latency if the codec remains static. The consistency of the audio is improved by buffering and buffering takes time.

---
Tags: software-engineering, algorithm, networking, multiplayer, voice
---


title: Voice input in games beyond voip chat

text:
# Question
Title: Voice input in games beyond voip chat
Is there any cross platform libraries available for handling input from a microphone?

I am thinking beyond voice chat to noise / voice recognition.

I am putting together a plan for a role playing game and in thinking of features I was thinking it would be nice if the player could be standing in a crowded place and yell and have the npc's react to that and look at the player for example.

As I plan to make this an open source project I want to make it as cross platform friendly as possible.

# Answer
Check out Carnegie Mellon's Project Sphinx it's an open source toolkit for speech recognition. I haven't used it, but it's certainly a place to start.
> 1 votes

# Answer
PortAudio should have a cross-platform input API, but I've never tried using it.
> 1 votes

---
Tags: cross-platform, input, voice
---


# Question
Title: Dynamic pathing algorithm for tower defense game
I'm making a Tower Defense and I need a good pathing algorithm for it.

I have thought about Dijkstra but I need one that can be dynamic; it must be able to update itself when one edge is removed or added without a full recalculation.

I'm coding in C# if it helps.

# Answer
> 7 votes
You'll generally want to use A\*, unless there's something importantly different you're looking for.

# Answer
> 19 votes
I needed to solve a similar problem: pathfinding on a large maze-like grid with constantly changing "costs" and barriers.

The thing is, in tower defense game the number of entities that need to have the path solved for them is usually much larger than the number of nodes in the graph. A\* is **not** the most appropriate algorithm for handling this, because you'll need to solve it anew each time something is changed. Well it is appropriate if you need to find only one path, but in my case I needed to be able to handle entities which can appear in different locations and each has its own path.

The Floyd-Warshall algorithm is far more appropriate, though for my case I wrote a custom algorithm that whenever a node changes, it re-calculates the cost to that node from all its neighbors, and then *if* the neighbors have been changed it is invoked recursively on them.

So in the beginning of the game, I just fire up this algorithm on all my "goal" nodes. Then, whenever a single node changes (for example, becomes un-passable), I just fire it up on that node and the change is propagated to all the nodes that will be affected, and then stopped. So no need for global recalculation, and the algorithm is completely independent from the number of entities that will require pathfinding.

My algorithm was basically something like (pseudo-code):

```
update_node method in Node class:
    $old <- $my_score
    find $neighbor node among all neighbors such that
        $neighbor.score + distance_to($neighbor) is minimal
    $my_score <- $neighbor.score + distance_to($neighbor)
    $next_node <- $neighbor
    if ($my_score != $old)
        for each $neighbor
            $neighbor.update_node()

```

With the initial score depending on whether the node is a target or some kind of barrier.

# Answer
> 5 votes
The route algorithm I used on my TD was backwards from normal A\* pathing due to the number of entities I had in the game. Instead of routing from the goal to the bad guys, I routed from the goal to every empty square on the board.

This doesn't take very long, you just keep iterating the board until you've found your "costs", and it provides good feedback for blocked routes (if you're doing those). Using Floyd's algorithm is fast and cache friendly compared to A\* as it's not doing data dependent lookups, it's just loading in and operating on data in streams.

Start with your board set to infinite cost, then set the goal square to cost zero, then iterate over the board checking to see if a neighbouring cell costs less than the current cost plus the travel cost. The travel cost is where you put your heuristic (in my case, the cost of travelling diagonally was infinite, but the cost of travelling through a tower was high, so they were allowed to eat through towers, but didn't unless they had no choice)

Once you've got your costs grid, you can quickly build a "flow" grid from that by testing the steepest gradient of cost on the cells. This works really well for massive amounts of bad guys because none of them ever have to path find, they just follow the virtual signposts.

Another benefit is that this way you only have to run this task every time you adjust the obstructions (or in my game, when a creep eats through one of your towers). Not every time a creep/mob enters the field (which with thousands of mobs and tens per second would have been quite a headache).

# Answer
> 4 votes
Pathfinding is fast, and on something the size of a normal tower defense game, you'll have no trouble running a full A\* or Dijkstra pass whenever something changes. We're talking well under a millisecond for a full refresh. Any kind of adaptive pathfinding ends up horrifyingly complicated. Just do it the simple way, unless you're making the world's largest tower defense grid.

# Answer
> 2 votes
How does A\* pathfinding work? might be a good place to start :-)

# Answer
> 2 votes
This may be overkill for your solution, but think of routing backwards instead of forwards.

In a TD game, the enemies are generally trying to get to a specific goal. Route backwards from that goal to the first enemy, then cache that path. On path generation for subsequent enemies, use the first path as a starting point, and so on. If you have multiple enemy entrace points, or multiple goals, have a range of pre-cached paths to start from.

# Answer
> 1 votes
Waypoint pathfinding would probably be the best for a td game, because generally based on the level the ai follows a direct path. Basically you set your nodes or waypoints then have the "ai" point towards the waypoiny and walk to it, once it gets close enough to that have it go to the next waypoint, face it and move towards it.

# Answer
> 1 votes
Since someone asked, you address dynamically-changing environments by re-computing the path every time the player places or removes a tower, and you just store that path in memory in the mean time. The environment doesn't change on every frame.

Note that some TD games have a set path and don't allow you to place towers on it, so they solve pathfinding the easy way: by hardcoding a path and not letting you block it :)

# Answer
> 1 votes
A simple solution is to cheat.

Design the map beforehand to make sure that there is no dead ends. Then in each intersection, add a trigger that makes the character to choose a route (example: always turn left, always turn right, or random).

---
Tags: c#, algorithm, path-finding, tower-defense
---


# Question
Title: Finding other programmers to help on a project
As a semi FAQ question attempt :

Where can you find people to work with you on a project? Particularly programmers. One thing that is obvious is that all programmers have a project (or twenty), and the chances of a programmer just hanging around looking for something to do is a lot less likely than if it were an artist needed on the team.

So, where do you post? Where do you search and follow people around until it looks like they are a viable team member? Is it really difficult to assemble a team that are not close friends or chat buddies? Are there sites with this sort of posting?

To clarify : I am referring to a team.

Example 1 : I am making gameEngineOfAwesomeness. I need help.

Example 2 : I am 70% complete on this game, and i need help.

Example 3 : I have an open source project idea, with a prototype. I need help.

It doesn't necessarily mean open source, just programmers who can work with me on something (and where to find them :))

# Answer
> 10 votes
1) Press the flesh at places like Penguicon or local users group meetings and have your elevator pitch down and some color fliers with calls to action. If you want to enlist the help of others, you will need to market yourself and your idea. Explain 'why you' and 'why this' to a group of people who don't know you and surely have 15 of their own ideas that they haven't followed through on themselves. If you have a prototype, set up several machines in a con-suite or talk to the users group about being a speaker and present what you have to as large an audience as you can.

2) Make it easy to help you by setting up all of the infrastructure yourself before you talk to anyone. Get a well populated WIKI in place, source control system, storyboards (even if the art stinks), etc. and ideas on how 'this game' is going to change the world.

3) Be prepared to do more work than any two or three other team members, because you will need to be cheerleader, project manager, and contributor all.

# Answer
> 8 votes
From what I've seen, the internet is not a very good place to find programmers, especially if you're looking for them to work for nothing. But it sounds like you perhaps just need a programming task to be done (like making a specific game based on your art), rather than needing to actually form a group. You might try the following:

If you have a single specific task that needs to be done, you can post it on vWorker (previously Rent-A-Coder) and programmers (or programming groups) will bid on your project; accept the most viable-looking bidder, they do the work, and then you pay them once you receive the work. It's well-made to keep both sides fair; for example, your money goes into escrow, so that any foul play on your part and the programmer still gets paid; but any foul play on the programmer's part and the money comes back to you. Communications should be done through the website so that everything is documented, and their moderators are pretty quick at resolving issues, should you need them.

There are many "outsource" workers and groups who will do your task for very cheap and quickly, but watch out for bad quality code. Also make sure to have crystal-clear requirements, and document everything through the website. Anything said on there is like a contract, and if you put complete requirements up there, the coder will be required to complete them before they get paid. Conversely, the programmers NEED a clear specification of what needs to be done in order to accurately bid and estimate their time, and poor requirements are often the source of buyers taking advantage of coders, making them work extra before they get paid just because there was a misunderstanding.

I've had both good and bad experiences as a coder on the site, but it seems to me that buyers are treated very well; they are certainly in the position of power. Again, if you have a very clear idea of what needs to be done and you post all of your requirements upfront, you won't have any problems; coders will complete your task as you ask for it, or they don't get paid and you just try again.

# Answer
> 6 votes
Let's turn the question around: There are plenty of in-progress game projects on the Internet already. Why aren't you helping one of those, and would rather start your own?

When you figure out the answer to that, you'll have the answer to your question.

# Answer
> 3 votes
You guessed correctly that programmers are both in intensely high demand and full of their own projects. Your options are:

1. Offer to help a project of theirs in exchange for them doing programming for one of yours;
2. Have a fantastic idea no programmer would ever be able to deny (this never happens);
3. Get a student programmer that doesn't quite realize how the system works yet;
4. Open your wallet.

Remember that programmers are usually the ones most in tune with how long a project really will take. If no programmers are biting your hook, it's likely your project is not as feasible as you guessed.

# Answer
> 1 votes
The difficulty here is that you're asking someone else to do your work for you (particularly with programming). If you say "hey, I'm a game programmer and I'd like to make a game, but I need some help with design" it is probably a lot easier.

Joel wrote a great article on finding programmers here: http://www.joelonsoftware.com/articles/fog0000000050.html

Yes, it's geared towards actually *hiring* programmers and not getting them to do your work for free, but a lot of the same logic still applies. Offering vastly above market price will get their attention. Failing that, from their perspective, your project needs to be worth their time in other ways (the most likely of these being, if you've got a great game). You didn't say if you're actually willing to pay for the work done or not, so I'm assuming the answer to that is no, but feel free to clarify.

If you're envisioning some kind of "resource exchange" board where you say "hey everyone, I've got this Great Idea for a game, I just need people to make it for me"... yes, those do exist, and in my experience they're worthless. You see tons of posts from people wanting someone else to do their work, and next to no posts of people offering anything of practical value. If I'm a programmer, why would I spend my time making YOUR game instead of MINE, if I'm working for free?

There is, of course, another way around this: don't rely on other people. Learn to do it yourself. This has a lot of benefits. You get total control over the course and scope of the project. You don't have to rely on someone else screwing up your grand vision. You don't have to get into legally sketchy areas about who owns the work and the IP if it actually sells for real money. Given the number of really bad programmers out there, and the fact that the really good ones are going to cost you an arm and a leg, this is the best option for a surprisingly large percentage of projects.

---
Tags: software-engineering, project-management
---


# Question
Title: XNA 2D Collision Detection with Rectangles: Helper Objects?
Per this excellent question, and excellent answers, I am attempting to write a breakout clone.

Regarding the collision detection against the walls, does XNA provide a set of helper methods/objects to determine which side of the rectangle was hit? I'd like to use the Vector2.Reflect method to properly create a new velocity vector, but it requires the proper normal. I can write the methods to figure out which side was hit, and thus which normal to use, but I wanted to know if XNA provided code to handle this already.

# Answer
> 1 votes
I honestly don't know, but I would think breakout is one of the suggested games *because* that's eactly the kind of problem you learn to solve yourself. I'd go as far as to say that writing your own vector2.Reflect would benefit you.
I mean.....if you'd use supplied methods wouldn't you sidestep the learning/wing earning process?

# Answer
> 1 votes
I don't know if you can detect which side was hit by default (for a normal collision check in most cases the answer is no, it just returns a boolean of whether there's a collision or not), but there are other ways around this.

Obviously if you just say "is there a collision? Reflect" you can run into a problem where the ball hits the wall, reflects but not enough to actually make it back to "outside" the wall, reflects again, and so on every frame where it just gets stuck in the wall forever. So you need to avoid that. One of many ways of doing this: treat the ball as a state machine that is by default in the "non-reflecting" state. When in this state and you detect a collision, change it to the "reflecting" state. When in the reflecting state, ignore collisions, and only return to the non-reflecting state when there is NO collision.

Another problem: how do you tell the difference between a side collision (horizontal reflection) and a top or bottom collision (vertical reflection)? The original Breakout actually didn't make this distinction, so much; when the ball hit a brick, it would reflect vertically no matter where it hit, and the walls and ceiling were presumably hard-coded (checking the x or y coordinates of the ball). Changing the trajectory on collision with paddle is just a matter of comparing the x coordinate of the ball with the paddle to figure out sides. You could use that method for other things as well, so if you wanted the ball to reflect horizontally OR vertically against a brick, I'd be comparing the coordinates of the brick with the ball.

---
Tags: xna, collision-detection
---


# Question
Title: Attributes for calculating a hit in a turn based game or Roguelikes
I'm trying to figure out a good formula for determining a hit when the player attacks an enemy in a Roguelike. I'd like to come up with something simplistic but, still true to the way it's done in D&D or popular Roguelikes like AngBand or NetHack.

What I have so far is adding the differences between player and enemy attributes, along with a random integer:

```
if ((player.dex - enemy.dex) + (player.speed - enemy.speed) +
    (player.luck - enemy.luck) + random_integer_below_6()) >= 10) {
    hit(enemy);
}

```

This makes for unnatural gameplay: the player never misses weak enemies and vice versa for strong ones. Does anyone know of a guide to attribute based combat used in turn based games etc? Should I (and can I) copy the D&D rules verbatim?

# Answer
I'd figure out what you want the "guaranteed hit" and "guaranteed miss" chances to be (i.e. the chances for a kitten to hit a dragon and a dragon to miss a kitten). Store your random result, and before applying power differences, mark a hit if it's within those bounds. That will prevent the 100% hit/miss chance problem... although there's another option for always providing a chance of a hit, detailed below.

D&D is a "flat" system, where probability is evenly distributed across the possible roll results. Other systems use a more curved distribution, usually achieved by rolling multiple dice and adding them. It's easy enough to create a curve like this (rand() + rand())/2 comes to mind).

Another possibility is "exploding dice." In systems like Shadowrun and Savage Worlds, rolling the maximum possible die result lets you reroll that die and add the new result. In your game, you'd test to see if your random result was above a certain threshold, and if so, roll again. If you let dice explode indefinitely, then even the lowliest goblin has a chance to hit a god, and you don't need an explicit "guaranteed hit" mechanic.

So one possible approach with a curved roll, guaranteed chance of missing, and exploding dice would be something like:

```
function getRoll():Number
{
  var result:Number = (rand() + rand()) * 3; //Curved result from 0 to 6
  if(result > 5.75) result += getRoll(); //Explode over a certain threshold, recursively
  return result;
}

function attackHits():Boolean
{
  var roll:Number = getRoll();
  if(roll < 0.25) return false; //Guaranteed chance of miss
  else return ((player.dex - enemy.dex) + (player.speed - enemy.speed) +
    (player.luck - enemy.luck) + roll) >= 10; //Your original test.
}

```

Of course, that's untested and unbalanced; you'd want to adjust all those magic numbers until they felt right.

As for copying rules verbatim, there are legal and ethical issues with that. You're fine pulling inspiration from D&D and other tabletop games, though; that's how they all got designed in the first place. You don't need to show the player exactly how the rules work, either, and you may find that using a smooth floating point dice curve leads to a better feel than restricting yourself to the integer constraints of physical dice.
> 18 votes

# Answer
I'm assuming this is a game balance question and not a coding question, and there are a lot of ways to handle this. From your existing algorithm, I suspect you are making it more complicated than it has to be (three attributes AND a random number make for an extremely muddy system from the player's perspective). My first instinct is to simplify!

Favor attributes that do multiple things, rather than results that are determined by multiple attributes. DEX works just fine as the primary determiner of to-hit chance; the addition of everything else just serves to make it harder to balance. Think of it this way: a player's expected damage on each hit is their to-hit % multiplied by their average damage when they do hit. How do you plan to calculate an "expected" or "typical" to-hit % with so many variables?

I see another issue, which is that your formula doesn't scale, and this is probably what you're experiencing. Assuming DEX, LUCK and SPEED tend to increase over the course of the game, differences between player and monster in those stats will also tend to increase. Just as an example, if a player's early-game DEX is in the 4 to 6 range and so are monsters, that's a 10-20% to-hit modifier. If the range is more like 10 to 20 in later stages of the game, that's up to a 100% modifier.

One way to fix that is to keep the stats fixed. Player and monster ranges are the same throughout the game, and getting something like +1 DEX is a huge deal, extremely rare, and treated as such (if it exists at all). Then your formula will work fine for the entire game, and you'll see a player with about the same to-hit chance throughout.

Another way is to change that hardcoded "10" to scale with level, so maybe it's "10 + monster level" or "10 + dungeon level" or something, which causes a slight increase in difficulty as the game progresses unless the player levels up their stats accordingly.

A third way, as others have said, is to set hard caps on the highest and lowest acceptable to-hit %, and simply say "if the calculated value is less than X, use X instead".

For the sake of completeness, I'll point out that there's no absolute law that you MUST include a to-hit roll in the first place. Taking an action in a game that's ineffective is not particularly fun, and doesn't really add to the experience except in rare cases. An alternative is to let players ALWAYS hit, and just mess with the damage range so that sometimes they'll do a lot less damage than others. Remember that complex systems are more fun for the designer than the player.
> 6 votes

# Answer
You might want to add critical hits (usually can't miss, bonus damage) and critical misses (flat chance to miss no matter what, possibly dazes the player).
> 3 votes

# Answer
A lot of games use a five percent change of a hit regardless of all factors in addition to the normal hit formula.
> 0 votes

---
Tags: roguelikes, turn-based
---


# Question
Title: Getting It Done vs Solid Software Design?
With barely enough time at our hands to complete the games we craft, how can you strike a good balance between solid software architecture and making good progress to get it all done?

My personal challenge: How about being effective today and long-term thinking at the same time? Plus, while you're doing it you may just as well want to learn new things on the way instead of resorting to the same repetitive patterns you've been using those past 5 years?

# Answer
> 21 votes
The less experience you have, the more time you waste with up-front design. Making good designs is something that you will learn by doing it and then seeing/evaluating how it turns out. Some decisions have far reaching but obscure implications. After some games you will probably be able to make the initial design pretty solid and it will pay off to invest some more time to this stage.

My motto: get things done in the first place, but use you common sense to detect what components are more critical than others and designs those pretty well, within your time limit. For example, if AI is critical to your game, make sure that you can easily extend/change it later on. Or, if you're going to write a component that you will use in every game, design it for reusability. Track your time and don't go wild on designing. Set a design-deadline and after that, start hacking everything in to get your release-deadline. But make sure you note what points need refactoring/redesigning afterwards and calculate in some time before you start on the next game to improve those things, so that they don't get to bite you back!

A good advice: if you have to choose between two options, don't linger too long over details. Most often, there is no "good" or "bad". In some situations, A will be better, in some, B will be, and overall, the difference between both may not always be worth the time.

There is a lot of experience to gain in designing software or games, so make sure you spend some of your time on research (e.g. reading a book on design, reading about others experience, talking with fellow programmers about your designs, etc...).

# Answer
> 13 votes
People are terrible at predicting the future. This is especially true for games, where requirements can change on a daily basis.

There's a principle called YAGNI, aka "You Aren't Gonna Need It", which basically says that you shouldn't implement something until you *know* you're going to need it.

I've seen so many systems get bogged down with architectural rigidity that didn't actually use any of it since the features people thought they were going to need never got around to being used.

My personal philosophy is Do the Simplest Thing That Could Possibly Work. That being said, there's a difference between Getting It Done and Hacking Shit Together. Writing code with a purpose shouldn't imply doing things that generate "code smell" like making everything public, of having blob classes that do everything, or any of those dozens of other things that signify "bad" code.

# Answer
> 8 votes
This evaluates to true in my mindset today:

* Pragmatism over Ideology
* (1) Make it work (2) then make it right - game over if you forget step 2
* Release it!
* Too much up-front design will be a waste of time
* TDD and Clean Code leads to more simple, more stable software designs

# Answer
> 5 votes
I'm friend of software rapid prototyping. Especially during game development. It's good for quick learning , testing and useing things. For close to hardware programming or complicated algorithms is the best method for me.

```
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
 Testing();
 LotOfFixing();
 PlayingWith();
 bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();

```

My version of Rapid Prototype has to have proper prototype crust:

* Max friendly input interface to configure directives and setup variables or data.
* Stable exceptions and errors handling.
* Online like debuger function but on level what you need to.
* Max friendly output interface for showing or capturing results on all posible and necessary ways.

Advantages:

* You can improve RapidPrototype crust during whole development.
* You can see and setup your code in many ways.
* You can focus only to theory and problem what You need to solve.
* You can fast develop any new parts of project and try it with the rest of final things.
* You can deliver new things for useing in content filling more quickly and finalize it later.(Especially in sandbox case)
* You can easily describe and show priciples or solutions to anybody else. Online.
* Funcional and transparent prototype is the best source of information for final code(anybody else can do it).

If You do it well You Can have real debug/learn version of your product on the end.
We are using it in our project and we are happy with it.

# Answer
> 1 votes
Have a look at agile software development. Although it is not a silver bullet, it aims to do both (get it done **and** have solid software design).

---
Tags: architecture, time-management, development-speed
---


# Question
Title: How can I integrate IK into a hierarchical editing environment?
I have a situation where I'm trying to push the output of an IK solver back into a user editable joint hierarchy (which stores components as it's primary source), and I'm not sure how to go about it.

My IK solver returns three world space transforms representing the position and orientation of a chain of joints (0,1,2).

A: I need to turn this into a hierarchy so that transform 2 is local to transform 1, and transform 1 is local to transform 0. Now I have local transforms for each joint.

B: Further: I need to decompose each joint's new local matrix into source Translation, Rotation and Scale.

Can anyone give me some tips for each step? I have some ideas, but I'm worried that to do B I need to particularly careful with A.

Edit:

For example if I get my world matrices like this:

```
M4 world_mats[3] = IK_solve( ikparams );

```

And then convert them to local like this:

```
M4 local_mats[3] = GenerateLocalChain( world_mats );

```

And then extract components:

```
Scale     s[];
Rotation  r[];
Translate t[];

foreach ( matrix in local_mats )
    Decompose( matrix, s, r, t );

```

How can I implement the `Decompose()` function to match matrices created in`GenerateLocalChain()`?

# Answer
If your matrices are invertible, which they should be, then to get the local B just do (A^-1) B or B (A^-1) depending on the order they were multiplied to get to their current state. You can repeat this process to get back the other matrices.

For part B lets say your matrix was made by S\*R\*T. I'm pretty sure you should be able to read of the translation as the first three elements of the last row. The determinate of the upper 3x3 matrix is the uniform scale (I am assuming the last column is 0,0,0,1). You can remove the scale from the 3x3 rotation matrix by dividing by the determinate of the upper 3x3 matrix.

If you are introducing non-uniform scale I'm not sure how to get your matrices back, I'll think about it. IK is not going to need to scale things, so if your bones have non-uniform scale I bet you can bake it into the geometry before you start.
> 1 votes

# Answer
For step A,

LocalTransform for your joint = Inverse(WorldTransform for parent joint) * WorldTransform for your joint. (If you're dealing with orthonormal matrices, Transpose can replace Inverse)

For step B, Assuming your matrix is in column major form:

* For extracting translation, just grab the first 3 components of the last column.
* For extracting non-uniform scale, assuming your matrix is in column major form, you should be able to extract the scale components by determining the length of the vector in the first 3 components of the first column, 2nd column, 3rd column eg.

```
Vec3 getMatrixScale(Matrix* matrix)
{
  Vec3 scaleVec;
  scaleVec.x = Vec3Length((Vec3*)&matrix->data[0]);
  scaleVec.y = Vec3Length((Vec3*)&matrix->data[4]);
  scaleVec.z = Vec3Length((Vec3*)&matrix->data[8]);
  return scaleVec;
}

```

EDIT: How you decompose your matrix will depend upon how apply (Rotate, Scale, Translate) to reconstruct your local transform during animation. If it is indeed S\*R\*T as Jonathan mentioned, then what I've already described should do the trick.

If you want to know specifically about transforming rotation representation to/from matrix form then you'll have to clarify exactly how you represent "Rotation". The links I posted deal with common variants of this.
> 1 votes

---
Tags: animation, skeletal-animation
---