# Question
Title: Are there cases where globals/singletons are useful in game development?
I know that having global variables or singleton classes creates cases that can be difficult to test/manage and I have been busted in using those patterns in code but often times you gotta ship.

So are there cases where global variables or singletons are actually useful in game development?

# Answer
These things can always be *useful*. Whether or not it's the prettiest or safest solution is another matter, but I think game development involves a certain degree of pragmatism.
> 30 votes

# Answer
Definitely a non-exhaustive list, but here goes:

## Cons

* **Lifetime management**. Singletons and globals may like to start up before key systems (e.g. heap) are initialized, depending on how you set them up. If you ever want to tear them down (useful if you're doing leak tracking, for instance) you have to be careful about the teardown order or start getting into things like phoenix singletons. (See static initialization order fiasco.)
* **Access control**. Should rendering only have const access to game data, while update gets non-const? This may be harder to enforce with singletons and globals.
* **State**. As Kaj pointed out, it's harder to functionally decompose and transform singletons to work at all in a non-shared-memory architecture. It also has potential performance implications for other types of NUMA systems (accessing memory that isn't local). Singletons usually represent centralized state, and thus are the antithesis of transforms that are made easier by purity.

## Either pro or con

* **Concurrency**. In a concurrent environment, singletons can either be a pain (you must consider data race / reentrancy issues) or a blessing (it's easier to centralize and reason about locking and resource management). Clever use of things like thread local storage can mitigate potential issues somewhat, but it is not usually an easy problem.
* **Codegen** (depending on compiler, architecture, etc): For a naive create-on-first-use singleton implementation, you may be evaluating an extra conditional branch for each access. (This can add up.) Multiple globals used in a function may bloat the literal pool. A "struct of all globals" approach may save space in the literal pool: only one entry to the base of the struct, and then offsets encoded in the load instructions. Finally, if you're avoiding globals and singletons at all costs, you generally need to use at least a little extra memory (registers, stack, or heap) to pass pointers, references, or even copies around.

## Pros

* **Simplicity**. If you know the cons listed above don't affect you as much (e.g. you're working in a single-threaded environment for a single CPU handheld platform), you avoid some architecture (such as the aforementioned argument-passing). Singletons and globals may be easier to understand for less experienced coders (although it may be easier to use them incorrectly).
* **Lifetime management** (again). If you use a "struct of globals" or some mechanism other than a create-on-first-request, you can have easy to read and fine-grained control over initialization and destruction order. You automate this to some degree, or manually manage it (having to manage it may be a pro or a con, depending on the number of globals/singletons and their inter-dependencies).

We use a "struct of global singletons" a lot in our handheld titles. PC and console titles tend to rely on them less; we'll switch more toward an event-driven/messaging architecture. That having been said, the pc/console titles still often use a central TextureManager; since it usually wraps a single shared resource (the texture memory) this has made sense for us.

If you keep your API relatively clean, it might not be too terribly hard to refactor out of (or into!) a singleton pattern when you need...
> 16 votes

# Answer
They can be very useful, especially during prototyping or experimental implementation, but in general we prefer passing references around for manager like structures, that way you at least have some control over where they are accessed from. The biggest problem with globals and singletons (in my opinion) is that they are not very multithread friendly, and code that uses them is much harder to port to non shared memory, like SPU's.
> 4 votes

# Answer
I would say that the singleton design itself isn't useful at all. Global variables can definetly be useful but I'd rather see them hidden behind a well-written interface so that you aren't aware of their existence. With singletons you are definetly aware of their existence.

I often use global variables for things that need access all through out an engine. My performance tool is one good example which I use all over the engine to call. The calls are simple; ProbeRegister(), ProbeHit() and ProbeScoped(). Their real access is a little bit more tricky and uses global variables for some of their things.
> 2 votes

# Answer
The main problem with globals, and poorly implemented singletons is obscure construction & deconstruction bugs.

So if you work with primitives which don't have these issues or are very aware of the issue with a pointer. Then they can be used safely.

Globals have their place, same as gotos and should not be dismissed out of hand but instead used with care.

There is a good explanation of it in the Google C++ Style Guide
> 2 votes

# Answer
Globals are useful while quickly prototyping a system that requires some state between function calls. Once you've established that the system works, move the state into a class and make the functions into methods of that class.

Singletons are useful for causing problems to yourself and others. The more global state you introduce, the more issues you will have with code correctness, maintenance, extensibility, concurrency, etc. Just don't do it.
> 1 votes

# Answer
I tend to recommend using some sort of DI/IoC container with custom lifetime management instead of singletons (even if you use a "single instance" lifetime manager). At least then it's easy to swap out the implementation to facilitate testing.
> 1 votes

# Answer
If you want the memory saving features of a singleton perhaps you could try the flyweight design pattern?

http://en.wikipedia.org/wiki/Flyweight\_pattern

As far as multi-thread issues mentioned above it should be fairly simply with some foresight to implement a lock mechanism for resources that may be shared between threads. http://en.wikipedia.org/wiki/Read/write\_lock\_pattern
> 0 votes

# Answer
Singletons are a great way to store a shared state in a early prototype.

They are not a silver bullet and come with some problems, but they are a very useful pattern for certain UI/Logic states.

For example in the iOS, you use singletons for getting the \[UIApplication sharedApplication\], in cocos2d you can use it to get references to certain objects like \[CCNotifications sharedManager\] and personally I usually start out with a \[Game sharedGame\] singleton where I can store state that is shared between a lot of different components.
> 0 votes

# Answer
Wow, this is interesting to me, as I've never personally had a problem with the singleton pattern. My current project is a C++ game engine for the Nintendo DS, and I'm implementing a lot of the hardware access utilities (ie. VRAM Banks, Wifi, the two graphics engines) as singleton instances, because they are intended to wrap global C functions in the underlying library.
> 0 votes

# Answer
Only when you have an item that only has one controller but is handled by several modules.

Such as, for example, the mouse interface. Or joystick interface. Or music player. Or sound player. Or the screen. Or the save files manager.
> 0 votes

# Answer
Globals are much faster! So it would fit perfectly for a performance intensive application, like a game.

Singletons are a better global, IMO, and thus the right tool.

Use it sparingly!
> -1 votes

---
Tags: software-engineering, design-patterns
---


title: Agency versus story

text:
# Question
Title: Agency versus story
What are good ways to reconcile a desire to allow the user to have freedom of choice and have their choices affect the world, with the desire to be able to have a story without the player 'ruining' it?

# Answer
> 3 votes
Why is linear vs. nonlinear narrative something that has to be "reconciled"?

Some games tell great stories. The two most oft-cited memorable moments, the death of Aerith and the death of Floyd, were both completely out of the player's control and happened in non-interactive cutscenes (or equivalent). Nothing wrong with this.

Some games let the player tell their own stories. The Sims series takes this to a rather extreme level, and the series has done quite well for itself, thankyouverymuch. Sure, a lot of the stuff players make is worthless... Sturgeon's Law and all that... but the flip side is that you've got a few real gems in there from really creative players, expressing things that just couldn't be done in a linear game.

Some games split the difference, giving the player a choice of several paths or stories, so you can think of this less as something where each game lies along a continuum with "fixed, hand-designed experience" on one end and "player-driven sandbox" on the other. Some players prefer one, or the other, or anything in between. So I think the real question here is: what kind of game do you want to make along this continuum, and how do you make it the best game you can?

# Answer
> 7 votes
One relatively easy pattern I've seen several games use to a varying degree of success is to have the player change something about themselves instead of something about the world. Red Dead Redemption is a good recent example of this. Basically the idea is that you try to structure your player's goals in a way that they can choose to do "good" vs. "evil". The end result is mostly the same (or if it's different the difference doesn't affect much outside of the little area of the world).

The way the player feels like the world is changing is then solely due to the semi-emergent behavior of the NPCs reacting to the player given his notoriety. You set up your NPCs to say random things to the player and have good and evil player chit-chat banks. You might even go so far as to start structuring the major quests' wording depending on how good/evil the character is. Maybe you set up some kind of ancillary "faction" system where if the player starts down one path they can reinforce it with a separate (but smaller and therefore more maintainable) set of quests to accomplish.

Of course it doesn't have to be good/evil. You could do stealth/action, or whatever kind of choice dichotomy you set up for your player.

# Answer
> 2 votes
Writing branching story-lines is effective but time consuming and doesn't account for player autonomy to do random things. Players will enjoy the ability to change the story but will still know they are on a planned path. Mass Effect is a good example of this.

Separate story elements from player autonomy like Red Dead Redemption as Tetrad pointed out. This makes it difficult to allow players to change the story and is very "Theme Park" design.

Honestly playing a game where you could ruin the story would actually be kind of fun, but you would have to have an appropriate response from the game for doing that though.

It all comes down to how well you plan out your story.

**EDIT**

Game Career Guide just released this article on Nonlinear Narrative.

# Answer
> 1 votes
Out of all the "systems" I've seen, new and old, implemented in games, I think Morrowind got very close to achieving a solid balance of freedom coupled with a reason to play the game.

That is, an extensive, entertaining, epic main-quest and lots of side-quests. And the main-quest actually meant something... as say, compared to Fallout3, *yawn*.

For example, Borderlands could have been something very special if they had realized this. Oh, and in Morrowind, you could easily ruin the "story." Bug or Feature? :-)

# Answer
> 1 votes
Look at Deus Ex and the Ultima series for examples of games that have a strong storyline but give the player plenty of leeway on how to achieve their goals.

# Answer
> 0 votes
Ever try playing a Way of the Samurai game? Your decisions change how the world reacts to you as well as change the story. The caveat though the usually use active time constrains and short time for each play through this way they can minimize the variations available.

---
Tags: game-design
---


# Question
Title: What are some techniques used for mouse tracking, with a bit of "emulated lag"?
I am trying to implement a system, where the cursor (in my case the player's avatar) is always about 1.5 seconds (a configurable interval) behind where the mouse actually is. If I change the cursor's location every time through, I get an emulated mouse cursor with no delay, I'm wondering if there are any pre-canned type of solutions I can throw at this before I "roll-my-own." Source code or even just basic steps you've used would be helpful.

# Answer
> 7 votes
I don't think there are any pre-canned solutions; at least I haven't seen any. But here is the logic to such a thing.

What you essentially want is a **queue** of mouse positions and timestamps. So define an object, let's call it `MousePositionSnapshot`, which has two members, `time` and `position` (or separate x,y if you want). And then define your queue of `MousePositionSnapshot`s. Each update, make a new MousePositionSnapshot with the current timestamp and the current position of the mouse, and push it onto the head of the queue. Then peek at the tail of the queue to see if the timestamp is delayed enough for you, and if so, pop it off the end of the queue and move the emulated cursor to the given position.

Or, if you have a fixed framerate, you could skip the timestamp since you know how far apart each update is, and just keep your mouse lag in terms of number of updates; if the queue is smaller in length than that amount of updates then don't pop-and-move, otherwise just pop and move the emulated mouse each frame.

By the way, Queue may already be implemented in your language of choice; it is part of the C++ standard library and of course exists in java.util.Queue for Java.

# Answer
> 4 votes
Ricket's answer was my first idea too. If you draw all the mouse pointers in your queue you get a nice trail as well. Another option would be to linearly interpolate your detected mouse position and the actual mouseposition, that way it will gravitate towards the mouseposition with a delay, but it won't actually follow the exact path the mouse travelled. They both achieve the same (configurable delay for the mouse to catch up) but in a decidedly different visual fashion.

---
Tags: path-finding, control
---


# Question
Title: In Cocos2D, how do I check for collisions against an arbitrary user-drawn shape?
I want to detect a collision between a sprite and a user-generated shape of some sort.

For example. There are 3 objects on the screen. The user takes their finger and draws an abnormal shape around 2 of the objects. I need to detect those 2 objects.

How do I approach this efficiently using Cocos2D?

# Answer
There's a very easy solution for that particular example.

I'm assuming your arbitrary shape is just a series of points.

Draw a ray from each of your objects in any direction. If the number of times it intersects a line segment on your shape is even (including zero), you are outside of the shape.

If the number of times you intersect is odd, you are inside the object.

Ray/line segment collision is a pretty easy algorithm to find/implement.
> 10 votes

# Answer
Sure, I had to figure that out for my game Star Catch. There may be better ways of doing it but this is how I did it. I actually found the algorithm online (sorry I can't remember the source) I did a search for detecting a point inside a polygon.

I created a NSMutableArray to hold my point. I add the points in my touchevents.

```
- (BOOL) testNodeInLoop:(CCNode *)node {

    CGPoint prev;

    // This is more accurate point for the node
    CGPoint absPoint = [node convertToWorldSpace:CGPointZero];

    float x = absPoint.x;
    float y = absPoint.y;

    BOOL isIn = NO;

    CGPoint cp;

    for(int i = 0, j = [points count] - 1; i < [points count]; j = i++) {
        [[points objectAtIndex:i] getValue:&cp];
        [[points objectAtIndex:j] getValue:&prev];

        if( ((cp.y > y) != (prev.y > y)) && (x < (prev.x -cp.x) * (y - cp.y) / (prev.y - cp.y) + cp.x)) {
            isIn = !isIn;
        }
    }
    return isIn;
}

```

Let me know if this is helpful.
> 3 votes

# Answer
The book "Real time collision detection" has a section about line/segment collision detection. Example via Google Books: http://ow.ly/2gjQf
> 2 votes

# Answer
For pixelwise collision checks there's a nice tutorial series on the XNA developer site.
http://creators.xna.com/en-US/tutorial/collision2dperpixeltransformed
One optimization you can use that wasn't used in those tutorials (oddly enough) is that in most cases only the outline needs to be checked, saving precious cycles.
Edited to add: Lousy answer, misread the question. The tutorials are still pretty decent though if you want to read up on per pixel coldet.
> 0 votes

---
Tags: objective-c, cocos2d, collision-detection
---


# Question
Title: Mahjong solitaire - navigating between open tiles
I am looking for an algorithm to help me navigate between 'open' tiles in a Mahjong solitaire game. The game is to be played on a limited device with only left-right-up-down buttons and I want to speed up the time it takes to reach the appropriate tile. Toward this goal, I have made the movement work between 'open' tiles (tiles that you could move).

For example, pressing down will find the closest open tile below the one you are on, etc... The problem is that some tiles are really tough to get to. I am sure there are some known algos for this soft of things, but I can't find anything online since searching for 'Mahjong' returns 10 pages of free flash games.

Anyone has any idea?

# Answer
Branching sucks. Every time the user has to look at the screen, comprehend it, and then make a decision, you're slowing the game down. With your somewhat-chaotic "move between open tiles" algorithm, nobody but an expert is going to be able to play the game without constant look-comprehend-act-look-comprehend-act cycles.

Here's how I'd do it. Make a horizontal bar on the screen. That bar can be moved up and down by the up and down buttons. No branching - you hold up, it moves up, you hold down, it moves down. Then the user can hit left and right to toggle between available tiles. There's branching here, but very little, since Mahjong is a mostly-vertical game. Most of the time it'll either be "I'm on the right tile" or "I'm on the wrong tile, but the other one is right".
> 2 votes

# Answer
I would experiment with exploiting the fact that Mahjong has two sides. Left/Right to control which side you are on. Up/Down moves to the next tile up or down the same side by row/height.

e.g. When pressing Down: if there is a tile at a lower height than the current selection, move to that one. If not, move to the highest free tile in the next row down. Pressing up can move up in elevation or up to the next row.
> 1 votes

# Answer
You could search in both directions - from the current tile to the nearest neighbour, but also looking to see if another tile has the current one as nearest in the opposite direction. Move to the closest of those two if different.
> 0 votes

# Answer
I'd suggest implementing all suggestions given, and a few more you could come up with and have people try it without explanation. That alone will tell you what works, and might give you suggestions for what might work better.
It's hard to beat feedback from real users.
> 0 votes

---
Tags: game-design, algorithm, control
---


title: How do you start development of a game?

text:
# Question
Title: How do you start development of a game?
When you start a new game project, what do you do first? How do you begin? What gives you the best head start toward completing the project rather than burning out before it gets anywhere?

Mods please help with the tags... I have no clue how to categorize this... :)

# Answer
> 27 votes
Prototype. Try to implement your game concept using some sort of quick iteration tool. Try python or just some easy-to-work-with open source api to get your "game idea" running. Try to simplify as much as possible, use balls instead of characters, get the vision down on some sort of visual representation. That way you can always look at it, discuss it, debate it and give feedback. Put a set timeline for each prototype (maybe 2 days? maybe a week tops?). That way you only get to do as much as you want to do in the prototype.

Sometimes you might be able to plot your idea down on a little piece of paper if it's simple enough. Once you have your idea set, start planning to see what kind of systems and mechanics you need. Try to structure the time-lines for things and see if it's possible to commit to them. If you're a bunch of people that want to make a game together, you need to do this together. Do it over a beer, either in person or using a voice-chat program. Once you know what to do - everyone can start with what they're doing. Make sure that you have communication. Try to have a team-meeting with a frequent interval dependant on how much time you guys want to put down.

If you are making your own game, remember that time is limited and you can't do everything pretty. Maybe spheres and cubes will be enough to get your graphics going if you're a programmer. Realize your limitations and work with them rather than against them.

I hope these few tips help :)

# Answer
> 29 votes
As a teacher, I see a lot of student hobby projects that fail. Invariably, the single highest reason for failure is overscope: the project starts out as this grand vision of a huge thing that's too big to possibly complete, more and more people are brought on until it collapses under the weight of its own design, and everyone leaves feeling frustrated and demoralized.

The best remedy for this is to constrain your scope ruthlessly. Instead of saying "how do I keep my energy up enough to finish a long project?" you should instead be saying "how do I design a project that's short enough that I can finish it before I get bored with it?"

"Game jam" events (make-a-game-in-a-weekend sorts of things) are a great way to get started, and they're great for building good habits when making rapid prototypes. At WORST, you spend a weekend making a lousy game... you probably learned something in the process... AND you saved yourself months of working on an idea that ended up not being as cool as you originally thought. At best, you find that you have something really special, and can start adding small features one at a time until you have a full-featured project.

On my own small hobby projects, the other thing I've found that helps is to start with a complete list of all known development tasks that need to be done, ordered, and scaled down so that each individual task is doable and testable in maybe 30 to 60 minutes, tops. It is very energizing to do a small task, see it working in the game, and crossing it off the list... which then just makes it that much more likely I'll do the next thing on the list since the last one was so easy, and then the next... sort of like eating potato chips.

Another hint: whenever you successfully implement a new feature, make a backup (or use source-code control, which is basically the same thing, but not everyone uses source control if it's just them working on their own personal project). That way if you totally screw up the code at 2am and can't figure out how to get it back in a working state, the project isn't dead and doesn't have to be restarted from scratch; instead, you just roll back to the last completed and working milestone, and try again.

# Answer
> 12 votes
I would say the really important thing is to always have something showing.

I mean, you could spend ages and ages on a data driven entity system, with deferred rendering and really high FPS, and all that. But chances are you'll get bored of having nothing to show, and give up. Whereas, if you first try getting a few models on the screen, move them around, and go from there, you'll have a much better chance.

I think the first is bottom-up development; working from a framework up to the actual content, and the second is top-down; working from getting some content and building up from there.

A little point, but something that really helps.

# Answer
> 10 votes
As a lone developer I find it helps to implement sound early on. I find it motivates me to work harder on the other features because even in the first few weeks (with graphics limited to brightly-colored polygons, flaky collision detection, missing controls etc.) the sound still gives it a feeling of being "nearly there."

# Answer
> 6 votes
I once worked on a project that was seeming to do everything right. They'd set up a website/bulletin board for everyone working on the project to collaborate. They'd presented everyone with specific timelines and goals and the game itself was a good concept. Despite this, it still only took about 2 months for people to start dropping off the map. After 3 months, development was finished and the game was never completed.

So if you're working in a team then I think you need incentive. You need someone continually in contact with everyone making sure they're doing the work and reminding them *why* they want to keep doing it.

If you're working alone; I'm not too sure. I'm terrible with artwork etc. so I mostly concentrate on the engine side of things. This is always enough to keep me interested :)

Developers will always tell you not to move onto new areas until you've finished the one you're working on now. If you're trying to build a game by yourself then I don't think it's too heinous if you decide to break this rule. Working on something fresh is a good way to keep your excitement levels up!

# Answer
> 3 votes
There are a lot of good answers, but I'll add mine as well:

* Always have a running project that you can look at. Do not go in tank mode where you code for 2 weeks without something to show for it.
* Keep the feedback loop short (this is further expanding on the previous point): code a little new feature, show it around, get feedback.
* Do not *ever* implement something you don't need now, which is the corollary of: never build a framework first thing in a project.

I would like to expand on the last point a bit, since I've seen it happen multiple times: never build a framework first. There are many reasons, but basically, you won't have the necessary vision to do things right, you will waste a lot of time thinking about what-ifs and you will lose morale when after X days/weeks of working, there will be nothing to show for it.

The problem is that framework are often necessary to the end product, so, what's a coder to do? Start building specifically, with hard coded values. When you'll need to change a value, make it modifiable in options. When you need to make two similar things, abstract the similar pieces together, but keep the rest specific. If you keep doing this you will actually end up with a framework that springs into existence due to necessity, instead of wasting time on what-ifs at first.

After you build you Xth game, then you can consider starting with the framework, you'll have enough experience by then to pull it off.

# Answer
> 2 votes
I had two or three notebooks worth of ideas before I actually started developing my first game. I spent several months playing similar games for research purposes--determining which features I liked or didn't like. I generally try to focus on the mechanics first and tackle the look and feel later (but being careful not to ignore usability). I'd recommend having a rough but thorough design before you dive into development. Don't try to nail down every detail too early, as your design will necessarily evolve to accommodate playability issues, technology limitations, etc.

# Answer
> 2 votes
Make sure your idea is full by brainstorming it and writing down some key design goals. I go through a process I call finding the game 'soul'. IE what is the main reason I'm making this game. From here I flesh out some more concepts and ideas that will support this main goal. This entire process can take hours, days, weeks, or longer depending on how the idea comes to you.

From here, get something visible and kinetic. I find that being able to play with the game and get feedback from it is vital in keeping motivation up. I tend to implement visual and sound effects, as well as simple input handling and processing just so something is 'happening' and it feels like a reality rather than a dream.

No matter how your development strategy goes, I cannot emphasize enough that you don't get wrapped up in trying to design and code a game "engine". Every feature that has no visible or tactile effect on the game will offer very little reward. To help offset this with the essential core systems, put up development info on screen. IE FPS, AI variables, and any other text that will help expose that something is there that wasn't before. There is nothing more draining than spending 10 hours coding a system, compiling, and having the exact same experience as before.

I wrote an article several years ago about finding your games soul that you may find of interest here: http://deleter.phatcode.net/index.php?page=articles&a=8

edit: And one more thing that I see mentioned in another post I want to elaborate on. Play games not only while designing your game, but any time you aren't feeling very motivated to work on your own game. I find that playing similar games helps me remember why I want to make my game and helps give me that extra boost I need to keep going.

In addition, you can build up an "inspiration bank" of pictures, videos, music, and sound clips that all contain elements of what you want to put in your game. Any time you need direction, return to these sources to help guide your decisions. This will help keep you motivated and on track.

# Answer
> 1 votes
I usually focus on the UI first. It helps me envision how the game will play. Also I tend to work on easy thinks first so I do not get bogged down in something.

# Answer
> 1 votes
Start with a game concept, set the reason for the game, gameplay, look and feel of the game you want to make.

From there you can start making a features and asset lists so the programmer and artist can at least start working on something, while the designer does some thinking or tweaking the game mechanics.

This way you at least have some code and assets within a few days or weeks to boost morale and kick start your project.

# Answer
> 0 votes
For me, it helps to mentally 'map out' the game idea before starting it. I'll try and figure out the main mechanics, a basic structure of the internal game, maybe some little details about how i want it to work. Then i apply rubber to road, and start work, bending or breaking parts of my mental map where the code needs a different setup. I might write some things down (a backstory, maybe the key features), but at that point the design is usually shifting too much for a document to be useful.

Otherwise, i kinda stall out with it ending up being a faled project early on :/

---
Tags: planning
---


# Question
Title: The pros and cons - DX9 moving to DX11 render?
We are a "nano" game dev company working on REFUSION. DX9 renderer is almost done and question is: Should we move it to DX11 or not? Anyone have experience with this?

Here are some videos from dev progress from the very beginning:

Dev test videos

EDITED: I'm going to ask more fundamental. What about NextNextGen XBOX1080 or PS4?
When? Resources? Architekture? PC DX11 -12 , next XBOX, next PS relations? Future?

# Answer
Regardless of your technological stance, the question should be framed in terms of your market. Are you going to be creating a game that runs on all available hardware? Or are you going to be the next Project Offset?

According to Valve DX11 capable hardware is only 5.6% of the market.

The other factors are - does your "nano" team have the bandwidth create the content and pipelines that take advantage of more recent hardware? Or are you going to be beg/borrowing/stealing art to ship something?

Note that Valve themselves support a huge range of hardware. They have a scalable engine, and the resources to do so.

EDIT: Personally, I would concentrate on shipping something that makes money as soon as possible. Yes you will need to to refactor later, even if you design your engine well.

Remember your market - they point of the game is to sell. As a compromise, I would probably target DX10 as a minimum spec. You'd get around 50% if you shipped tomorrow, and the interface is a lot cleaner than DX9. I believe, but I'm not certain, that the API difference between DX10-11 is a lot smaller than DX9-10.
> 0 votes

# Answer
DirectX 11 is a much cleaner and much more powerful API than DX9 without any legacy fixed function stuff. It also allows to use DX9 and DX10 class hardware through "Level 9" and "Level 10" with the same interface.

Furthermore, you can render the same scene more efficiently than with DX9. This results in higher framerate or better visuals on the same machine.

But for a small indie development I would not take the step yet. You will completely lose the XP install base.
> 7 votes

# Answer
An immediate point is that if you have solely DirectX11 rendering, you miss out on any users still on Windows XP.
EDIT: After misreading as the project was almost finished, I think it would be good to switch to DirectX 11, since in 2 years, DX12 may be released. Though I would keep a backup option of 9 available, in case there are any xp users still.
I do not have any DirectX experience, but for the end user, there is not much difference between DirectX9 and DirectX11 features, unless they have very good eyesight and pay attention to graphics.
And a quote from the article:

> What's the good news? In our testing, the DirectX 11 code path provided superior performance compared to DirectX 9 in many cases, even though the enhanced effects were enabled.
> 2 votes

---
Tags: graphics, 3d, directx, directx11
---


# Question
Title: Accuracy and frame-rate in a rhythm game
My question is related with Fixed time step vs Variable time step. But where a fixed frame-rate improve the consistency of a physics based game, is it the case for a rythm game, or wouldn't it be preferable to use a variable frame-rate ?

Say, I set the frame-rate to 100/sec, that will lead to an accuracy of 10ms, which is correct, but depending on the computer it will be possible to have a better accuracy. And if I set a too high frame-rate, some other computers may not follow, which may resolve in unsyncing the game and the music.

* The first solution that came in my mind is to use a variable frame-rate. This way, the game will not be unsynchronized with the music, but the accuracy is too dependent of the computer.
* Another, better, idea (I don't know if this is possible or not), would be to get the instant when has been pressed a key, and the accuracy will be no more dependent of the frame-rate. I'll make this game with LWJGL and I while reading the javadoc I found the method getEventNanoseconds(), and I was wondering how it is reliable since it's written "Only useful for relative comparisons with other Keyboard events, as the absolute time has no defined origin.".

What game loop method, do you think, is the most appropriate for a rythm game ? And for a rythm game with keysound ? Did you made a rythm game, or some game that require a good accuracy and how did you manage the updating ?

Thanks for your help ! :)

# Answer
> 6 votes
1) What Kimau said about compensating for controller lag/perceptional differences is important. While a lot of people get the basic rhythm, just translating it into a keypress might mean they're slightly off. If you can, give them exact feedback where their press occurred. (I.e. display a marker relative to the real beat, or something similar)

2) relative comparisons with other keyboard events are good - *if* you use a keyboard event to start play. Otherwise, you need to use system clock for the initial event, and then slowly transition over to keyboard events. Check out the NTP (RFC 1305) for issues in synchronizing different clocks with different resolutions

3) If you can, keep the controller on a different thread decoupled from the UI thread - that allows you a higher frequency there. (Assuming you don't use the timestamp on the keyboard events).

4) Having even a 100Hz resolution on keyboard event is small. Assuming a song with 120BPM, that's 2 beats per second. Which basically means your resolution is big enough that up to 2% time difference between real beat and your controller input are completely unnoticed. So, if you can, up the resolution

5) Also, if your sound driver allows you to query the current sample position, that would be the best timing indicator, since it's directly tied to the music.

And finally, DO have a musician check your idea of timing. There are plenty of rhythm games that are slightly off. Which is annoying as heck if you actually play music yourself.

# Answer
> 0 votes
It's highly dependent on the system you are using and how good the sound drivers or libraries are. Different consoles have vastly different approaches to sound streaming.

I would generally recommend a fixed time step for consistency because a smooth frame rate without pikes and dips is very important to keep a smooth feeling which doesn't break the flow.

Controller lag is a bigger factor than you would think. I quite like Rhythm games which use an auto-configure mode which basically lets the play define where they see the moment as being, then artificially compensating for it.

---
Tags: frame-rate, events
---


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

# Answer
Consider that there is no NEW ideas, only different combinations of old ideas.

**Make lots of games**

The best way to get really good ideas — ideas that will become great games — is to make lots of games. You should brainstorm up lots of stuff and make prototypes. You will not make good games without lots of trying things and failing with some and iterating on what works. World of Goo and Crayon Physics both started out as small, quick prototypes (not sure about Gish).

**Prototype**

Prototyping allows you the freedom to try out wild ideas, figure out how to make them shine or figure out that they don't work, and not spend years of your life doing it. The years of your life come when it's time to make a real game.

Prototypes come in various forms. The two big ones I see a lot are quick and dirty videogame prototypes and paper (or boardgame) prototypes. Do the simplest, smallest thing possible and make that. See whether it works and what needs to change. Iterate. Then go and do the same exercise with a new idea. Eventually, you'll have a prototype that you MUST MAKE: something you feel really strongly about.

Make that.

Keep in mind that a prototype need not be a vertical slice of the entire experience. More likely it is just some simple aspect of an unpolished product, like some new mechanic that needs to be proved to be feasible and fun. Therefore, the time to prototype an idea can easily range between an hour and a month depending on the complexity of the idea and the skills and tools you can leverage to get it done.

As a reference, Kloonigames — Experimental Games, from Petri Purho, the creator of Crayon Physics, was "the experimental monthly game project". The projects always used SDL+box2D, always just a few hours/days. It eventually created World Of Goo.

**Work with other people**

Most idea generation techniques can be done by yourself, or with a group. When in a group (even when "group" means "you and a partner") you have the opportunity to feed off each other, and come up with more unique ideas because of the different perspectives. Don't underestimate other people, even "non-creatives" can have great ideas.

**Observe the world around you**

One informal way is to observe the world around you. Watch the kind of objects and interactions you have every day. See what makes people happy or what captivates them. Is there any way that can be used as the basis of a game? Or can you add it to an existing game in a way that makes something new? Mull it over, try playing a mini prototype in your head. If it doesn't have potential, move on. If it does, make a real prototype.

Spend a lot of time thinking and observing. Eventually you will have a lot of ideas that aren't good enough and some that are.

E.g. Shigeru Miyamoto has got his inspiration for Pikmin from watching ants.

**Hit Wikipedia's or a dictionary random page**

A solution is to hit the random page link on Wikipedia or select a random word from a dictionary a few dozen times until you find some amusing topics and then build something from that.

Another approach with this is to try to come up with 10 bad game ideas for that topic. Usually after 5-8 bad ideas you will have a really good one. Then try to implement the essence of that idea over 2 or 3 days, setting a strict deadline before you start. Toss the result away and do it again. From there on it's just execution...

**Turn off the computer, leave home**

Some take their inspiration from things completely unrelated to games. It's better to go out and do stuff: travel, watch movies, read novels, do sport, just walk around downtown, etcetera. E.g. Shigeru Miyamoto's inspiration for Legend of Zelda was when he used to play in the woods as a kid.

**Carry a notebook and a pen**

For some, the best ideas come when they are not trying to think about them: in the shower, while commuting to work, having a nice walk in the park, or when sleeping. Always have a notebook and a pen with you, wherever you go, whatever you do. Then when you're sitting back in front of the computer the ideas will be there with you in your notebook.

**Attend game jams**

Taking part in game jams and participating in activities like The Experimental Gameplay Project can help: sometimes placing restrictions on your design or building a game around a theme will yield some interesting ideas. How would a game about candles play? What would a game in which you could only use black and white look like? How can you exploit that restriction in terms of a game mechanic?

**Take game design classes, read game design books/articles**

Many universities offer classes in game design (though make sure they are really teaching what you want to learn, as the term is misused a lot).

**Improve aspects of a game you like**

Many highly successful games are simply refinements of previous games, figuring out what makes players enjoy a certain playstyle and then enhancing or providing better gameplay. WoW is a great example, taking cues from previous MMOs and tweaking things for the "common" gamer, and even casual gamers.

WoW took from Everquest, which enhanced ideas from MUDs, which were taken from adventure games mixed with old school paper and pencil Dungeons and Dragons which took from J.R.R. Tolkein. Basically, all the old things are new again in the right hands.

Take an idea or two that you like from games and think about the process that might make a game better that would use those ideas. Plot out what a player would do in order to start playing the game, and what kinds of things would be fun for a player to do. Many new designers simply take ideas and steal them directly, not giving much thought to what the player is supposed to do that differentiates their game, or why they should be fun. In order to stand out, you must improve on the gameplay that you decide is part of the core fun.

**Other idea generation techniques**

This also known as Ideation:

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

**Also see**

**Words of caution**

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

---
Tags: game-design
---


# Question
Title: What has your experience been with Torque products?
I'm most interested in your experience with Torque-X, the Managed XNA version of their engine.

* How did it perform in your use case? (also info on your use, would be helpful)
* What was the usability of the tools?
* What did you build with it? 2D, 3D, both?
* Did you find any "gotchas" that you had to work around?

If you have used both Torque and Torque-X, I'd be very interested to hear your thoughts contrasting the two engines. On the website, there are some pretty amazing screensshots for the Torque engine; yet the screenshots of Torque-X look kinda cheesy. At this point I don't have the 3D artist expertise to build some of the amazing 3D scense they demoed, but I'm wondering if this would even be possible on Toreque-X engine.

As always, any thoughts are greatly appreciated.

# Answer
> 6 votes
I am a licencee of most Torque products. Don't let the screenshots fool you, it's indeed the art that sells it. As for the engine - you can make games with it, and decent ones at that, but not without putting in a lot of blood, sweat and tears. That holds true for most engines though.
Would I recommend it? Hmmm, hard to say. It has an editor, it has documentation, it has support and it's affordable. The code is reasonably structured - you could do worse.
Would I use it? No. As with most engines I find it easier to write it myself so I know what it can do and how I should do it without having to grasp someone else's philosophy that is bound to clash with mine.
However, having the source and seeing how they approached certain problems is always nice. It's also a full game engine, with pipeline, as opposed to a lot of engines out there.
Bottom line?
I don't regret buying it, as a learning tool. I wouldn't use it to make a game. I would definitely not recommend it to someone just starting out.

# Answer
> 14 votes
**This is a huge warning against using and even thinking about using TorqueX!!**
*note: this is based off of my experience from around 06/2009*

I too, was naive and thought, wow a XNA based engine that would help speed along development. And on top of that TorqueX is free if you have an XNA creator's club account.

I want to stress again this was **NAIVE**.

I purchased the XNA account on 06/18/2009 so the TorqueX I have experience with is back in the days of TorqueX 2D and TorqueX 3D 3.1.5

From what is on their site it would give you the impression that the 3D editor and engine would greatly help with development. They even show Box Macabre on their site which uses the TorqueX 3D engine.

Everything is peachy at this point and hopes are high. That is until you actually try and use it...

TorqueX 3D 3.1.5 is based around using their editor to modify xml files. Too bad the editor was **EXTREMELY** unstable. You of course don't get to know this until you get access to their "private" forums. If you want to know why they are private it's because you'll see huge gripes. One, that TorqueX 3D was basically a POS and two, the utter lack of documentation. The companies "defense" against the lack of documentation is that there was only one documentor that was shared between all the engines they develop.

I even had "The Complete Guide to Torque X" book which was written by one of the developers of Torque X. Basically the only documentation that existed at the time. Anyways to the end of the story it was a complete nightmare. I ended up switching over to TorqueX 2D which also was a ton of problems.

The TorqueX 2D engine/editor was a lot better. Actually usable, but since I had the free XNA creators version I only got binaries and no source code. It's no fun when you find bugs in the engine but lack the source code to actually fix them. Their forums were littered with source code fixes which could not be applied to the binary distro.

All in all, a waste of time and money.

I would never in my wildest dreams touch any Torque product with a 10 foot pole.

# Answer
> 6 votes
I was forced to work with sevreal Torque products...

It was a disaster.

First, the regular Torque Game Engine, the documentation is a mess, the support is more about forcing you to ask on the forums, and the engine although solid, it is old, and has several bugs of the "hilarious" type...

But some other teams that I know, don't found those bugs to hilarious, specially one that after 4 months working to make a REALLY cool castle, could not make the collision work (even doing it properly...) without severe hacks, and even then it was still strange...

My own team had problems with that too, ranging from random collision boxes in the middle of the nothing (yep, you was walking and suddenly you could not walk...) to walls that don't collide.

And finally, the model editor of TGE is REALLLY awfull.

TGEA is a TGE that support shaders, unfortunately it can easily get hell slow, and it was sorta broken (I know some dudes that spent 80% of their resources hacking TGEA source to make a simple cartoon shader work properly).

So, about TGEA and TGE: Lots of people claim that the best is that they provide the source... I say that they provide the source, because without it you cannot do much...

Now TorqueX... well, the editor was crashy, and crashy, and SO CRASHY that we decided to switch engine in mid development.

After that, happily we never had contact with Torque again.

That said, during that time, we also worked with 3D Game Studio A5, and Torque was better...

---
Tags: torque
---


# Question
Title: How to design a game's software such that it is easy to unit test?
Is it practical to use a testing framework like JUnit in a game development situation? What sort of design considerations can you follow in order to make your game more testable? What parts of a game can/should be tested and what parts should/must be left to human testing?

For example, if the game loop is encapsulated in one function, it seems like it would be terribly hard to test. I like to refactor out an "update" function that takes a time delta and moves forward the game logic; this allows some interesting tricks like the ability to slow the game down by feeding it fake, slower time deltas.

# Answer
One of the tenets of TDD is that you let TDD in some cases influence your design. You write a test for system, then write the code to make that test pass, keep dependencies as shallow as possible.

For me, there are only two things I don't test as part of unit testing:

First, I don't test visual elements and how things look. I test that and object will be in the right place after it updates, that a camera will cull an object outside it's bounds, that transforms (at least those that are done outside of shaders) are performed properly before being handed over to the graphics engine, but once it hits the graphics system I draw the line. I don't like trying to mock out things like DirectX.

Second, I don't really test the main game loop function. I test that every system will work when passed a reasonable delta, and that systems work together correctly when they need to. Then I just update each system with the correct delta in the game loop. I could actually have a test to show that each system got called with the correct delta, but in many cases I find that overkill (unless you're doing complex logic to get your delta, then it's no overkill).
> 26 votes

# Answer
Noel Llopis has covered unit testing to the degree that I believe you are looking for:

With respect to testing the entire game loop, there is another technique to prevent functional regressions in your code. The idea is to have your game play itself via a replay system (ie. first recording player inputs, and then replaying them over a different run). During the replay, you generate a snapshot of each object's state for every frame. This collection of state can then be called the "golden image". When refactoring your code, you run the replay again and compare each frame's state to the golden image state. If it differs, the test has failed.

While the benefits of this technique are obvious, there are a few things you need to be careful with:

* Your game needs to be deterministic, so you need to be careful with things like depending on your system clock, system/network events, random number generators that aren't deterministically seeded. etc.
* content changes after the golden image was generated can cause legitimate differences with your golden image. There is no way of getting around this - when changing your content you need to regenerate your golden image.
> 20 votes

# Answer
I agree with both of the Jeff's and jpaver's comments. I also wanted to add that adopting a component model for your architecture greatly increases it's testability. With a component model each component should be doing a single unit of work and should be testable in isolation (or with limited mock objects).

Likewise, the other parts of the game which rely on entities should only rely on a subset of the components to function. In practice this means you can usually mock out a few fake components to facilitate testing these areas or you can simply compose partial entities for testing purposes. e.g. you leave out the rendering and input components because those aren't needed to test physics.

Finally, I would ignore the advice around performance that you get from some people in the game community concerning interfaces. Write the code well with interfaces and if you run into performance problems down the road you can easily profile, identify, and refactor to solve the issue. I was not persuaded by Noel's concerns around the performance impact of interfaces or the complexity overhead that they added.

That said, don't go overboard trying to test every little thing independently. Like most things testing and design are about striking the right balance.
> 9 votes

# Answer
I thought I would add a second answer responding to the OP's comment that user could replace unit tests. I believe that is completely wrong as the purpose of unit tests is not to assure quality. If you want tests in place to ensure your program's quality you should likely investigate scenario tests or invest in great monitoring.

(With great monitoring and a product running as a service it is indeed possible to push some "testing" onto the customer but you need to have a sophisticated system which detects errors quickly and rolls back the changes responsible. Most likely this is too much for a small development team.)

Unit tests main benefit are that they force the developer to write better designed code. The act of testing challenges the developer to separate concerns and encapsulate data. It also encourages the developer to use interfaces and other abstractions so that he tests only one thing.
> 3 votes

---
Tags: architecture, unit-testing
---


# Question
Title: Android differences (Dalvik+Java vs Old School C++)
Developing in Android is going to be different for me, having spent the last 10 years coding games in C++. What's the main differences / pitfalls / bottlenecks to developing for the Android? My big worry is moving to Java, what am I going to miss most?

To be clearer: what would I miss if I coded the whole thing in Java compared to the way I normally code C++ for consoles?

# Answer
The single biggest thing that you'd probably miss would be explicit memory management. On the plus side, Java has run-time type information and real generics. Also see this link for some tips from Google on how to keep your Java code efficient.

Raymond Chen has recently been venting about garbage collection and memory management in the CLR and his blog posts are great for understanding how it works. (I know the following links are for the CLR, but they're still relevant for Java development). See especially here and here.

That being said, there isn't that much difference between Java and C++, and as Chris pointed out, you *can* code in C/C++ on Android using the NDK.
> 6 votes

# Answer
Google's Chris Pruett talked about writing real-time games for android in Google I/O 2009 and again in 2010. He talks about Java performance on Android among other topics. He also made a game, Replica Island, in Java and you can download the source code to get an idea of how an Android Java game might look like. His blog about the game also has several insightful articles.

The typical pitfalls are similar to those of writing in other garbage collected languages, you use a object pools and allocate stuff in advance to avoid having the GC run when you don't want it to. Methods are virtual by default in Java and it helps to mark them as final when you don't need to override them. The Android Eclipse plugin comes with some neat tools to help you profile your application and monitor heap allocations.
> 4 votes

# Answer
You are worrying too much. The API for OpenGL in Android, OpenGL-ES, was deliberately kept C-like. See the OpenGL specs at http://www.khronos.org/opengles/ for details.

It is even possible that you won't miss much of anything from C++. A lot of developers, even the famous programming author Bruce Eckel ('Thinking in C++', 'Thinking in Java'), have found Java a much more effective language for object-oriented programming. Largely because the things they 'missed' at first turned out not to be so important after all.

That said, what I miss most is the ability to override operators, not just methods. The syntax really is clumsier when you have to define/override methods instead of operators.

Consider, for example complex number arithmetic. It is really elegant in C++. Not so in Java. But this turns out to have minimal impact on most real projects.

Some people complain about the inability to do multiple-inheritance. But the most useful kind of multiple inheritance IS the kind that Java does with the 'interface', so you shouldn't really miss it that much.
> 2 votes

---
Tags: java, android
---


# Question
Title: What is the difference between OpenGL ES and OpenGL?
Android uses OpenGL ES, what is the difference between it and OpenGL?

# Answer
> 14 votes
OpenGL ES (Embedded Systems) is a stripped down version of OpenGL. There are a lot of differences between those two and if you want to go way into the details, then you can read this 128 specification paper. But ES is a subset of OpenGL so all ES apps work on non ES systems but not the opposite.

There is no one place where you can easily define what is in ES and what is not. Even one definition is "OpenGL-ES is just like OpenGL, but without a lot of stuff. For example, there's no glBegin or glEnd."

# Answer
> 20 votes
Alas, not one of the answers so far is both complete and fully correct. Really, OpenGL-ES does two things OpenGL does not:

1) it strips down and then extends OpenGL APIs to make it suitable for a mobile platform. That is, first they strip out APIs and features you really don't need, and are burdensome for mobile implementations, such as rendering polygons or using display lists. Then it makes a few judicious extensions to make it more useful for the mobile platform. I can't even remember an example of this, though.

2) it provides the interface to the window manager (and therefore native graphics hardware) of the mobile platform. This part of OpenGL-ES, known as EGL, is a lot like GLUT on the desktop. Except that it has none of those convenience methods that are not strictly necessary for that interface. So there is no API for drawing polyhedra or spheres (like in GLUT). But there are, for example, APIs that correspond to GLUT's init(), and to DisplayFunc() and ReshapeFunc() callbacks.

# Answer
> 8 votes
There is two OpenGL ES versions available on Android:

* OpenGL ES 1.x (1.0 or 1.1): a subset of OpenGL 1.5 without immediate commands
    + no glBegin/glEnd
    + no Quad or Polygon support
* OpenGL ES 2.0: a subset of OpenGL 3.X without fixed pipeline
    + vertex shaders
    + fragment shaders
    + geometry shaders are not available

Warning, OpenGL ES 2.0 is not compatible with OpenGL ES 1.X!

Almost all Android phones have OpenGL 1.X GPU and most have 2.0. OpenGL ES 2.0 is only available with Android 2.x or newer.

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


# Question
Title: Combine n Gaussian Probability Sets in a limited float range
I've got a fixed solution space defined by a minimum and maximum float which has no divisible slice.

You then have 0..N Gaussian distribution probability sets which I need to combine.

In the end I neeed

1. Method to define probability set with a numeric range (not sliceable) and 0..N Gaussian functions
2. A function which can generate a random number in the range as defined by the calculated probabilities.

Also I know it is possible that some combinations will generate a zero solution space.

Now I'm thinking the way to do it is take the normalised probability density functions and multiply them to get a new space then normalising the result. I just can't seem to break it down into algorithmic form.

Any ideas?

# Answer
> 1 votes
First let's make sure I understood your question correctly:

* You have a probability function that is expressed as a sum of N parametrized one-dimensional gaussians, each with different mean and standard deviation.
* You want to generate stochastic variables according to this distribution.

Is this correct?

If this is the case, I reccommend you use a variation of rejection sampling. The recipe is quite straightforward, but you might have to iterate a bit before you get an answer out of it. This is the basic outline.

1. You generate a uniformly distributed random number in your desired interval, x.
2. You calculate the value of your probability distribution, p(x)
3. You generate another uniformly distributed random number between 0 and 1, q
4. If q \< p(x), return x
5. If not, start from step 1.

No matter how large the temptation, do not re-use q for different iterations.

---
Tags: mathematics, random
---


# Question
Title: How do I make a vehicle move to a point and stop without overshooting or oscillating?
Ok so consider we have a vehicle like the one I described in my answer to this question, with a 2D position, velocity, angular velocity, and drag/friction. It can accelerate and break by a variable amount, but not stop dead instantly or reach top speed instantly. How can I make it move to a particular point and stop - in the fastest time possible - without overshooting or oscillating?

I was thinking something like:

* turn towards target position.
* accelerate
* look 1 tick ahead, asking "If I applied the breaks next tick, would I overshoot the target?"
* If it would overshoot, apply the breaks now by some amount.

I'm sure this is a solved problem and there is a probably a better method than the one I described.

# Answer
Using calculus, if you know your velocity and maximum deceleration rate then you can know your minimum stopping distance. With that in mind, you can know exactly when you need to apply the brakes (rounding/quantisation errors aside) to stop at a certain point.

Now, hopefully someone better at mathematics than me will post the actual formula...
> 4 votes

# Answer
Steering Behaviors For Autonomous Characters. Check out seek and arrival.
> 4 votes

# Answer
It's a control problem. You need to vary your inputs proportionally to some kind of "error" measure, like the distance to the target. See also the answers to this question.

Target Tracking: When to accelerate and decelerate a rotating turret?
> 3 votes

# Answer
Sometimes, in game development, you need to take shortcuts. The shortcut here is called an Impulse, which, physically speaking is a very large force applied in a very short time. Instead of integrating it over time, you just apply it to the parameter as a direct change: set velocity to 0.

The question is: do you want to use the shortcut or not?
> 1 votes

---
Tags: physics, ai
---


# Question
Title: On cocos2d, what is better: one monolithic game cycle or many scheduled selectors?
I am building a simple tower defense game, and I have to take a decision between two(or more, feel free to suggest other ways) to do the game cycle.

**Option 1: Monolithic game cycle:**

I could have a global scheduled selector that calls update for every sprite/object/logic thing that I need to calculate.

I could achieve this by having a singelton Game class that has a mutable array of objects and then on the Scene(or that singelton) I could have a setup with:

```
[self schedule: @selector(gameCycle:) interval:0.1];

```

And then on that gameCycle do something like:

```
-(void) gameCicle: (ccTime)dt {
    for(Entity* e in [[Game sharedGame] entities]){
        [e gameCicle];
    }
}

```

**Second option: Each object could create its own selector @ init.** This is almost the same, but instead of a singleton, every time that i create a object I could create a new scheduled selector as such:

```
-(id) initWithTexture:(CCTexture2D*)texture rect:(CGRect)rect {
    if( (self=[super initWithTexture:texture rect:rect])) {
        [[CCTouchDispatcher sharedDispatcher] addTargetedDelegate:self priority:0 swallowsTouches:YES];
            [self schedule: @selector(gameCycle:) interval:0.1];
    }
    return self;
}

```

Now I don't know what is better(or if there is a very big difference in performance). What is the usual/best approach for cocos2d?

# Answer
> 3 votes
Use the first one. You certainly don't want your timers be called in random order.

Although I'd suggest to actually use none of them, but use the standard update method of cocos2d. This will give you the best available performance and consistent behavior.

# Answer
> 2 votes
There is a third option: have a small number of scheduled updates for tasks that can be independent.

Scheduling one update method for each layer could be useful, especially if they are logically separate. One useful example of this is using one scheduled method for the main game logic and another to update the score display.

---
Tags: iphone, cocos2d, ipad
---


# Question
Title: Can a standalone WPF application create an interface that looks like a Flash interface?
It seems like WPF was created as the application answer to Adobe's Flash. Silverlight is used for creating web pages. But, can that same functionality be pulled into a standalone WPF application. Scaleform allows Flash to be used within unmanaged C++ games. Can WPF be used to create the same type of interfaces? What I've read seems to make me believe it can. But, I haven't seen any sheetshots of applications that show this kind of interface.

# Answer
> 6 votes
WPF was created to provide a better way for Windows developers to build GUIs for desktop applications. Silverlight was created as an answer to Flash and re-uses much the WPF API but has a different implementation.

In theory you could use WPF to create the GUI for a game, but in practice you probably wouldn't:-

* Your game would depend on the .NET framework being installed. This isn't such a big deal any more, but still, it's one more thing to worry about not working.
* WPF uses Direct3D 9 to render. There is an extension to it which on Vista/Win7 and XP SP3 or later allows you to allocate a surface and share it between WPF and your unmanaged C++ game engine. You might have problems with DX10.1 or 11.
* The .NET runtime suspends all threads that are involved in any way with managed memory during a garbage collection. To avoid having your game loop suspended you need to come up with a way of exchanging data between your unmanaged code and the .NET runtime that avoids calling into the .NET runtime via interop. Probably you'd have a shared area of unmanaged memory that you both have access to and synchronise using umanaged threading primatives.
* Here's the real problem though: If you went down this route you'd be handing over control of your window to WPF. You just get to supply WPF with a D3D surface containing your final 3d render and then it composites that with whatever it has generated before presenting it. You'd be locked to WPF's refresh schedule and there's also no chance of going full-screen in the way that 3d games normally do.

There is a possibility that this situation could be rescued though. There is an open-source re-implementation of .NET called Mono. They have a sub-project called Moonlight which is a re-implementation of Silverlight. With source code available there's a possibility it could be integrated in a similar way to Scaleform and allow you to build GUIs using Microsoft's excellent Expression Blend authoring tool. I don't think anyone has done this yet so there are probably issues to be uncovered, but I'm just throwing it out there as an idea.

EDIT: It occured to me after adding this that maybe your interest isn't so much in leveraging authoring tools like Flash Studio or Expression Blend and maybe you just want to be able to draw high-quality 2d graphics fast. In which case there is the Direct2D API that Microsoft added in Windows 7 and then back-ported to Vista.

# Answer
> 1 votes
You can definitely create similar kinds of interfaces in WPF, but integrating them into a Direct3D game is problematic. You can host Direct3D content within WPF (via `D3DImage`), but your 3D content would be composed into the WPF application, so rendering becomes dependent on WPF. Consequently, you might see relatively poor performance, as you are limited by WPF's frame rate. Also, as U62 noted in his comment, WPF can only host Direct3D 9 content (as opposed to Direct3D 10/11). However, you might be able to get around this, as `IDirect3DDevice9Ex` is capable of sharing resources between devices. Therefore, you could potentially create a shared render target in Direct3D 10 or 11 and bring it into WPF via an intermediate `IDirect3DDevice9Ex` device. Jeremiah Morrill discusses this technique here.

An alternative, though far from elegant, would be to render your WPF UI in a separate layered window above the Direct3D content, as described here.

There are also ways to access WPF's internal Direct3D surface, which would give you a way to host WPF content in an external Direct3D scene (instead of the other way around). However, this is a rather nasty hack and could easily be broken by future WPF releases.

Of course, none of this is relevant if you don't actually *need* to interoperate with Direct3D. Games that don't require complex 3D graphics can certainly be developed completely in WPF. WPF does have some simple 3D facilities at its disposal, though they are generally insufficient for anything beyond primitive shapes with simple textures. It also supports custom pixel shaders, though there are many restrictions (e.g. they must be single-pass effects).

---
Tags: flash, c#, gui, interface, wpf
---


# Question
Title: How do I render my own DirectX Stuff to a full screen WPF's DirectX surface?
Basically Danny Varod seems to know as he posted it as an answer to this question:

Display a Message Box over a Full Screen DirectX application

I think, theoretically this might work, but I have no idea how to actually do it. Since I'm also not allowed to post a comment under his comment nor am I allwoed to ask on meta about how to contact another user, I ask this as a normal question here:

How do I render my own DirectX Stuff to a full screen WPF's DirectX surface?

For starters, I have no idea how to get the DirectX surface from a WPF window. If I had it, what do I have to take care of that the WPF rendering doesn't screw up my own rending or vice-versa?

# Answer
I think what he means is to host your DirectX surface in a full screen WPF application using the D3DImage class.
> 3 votes

# Answer
There are a few ways you could approach this, and I outlined them in a response to a similar question.
> 0 votes

---
Tags: gui, directx, wpf
---


# Question
Title: Do "Results-Oriented Work Environments" work?
A game development company seems like an ideal testbed for experimenting with new or uncommon models for work environments. I'm curious if there's anyone out there successfully doing something creative with their methods of doing creative work, and how it's working out.

This is a community wiki since there won't be an objective answer to the question:

**What are some unconventional but effective methods of running a game development office? In your experience, what works well and what doesn't?**

I'm mostly talking about the culture and business side of things, and not so much about things like pair programming, test-driven development, scrum, waterfall, etc. In other words: I don't mean development methodologies. I mean development environments. They're closely related in many cases, but please don't turn this into an evangelism platform for scrum or TDD or whatever your favorite happens to be.

Do you have strict hours and fire people who are late? Do you have "core hours", like 10pm to 4pm, that gives people a few hours of flexibility? Or do you just show up when you want for as long as you want?

Does forcing people to work overtime actually work? What about forbidding overtime? Weekends? Do you give people free time to work on whatever they want during business hours?

Do you allow telecommuting (e.g. VPN from home)? Clearly this will be a big issue for people who outsource a lot. And people who subcontract or work on large projects have limited options.

If your hours are not strict, how do you handle meetings, conference calls, or emergency emails?

Some examples of what I'm talking about:

# Answer
> 4 votes
There are a number of growing companies that work with minimal studio time and people from across the globe. A lot of flash programmers from what I've seen have adopted this method as the artist usually lives in a different time zone than the programmer etc.

I believe the project Natural Selection 2 which is coming out this Halloween was made almost entirely by a team split across the US. Many other small and indie companies do this as well.

The key is that no matter how "chaotic" you allow your employees hours to be, there has to be accountability for work. In short, they have to be worth what they are being paid to do. If you're paying them to provide a pretty face in the office and good face-to-face time with others, then an hourly schedule is probably what you'll be using at a local office. If you need a collaborative environment, there are PLENTY of online capabilities allowing instant communication with chat backup for those "he said/she said" conversations, such as Basecamp.

If you allow flexible hours or little to no office time, you MUST be able to keep on top of tasks and have a result-oriented environment. So far, they've proven quite effective with the right people in small to small-medium environments. I haven't seen any medium or big companies take it up yet, but it tends to work very well for small close knit groups, AND those who it works for which is not everyone (see: slackers).

Part 2

While I laud this approach, your problem is going to be billing. You're going to either have to be developing your own stuff on your own timeline or not charge by the hour. The reason a lot of companies want to charge by the hour is that they completely underestimate the amount of time that a project requires and simply take very specific requirements, allowing them to charge for any problem that makes the project deadline slip.

While in my experience these groups provide higher quality work, the trade-off is in time. There is, however, the advantage that you can usually pay employees less for being able to have such flexible time and movement. Also, in a truly results-oriented environment, you shouldn't have to care if your employee is in the Caribbean during release week as long as they are providing you with the code and access to them that you need. Meaning it's not for the weak of heart managers or those who feel the need to "check up" on their employees at unscheduled times.

# Answer
> 4 votes
Not everyone is the same. Some people flourish under light management while others just waste their time (and that of those around them). If you have a team in place, get to know what motivates each of them and go from there.

# Answer
> 2 votes
Most studios have "core hours" and allow flexibility outside of that. VPNs exists but they are more there to get extra work done, and not to allow the employees to not come in. Too much of what is done in a game is collaborative and requires people to work together, so working from home for any extended period of time is pretty rare unless you have highly specialized skills.

Does overtime work?

Well in short bursts working longer hours does increase productivity. Over a longer time though it's actually slower than working consistent hours. Unfortunately that doesn't stop most teams from marching through hours of crunch, long past the point of productivity return, towards the end of a project.

# Answer
> 1 votes
I would suggest that many game development companies are exactly not the sort of environment that allows this sort of "exploration" for the simple fact that you need access to the development equipment, and this is not the sort of thing that the console manufacturers typically allow one to take home. In addition, the support resources that these console manufacturers offer are bound to the IP address of the studio itself.

VPN can work around this to some extent; there are examples of game developers pointing a webcam at a television and proxying controller input but it's an additional investment that many developers are loathe to undertake.

Game development is highly collaborative, and even if the technological barriers are removed there is no substitute to working in close proximity to someone working on the same product you're working on.

That said, I've highly enjoyed working from home when it's been available and I get a lot done once I'm set up and underway. However it's harder to address problems across the internet link; if I'm responsible for code crashing on somebody's machine, I can't just walk over and check it out. Same goes the other direction. So when I'm working from home, my most successful hours are when I'm working on something fairly disconnected from the rest of the team, a subsystem that is standalone or something of that ilk. If I were to need to iterate on something with another person, it'd be substantially easier in person.

---
Tags: business, methodology, management, productivity
---


# Question
Title: The Thin Red Line. What to present to get interest without showing too much?
I am Dalilean and I am a gamer. There I have said it. Damn, feels like a weight is lifted from my shoulders… They say the first step is to admit the problem. Now the second step is doing something about it.

So….

As more than a few of you know, I decided to design a game.

Right now I feel like I am at a critical point in development. I am looking at the aspects of the game, from a game play point of view. This means I am past the story, the conceptualization, and now I am dealing with issues of “What specifics do each character have”, “What options and results do the actions of the player have in the game.”

I got to wondering, How much do I show possible investors or developers without showing too much?

I worry that I give them a copy of the Game Design Document; they will just say thank you and nothing else. Then, several years later, I will see my concepts seeping into games. I have learned from previous experiences that not everyone is honest and that a healthy level of paranoia goes a long way in this world.

# Answer
Game development studios and Publishers do not accept unsolicited design documents. If you send them one directly it will be immediately trashed. Any dev studio has far more ideas than it has time/money/resources to build them and so they aren't looking for stuff from the outside. Also as a legal protection if they are working on something unannounced that has similarities with a document that was submitted to them, then proving they were already working on those concepts can become costly. It's just safer to not look at those things.

Most of the indie community are self starters. They decide to build games because they have some concept they want to explore and start making it on their own. You aren't going to find an untapped resource of programmers & artists that desperately want to make someone else's work.

If you really want to make your game, then find out how to simplify your idea to match your ability and start building it on your own.
> 20 votes

# Answer
Since you mention "investors" - investors care less about your Great Idea for a game, and more about the team you've put together. Do you have people with a strong track record of executing a project, getting it done, and doing it well? If not, you'll have a hard time getting investment capital. The design doc is the first 1% of the work, after all.

That said, if someone does want to see your design doc and you're really that paranoid about it, my advice would be to consult a lawyer in advance and have some kind of NDA (Non-disclosure agreement) that the other party can sign before you show them anything that would be potentially damaging to you if they "steal" it. NDAs are pretty common in this industry. As others have said, no one is going to steal your idea (they have too many of their own as it is), so it comes down to how paranoid you want to be.

And for the love of all that is holy, have a working, playable demo to show. That is the bare minimum bar to hit if you're trying to get funding. If all you have is paper, then you have failed to show any ability to turn it into reality, and you'll be politely shown the door.
> 9 votes

# Answer
Just show them the design document. Game ideas/design are rarely the main factor in ones success. It's how you implement the idea and the team that puts it together is what will make the difference. You need not to worry about people copying your game idea, that is, if your game ideas were truly revolutionary, you will have many copycats but will always be one step ahead of them. Only you know how to implement your ideas in your unique way and no one can copy that. If your ideas was easily copied, it is not because someone stole your idea, it is because you did not have the ability to carry out that idea in a successful way. You will need this level of confidence to gain investors trust.
> 3 votes

# Answer
**Why Your Game Idea Sucks** \- courtesy of Escapist Magazine.

Seriously, the only thing that you should show investors is a *completed game* (or close to completed). As others have pointed out, they're not going to look at "ideas on paper", and if they did, probably couldn't tell if the idea would be successful or not. Really, who would have predicted that a 140-character-maximum messenging server would *succeed*?
> 3 votes

# Answer
The main thing to show them is your passion and excitement for the game. Show them as much of your game as needed to get them to share your excitement. It is better to risk showing them too much and get them sold on it.
> 0 votes

---
Tags: game-design, design-document
---


# Question
Title: Should the content pipeline tools be embedded in the engine?
How minimal should a games engine be? How much of the content pipeline should be embedded in the engine?

Some use cases where the super engine might be useful:

* When loading user content, the user isn't required to package up his textures, the engine will do it at load time.
* A script requests a font at a much larger size than was pre-generated, the engine could parse the ttf file ad build a new texture atlas.
* Halo forge.

None of this is free of course. This requires your content pipeline tools to written in C++. Support libraries you use in the pipeline need to be compiled for use on the device. It requires the content generation to be not buggy. And it generally makes your engine larger and unwieldy.
What are some other pros and cons?
Do the pros outweigh the cons?

Some specific questions:

* Should engine be capable of loading various image formats? A TGA only loader is pretty easy to hand code.
* What about audio formats? Is it feasible to only support loading wav files? What about ambient music files which are often huge.
* Should the engine be capable of dynamic TTF parsing and atlas generation?
* Texture packing.

# Answer
Noel Llopis's Games from Within blog touched on this recently in the "Remote Game Editing" post. The opening paragraph:

> I’ve long been a fan of minimal game runtimes. Anything that can be done offline or in a separate tool, should be out of the runtime. That leaves the game architecture and code very lean and simple.

(The article is a highly recommended read, as with most of Noel's stuff, whether you agree 100% or not.)

I believe the key here is to keep the complexity outside the engine. You can still have flexibility, but it's flexibility in the content pipeline. And you get better performance by not spending time converting and moving data around.

Better performance may translate into lower iteration time, strangely, despite losing some of the in-engine editing abilities: it's easier to try something if you can load the game in a second.

Adopting some of the tenets of the "unix philosophy" will help you keep your toolchain flexible: a small modular pipeline.

My personal philosophy: bake as much of the data as much as possible offline, but provide engine support to receive new baked data at any time. (Note that this new data doesn't need to come into play until a convenient point: the "refresh" button is pressed, the next level begins, you transition to a new area, whatever. The key is finding the sweet spot that minimizes iteration time with minimum code complexity and coding effort.)

At our company most of our artist/designer-facing tools are focused on UI issues: ease of manipulation of single assets or batches thereof, etc. Sometimes they're just 3rd party tools like Photoshop or 3DS Max. These tools export to an intermediate format (often xml that references source binary data, but not always). The intermediate format is picked up by a backend "data make" tool, which bakes it into something useful and quick-loading for the target platform.

Portability is achieved by adding additional backend data make tools, or expanding the existing backend data make tools, which has the additional advantage of being invisible to the content creators.

Now, with a proper incremental data make, you can have changes in baked format within seconds; your engine can spider, or a tool can spider, and then these will appear in your resource system, ready for reload when it's convenient.

The tools -- especially the backend data make tools -- are often sloppier and buggier than the engine code. This is OK, because they're easier to refactor/rewrite, extend, and test; you have specs for their behavior and it's fairly easy to unit test them as compared to some engine code.

My opinions on your questions:

> Should engine be capable of loading various image formats? A TGA only loader is pretty easy to hand code.

(Aside: even if you use a TGA decoder in-engine, don't handcode it. You're just asking for trouble -- there are a lot of subtleties with most image formats, and a lot of tools that don't adhere exactly to the probably-underspecified format. You're best off finding existing well-tested library code for image processing.)

I'd have the tool here convert from TGA to whatever your internal texture format is, plus metadata.

> What about audio formats? Is it feasible to only support loading wav files? What about ambient music files which are often huge.

We use three formats here: tracked music (.xm), ADPCM (.wav), and Speex (.spx). This is mostly because we're on handhelds, and these formats are very lightweight to decode.

> Should the engine be capable of dynamic TTF parsing and atlas generation? Texture packing.

Atlasing is a hard problem: see your recent question's answers. It's almost always worth doing offline.

Plus you can make the per-character metadata into a near-zero-load-code baked struct.

In closing, you can clean up and package this pipeline with your game, for the mod community. You can always add more source formats. And there's nothing preventing you from bridging the gap between the content creation tools and the engine in specific cases; hopefully your data baking code and spider/transfer code can be refactored into libraries that might eventually be used directly by the content creator tools in some cases. But I wouldn't make that my first goal, necessarily... Just be aware that it will be an eventual goal and let that influence your design a bit, and go for the low hanging fruit first.

---

As an update, you may want to consider using the KTX File Format for textures. It has the advantage of being mostly "read into `struct` and go" for most GL usecases (and from your comments it sounds like you were targeting GL) while still being flexible and well-defined.

The KTX header overhead may be a bit high for fully-baked data, depending on your target, and you may want to forgo endian swap support, depending on your usecase... but it's definitely at least worth a gander for design considerations.
> 11 votes

# Answer
Your questions sound very subjective and depend heavily on who your target audience is.

Let's take your font/ttf parsing question. If you're planning on modders adding their own font, then you probably want to make the import process as few steps as possible. If you're adding a lot of fonts/font sizes to the game internally, maybe you want a somewhat sophisticated tool that an artist can use with a little training. If you're going to be doing it once internally then the time you spend making a proper importer is probably going to be less than taking the time to write tools for the previous cases.

It's really a matter of scale with everything else. Embedded tools are worth the effort when you're doing something a lot of times and want to reduce the complexity/bugs that result from it. Every additional qualifier you add (i.e. TGA textures only instead of importing of, say, PSDs) results in more time spent by the end user.

Remember that content tools are usually used by the less technically inclined (read: artists). Personally, I really like the way Unity works where you can just drag in a source file (psd, 3ds, ttf, mp3, jpg, mov, whatever) and it will automatically convert it to its internal format. The internal format is mostly hidden from the end user. It'll also auto-re-convert when it detects the source file changing. But that's a lot of work.
> 3 votes

---
Tags: textures, architecture, pipeline
---


title: Is Font Squirrel for real?

text:
# Question
Title: Is Font Squirrel for real?
I found Font Squirrel, and while it claims to have fonts free for commercial use, i can't find a license or legal pages anywhere. Are these fonts really usable for commecial use like they say?

# Answer
I would get them from the sites of the people that they are credited to. I say this because I see a font that I use (Museo) and I know that the font is free, but when compared to the license given at the Font Squirrel site it is different (and kind of unclear) than the one on the creators site.

Checked a few more and the licenses seem alright. But I still recommend cross-refrencing the license available at the original creator's sites just to be safe.
> 3 votes

# Answer
I don't really think they could say, in very large print on the home screen:

> Only the best commercial- use free fonts
>
> Free fonts have met their match. We know how hard it is to find quality freeware that is licensed for commercial work.

If they weren't.
> 3 votes

---
Tags: fonts
---


# Question
Title: What's the most efficient way to find the intersection point of a missile and a bitmap terrain?
Following up on my earlier question about finding the slope of a 2D bitmap terrain I now need to know the best way of finding the point on the 2D terrain that the missile hit. Obviously, I can see if any pixels under the missile intersect terrain, but say it has moved quite deep into the terrain.

What is the best way to step back to find where it initially collided? I could move back X pixels at a time towards the missile's previous position, but what would be a good value of X? And is there a smarter way? Maybe moving half the distance, then a quarter etc?

# Answer
> 3 votes
For collision testing you shouldn't do tick-by-tick static testing, you should be doing traces/sweep tests.

There's an exhaustive list of various formulas for different kinds of primitives here: http://www.realtimerendering.com/intersections.html

That is, of course, assuming you can break down your terrain into some kind of set of primitives you can test against (i.e. line segments). There are various ways of doing that.

See also this question (only slightly related): What is a good algorithm to detect collision between moving spheres?

# Answer
> 3 votes
Binary search wont help if you have thin bits of scenery and fast moving projectiles - you might miss them.

I think your best option is to sweep a line across the front of the projectile along the path it takes, pixel at a time. You could do a bounding check first on the whole volume to avoid doing it every step.

# Answer
> 3 votes
Since the missile is unlikely to move a huge amount of pixels each frame (it wouldn't be smooth on screen) I see no reason to not just check every pixel on the path. Bressenham line algorithm is your friend, and making sure you got a local copy of your bitmap too as you generally don't want to access video memory for every pixel. This is assuming your bitmap terrain is fully random (as per destructable worms terrain). If your world is tile based you could skip every tile that you know is empty to begin with, but as mentioned before, unless you have a huge amount of missiles to check I couldn't think of a platform that would need that is too slow to just test pixel by pixel, and you won't need to have your world defined in primitives (a worms clone would make that tricky)

# Answer
> 1 votes
In addition to the other answers, there are some things you can do to speed this up if you want to do a little bookkeeping with regards to "collecting" a bunch of pixels into blocks of "known similar state." E.g. you could store the height of the highest terrain piece, so you can take for granted that the missile won't hit anything as long as it's above that. You could also store the height of the lowest "air" space, so you'll know that if the missile gets to that altitude that it must have hit something (although this might be best used as a sanity check). Going further than this, you could store rectangles representing areas that are all terrain and other rectangles that are all air, but that might be more work than value.

Ultimately, the best method is probably going to be "store off the height of each terrain column" and then just compute the missile height at each step of its path. I can't speak to more modern games, but I believe that when you made a "cave" in Scorched Earth, that the terrain above that cave fell straight down, leaving no overhangs. If you want overhangs the work will be a little greater, but it will be an extension of this basic idea. (Hint: get the basic idea working first!)

Since your terrain is presumably completely arbitrary, there are no shortcuts. Even if you forced your terrain to be a spline or something, that'll get upset once you start destroying it and line-spline intersection tests are iterative and non-perfect or exhaustive and pointlessly slow for your type of problem.

---
Tags: 2d, collision-detection, terrain, projectile-physics
---


# Question
Title: Optimizing Bullet and ODE Physics on consoles and mobile phones
I'd like to use either Bullet or ODE on low powered devices (mobile and consoles), but the frame rates are below the acceptable 25-30fps for simulations.

I've found that one articulated body by itself is enough to degrade the performance of either engine.

Are there optimizations or tricks I can use to get around these problems?

# Answer
> 3 votes
I've used Bullet on a fairly low-powered console with a scene containing a couple of dozen boxes. Maybe the issue is with your scene setup? What collision shapes are you using? Try to use simple collision shapes such as boxes and cylinders, rather than convex hulls.

Take a look in btScalar.h and make sure you are using any platform-specific math routines you have access to. Make sure you aren't using double-precision. Does your platform have hardware FP support?

I have never used it, but Bullet contains some profiling functionality. It may help to determine exactly where in Bullet you are spending the most time.

# Answer
> 3 votes
If your target devices don't have hardware floating point support (many don't), you should look into converting the engine to fixed-point math. I'm not sure of whether this is just a matter of changing a define or potentially a whole rewrite though :-(.

At any rate, http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/IntroductionToFixedPointMath is a great resource for learning how fixed-point works.

# Answer
> 1 votes
In bullet you can skip the broadphase. It is a pre-phase supposed to find and collect potentially colliding objects, an optimization for bigger scenes, but since your scene is simple, you know your colliding objects anyway. ODE has something similar IIRC.

---
Tags: 3d, physics, optimization, physics-engine
---