# Question
Title: Movement & Physics in an entity-component system
I'm currently playing around with entity-components systems and got started on the movement/collision/physics parts and would like to have some pointers!

It's a basic 2D sidescrolling game, with the goal being something in the style of Terraria. My first goal was to have a character that could run left/right & jump on blocks/tiles and when clicking tiles they'd disappear.

At the moment, each tile/block on the screen is an entity with a Transform(Position) component, a "Renderable component and a Collision component (boundaries)

My player has a Player component(tagging class), a Transform, Renderable, and Physics (velocity, acceleration, mass) and Collision component.

Currently a bit stuck on how to fit in the physics and movement. I read the threads I could find about it here on Stack but left with some questions:

1. What would be a good approach to let my character move? Should I have a player system that updates the Player's position or velocity? Or should I let it set a state & let another system update the movements of entities based on their velocities and their current state? Leaving the option open that I could move a character by clicking somewhere?
2. If I were to add gravity, should these affect your acceleration/velocity? I have problems with figuring out how to implement acceleration & which systems could/should be responsible for that..

And unrelated to the questions above, when I was starting on the collision I ran into the issue that it would try to check every single tile against the player & since on a large resolution already 1000ish entities fill the screen it quickly sent performance down the drain. I implemented a quad tree to select the entities only around the player, which seems to work. (Based on http://www.mikechambers.com/blog/2011/03/21/javascript-quadtree-implementation/ but made it from scratch in Python).

But since it takes the current window size as dimensions once the player would move off screen, the entities wouldn't add correctly anymore. Should I let the Quad Tree *grow/shrink* in certain directions? (If anyone has experience with using this?)

Thanks in advance!

# Answer
> What would be a good approach to let my character move? Should I have a player system that updates the Player's position or velocity? Or should I let it set a state & let another system update the movements of entities based on their velocities and their current state? Leaving the option open that I could move a character by clicking somewhere?

I would create an input component and various other action components, like walk, jump, crawl, weapon, etc. The input component would have fields that describe how the entity *wants* to move, such as: walk left, jump, and attack. This can be supplied by the keyboard, by an AI, or over the network, which is implemented as a control component.

This three-tiered system allows for easily customizable abilities and swapping input sources. Want an entity to not be allowed to jump? Remove its jump component. Want to allow an entity to do a charge dash? Give it a component that does that, and acts on the attack+run signal. Want to allow the player to mind-control an enemy, like the Ghost ability in Kirby Squeak Squad? Just swap out the AI component for the keyboard component.

> If I were to add gravity, should these affect your acceleration/velocity? I have problems with figuring out how to implement acceleration & which systems could/should be responsible for that..

I'd leave that up to the physics system. When it's integrating the acceleration and velocity, it can also add gravity. Something like this could work (don't actually use Euler integration, this is just for simplicity's sake):

```
acceleration += 9.8 * time;
velocity += acceleration * time;
position += velocity * time;

```

Alternatively, if you were doing a more complex physics system you could implement gravity as a generic, persistent force. This would make it easier to do things like different gravities in different regions of space.

> But since it takes the current window size as dimensions once the player would move off screen, the entities wouldn't add correctly anymore. Should I let the Quad Tree grow/shrink in certain directions? (If anyone has experience with using this?)

The quad-tree should encapsulate the whole world, not just the visible area. Aside from that, it's overkill to represent ground tiles as entities. It's rare that you'll need to have modular functionality for the ground.

---

---

> How would the systems interact with your approach of components? Would you have a system that sets state & let the physics update the position based on those states?

Basically, there are three "sets" of systems involved.

1. The control systems - there is one for each control component type (keyboard, gamepad, network, AI, etc.); they set fields of the input component
2. The action systems - there is one for each action component type (walk, jump, attack, interact, etc.); they look at the fields of the input component and modify the physics state, weapon component, etc.
3. The physics system - looks at the physics data and simulates a step

> For the quad tree & all the tiles, I want it to be possible that each tile can be removed individually, how can I avoid treating it as an individual tile?

I'm not saying you can't treat each tile individually. Just don't make them entities. It's better to have a single `Tile` class in a large 2D array. This array can be part of the quad-tree.
> 7 votes

---
Tags: architecture, physics, entity-system, quadtree
---


title: 1% idea, 99% execution?

text:
# Question
Title: 1% idea, 99% execution?
I keep reading in the game development community that the idea of a game is 1% and the execution of the game is 99%.

Do you believe that to be true? Not necessary in those percentages..

I always thought that a great idea is invaluable and it makes a game successful even though the execution is simplistic.

# Answer
### Why Your Game Idea Sucks

> Your game idea sucks. That's the bad news. The good news is *everyone's game ideas suck*, so you're not alone. And hey, now that you know, you can stop wasting your time worrying about it and actually sit down to **make a game**...

Also, there's a difference in simplistic and badly done. Pacman was simplistic, and BattleCruiser3K was horribly done (I actually once bought a copy - the cursor movement on the screen, rarely matched the *mouse* movement). The game's *idea* was fairly cool, but implemented in a way that was unplayable.

For another excellent example of why *execution* matters more than the initial idea, consider the history of Quake:

> The earliest information released described Quake as focusing on a Thor-like character who wields a giant hammer, and is able to knock away enemies by throwing the hammer (complete with real-time inverse kinematics). At the start, the levels were supposed to be designed in an Aztec style, but the choice was dropped some months into the project. Early screenshots then showed medieval environments and dragons. The plan was for the game to have more **RPG-style elements**.
> \[...\]
> Eventually, the whole id team began to think that the original concept may not have been as wise a choice as they first believed. Thus, **the final game was very stripped down from its original intentions**, and instead featured gameplay similar to Doom and its sequel, although levels and enemies were closer to medieval RPG style rather than science-fiction.

What made Quake a great game was not the initial ideas, which changed frequently, but that **id Software had a great programming team**, including people like John Carmack and Tom Hall. They didn't depend on an idea that *sounded* great - they built it, and tested it. And when it didn't work as intended, made changes. They evolved the game over time, to something that wasn't even *close* to the original concept.

**Update** \- Just ran across a great article (source DaringFireball) which explains that **Ideas are just a multiplier of execution** \- nicely explained, using dollar values for ideas. (Since the link is now *dead*, pasting in the original short text:)

> It’s so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.) To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.
>
> Explanation:
>
> AWFUL IDEA = -1
> WEAK IDEA = 1
> SO-SO IDEA = 5
> GOOD IDEA = 10
> GREAT IDEA = 15
> BRILLIANT IDEA = 20
>
> NO EXECUTION = $1
> WEAK EXECUTION = $1000
> SO-SO- EXECUTION = $10,000
> GOOD EXECUTION = $100,000
> GREAT EXECUTION = $1,000,000
> BRILLIANT EXECUTION = $10,000,000
>
> To make a business, you need to multiply the two.
>
> The most brilliant idea, with no execution, is worth $20. The most brilliant idea takes great execution to be worth $20,000,000.
>
> That’s why I don’t want to hear people’s ideas. I’m not interested until I see their execution.

**Update 2** \- the question seems to have re-surfaced, so here's another data point that comes to mind: **The Aristocrats**. This is a DVD of 100 comedians telling jokes - and they're all telling the *same* joke (a very old, very *dirty* joke called the Aristocrats). But of course, they're all telling it differently - the joke is the same, but their *execution* is totally different.

Of course, to apply it to games, we'd have to get 100 game developers to all make their own version of some well-known game (like Minecraft) - then we could compare the results.
> 67 votes

# Answer
> I always thought that a great idea is invaluable and it makes a game successful even though the execution is simplistic.

I've never seen a great game that is great *solely* because of a novel idea. Even in the old days, how well you executed an idea mattered more than the idea itself.

Take SpaceChem, for example. This is a game that has a good idea: use "chemistry" as a means for essentially circuit diagramming and programming. However, that idea could very, *very* easily fail if it isn't executed well. If the game had poor level design, nobody would have bothered. If the circuit pieces were not well designed, reuseable, and interesting from a gameplay perspective, nobody would have cared.

For an older example, look at Super Mario Bros. This game had a number of novel ideas in it. But it wasn't great based solely on ideas; level design was what made the game *work*. Anyone could have put those ideas into a game. But without the proper level design, you would have gotten a forgettable mess.

I'd say one of the best examples of an old game with a novel idea and impeccable execution was the original SNES StarFox. The first polygon-based console game. But it did not look like a first effort at all. There was detail *everywhere*, from robots that moved to robots that carried buildings, the behavior of enemies, etc.

Bionic Commando had a novel idea, but if the level design was crap, nobody would have cared. If the level design did not exercise the swinging mechanic properly, it would never have been what it became. I can keep going, but I think my point is clear.

I honestly don't know about a 99/1 split, and it doesn't really matter. It's not like you can quantify that sort of thing anyway. What matters is that yes: execution of an idea is far more important than the idea itself. An idea might get your game played, but it won't make your game stand the test of time.
> 38 votes

# Answer
To build on Nicol's answer, consider a more recent game, Achron. It has a *very* novel implementation of time travel. To quote the review I linked to above,

> Forget about simple time-travel gimmicks like Command and Conquer’s Chronospheres that were really just teleporters. Achron offers the real deal. Throughout a battle, you have a timeline at the bottom of the screen that shows you key events. By clicking on different points, you snap your viewpoint into the past or the future, where events play out either as they did, or as a simulation of what’s likely to happen. The first twist is that you can give orders at any point, with time ripples updating the present on a regular basis. The second twist is that everyone can do this

Unfortunately, as original as that was, the basic execution of the game is bad - the graphics are bad (which is ok), but it's also incredibly hard to distinguish between units which is basically the point of graphics in the first place; all the time traveling in the word won't help you if your units have terrible pathfinding and so on.

A good idea can be a major selling point, but it can't be the only one. Consider indie company ACE Team. Their second game, Rock of Ages, has a completely crazy premise (you play a rock rolling around) but because the implementation isn't *just right*, it's not as successful as their first game, Zeno Clash (which is basically first-person Mortal Kombat, but with an excellent art style and a very "meaty" execution of the actual fighting).

I could go on; the point is that there are countless games with a good idea that are marred with a bad execution, just like there's a lot of games with a simple idea but excellent implementation that are successful (again, Nicol's answer has a list of those).
> 10 votes

# Answer
> I always thought that a great idea is invaluable and it makes a game successful even though the execution is simplistic.

We have no idea how many amazing ideas never got made because of problems during the implementation. There might be millions. So it's hard to judge. And if there are millions of good ideas that came to nothing, that would imply that good ideas are still not worth much on their own.

On the other hand, we know of many successful games which came from rather mediocre ideas, and the only reason they were successful was because they got implemented adequately.

We also know that ideas, no matter how good they are, require much less effort to create than the implementation of that same idea. So, given that you always need both, the implementation is more highly valued.

And we know that ideas themselves are impossible to judge for quality. *"Be a soldier during World War 2"*? Trite. *"Control a space marine as humanity fights off aliens"*? Hasn't this been done a thousand times yet? *"Play an Italian plumber who rescues princesses and jumps from one platform to another"*? Ridiculous. Yet these games sell millions each year.

A good idea can be worth a lot. But ideas in general are worth, on average, almost zero.
> 9 votes

# Answer
I believe it to be true. Your counter-example, that a great idea can make a great game even if the execution is simplistic just shows that simplistic execution is not inherently bad and often optimum.

We used to say that ideas are a dime a dozen. Now we say ideas are a dollar a bale in thousand idea bales.

I think what happens is that you look at a truly great game that also had a novel idea, say Pac Man or Tetris, and you think the idea is what made it great. But if you think about it, it's pretty clear that those same ideas could have been implemented in dozens of games and *never* made a great game.
> 5 votes

# Answer
Consider the game *Burnout Legends*. On PSP it's pretty good. On NDS it is laughably awful. Really really bad. So implementing the idea seems important.

Consider the game *Rise of the Robots*. It seemed like it'd be a brilliant game (Robots! Fighting! Fighting Robots!!) but it was (on every platform) terrible. Implementing the idea failed horribly.

I have very many ideas for games. I think they're awesome ideas. But I do not code; I cannot program. So these ideas are worthless.
> 5 votes

# Answer
Your question is one of valuation.

In some ways, comparing ideas with execution is apples vs oranges. Fortunately, we have a system tailor made for that: economics. And the valuation we assign is termed "money".

But in order to do that, we need a more concrete understanding of the term "idea". Let's consider a treatment, a textual description of a few paragraphs. Something that could take a few minutes, at most a few hours, to write. By comparison, the work of implementing a game takes months or years, if not hundreds of person-years.

All right, maybe that's not a sufficient description of an "idea". A good idea should also be considered a product of all the bad ideas that came first, and were rejected. Maybe it takes months of thinking about ideas, considering them, evaluating them, tweaking them. So then the disparity is not as extreme.

But even then, if all you are left with is a splendidly inspiring paragraph, you're still at a significant disadvantage, vis a vis implementation. How do you evaluate it? Assuming the idea is 1 in a million, how do you convince people of that? Is it obvious to anyone reading it that the idea is valuable? No. So you need to make a case for its value.

You need to solicit opinions. The problem is, to increase your certainty of the valuation, you have to ask more people their opinion. But then you have to share the idea. And that means your idea is going to leak. At which point, it will no longer be scarce, so whatever significance it had as being "original" or "unique" will have evaporated. Asking people to sign an NDA to read your treatment will probably not work.

Now, if you expand your idea of "idea" beyond treatment into a full-fledged design document, say a twenty-thousand word treatise describing setting, characters, story, mechanics, and complete with illustrations and charts and graphs, you're into a different territory. At that point, the ability to copy such an idea is no longer trivial (and is easier to protect legally). It's real work that required a significant investment. That is more in line with a completed script for a movie.

A script is not a movie, but good scripts are valued highly, because they include the essence of the story. A game design document that successfully captures the essence of a game is also worth a lot (although I don't know if there will ever be a time when it becomes normal to sell game treatments to studios a la scripts).

The trick is, they are no longer just "ideas". In both cases, they are actually part of the implementation. But they are both reasonable challenges from the point of view of a single person (writer or game designer). As artifacts, they can be sufficiently well-formed to be considered and effectively judged, and from there can be produced into a real product (movie or game). A poor implementation would still fail, but that wouldn't necessarily diminish the quality of the design/writing work.

So if you want to prove your "idea" is worthy of implementation, write a design document.
> 5 votes

# Answer
It is true but it isn't really a bad thing. As everyone here will tell you, an idea isn't worth anything if its executed poorly. How are you going to bring your idea to life, how are you going to translate it into game elements and mechanics, that is execution and that is 99% of the work and effort.
> 4 votes

# Answer
In my opinion, both the idea and it's execution are equally important.

---

**Execution:**

Execution is what gives physical form to an idea. Yes, an idea. Without an idea first, any execution, if existing, is completely worthless and pointless.

If you pay attention, many of the answers here are actually labeling the **good execution of good ideas** as just "good execution (of possibly nothingness)".

I'll use a different perspective on the Infinite Monkey Theorem here: Execution without ideas is like you having an infinite amount of monkeys randomly typing text, but without any idea of what to do. Chances are they will give you a centillion (10^303) worthless papers before you get your first "William Shakespeare's work".

You can make the most advanced, reliable, visually appealing chess game ever made; You will still not rise much higher than any other professional chess game currently on market. The reason is, even tough the execution could hardly be any better, the project's goal, the idea, is terrible if you consider how many professional chess games are out there and how much the execution costs compare to those.

---

**Idea:**

Much like execution is nonexistent (or otherwise waste of resources) without an idea behind it, ideas that are never executed are also worthless; If they never turn real, they are a waste of thought and time.

Execution is what gives physical form to any idea. In a sense, the execution is an idea's body. Some people will hate me for giving this example in this way, but, an idea without a good execution is like Stephen Hawking: "Brilliant indeed, but still looks retarded."

---

Finally, in today's market for games or whatever software really, you will need both to be good in order to be successful. Too many people in too many places have too many ideas and/or too much time and money to work on them. And finding something that has not yet been done (and done well), although still not too hard, is not a simple task.

---

**\[Additional section\] The devil's lawyer (Idea's defense):**

I don't know if this is true for all successful games, but every single successful game I know about **has an excellent idea behind it!**

Many fellow answers here give examples of *"why execution is far more important than the ideas behind them"*, that are missing a very important point:

**There is a difference between general-concept ideas, and ideas for distinctive characteristics.**

Most (if not every) successful games have distinctive characteristics that make them essentially different from other games of the same genre.

For example, even tough many FPS games have the same "soldier in WW2" concept, successful ones that do not have a distinctive characteristic are extremely rare, in case any even exists.

The idea that makes a game successful is usually **not that of it's top-level general-concept**, but those of it's characteristics and smaller concepts that make it different.

Take the multi-player gameplay of *Counter-Strike: Source* and *Call Of Duty: Modern Warfare (1)*, for example; Both of them are First-Person-Shooters of quite the classic essentials; They are not very different from a shooter's perspective.

Essentially, you have modern guns, a scenario to use, and enemies to shoot, **in both games**. But can you call them the same? Far from that, right? Well, take graphics, physics and even sound out of the equation; Are they still different? Sure are, aren't they? So here is the golden question: **What exactly makes them actually different to the players?**

Well, the answer to that is: "Mostly, the way you acquire your weapons, and the way you respawn".

* In *CS:S*, weapons are acquired per-match with currency acquired per-round; and spawning is round-based (obeys a "hardcore" style), and dying in a round means you will only re-spawn at the start of the next.
* In *COD:MW*, weapons are player-based and unlocked to player's accounts as they gain experience points and advance in "ranks"; Spawn depends on match mode, but is, on the default game mode of "Team Deathmatch", only delayed for 15 seconds.

The top-level concept of both games is practically the same, and both games have good execution, but the ideas that brought the different characteristics plays a critical role in both's successes, as otherwise, with similar concept, characteristics and execution, either the older would be abandoned in favor of the newer, or the newer wouldn't be popularized because the older exists.

**Thus, good ideas are critical to a game's success.**
**And good execution, to successfully implement those ideas, is also critical.**
> 4 votes

# Answer
I think that your instinct is sound.

I see three contexts in which this question might be asked. First: planning for developing a new game, with a meaningful studio and budget. Second: wondering whether an idea can be sold to a game company, and if so, how much it can command. Third: a lone wolf wondering how to direct his energies, in creating a new game.

## Development with a studio

Here and in general, within the limits of sanity, idea is more important than execution.

The limits of sanity are that the game must (1) implement gameplay expressing the idea in question, and (2) work. If you don't have what you want to have, you aren't done with development yet; if you have a great game that occasionally suffers from crippling bugs, consider the fate of Black Isle after *Fallout 2*.

Within these limits, a game is about its premise, not its implementation. The difference between *Angry Birds* and various other *Scorched Earth* derivatives is that in *Angry Birds*, you're shooting at pigs with robins, not at tanks with other tanks. *The Sims* and its franchise have made a horrifying amount of money, but I wonder whether the original took more than a year to develop. *Deer Hunter* was an extremely crude game, but it made more than enough money to horrify the gaming mainstream.

There's a fashion in game development for ideas that are self-consciously *ideas*. The independent game development community, in particular, seems to think that if you're not making a WWII shooter or a Tolkien ripoff, you're making *World of Goo*, *Splosion Man*, or anything by Tim Schafer.

If you absolutely must limit yourself to these two categories of ideas, well, at least being yet another game about shooting Nazi elves won't actively damage your sales. But if you can come up with a premise that interests a significant number of people, it will be an enormous force-multiplier. The mass market is capable of understanding much more complex games than you think they are; it's just that they don't have a reason to.

## Selling an idea

This is impossible for two reasons.

First, every game company has a long list of their own ideas, which they'd want to work with first. If your idea is not good enough to be self-evidently superior to everything they've done so far, they won't be interested; if it *is* good enough that they would be willing to buy it, you should be developing it yourself.

Second, at least in the United States, to pitch an idea to a company puts you and them in sufficiently dangerous legal waters that no IP lawyer in his right mind would permit the company to listen to your pitch unless they've purchased your concept sight-unseen -- which they won't do unless you're a member of a category of maybe twenty people, most of whom you can probably name.

## As a lone wolf (or founder of a new team)

Have an idea that you can implement in a finite amount of time, but that's interesting enough to keep you motivated and attract an audience. It will take time to reach this point, but keep experimenting with different ideas and you'll get there.

Once there, make it happen. The days of successful garage game programmers have returned -- and this time you don't need to do rotoscoping in your backyard in order to potentially succeed.
> 3 votes

# Answer
I don't know about 99/1 but there is a reason I set my desktop background to the slogan "Ideas are easy, Implementation is hard"
> 2 votes

# Answer
Everyone is focusing on how important the execution is, which I suppose is natural in a forum full of developers/engineers (myself included). And execution is important, but I think the idea is being discredited a little too much. I think the reason Angry Birds is so much more popular than thousands of other apps is because, even though it could have been executed in a number of ways, its a relatively simple, but ingenious idea. It has been re-implemented on many platforms and maintains its popularity. But part of the idea is how its delivered. It's a game you can enjoy quickly and easily among other things. But that combined with dozens of other ideas that are combined into this game (make the characters cute and funny, etc) are what make this game so successful.

In short, execution is of little value without a good idea too. It's very hard to put a value on an idea, but when a particular application or game is orders of magnitude more successful than the alternatives, I would attribute that mostly to the idea. Another way to put it: A game can fail because of bad execution, but it can succeed because of a good idea.

**Edit:** Succeed isn't really the right word. I think excel is a more appropriate word. No matter how good the execution, a game can't excel with a boring idea, but it can still succeed. But a great idea can be responsible for a huge success (when paired with good execution).
> 1 votes

# Answer
It truly depends on how you form ideas, what you define an idea as, etc.

When I create an idea that I believe is considered a "Game Design Idea" it is extremely well formed, thought out, flaw-tested in my mind, and highly executed with thousands of practical variables to create a set of fault-finding methods.

Usually my ideas of this nature are attempted (eventually) by a real game developer who releases a full product. The ideas implemented in games sometimes work well, sometimes are obvious failures, but often are less than satisfactory (IMO at least) because the developer didn't use the same fault-finding methods as I did. Sometimes these developers patch their games, and fix the problem making the idea as I had originally came up with.

Because of this and my experience in game design and my constant watch of people's implementation of features which can be difficult to pull off successfully (ex. permadeath) I believe that an idea is everything, and execution is nothing more than a test to see if the idea is practical.
> 1 votes

# Answer
**Idea is more than 99% of the game, and execution is the rest.**

Ideas don't give you errors, ideas don't leak memory, ideas have no security issues. They are imponderables: a player won't say he doesn't like the idea of the game - he will say the game is boring!

Maybe idea is only a 1%, but it is the most important percent in your entire game. Idea is a foundation. You can build hundreds of houses (games) every year, and after a year or two they will collapse (be forgotten). You can also dig up to the ground, make a solid foundation and see your tower not only stands the test of time, but also grows, being upgraded by next generations, because the tower's foundation is so durable (ingeniously universal) that it just lets them to do so!

One may ask - why do games without ideas or with weak ideas turn out to be quite fun, then, or at least don't 'die' instantly? Because each of them has an idea, and it is a great one. Let's say you make a board game. It's not just a board game, it is the board game, a descendant of great Chess. What if you make a platform game - it may be really weak, but it's still a great idea of a character having an adventure in a two-dimensional world, jumping onto platforms and facing enemies with either, still beautiful in it's minimalism, jump-on-their-heads technique, or by something more sophisticated like RPG mechanisms. We don't create ideas, we change them and, just like in object inheritance, always base them on older ideas, even if the idea is only a "game" (like an "object" in inheritance). So while you can't make a tower without digging a little yourself, you probably can build a palace without foundations, because what was once swamp, now became dense sand of millions of ideas from game development past.

Why it is so hard to sell an idea then? Because you can easily steal (borrow) an idea. In game development everyone borrows from everyone, and while we all know Torchlight (1) took a lot of ideas from Diablo 3, still no Blizzard employee will dare to call it stealing. What you want to do - go to Electronic Arts, present them your ingenious idea and expect them to be honorable and either buy it from you or not use it? If two companies were about to make a game, one spending 90% of budget on inventing a new idea, and second waiting for the first to finish, steal it's idea and execute it with 10 times more money, which of these two games would you buy? There was a mod to Warcraft 3, called Defense of the Ancients. It got popular quickly, but the true success was achieved by RIOT company, who took the idea and executed it pretty well as League of Legends game.

Before Diablo III was released, it's lead designer Jay Wilson said in an interview that execution is more important than innovation:

http://www.youtube.com/watch?v=Nrli-by8oOU#t=2m25s

We all know how it ended. Diablo III made lots of money in first day, but players rated it quite low:

http://www.metacritic.com/game/pc/diablo-iii

There's much more to this Diablo 3 score, than lack of innovation (in fact I find D3 more innovative than better rated Torchlight 2). However it's not server issues or bugs (that are already fixed) that made 90% of people in my Diablo 3 contacts, and me, stop playing the game. Blizzard made too weak foundations to withstand huge hype for Diablo 3. DotA and League of Legends revolutionized co-op experience, and made H&S multiplayer system obsolete. The new idea of fair, skilled, rich PvP without items persistent between games simply won with an old idea where people with money or free time win.
> 0 votes

---
Tags: game-design
---


title: sprite animation individual framerate

text:
# Question
Title: sprite animation individual framerate
When animating sprites I am taking the delta difference between frames and locking the rendering frame rate of the sprite animation to the delta time.

```
float delay = 1000.0f / FPS;
float now = SDL_GetTicks();
if(now - sprite->last_update > delay) {
    render sprite frame
}

```

This is causing flickering because the background is being drawn faster than the sprite. (my guess) If I draw as fast as the frame rate the flickering goes away. If I slow down the background rendering then the background flickers. By slow down I mean set the FPS to 30. I want to be able to slow down the animation for a single sprite. I need a better way to lock the frame rate for individual sprites. I can slow the entire frame rate down by delaying in the game loop but I want to be able to slow down a single sprite. Is this possible?

# Answer
> 1 votes
Seeing as how you are already using SDL, I would advice taking the tutorials over at SDLtutorials.

In particular there is a tutorial on Animation which gives you an Animation CLASS, which includes framerate, frame increments, and even other more complex things like oscillation.

http://www.sdltutorials.com/sdl-animation

---
Tags: graphics, sprites, graphics-programming, spritesheet, graphic-effects
---


# Question
Title: How to break the feeling of busywork in a game
I don't know if this topic has been explored before but in a handful of games I've played there comes a point where trying to explore everything, doing sidequests, or even trying to get gear starts feeling like busywork. That sort of feeling makes me less interested in the game, and I usually wind up either just stopping playing altogether or just breezing through the rest of the game just to get it finished and out of the way. This feeling seems to happen mostly with RPGs from my own personal experiences.

How do you prevent activities the player can do (sidequests, exploration, item crafting, etc.) from feeling like artificial time padding or busywork?

# Answer
I think this can be summed up by my personal definition of the difference between work and play:

* **Work is when you spend effort to perform an arbitrary task in order to gain a reward.**
* **Play is when you spend effort to perform an arbitrary task which is itself the reward.**

---

**Game mechanics as a reward:**

"Rewards" in a game should be pay offs to encourage a player to become immersed in the game-play in ways you intend, and to encourage them to expand their understanding of game mechanics and learn how to play in the way you intended the game to play out.

*Example- Side quests.*

What is the purpose of the side quest, and what is the reward? The true purpose of a side quest in an RPG should be further branching the story, revealing more sub-plots and quirks in the tale and giving the player a feeling of uniqueness to their personal journey through the game. In this way, the side quest itself is the reward. This is far better than arbitrary non-story quests who's reward is gear. This second model causes a "minimum expected side quests" mentality, which turns the side quest from the reward itself (an expansion of the story and a chance to have more adventure) to a task (performing objectives X and Y to receive item Z which allows me to continue on the main quest as I'm strong enough to fight bad guy Q now).

There is one other thing to consider which goes hand in hand with game-mechanics as play which leads us to:

---

**Choice of play**

Choice of play involves giving players the option of performing a task, while minimizing arbitrarily limiting them or punishing them for not performing a certain set of tasks in a certain manner.

Lets take the master of this, Minecraft. The entirety of the reward of Minecraft is the creation of things, whether personal items or structures. If you view the standard survival mode of Minecraft as an RPG when you think about it the game itself requires very little to "beat". Bare bones play through you can ignore about 85% of the content in Minecraft to beat the game. Looking deeper though(as anyone who plays it at all does), and you realize that the game isn't about what you can do as HOW you can chose to do those things. In a sense, with a world with no written quests or missions the player "is their own NPC quest giver". What you take with you are your personal creations, and the obtainment of raw materials, the planning needed and the choice of what to make and in what order are the rewards themselves.

The most important part though, is that there is always a choice. How you go about retrieving your resources is a personal choice, as is the amount beyond the very bare minimums, and the "least fun"(work) choice for that player is the one which they will avoid while the "most fun"(play) is the one they will gravitate towards.

Each person is different and there really is no predicting what will REALLY be "play" in your game for a given person. In giving the players a choice each player can decide what is and is not their optimal route to enjoyment(note: I do not use the word "fun" intentionally here. Horror games are not "fun" they are enjoyable). No individual route should be arbitrarily more difficult, nor should any be arbitrarily easy (avoid "you're doing it the wrong way" game play traps).

---

**Conclusion**

The key point to take away is that if a game mechanic or set of mechanics is or can become tedious, then steps should be taken to minimize the mandatory performance of those mechanics lest they become work mechanics rather than play mechanics. This is by far not an extensive list, but I do hope it is helpful.
> 52 votes

# Answer
This is actually quite easy to say. Just not as easy to *do*.

Things feel like busywork when the player is *thinking* of them as busywork. Which means that the following are probably going on for the player:

1. The gameplay is no longer interesting on a moment-by-moment basis. They've figured out the basic act of play and can essentially switch off higher brain functions during the main portions of your gameplay.
2. The elements of the story (assuming you have one) are not captivating the player's interest. From Mark Twain: `the author shall make the reader feel a deep interest in the personages of his tale and in their fate; and that he shall make the reader love the good people in the tale and hate the bad ones.` Things like that. If the player flat out doesn't care, then you've failed as a storyteller.

So just make sure that your game is interesting to the player, either gameplay-wise or story-wise. Easy, right?

---

**Gameplay**

Keeping gameplay interesting for hours-long play times is *exceedingly* difficult. There's a reason why a lot of 20+ hour RPGs have a story and try to use that to maintain player interest. MMOs use a social component to keep people playing, but then they're not playing for your *game*, but for the other people *in* your game. It may as well be Monopoly at that point; it can still feel like work, just working to get something for someone else rather than themselves.

Sooner or later, players are going to figure out your game. The best way to handle this is to make sure that your core gameplay is flexible enough to keep throwing curves at the player that they are forced to react to. Make sure that there is no single optimal strategy. Change the gameplay as they play by introducing new mechanics and enemies that they have to react to in unexpected ways.

Most RPGs tend to be mechanically front-loaded. They show all of their basic play mechanics (magic systems, skills, etc) in the first few hours. They'll expand on the list of particular fields of mechanics (adding new spells and skills), but you generally don't get entirely new mechanics in the middle of a game. Getting new mechanics is a strong way of preserving interest.

Even something as simple as a mobility-based skill can radically change how the player plays and thus increase their interest in playing the game.

Use new enemies to help introduce new mechanics. Use those enemies to ensure that the player knows those mechanics exist and that the player can use them. And don't forget to test the player on *all* of their mechanics often, lest they fall out of habit with using them later.

While it's good to focus on the intellectual act of playing the game, don't discount the visceral or spectacle elements either. Hitting monsters with impressive-looking spells can hold a player's interests too. Probably not as much as interesting gameplay, but it is a way to help.

---

**Story**

Story is a bit easier, in terms of basic structure. Especially since the elements of narrative is a fairly well-understood concept; there are many books and such on crafting a story. Really, start with Mark Twain's absolute vivisection of Fenimore Cooper's work and go from there.

Of course, this is a videogame, so you need to figure out how your story is going to work in terms of being a game. How will the player interact with the unfolding story.

One of the most difficult things to do in videogame storytelling (without stripping away all control from the player) is to maintain a strong element of pacing in the game's story.

For videogame storytelling, mysteries often work quite well. It's very difficult to tell story during gameplay, so games often have a lot of dead time between explicit narrative elements. As such, one way to maintain interest in the narrative is to build elements of mysteries and the unknown into the story. A few subtle hints can keep the player's interest by making them wonder what it all means during gameplay segments. A hint here, a suggestion there, and so forth.

Characters are also a good way to maintain player interest between plot points. Making the characters interesting, real, and deep, people that the player wants to get to know or wants to hate.

Sidequests are far too often just excuses to force the player to play through an area and lengthen the gameplay. That's fine if the gameplay is interesting on its own. But unless a sidequest's storyline has something to do with the story (whether it's a piece of a main plotline, some element of a more complex non-linear plot, or erudition about an important character, etc), the sidequest is going to feel pointless to the player.

Sidequests often detract from the pacing of the overall story. There's a reason why most novels and movies don't have characters going off on sidequests. It's hard to build tension if characters are distracted every 2 hours with something that's irrelevant.

TV shows and comics, long-form episodic stories, will often have the effective equivalent of sidequests: standalone episodes/issues that don't contribute to the main story. However, even if they don't contribute to a main plot, they often *will* contribute to character establishment/development or thematic progression.

Basically, make sidequests *matter*. Never add a sidequest for purely gameplay reasons. If story is going to matter for your game, then a sidequest needs to be justified by that story.
> 10 votes

# Answer
This is a very difficult task. Primarily because you're dealing with the perceptions of others. What one person sees as busy work, another will see as a fun side quest. RPGs (online or otherwise) are notable for this "busywork" or "grind" because of the XP systems and leveling. If you need X experience points to get to level Y, and you know that killing monster Z gives you N experience points, etc, etc. Grind ensues.

The primary way to solve this is to abstract away the XP system and leveling, and **make the progress of them game story driven instead of XP/level driven**. Giving each *required* quest a true purpose in the game is important. Advancing the story should be more important that leveling up your character. This is the hard part, **the story has to be interesting for this to work**. Like a good book, your story should be a page turner. It's a role playing game after all, if the player really feels like the role they're playing is important, it won't feel like a grind.

Player skills and abilities develop as the story progresses. It depends on the skills/abilities system you're implementing for how this will work. Perhaps it's a Skyrim style system (I'm a fan of this one), that improves the skills you use, as you use them. Or some type of XP pool system that allows you to spend XP in their pool on the skills they want. Whatever way you go, it should be secondary to the story. Maybe the story unlocks a larger pool of XP, opens up more skills or increases the rate you improve skills/gain XP.

Side quests are still important for players that want to spend more time with the game and explore more of the world. These quests should add to the story of the world.

Play testing will be critical for determining the "grindy-ness" of quests/tasks. Play test it yourself and get friends (gamedevSE colleagues?) to test your game. Implement a information gathering GUI that can pop-up after each quest to ask the player to rate the quest for fun/grind/rewards/difficulty/etc.
> 8 votes

# Answer
Just like with any design(not just games, but anything) you do not add in something unless it meets quality standards.

Designers who add "filler" in their games do a great disservice to both their gamers and to their talents as designers.

A good design only implements that which is fun. It skips the boring tasks, the repetitive dulling often coined as "the grind", and gets players straight into the action.

Critics of the "Only add what is fun" method complain that the consumers of this design are ADHD or want "EZ MODE" but these people should most often be ignored despite how vocal they can become. They claim 'filler' is required in games to separate the fun from the dull. However, one needs only to look at games which never add boring elements, such as TellTale's THE WALKING DEAD game which easily won Game of the Year.

This game takes players into the hallmark moments of the storyline. You do not have to do boring walking, traveling, repetitive combat, or any form of busywork outside of collecting clues. Yet the "busywork" of point & click not only allows the player to feel like they're taking a part in the story (incredibly important to gameplay and the player's connection to the story) but it is a vessel to bring MORE fun to the player in the form of character discussions, monologues, and other visual and audio elements that bring the story to life.

There are very, very few moments where I felt I wasted my time clicking an object, such as during a crisis where the player clicks on something useless and the character replies, "I don't have time for this!!" It is things like this that are added to games, "busywork", or content that is utterly pointless. It would have been a better experience if those 1-2 objects weren't in the game to click during those crisis scenes.

FTL: Faster than Light, is another great example of skipping the boring parts to instantly go into the FUN gameplay. There is no busy work of grinding for resources, as your time is limited in each zone. You can try to do busy work, but the fleet will quickly force you to proceed to the next level. Your character spaceship does not travel through WASD movement, but instead travels faster than light- and instantly arrives at various random encounters. Random encounters that all have purpose. Even the empty encounters have purpose! The encounters where nothing happens, gives the player a much-needed break from the never-ending difficulty of the game's relentless aggression.

These games are great examples of how to break free of busywork, by only allowing the player to experience the FUN, INTENSE moments. Both games have no boring moments, as you are constantly on edge or taking a break from a crisis. A break that is never long enough before the s\*** hits the fan again.
> 1 votes

---
Tags: game-design
---


# Question
Title: How do I create a cel-shaded cartoon look?
I am interested in everything related to this kind of effect (modeling, game engine, animation). What sort of stuff is needed?

Here are some sample images of what I mean:

# Answer
## Cel shading / Toon shading

There might be something more to it, but in general, all of your examples use Cel shading to some extent.

As for your question, whether there are any engines that support this. Well, that should be possible in every engine out there. The ones that aren't hobby projects should actually have such shader available in their standard assets (Unity3D has those dupped **Toon shader**).

But, the power behind the cel shading is shaders.

### 2D Games

For 2D applications, using software rendering, you could achieve this by applying a per-pixel modification. That won't be nowhere near fast, but it's doable.
Though, for a software rendered application I'd suggest that you ask your graphics artists to make such sprites out-of-box.

A quick google search gave me these results. There has to be more.

### 3D Games

As for 3D applications, rendering is done either by OpenGL or Direct3D. Both of these have shader languages implemented, that can do your kind of manipulations and many others.

OpenGL has GLSL — OpenGL Shading Language.
Direct3D has HLSL — High-level Shading Language.

As for tutorials and guides, there are plenty (GLSL, HLSL), due to the release of Borderlands and huge amounts of Indie studios started the past years, the information available about cel/toon shading is aplenty.

There is a specific question on GLSL cel shader right here in GameDev.SE: Is there any opengl cel shading tutorial out there (without GLAUX)?.

*A screenshot of Borderlands*

That should be enough information to get you started with.
> 16 votes

---
Tags: 3d, shaders, graphic-effects, cel-shading
---


title: questions about position and size

text:
# Question
Title: questions about position and size
I am new to game development and I wanted to ask a question.

I am reading the simple game example from here.

1) I want to ask why we define bucket.x = 800 / 2 - 48 / 2 ? How is that? Why not just set bucket.x=400 ( at the middle position).

```
...

camera.setToOrtho(false, 800, 480);
...
bucket = new Rectangle();
   bucket.x = 800 / 2 - 48 / 2;
   bucket.y = 20;
   bucket.width = 48;
   bucket.height = 48;

```

2) The bucket width and height are seet 1/10 of our screen size.Ok. But what about the real dimensions of bucket object?I mean , the bucket what size must be?32x32 pix?48X48 pix?How we handle that?

3) Also, I am a bit confused about x and y dimensions. x refers to width and y to height as we see the cell phone in portrait mode? So , if we are in landscape mode , y is "x"?

Thanks!

# Answer
1. If you set `bucket.x` as 400 you will draw the **left edge** of the bucket at 400 which will make it displaced to the right. You need to draw **the center** of the bucket at 400 to effectively center it, hence you subtract its size divided by 2.
2. There are multiple ways to handle this. In my small project I'm using a fixed Orthographic. You set the camera width to 480 pixels. If you display that camera on a different screen size it will still be 480 stretched to the new size, and the bucket will be 48 pixels stretched to fit. The best way to work in my (little) experience is to choose a resolution and make your assets based on that resolution and let the engine to the scale job. There is multi-resolution options for optimal display but that requries multiple size assets and it is better start simple.
3. `X` will always be the horizontal coordinate and `Y` the vertical one. Just consider you changed resolutions, for example, from `640x480` to `480,640`.
> 2 votes

---
Tags: libgdx
---


# Question
Title: Is it possible to show vertex information in tables in VS2012 like in PIX?
In PIX I was able to watch the objects' vertex data at different stages in tables, like before vertex shader, between vertex and pixel shaders, and so on. Can you see this in Visual Studio 2012 graphics debugger? I mean, you can see the data as a list of sorts, but it's impossible to get a good overview of that if you have more than like 3 vertices.

# Answer
> 1 votes
To my knowledge, the list-based PostVS functionality is completely gone from VSPix. All you can get is a small wireframe image from the pipeline stages.

You can modify your code to use stream-output via CreateGeometryShaderWithStreamOutput as a non-generic workaround hack to store the intermediary results into a buffer and read that back CPU-side. It's intrusive, but it might just be enough for those situations where you really need the data.

---
Tags: debugging, pix
---


# Question
Title: 2D Platform character getting "unaligned" with the map
I'm trying to make a 2D Platform game and so far I can have my character moving around in a tiled map and collisions are working too. So far so good.

The problem I'm having is that the character can get "unaligned" with the map if I spawn it without double checking the X coordinate. This means that, on certain conditions, the character could walk over a small gap (just large enough for it to fit in) on the floor. This happens because the X speed is a constant value, so in one frame the character is standing before the gap but the next frame it's past the gap.

I can solve it by simply making sure the spawning coordinates will be aligned with the map (and the X speed allows it since the tile size is a multiple of it), but it does sound like a fishy solution to me since I may want to add power-ups in the future that increase the speed.

So I'm wondering if I'm missing something on how characters should move or maybe I should actually just double check the spawning coordinates? Or maybe it is a normal thing to happen in a game??

# Answer
If the "fixed speed" is a feature of the game (e.g. so that in a tile based game the character is always positioned in line with the tiles), you need to ensure that X is initialised to a good initial step.

If not then you have a couple of options

1. The simplest change that you could do would be to make the "fixed speed" small enough relative to other dimensions in the game so that issues like this aren't a problem (e.g. make the gap bigger)
2. A more sophisticated solution would be to work out the distance travelled each frame based on the characters speed and the elapsed time since the last frame. This would mean that the distance travelled over time would be constant howeve the distance travelled each frame wouldn't. Consider reading Fix Your Timestep!.

With option #2 you would still need to ensure that your gap is big enough so that the player can fall down without too much difficulty.
> 0 votes

---
Tags: c++, opengl, 2d, platformer
---


title: Colliding a player and a maze wall

text:
# Question
Title: Colliding a player and a maze wall
I am making a game very similar to Tank Trouble. I cannot get t the tank to collide with the maze in the map.

Let `tx` and `ty` = the tank x and y value.
Let `x` and `y` = the walls x and y value.
Let `h` and `w` = the walls height and width.

```
public boolean collidesWith(double tx, double ty)
{
    if ((tx - 55 > x) && (tx + 55 < x + w) && (ty - 55 > y) && (ty + 55 < y + h))
    {
        return true;
    }

    return false;
}

```

# Answer
> 0 votes
One way is to just return false whenever you find a case that makes it impossible for the two to intersect.

```
public boolean collidesWith(double tx, double ty) {
    if ((tx + 55 < x) || (tx - 55 > x + w) ||
        (ty + 55 < y) || (ty + 55 > y + h)) {
        return false;
    }

    return true;
}

```

---
Tags: java, 2d
---


title: How to avoid being throttled?

text:
# Question
Title: How to avoid being throttled?
I'm writing a networked iOS game. When sending packets with `GKMatchSendDataReliable` (which I **assumed** was UDP with their own packet reception code written) at 60 packets per second (so 16 ms between adjacent packets), average ping times rapidly get worse: I opened 7 GameCenter matches below (one after the other) and simply sent a "flood" of 100 packets (at a rate of 60 packets per second). I measured the average roundtrip time, and these are the results:

```
[ 21:16:39 ]:  I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms
[ 21:16:34 ]:  I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms
[ 21:16:45 ]:  I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 ms
[ 21:16:51 ]:  I saw an average roundtrip time of 179.053118 ms, he saw 156.869141 ms
[ 21:16:57 ]:  I saw an average roundtrip time of 75.025076 ms, he saw 75.419723 ms
[ 21:17:23 ]:  I saw an average roundtrip time of 8832.082488 ms, he saw 7616.877558 ms
[ 21:19:33 ]:  I saw an average roundtrip time of 25088.962344 ms, he saw 16833.064914 ms

```

After the last 2 tests the results are around 1000 ms.

It would seem that I'm being throttled, most likely by my ISP. Because this is an iOS game, people will use regular residential connections.

When I changed the packet send rate to being 10 times slower (so 1 packet every 160 ms), the tests take much longer, but roundtrip times remain consistently low.

> \[ 21:31:27 \]: I saw an average roundtrip time of 55.289109 ms, he saw 69.032727 ms

So it looks like to keep low latency on the connection (and not be "punished" by ISPs) I have to reduce the rate of packets that I send. Keep in mind these are **very** small packets, like 40 bytes maximum, yet I'm still being throttled.

I'm looking for guidelines on how many UDP packets I can send per second to avoid being throttled! Are there any general guidelines anywhere?

# Answer
Not even home PC based action games or big MMOs run their packets at 60Hz. Plus having really small packet sizes is not necessarily a great thing, each one of those tiny packets has a big overhead in just sending it out.

Try shooting for 10Hz updates with some client-side interpolation. I assume that you're already interpolating because there will always be ping delays.

Read up on MTU sizes and throwing more info in there to cover the longer time frame. An average packet size at the transport layer will be 1400 or so, anything over the MTU size will split your message and cause even more overhead.
> 9 votes

# Answer
First, you have to make sure how big the entire data is. Your ISP will most likely care about actual bytes sent, not the amount or frequency of datagrams. If you're sending maximum (65507 payload octects) sized datagrams 60 times per second, you're sending around 30 Mb/s upstream. Not everybody has that kind of connection.

Remember that the IP header is 20 octets long, and the UDP header is 8 octets long. That's an additional 28 octets you're sending for each datagram.

If you're not maxing out your connection, there are many places where your packets may be getting delayed: namely the client's OS, your gateway (probably a wireless router or cable modem), your ISP, the other peer's ISP, the other peer's gateway, the other peer's OS among others.

In case you haven't used it yet, I recommend you use Wireshark, which is an extremely powerful tool to diagnose networking problems. Think of it as the equivalent of a debugger, but for networking.

There are several ways you can diagnose network traffic with Wireshark:

* Use Wireshark in a PC in the same network as the mobile device, with a promiscuous hub and setting your network device as promiscuous
* Set a PC as a wireless gateway and connect your mobile device to that gateway, then listen with Wireshark on said PC
* Run Wireshark in the same machine as an emulator
* Run tcpdump in the device itself (easy on Android, requires jailbreak on iOS), and then read the captured data on Wireshark
* Make a simple program that does the exact same thing, but that works on a PC, and use Wireshark in there.
* ... and many others

You want to check which packages are getting sent, and when. For example, if the delay occurs before they're getting sent, you're being throttled by the OS; while if you're getting the delay even on a desktop version of the same program, this means you're being throttled by the network somewhere.

Usually, if you're getting throttled by the network, you should get ICMP type 4 datagrams, so you can use those to check where exactly you're getting throttled.

In conclusion, there are many reasons why your packages may be getting delayed, and it would be wise to find out where the problem is before you start attempting to solve the problem.
> 7 votes

# Answer
It appears one of my assumptions was wrong. According to this:

> GKMatchSendDataUnreliable mode, the image to be transmitted in the so-called UDP. GKMatchSendDataReliable mode image send by TCP. Should it be a GKMatchSendDataUnreliable usually.

Changing the send mode to **real** UDP (ie `GKMatchSendDataUnreliable`) **appears to** maintain low ping rates at 60 packets per second. It looks like I've been struck by Nagles *yet again*.

I still get weird behavior (periods with very high ping times), but I'm not sure the root cause (ISP or network congestion).

```
[ 10:30:33 ]:  I saw an average roundtrip time of 39.908923 ms, he saw 48.437794 ms
[ 10:30:39 ]:  I saw an average roundtrip time of 26.278577 ms, he saw 27.023854 ms
[ 10:30:48 ]:  I saw an average roundtrip time of 23.254163 ms, he saw 24.495182 ms
[ 10:30:54 ]:  I saw an average roundtrip time of 37.333127 ms, he saw 34.780404 ms
[ 10:31:03 ]:  I saw an average roundtrip time of 29.198575 ms, he saw 29.071106 ms
[ 10:31:11 ]:  I saw an average roundtrip time of 49.030299 ms, he saw 48.675459 ms
[ 10:31:18 ]:  I saw an average roundtrip time of 34.031792 ms, he saw 34.698117 ms
[ 10:31:24 ]:  I saw an average roundtrip time of 30.058642 ms, he saw 32.814952 ms
[ 10:31:30 ]:  I saw an average roundtrip time of 53.110438 ms, he saw 54.271453 ms
[ 10:31:45 ]:  I saw an average roundtrip time of 119.693933 ms, he saw 107.616359 ms
[ 10:31:50 ]:  I saw an average roundtrip time of 222.644443 ms, he saw 229.589861 ms
[ 10:31:57 ]:  I saw an average roundtrip time of 166.827070 ms, he saw 167.647724 ms
[ 10:32:05 ]:  I saw an average roundtrip time of 765.356593 ms, he saw 859.600923 ms
[ 10:32:13 ]:  I saw an average roundtrip time of 357.522686 ms, he saw 339.648654 ms
[ 10:32:24 ]:  I saw an average roundtrip time of 1115.639593 ms, he saw 1060.574401 ms
[ 10:32:39 ]:  I saw an average roundtrip time of 175.845995 ms, he saw 171.112166 ms
[ 10:32:44 ]:  I saw an average roundtrip time of 47.262925 ms, he saw 41.987869 ms
[ 10:32:52 ]:  I saw an average roundtrip time of 74.524443 ms, he saw 78.868198 ms
[ 10:33:47 ]:  I saw an average roundtrip time of 20.943917 ms, he saw 21.217377 ms
[ 10:33:52 ]:  I saw an average roundtrip time of 28.944821 ms, he saw 29.303144 ms
[ 10:34:06 ]:  I saw an average roundtrip time of 25.581624 ms, he saw 25.439416 ms
[ 10:34:13 ]:  I saw an average roundtrip time of 25.565568 ms, he saw 25.655267 ms
[ 10:34:18 ]:  I saw an average roundtrip time of 38.609394 ms, he saw 37.462835 ms

```

Later:

```
[ 10:38:11 ]:  I saw an average roundtrip time of 40.037623 ms, he saw 43.367524 ms
[ 10:38:21 ]:  I saw an average roundtrip time of 121.222703 ms, he saw 118.855264 ms
[ 10:38:28 ]:  I saw an average roundtrip time of 726.391897 ms, he saw 685.742454 ms
[ 10:38:33 ]:  I saw an average roundtrip time of 60.251207 ms, he saw 57.974503 ms
[ 10:38:42 ]:  I saw an average roundtrip time of 1133.909392 ms, he saw 1124.404501 ms

```

So it's sporadic and goes in waves. I guess I will have to try some of the suggestions in the other posts such as reducing my packet send rate.
> 0 votes

---
Tags: networking, udp
---


# Question
Title: Is it possible to rent a server for my own game?
I'm an independent game developer and I don't yet have a lot of money to buy myself a very cool high-speed and low-latency internet connection along with a powerful server machine to place somewhere in the world to host my very own game's server application for my fans to play on.

I know it's possible to rent a server for an existing popular game (for example, Team Fortress 2), but how about renting a server for my own game that I'm developing? Are there services specifically for that, or should I just rent some general purpose something and go from there?

Such a server should be:

* Easy to update
* With a low-latency for a specific region (I'm planning on renting EU and US servers)

# Answer
> 7 votes
What about VPS servers? They can be pretty cheap and easily upgradeable because of their flexibility.

VPS ( Virtual private server ) servers differ from real servers in the fact that they are actually just one of many virtual machines running on a real server, which makes it pretty customizable and flexible.

# Answer
> 4 votes
Amazon Web Services (AWS) is a very popular option for your kind of scenario.

For as low as six cents per hour, you can have your own Linux virtual machine (typically running Ubuntu or CentOS).

Here's why AWS might be a good fit for you:

* You can spin up a VM on an as-needed basis and spin it down when you don't need it, to save money
* You can create VMs in several regions, including US (Virginia, Oregon, N. Cal), Europe (Ireland), Asia (Singapore, Tokyo), Australia, South America (Brazil)

The biggest pain point you're likely to encounter is that AWS can be very confusing for beginners. There are many services - EC2 for controlling VMs, S3 for storing individual files, EBS for persistent disks, RDS for external databases, etc. When you think of AWS as "just a Linux VM" it doesn't make sense why you'd want any of those extra services; but when you need to start scaling up the number of servers you're running or when you need to store a virtually unbounded amount of data, having those components available external to your VM is exactly what allows you to scale.

If you don't foresee needing anything scalable to the extent that AWS is scalable, Digital Ocean is another currently popular hosting provider that is closer to the "renting a box" paradigm. For $5 per month, you can rent a VM that has 512MB RAM, 1 core CPU, 20GB SSD Disk, and 1TB of bandwidth; they also have more expensive options with more resources.

# Answer
> 2 votes
wingleader is correct, if you're up for creating your own Linux-based server program. One option is to use one of several cloud-computing options, which often are a bit more sandboxed using particular coding environments. I haven't ever used their services myself, but if I have the correct idea,

* Amazon Web Services will let you program in Java
* Windows Azure will let you use Microsoft languages like C#
* Google App Engine: No personal knowledge

It may partially depend on the type of game you're creating. If the response for a particular action doesn't depend on per-second responsiveness (ie, a space trading game where players travel between worlds buying/selling goods) then those web services may be fine. For a fast-paced shooting game with precise hit detection, you'll almost certainly be going the route of some sort of native-code Linux server (as wingleader suggested).

What early companies did was only make one server to keep track of other servers (each hosted by players with a spare Linux machine) and have their game connect directly to that to provide players places to go.

# Answer
> 0 votes
Yes you can, not many people can spend half milion dollars + on server building.

OVH.com servers are considered to be one of the cheapest, I use them. 10Gbit/s download speed, 18gb RAM, 6TB disk for about $350.

You can use pre installed server software, many versions of Debian, Freebsd, Windows, Ubuntu. 32/64 bit.

I assume that you either know how to or you have someone who can configure a server.

Search google for "Dedicated server", that is the best option when hosting your game, you got access to the machine, but you must know how to move around it.

---
Tags: server
---


title: DirectX11 Gamma Correction

text:
# Question
Title: DirectX11 Gamma Correction
I am writing a game using SharpDX with DirectX11 and I have been reading that it is important to apply gamma correction to my engine in order to perform correct linear lighting calculations.

So I modified the function which loads my diffuse texture maps so that it uses R8G8B8A8\_UNorm\_SRgb format rather than R8G8B8A8\_UNorm. I then modified my framebuffer format so that it also uses R8G8B8A8\_UNorm\_SRgb.

It was my understanding that this would use hardware to remove gamma correction from my textures allowing me to perform linear lighting calculations and then reapply gamma correction when rendering the final scene to the frame buffer.

However when I do this the scene looks washed out and too bright. My next step was to take a look at some gamma calibration charts Gamma Calibration Chart. When viewing this chart in my browser I get a value of approximately 2.2.

I then loaded this chart into my engine and rendered it to screen. When using R8G8B8A8\_UNorm I get the same value (approximately 2.2) but when using R8G8B8A8\_UNorm\_SRgb I get a value around 1.2.

It seems like the scene has already been gamma corrected somehow. Is this the case, what am I missing?

# Answer
> 2 votes
As suggested by Archy, sRGB conversion was not being applied to my texture maps.

The problem was that I missed a flag from the ImageLoadInformation used to load my diffuse texture maps. This meant that gamma correction was not being removed from my source textures before lighting was applied, leading to double gamma correction on output to the frame buffer.

```
return (Texture2D)Texture2D.FromFile(
    DeviceManager.Instance.Device,
    filename,
    new ImageLoadInformation
    {
        Format = Format.R8G8B8A8_UNorm_SRgb,
        Filter = FilterFlags.SRgbIn | FilterFlags.None,
        BindFlags = BindFlags.ShaderResource,
        CpuAccessFlags = CpuAccessFlags.None,
        Usage = ResourceUsage.Default
    });

```

I was missing

```
Filter = FilterFlags.SRgbIn

```

---
Tags: directx, directx11, sharpdx
---


title: How to rotate a cell of sprite sheet?

text:
# Question
Title: How to rotate a cell of sprite sheet?
I can draw an animated sprite sheet without problems. But when it comes to rotation, the single cell (which gets drawn) rotates around the center of the whole sheet.

How can I get my cell to rotate around its own center? This is what I found on the internet:

> Copy the current frame to a buffer, rotate the buffer, then copy the buffer to the screen. Source

But I don't know what this means.

# Answer
Just rotate the *polygon* that the sprite is being rendered to. You do not have to (and should not) rotate the *actual sprite texels* (unless you have a specific reason for doing so, which you didn't elaborate in your question).
> 2 votes

---
Tags: xna, c#
---


# Question
Title: Web workers for HTML5 game physics simulation?
A bit related to this question.

The idea is to guarantee the same physics behavior as much as possible. Would it be possible to run fixed time step physics on a web worker? The UI would update itself with different/variable refresh rate.

Has anyone tried such yet?

# Answer
> 3 votes
This could work, however `WebWorker`s follow the observer pattern, the `document` (html page that owns the worker) can only listen and post messages to/from a worker. From that, there's a few options, I guess. In all cases I think you will need to find someway to determine the optimal FPS of the user agent in order to optimize the information. Then you could either:

* Tell the workers to post messages at those time intervals
    + Downside(s?): you have to assume that the `document` will be ready for the response when it happens.
* Tell the `document` to send a message to the worker requesting physics at time interval `x`, then the worker would post a response (hopefully) shortly after that.
    + Downside(s?): since all posts and responses are asyncronous, there may be delays between the request and response from the worker. In this case you would also have to null out the `onmessage` event to prevent your `document` from listening when it doesn't expect to be.

I'm sure there's other things I missed or ways to handle communications as well. I'll be looking forward to other answers on the subject myself!

# Answer
> 3 votes
I found this experiment. It runs Box2d physics on a web worker. I haven't yet checked in the detail how it gets around issues mentioned in Vincent Scheib's comments.

# Answer
> 2 votes
Physijs uses a web worker. It glues together ammojs physics with Three.js objects and updates them as need be. It features both fixed and fluid time steps, I believe

---
Tags: physics, javascript, html5
---


# Question
Title: In Unity3D, try to load a png into a Texture2D in an Editor script and then run PackTextures, but they need Readable flag to be set
I am trying to automatically create a texture atlas from a set of generated png files in an Editor script. The problem is that I can't seem to be able to load a png into a Texture3D without it being inaccessible by the `PackTextures` method. I have tried a few different ways to load the PNGs, such as `Resources.LoadAssetAtPath(...)`, `AssetDatabase.LoadAssetAtPath(...)` and a few more.

Since all of this is done in `OnPostprocessAllAssets`, I don't want to have to do any manual editing of the textures. I just want to be able to drop a PNG into a certain folder and get an updated atlas. Answers such as this seem to suggest manual editing.

The actual error message is

> "Texture atlas needs textures to have Readable flag set!".

So the question is, is it possible to do this kind of post processing in Unity3D? Is there any way to import a PNG into a Texture2D with the Readable flag set, without having to manually change it?

# Answer
> 1 votes
Can you use the `AssetPostprocessor` to change the import settings of the textures in that particular folder?

http://docs.unity3d.com/Documentation/ScriptReference/AssetPostprocessor.OnPreprocessTexture.html

http://docs.unity3d.com/Documentation/ScriptReference/TextureImporter.html http://docs.unity3d.com/Documentation/ScriptReference/TextureImporter-isReadable.html

```
class MyTexturePostprocessor extends AssetPostprocessor {
    function OnPreprocessTexture () {
        if (assetPath.Contains("atlas")) {
            var textureImporter : TextureImporter = assetImporter;
            textureImporter.isReadable = true;
        }
    }
}

```

---
Tags: unity, textures, spritesheet, texture-atlas, png
---


title: Diagonal line of sight with two corners

text:
# Question
Title: Diagonal line of sight with two corners
Right now I'm using Bresenham's line algorithm for line of sight. The problem is I've found an edge case where players can look through walls. Occurs when the player looks between two corners of a wall with a gap on the other side at specific angles.

The result I want is for the tile between two walls to be marked invalid as so.

What is the fastest way to modify Bresenham's line algorithm to solve this? If there isn't a good solution, is there a better suited algorithm? Any ideas are welcome. Please note the solution should also be capable of supporting 3d.

Edit: My simple solution was to check if both corners are closed when a line's x and y coordinates change. For the working source code and an interactive demo of the completed product please see http://ashblue.github.io/javascript-pathfinding/

# Answer
Eric Lippert wrote an excellent series on generating line-of-sight in C# with Shadow Casting on a rectangular planar grid..

Amongst other issues, Eric dealt with various questions that must be answered about the line-of-sight requirements, which give different results, and gives examples of a couple of different results. One of the articles deals in depth with a "looking around the corner" circumstance which occurred in an early version of his algorithm.

I have adapted Eric's algorithm to a hexagonal grid here, and successfully used it on large hexagonal grids (\> 400 x 700) with an extensive visibility radius (\> 60 hexes). This implementation calculates and displays complete field-of-view as fast as I can blink, using a single i7 CPU. This is certainly fast enough for any uses I expect to put it to.

**Line-of-sight with elevation:**
The hex-grid implementation linked to above calculates line-of-sight with elevation, not just obstacles. The documentation notes also discuss an additional decision which must be made in regards to the elevation calculations: The target height and observer height. The default selection is to make both equal, which creates symmetric field-of-view, but ground-to-ground and observer-eyes to ground can also be selected. (The code is Open Source under MIT License)
> 7 votes

# Answer
What if for LOS calculation you have a separate "higher resolution" grid that fills in the corner gaps. I was thinking something like this:

The left is the original block section of 4 squares.

The right is the "high resolution" version, as you can see each original square was subdivided into quaters and one of the corners has been filled in. I'm not sure offhand the algorithm to generate that, but it can be pre-computed from the current map.

It does mean that the coordinate space is quadrupled but I don't envision that being a significant performance issue.
> 1 votes

---
Tags: 3d, tiles, tilemap, raycasting, line-of-sight
---


title: Udp protocol for game server/client

text:
# Question
Title: Udp protocol for game server/client
I've been trying to get a simple client server relation using udp for about a week now, And I think it's time for me to stop trying and ask for help... I understand how TCP works and UDP too. The thing is, when I use UDP, there's no way for me to know the client is still connected, and same thing for the client. I tried using two connections, one TCP for sending important data such as login information, but I don't know how to keep a stable connection in UDP!

Here's how I work:

1. The server starts a new thread for listening on port X with TCP
2. The client connects to the server in TCP using the port X
3. The server sends a confirmation for connection on the UDP part of the server
4. The client starts sending information (location of the player) via udp and opens a thread for that client (tcp and udp).
5. When the server hasn't received data for 15 seconds, it sends a "ping"
6. If the server hasn't received "pong" in the next 5 seconds, it closes the connection + thread for this client.
7. When a client is disconnected or sends a disconnect packet, it closes the connection + thread for this client.

The main problem with this is that I don't know how to receive data(server side) from a certain address via udp. At the moment, I can only receive data from every address...

Is there a way I could ensure I only receive data from a single remote computer (on the listening thread of that particular client)? Am I doing something wrong? Should work differently (seems it's making lots of connections and threads for a server that would have lots of clients)?

I'm working in C# with console applications at the moment, but I'll be using forms in the future, and the game is going to be in Java (C# XNA 4.0 for testing the connection first).

And most important of all, Thanks you!

# Answer
You can't route particular clients to particular threads automatically. You would need to open a different UDP port for each client and listen on a particular port on only one thread.

This really isn't ideal, though. Open a single listening UDP socket on a single thread and do all of your networking there. You can generate messages to other threads if your game actually needs other threads for processing (you probably don't). It's more common to have a single thread for receiving and sending network packets and then another for all your game logic, so you can easily get away with a pair of concurrent queues (one for pushing network messages into to be sent by the network thread, and one filled by the networking thread with incoming packets for your logic thread to process).

Java (and to a lesser extend, C#) try to make you think of using threads for everything but you really really shouldn't. USe them to process large parallel workloads, not to do I/O multiplexing. Especially when the very nature of the protocol being used (UDP) is designed to handle multiple clients on a single server socket.

You don't need multiple UDP sockets for each client as you can retrieve the client endpoint (address + port) when reading any packet from a UDP socket. You can use this endpoint to map to client status objects.

On an unrelated note, using TCP to initialize the connection is not super ideal. One of the primary problems is that a client behind most NAT firewalls will not be able to receive data on a UDP port unless the client sends outgoing data on that port. Better to just have a single incoming UDP port and use UDP requests from the client to initialize things.
> 2 votes

---
Tags: c#, udp
---


# Question
Title: Simple Bounding Sphere Calculations for 2d game
I'm writing a 2d game and have a question regarding the use of bounding spheres.

I'm kind of OK with the math, but I'm confused about one thing.

To work out the distance between the 2 centre points I've read that I need to do something like this:

XDistance = Sphere2\_center - Sphere1\_center.

And then some other calculations etc...

So if me Sphere1\_center X is say, 100 pixels and my Sphere2\_center is say 200, then the XDistance will equal to 100 which is fine, however, what confuses me is this. What happens if the positions of the spheres are reversed, then the 'code' would result in -100. This surely will affect the remainder of the calculations?

Not sure if I've got the whole thing wrong but I would be grateful if someone could advise. Many thanks

# Answer
The distance between the center of the circles can be understood as the distance between two points.

You can calculate it as:

```
dx = p1.x - p2.x
dy = p1.y - p2.y
distance = sqrt(dx*dx + dy*dy)
    // where p1 and p2 are two points (x,y) and sqrt is the square root

```

In your little example, using only the `x` coordinate:

```
distance_x = sqrt((p1.x-p2.x)*(p1.x-p2.x))

```
> 2 votes

# Answer
Aran's answer is exactly correct, but you could also do:

```
distance_x = Math.Abs(p1.x - p2.x);

```

So even if p1.x = 100 and p2.x = 200, 100-200 = -100, which the absolute value of is 100. I'm not sure if Abs is faster the sqrt, but it's less complicated.
> 2 votes

---
Tags: 2d, collision-detection, sprites, bounding-spheres
---


# Question
Title: How to calculate the Screen Position of a bounding sphere/box?
Synopsis: What I have is an object rendered on the screen. I need to calculate the top-left / bottom-right of it's location on the screen in Screen Coordinates.

Explanation: The object is basically a box that I'm trying to draw sprite textures into at specific locations, but due to the screen resolution being a variable (dependent on player settings), I can't hard-code in these translations. So what I need to do is find out what the bounding box of the object is in Screen-Coordinates. Once I know the bounding box, I can calculate the offsets to the positions within it.

I can calculate the center position of the box already with a function I scavenged:

```
public Vector2 GetScreenPoint(Matrix objMatrix)
{
    Matrix mat = objMatrix * mCamera.mViewMatrix * mCamera.mProjMatrix;
    Vector4 v4 = Vector4.Transform(new Vector3(0, 0, 0), mat);
    return new Vector2((int)((v4.X / v4.W + 1) *
        (pGame.GraphicsDevice.PresentationParameters.BackBufferWidth / 2)),
        (int)((1 - v4.Y / v4.W) *
        (pGame.GraphicsDevice.PresentationParameters.BackBufferHeight / 2)));
}

```

But now I need to go from that to the actual extents of the bounding box. I've tried converting the `BoundingSphere` of the model into a `BoundingBox` and then translating the object matrix by the `BoundingBox.Min` values, but I'm nowhere near the left side of the object.

Am I going about this backwards, or what am I not seeing? This would seem a simple enough thing to do, but I just can't figure it out. Or is there a complete different way I should be approaching this?

# Answer
Instead of using `new Vector3(0, 0, 0)` do that calculation for the local space position of each corner of the cube, and then find the minimum and maximum of those 2D positions. Those are the corners of the 2D bounding box for the 3D object.
> 1 votes

---
Tags: xna-4.0, transformation, screen, bounding-boxes, bounding-spheres
---


# Question
Title: C++ How to implement a spatial hash (for a 2d Game)
I feel kind of silly for asking this question, but are there examples or tutorials on how to implement a spatial hash (grid/cell-based partitioning), preferably in C++?

I'm stuck and I have no idea how to tackle this problem. I've searched all over but all I get are people saying "gosh that's easy to do", which I'm sure is true if you've seen another implementation or have done so yourself.

Instead of quadtrees I'd like to have a spatial hash to query areas of my game which has a very large world.

Thinking it probably wouldn't even have to account for sizes, merely points, as the type of game mine is that isn't that big of an issue. And if it is, I could always add that.

# Answer
> 6 votes
To do a basic spatial hash (slightly more complicated forms exist), you need to generate a broad discrete grid location for any game location. This might be as easy as converting float positions to ints or taking int positions and dividing them all by 64 or some other constant.

The idea there is to create a single discrete location most nearby objects will map to. For instance, if dividing by 64, then both objects at (137,76) and (142, 65) will be mapped to the cell (2, 1).

You can use this cell id as the index to a hash table or other fast lookup structure. You should be able to use `std::pair<int,int>` as a key to `std::unordered_map`, I think. Add both objects to the cell they belong to. Now you can easily query all objects that share the same cell.

To find all objects near a particular object, you could query every cell bordering the target object's cell. So to find all objects that might be colliding with an object in cell (3, 7), you'd check that cell plus (2, 6), (3, 6), (4, 6), (2, 7), etc. Just to find all neighbors of a particular game object will you do 9 spatial hash lookups.

Alternatively, insert every object into the cell its own and all neighboring cells. Whenever an object moves, calculate the new 3x3 grid it occupies. Take the disjunction between the old grid and the new one. These sets might be both empty if the object only moved a little (that is, it's new 3x3 grid is identical to the old 3x3 grid). Remove the object from the cells it no longer neighbors and add it to the new ones. In the worst case, if an object moves more than 1 tile in a second update cycle, you'll have to do 9 removals and 9 insertions, but that should be rare.

Which approach is better will depend on your game, but in general, the second approach will likely have a minor performance benefit.

---
Tags: c++, grid, quadtree
---


title: OpenGL shader problem

text:
# Question
Title: OpenGL shader problem
So, I've been working on this game engine for a while now, and just the other day my friend tried running the program and his output doesn't match my output...

My Program Output:

His Program Output:

both are supposed to be donuts, but his donut is very much misformed. I made sure that all the vertices and indices were loaded on his machine correctly so it has to be something going wrong in the shaders

Vertex Shader:

```
#version 150
in vec3 in_Position;
in vec3 in_Normal;
in vec2 in_TexCoord;

out vec2 ex_TexCoord;
out vec3 Normal;

uniform mat4 model_matrix;
uniform mat4 view_matrix;
uniform mat4 projection_matrix;

void main(void){
    ex_TexCoord = in_TexCoord;
    Normal = vec3(transpose(inverse(model_matrix * view_matrix)) * vec4(in_Normal, 1.0));
    gl_Position = projection_matrix * view_matrix * model_matrix * vec4(in_Position,1.0);
}

```

Fragment Shader:

```
#version 150

in vec2 ex_TexCoord;
in vec3 Normal;

out vec4 frag_color;

uniform vec3 lambient;
uniform vec3 ldifuse;
uniform vec3 lspecular;

uniform vec3 light_pos;
uniform vec3 position;
uniform vec3 lstrength;
uniform sampler2D color_texture;

float dcont;
vec3 light_dir;
float intensity;
vec3 normal;
vec3 light;

void main(void){
    float dist = length(position-light_pos);
    float att = (1/(1.0+(0.01*dist)+(0.001*dist*dist)));
    light_dir=normalize(light_pos-position);
    normal = normalize(Normal);
    intensity = dot(light_dir,normal);
    light = normalize(light_pos-position);
    dcont = max(0.0,dot(normal,light));
    vec3 ambient = lambient;
    vec3 difuse = dcont * ldifuse;
    vec3 specular = lspecular;

    if(intensity > 0.95){
        frag_color= vec4((difuse + ambient) * vec3(texture2D(color_texture,ex_TexCoord))*(att),1.0);
    }
    else if(intensity > 0.5){
        frag_color = vec4((difuse + ambient) * vec3(texture2D(color_texture,ex_TexCoord))*0.9*(att),1.0);
    }
    else if(intensity > 0.25){
        frag_color = vec4((difuse + ambient) * vec3(texture2D(color_texture,ex_TexCoord))*0.7*(att),1.0);
    }
    else{
        frag_color = vec4((difuse + ambient) * vec3(texture2D(color_texture,ex_TexCoord))*0.4*(att),1.0);
    }
}

```

# Answer
> 3 votes
Alright, so as stated in the comments the problem is the equation for the Normal. Nvidia accepts poor shader programming, so if you have Nvidia just make sure you check with the standards of the shader version. Also don't use keywords such as "Normal" or other words that would cause a name collision.

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


title: rendering a dynamic sized rock

text:
# Question
Title: rendering a dynamic sized rock
I am developing a 2d mobile game that has a large deformable terrain (a lot like worms). I am rendering the terrain using a gray scale bitmap (in a fragment shader) which serves as a texture position map. If the pixel in the bitmap is black i render the pixel with a ground (tiled) texture else i render the background texture.

This works very well but now i would like to add rocks and static images to the terrain. The rocks will look like this

So my idea was to extend the grayscale bitmap to a RGB bitmap and use the green channel to mark the rock shape and the blue channel to mark the location of static images (which are not tiled).

Since the static images are not repeatable i would have to create blue rectangles which are exactly the same size as the static image. Could this be done any other way?

For the rocks i would use a similar approach but with the green channel so if the pixel in the bitmap is green i would render that pixel with a rock texture (the bitmap shape is blurred on the edge to render the black border). The rock texture is the dark gray color close to the black border on the picture. But the problem is that the rock is now a solid color with a black border and i would like to get as close to the picture as possible. Is it possible to create a texture to get the same type of shading as on the picture? Or is there any other way of doing this?

Thanks!

# Answer
It's probably simpler to just render the rocks and static images as sprites, using alpha blending to composite them over each other and the ground.

To make the sprites destructible, the shader for the sprites could sample your mask texture using a second UV set that's automatically generated based on the sprite's position, so that it looks at the correct area of the mask. In destroyed areas you'd replace the sprite's color with transparency, so that any areas marked as background in the mask texture wouldn't be drawn.
> 1 votes

---
Tags: rendering, terrain-rendering
---


title: XNA GameDefaults Class Settings

text:
# Question
Title: XNA GameDefaults Class Settings
Are items such as the `GameDifficulty` enum, game settings, and other things in the `GameDefaults` class used for a lot? If so, is there a way to edit them or anything of the sorts?

# Answer
> 0 votes
These settings (all of `GameDefaults`) are used to describe a specific set of profile information from Xbox live. You can use them as you see fit. If your game supports any similar configuration options, you can employ this information to make a slightly better educated guess about a player's choices in your game. They are not required, or reliable, in any way.

There is no editing these properties. As you can see from the documentation, they are all read-only.

If you are developing for XBLIG, and your game even has useful configuration options, you are making a rare effort to add quality to your game. Making defaults that pay attention to these settings is...really special. (No, they don't get used a lot.)

---
Tags: xna, c#, game-mechanics
---


# Question
Title: Texture coordinate discontinuity with mipmaps creates seams
I just started learning openGL and I am getting this artifact when texturing a sphere with mipmaps. Basically when the fragment samples the edge of my texture, it detects the discontinuity (say from 1 to 0) and picks the smallest mipmap, which creates this ugly seam:

ugly seam http://cdn.imghack.se/images/6bbe0ad0173cac003cd5dddc94bd43c7.png

So I tried to manually override the gradients using textureGrad:

```
//fragVert is the original vertex from the vertex shader
vec2 ll = vec2((atan(fragVert.y, fragVert.x) / 3.1415926 + 1.0) * 0.5, (asin(fragVert.z) / 3.1415926 + 0.5));
vec2 ll2 = ll;
if (ll.x < 0.01 || ll.x > 0.99)
    ll2.x = .5;
vec4 surfaceColor = textureGrad(material.tex, ll, dFdx(ll2), dFdy(ll2));

```

Now I get two seams instead of one. How can I get rid of them? And why does the code above generate 2 seams?

2 eams http://cdn.imghack.se/images/44a38ef13cc2cdd801967c9223fdd2d3.png

You can't tell from the two images but the 2 seams are on either side of the original seam.

# Answer
Based on the shader code you posted, you're not interpolating the UVs from the vertices - rather it appears you're interpolating the 3D position (`fragVert`), then calculating the UVs by transforming to spherical coordinates.

Your analysis is correct in that the smallest mipmap is chosen when there is a discontinuity, since mipmap selection is based on derivatives that are estimated numerically from the UVs used in neighboring pixels. When one pixel has u = 0 and another has u = 1 you get a very large derivative. Your attempted fix has the same issue in that large derivatives occur around u = 0.01 and u = 0.99, which is why two seams appear on either side of where the original seam was.

A relatively simple approach to fix the problem would be to decide which mip level to use yourself and call `textureLod` to sample it directly. If the planet is always going to be fairly close to the camera, you could just hard-code the mip level to 0 (or, for that matter, just not include mip levels in the texture at all). Otherwise, it could be based on the log2 of the point's distance from the camera, scaled by some suitable factors. Note that this will effectively disable anisotropic filtering.

A more "correct" approach would be to calculate some higher-quality derivatives. Instead of using `dFdx` and `dFdy` on the UVs, which have discontinuities due to the `atan2`, you could apply `dFdx` and `dFdy` to `fragVert` (which will be continuous all the way around the sphere), then use some calculus (chain rule) to find the formula to get the UV derivatives from the position derivatives. This will be more complicated and slower, but has the advantage that anisotropic filtering should work.

Finally, since you're new to OpenGL I'll just note that while calculating UVs from spherical coordinates is a perfectly valid way to texture a sphere, it's not the "usual" way that most people pick. It's more common to build a sphere mesh that has UVs specified per vertex, and simply passed from the vertex shader to the pixel shader (linearly interpolated across each triangle). Vertices are placed along the seam, like this, such that there are two copies of each vertex, at exactly the same positions, but half with u = 0 connected to the triangles on one side, and the other half with u = 1 connected to the triangles on the other side. This eliminates any visible seam and doesn't require any tricks in the pixel shader.
> 6 votes

---
Tags: opengl, textures
---


# Question
Title: What is a good free "game development organisation" site?
I'm searching for a site that will help me to design a game. I don't have a development team in the same location. They are all located somewhere over the world. I am searching for a kind of site that allows people to post ideas and suggestions, but moreover to have control over who has the control over what. For example, one makes the graphics and has several people "under" him that can get a certain task to make a certrain graphic. This has to be easily found on this site.

Does anyone know a good site like this? I prefer it to be free.

# Answer
> 1 votes
Project management is an ever evolving process that every team deals with. There are many development methodologies that can facilitate different team sizes, deadlines, project types, and just personal preferences. Software development today is being heavily developed by teams implementing various Agile development methodologies. Agile development focuses on short term deliverable tasks, customer feedback, and flexibility in planning. There are many different software solutions that can help a team operate using Agile. I would recommend doing some research on how Agile works. There are a number of web based Agile software packages, here are a few of them.

*Edit* After posting this, I realize a full agile implementation may be unrealistic, and I have thus attached links to other free, web based project management solutions.

http://www.pcmag.com/article2/0,2817,2380448,00.asp

http://agilescout.com/best-agile-scrum-tools/

http://www.versionone.com/

---
Tags: teamwork
---