1. Curse you, missile; now I'll never be a vulcanologist.

2. No, you're gonna try something dangerous, now.  Sorry, pal.

3. Dumbo makes me sad.

For testing purposes, you need to set the routers involved to forward the ports you're using through to the correct computers which should be receiving the TCP stream.

This is always, always a problem for networked games which are hosted on home computers, because of the prevalence of NAT devices (such as virtually all home routers) which makes the computers inside the home non-addressible from the Internet.  (At the same time, it also makes the Internet a much safer place than it used to be.  Which is saying a lot about how bad it used to be!  :D )


For when your game launches, you'll ideally want to have a server that's running on a computer that's directly addressible by clients.  Either that server would serve as a middle-man, sending packets back and forth between the clients (so that they don't have to connect to each other directly, thus avoiding the NAT issues), or else initiating a NAT hole-punching exercise so that the clients can talk directly to each other.  I don't recommend the latter;  it's really annoying and error-prone and often won't work successfully with older (pre-XBox Live) routers.

I mean, if you removed all of the input options which presented no meaningful choice in Rock Band, then it'd just be iTunes, right?  To me, this seems like a pretty simple proof that at least in some situations, a game can be improved by adding physical input, even if that physical input doesn't involve any decision-making.

Not really. Would you like to have to press a button at a timed rate while playing starcraft, and be punished in-game if you didn't?

You totally ignored my whole comment.  I can't figure out why you even replied to it.  You're not even talking about the same game as me.  (Did you click on the wrong 'quote' button, maybe?)

But please feel free to dispute my facts, or point out how my comment was in some way incorrect.  I'm interested in alternate points of view, as long as they're being reasonable and not just stating personal opinions as though they were objective facts.

All games require physical input, of course. But the question is how much and how much of that can be avoided by control-design.

I don't think that I agree that reducing the amount of physical input is necessarily going to be an improvement for a game.

I mean, if you removed all of the input options which presented no meaningful choice in Rock Band, then it'd just be iTunes, right?  To me, this seems like a pretty simple proof that at least in some situations, a game can be improved by adding physical input, even if that physical input doesn't involve any decision-making.

Games require physical skills.  They all do, and always have.  Even video games, all the way back to Pong and Space War.  That they require some physical dexterity to play is nothing surprising or new or in any way unique to StarCraft or StarCraft 2.

I'll be interested in Core's simplified RTS interface ideas when he releases the game that uses them.  Until then, I have no way to judge their validity. So get to it, Core!  I'm looking forward to actually being able to try them out!  XD

[median]

Here's the general approach I've used in a few professional games:

Step 1:  Server sends a "ping" message to Client A, containing the current server time.

Step 2:  Client receives the "ping", and sends a "pong" message back to the Server, containing the same server time from the "ping" it just received.

Step 3:  Server receives the "pong" message, checks that the server time embedded in it matches the server time it most recently sent to that client, and if it matches, sends a "pang" message, which contains BOTH the original server time (from the original "ping"), AND the current server time.

Step 4:  Client receives the "pang" message, checks that the server time embedded in it matches the server time it most recently received in Step 2, and if it does, takes the time halfway between the two server times in the "pang" message as being its own current time, and the difference between the two as the current lag.

Note that for a real implementation, you actually want to do this process about ten to twenty times, taking the median result.

For most types of games, you don't want to adjust clock synch after the game begins;  it's better to just live with whatever clock offset exists, rather than skew clocks mid-game.

EDIT:  I just re-read this post, and realised that I specified the wrong approach.  Fixed to specify that one should use the median value, not the mean.  (means are affected too much by one-off lag spikes)

Of course, while you wouldn't need to install the game on each computer at the LAN party, you WOULD have to install the application that was going to receive the broadcasted images.

So I'm not sure whether that would actually be a net gain for you.


What you're basically talking about, though, is XWindows;  the standard windowing system under Linux and UNIX environments.   You can run a program on one machine, but have it draw its output to a window on a different machine.  It's a pretty clever (albeit convoluted) system.  But far beyond something that could be condensed down into a single tutorial.

The important thing is to be able to justify your business-related write-offs in such a way that an auditor wouldn't raise an eyebrow over them.

"I wrote off GTA IV because my job involves making games" sounds dodgy.

"I wrote off GTA IV because I bought it as camera reference for <specific game title>, which I was making last year" sounds like it was an actual business-related expense.

Most people (including auditors!) don't understand how playing video game 'A' would help you create video game 'B'.  For this reason, you really want to be prepared to give a strong explanation about why purchasing each deducted video game was a legitimate business expense.

As a practical concern, you can't design real levels until you know how the game control works.

For example, in a game where you control a character, you need to how big that character is, how fast they move, and how high they can jump before you can design any real levels for them to move through.  This is because changing your character's behaviours can easily invalidate any or all of your already-created levels.  If you've already created 96 levels before you've locked down how the character moves around, you're going to be in a world of hurt if you change your mind about how high the character should be able to jump.


My usual approach is to make several levels in a "grey box" format as early as possible;  simple, few art assets, but functional.  Usually built out of grey boxes.  Then I build the game code until I have a prototype of the core game mechanics in those "grey box" levels, and then I return to designing true levels (which often include art-enhanced versions of the "grey box" levels).  And from that point on, the two sides evolve together, organically.

Of course, different approaches are best for different types of game, and where it's important to lock down controls in a platform game before getting too deep into building levels, that may well not be the case if you're making a tower defense game where you just need to throw more and faster baddies at the player in each stage.  (drastically oversimplifying, to tease Paul)   

This is probably a completely obvious point to make, but..  clicking fast doesn't make you win at SC2.  Really, it doesn't.

At its heart, SC2 is a game about timing and precision, not about button mashing.  

SC2 is a rhythm game where you're playing several instruments at once, at the same time that you're writing the score.

SC2 is about knowing in your bones precisely how long commands take to be carried out, and being ready to give the next command in your plan the very moment that the previous one completes.  Ordinarily you'll have half a dozen or so of these different command sequences all going on at once, while you're simultaneously taking the results of some of those strings of commands to bend the paths you're taking in the others.  (When you send out your scout, for example, the things it sees should cause you to modify both the scout's path, as well as modifying what you're building in your base, etc)

If you're playing SC2 in any other way than this; moving your attention between all your various necessary tasks at precisely the moment when each task needs your attention again, then you're misunderstanding the point of the game.  The designers would never want to automate spawn larva or creep tumors or mules or chrono-boosting;  those are each critical parts of the timing and precision balancing act which is what StarCraft 2 is ultimately about.


Of course, at lower levels of skill you can simply build an army and go stomp on your opponent.  That can be fun too.  But it's really incidental to StarCraft 2's intended core activity.  

To me, it seems like the way to do holiday sales to avoid pissing off recent purchasers is going to be to do a staged sale.  Let's assume that we're going to hold a sale on from December 20th to December 25th, for a game which usually sells for $10, it'll cost only $5 during those five days.

So on the first day of December, we drop the price from $10 to $9.75.  On the second day, to $9.50.  Third day, $9.25.  And so on, dropping $0.25 per day until we reach $5 on December 20th.  In an early purchaser's mind, it's no longer "Gosh, if I'd just waited twenty days to make the purchase, I could have saved $5", it turns it into a long series of "And if then I'd waited another day, I could have saved a quarter" minuscule sale events.  A quarter to get the game a day earlier sounds like a pretty good deal to most folks, whereas $5 for not having to wait 20 days is a far more contentious choice.  It seems like a lot of sale-related frustration comes from those sudden, unexpected price changes.  If the price changes were very slow and gradual, I expect there'd be a lot less angst over them.

In theory, this approach is pretty much the same as the "pay what you want" thing that's become so popular lately, but where the price you want to pay is counterbalanced against when you can get the product.

(Actually, I think it'd be kind of interesting if someone was to release a "pay what you want" game where if you chose to pay full price or above, you could download the game immediately, but as the amount you paid decreased, the time you had to wait before you could play it increased.  So like, if you chose to pay $1 for a $20 game, you might have to wait until two weeks after paying before you could actually play it.  People would hate this, of course, but it's an interesting economic attempt to balance the desires of the purchaser against each other ("I want this game right now" vs "I want this game as cheaply as possible") so that everyone can find a balance that's comfortable for them, instead of just trying to set a static price which happens to be below what the majority of the market is willing to pay.)

All three of those special effects are accomplished using polygons.

The first has a couple elements.  The most noticeable one being the three ribbon-sprites, winding around a central cylinder.  ("Ribbon sprites" is a term for a sprite that stretches between two or more positions, with each segment twisting to face the camera as best as possible.  Ribbon sprites are generally used for drawing fast-moving projectiles, rocket trails, and other similar effects).  The ribbon sprites are drawn additively, to give a magical glow.  In the middle, there are two more solid cylinders, both darkly coloured and opaque (albeit with textures that let you see through bits of them).  This dark middle area gives the effect a real sense of shape, and makes it stand out really strikingly from the background;  without that dark core, the ribbon sprites would just wash out into the backdrop.  And of course, there's the ground effect.  Difficult to quite tell how that's being done, since it's kind of small in that screenshot.  But I imagine that it's one sprite flat on the ground, and the little ring is a separate cylinder that expands over the course of the effect.  Both parts of the ground effect are being rendered additively.

Second shot is spheres with a texture map on them (presumably animated), with a camera-facing sprite in the middle of each (slightly larger than the spheres), and some ground effects.  All additive.  This effect would wash out terribly if it wasn't being drawn in front of flat black.

Third shot is my favourite, and I dearly hope that they've implemented it the way that I would have.  In the middle is a smoke particle system;  just lots and lots of expanding puffs of opaque green smoke (again, the opaque area locates the effect within the game world;  without it, it would be difficult for a player to see precisely how deeply in the scene the glowing effect was located).  Around the smoke are two models of expanding, glowing helixes.  The fun trick here is that you can make helixes appear to animate by just rotating them counter to their direction of twist.  For example, in this screenshot, we have helixes which twist around in a counter-clockwise direction.  So if we slowly spin them clockwise, they'll appear to animate.  Animating the helix's texture UVs can make that illusion of real animation even stronger.  I've used this trick many times on game systems which didn't support shape animation, in order to make things that appeared to be organic and undulating, even though they were actually completely static meshes.

Piracy rate and lost sales are two very different things though.

I'm really not interested in opening up that particular discussion again.  It never leads anywhere productive.  (See my earlier comments RE: making one bitter, cynical, jaded, and profoundly unhappy.  Or, for that matter, the thread that chrknudsen pointed out.)

So please don't take it personally if I don't address that point today.  It's not you;  it's me.     

If your game is a hit, piracy is barely a dent in the massive amount of sales you'll be getting.

Most of the successful indies out there who've released numbers have estimated that between 80% and 95% of all players of their games are playing a pirated copy.  When you're talking about those sorts of number, I'm not sure that "barely a dent" is a fair characterisation of 90%.  (The World of Goo example is here:  http://2dboy.com/2008/11/13/90/)

But with that said, I completely agree that it's not worth a developer's time to try to deter piracy in any way other than by being a generally awesome person that players want to support.  Fighting (or railing against) piracy just isn't a cost-effective way to spend your time.  And it makes you bitter, cynical, jaded, and profoundly unhappy.

Far more fun and effective to simply be awesome, instead.   

Moving UVs into the middle of the texel instead of the corner of the texel is the standard way to fix this problem (adding half a texel, as craigtimpany mentioned). 

However, if you're using mipmapping then your texels all get averaged together to create those lower-mip textures, so you no longer have a half-texel boundary between one texture pixel and the next, which makes the "add half a texel" approach no longer work.  In that case, it's usually preferably to have a separate texture for each image (instead of putting lots of images into a single texture map), and turn on UV clamping to keep from accidentally sampling around the edge of the texture.

I switched from Linux to OS X way back when because I felt that it offered me all of the positives without any of the negatives of Linux.

I'm in the same situation.

I suspect that the Internet is (as usual) wildly spinning things into the absolute most controversial form they could possibly take via a careful combination of cherry-picked quotes and wild suppositions stated as if they were facts.  I really have trouble imagining that Apple would ever use the OS to cut off third-party apps that weren't distributed through their own "app store", because that would be such a spectacularly stupid and catastrophic thing for them to do;  the backlash would be unbelievable.  

But yeah.  If they were to actually do that, then I'd be back over onto Linux again in a heartbeat.  But I don't think there's a chance in the world that it's going to happen.  Because, as I mentioned earlier, Apple would have to be absolute imbeciles to do it.  And anyone with half a brain can tell that whatever their other faults might be (and there are plenty), Apple is not staffed by imbeciles.

Oh man, that's terrifying! You say that you managed to figure it all out in one day...?

Well, it from from about about lunchtime to nearly midnight on a day when we needed to get a build out the door, so I guess it was a bit more than eight hours, but yeah, all in one day.

Most of the time went into figuring out how to make the bug occur on a development kit, so that I could debug it properly (and recruiting a couple people from QA to play through the game up to that point).  After that, it was just a matter of struggling with the "clever" code which appeared to have been intentionally written to simultaneously require the worst ratio of code:functionality possible, as well as to make it as difficult to debug as possible.

If the responsible programmer had been on my team, I would have been ethically obliged to smack him around a little - though not too much, because I'm firmly opposed to needless violence.   

Longest time on a single bug was about 8 hours nonstop.  It was in one of the release candidates of a fairly high-profile Wii game, and resulted in a crash if:

• You were playing a retail copy of the game AND
• You were playing it on a test kit (not a devkit) AND
• You were playing using a retail memory footprint AND
• You were playing it off of a burnt disc AND
• It was a european build of the game AND
• You played through three quarters of the game in a single sitting AND
• You visited a particular cutscene within a particular level in a particular order AND
• The language was set to German.

It was a very esoteric memory initialisation bug; a byte of memory that was read from but was never actually being written into after being allocated.  If the value in that particular byte of memory happened to be any value other than zero, then the game would work correctly.  But under that list of situations (retail, not debugging, etc) then memory happened to be allocated in such a way that in that one specific instance, the uninitialised memory in that byte just happened to have a value of zero.

I was a cross mewse, that day.   

In my experience, you can't "fix" a team while you're inside the team.  The team will either work well together or it won't;  the only way for one of the team members to make it work "better" is for that team member to voluntarily back down and acquiesce to what the other members want to do.

In this case, it sounds like your goals are very different from the goals of the rest of the team, and you probably can't change the other peoples' goals.  I'm not going to advocate that you run away and live in a cave, but it does sound like you need to think about whether your reasons for wanting to make a game are compatible with the reasons that the rest of the team want to make a game.  If they're not compatible, then maybe you'll be happier with a different team, who share more of the same goals as you.

Well my philosophy is that the last thing he needs is another $10, where as $10 is going to go a lot further in my pocket, since I'm not making $250k a day. Maybe it's petty, sure...

And yet you're still apparently willing to pay for your internet access, even though your ISP/Internet Cafe/whatever almost certainly earns more per day than you do.

So LOL, whatever makes it easier for you to sleep at night.