Slashdot Mirror

Here http://kesen.realtimerendering... This truly helpful fellow collects nigh every paper from every conference covering such in an easily browsable site. The only 2 things not covered are here http://gdcvault.com/ and here http://advances.realtimerender...

A good place to start might be the talks archived at the GDC Vault.
http://gdcvault.com/

You can read all back-issues of Game Developer Magazine there as well.
http://www.gdcvault.com/gdmag

And sister website Gamasutra has loads of stuff like this.
http://gamasutra.com/

More low-level and rudimentary topics are covered by a couple of good YouTube channels.
https://www.youtube.com/user/B...
https://www.youtube.com/user/c...

If you want to dip your toes into game development without needing to know anything, check out Tom Francis' GameMaker tutorials.
https://www.youtube.com/watch?...

A good place to start might be the talks archived at the GDC Vault.
http://gdcvault.com/

You can read all back-issues of Game Developer Magazine there as well.
http://www.gdcvault.com/gdmag

And sister website Gamasutra has loads of stuff like this.
http://gamasutra.com/

More low-level and rudimentary topics are covered by a couple of good YouTube channels.
https://www.youtube.com/user/B...
https://www.youtube.com/user/c...

If you want to dip your toes into game development without needing to know anything, check out Tom Francis' GameMaker tutorials.
https://www.youtube.com/watch?...

... as a practice exercise for optimization.

Mike Acton gave an excellent talk Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize where he picked an integer sequence to optimize the run-time to calculate the sequence. Techniques include: memoization, and common sub-term recognition. For 20 values pre-optimization time was: 31 seconds, post-optimization time was: 0.01 seconds.

* https://youtu.be/GPpD4BBtA1Y?t...

Original GDC Talk

* http://gdcvault.com/play/10218...

side note: Alex Vlachos is the head of something-or-the-other-VR-development at Valve and gave a fascinating presentation at GDC2015 which GDC Vault has kindly opened up viewing of for free. This is where parent's 90fps comment came from.

Is the backlight really strobed at 90 Hz ? I guess that improves the perceived responsiveness of the display compared to simply holding the last frame (which essentially acts as a temporal lowpass filter), but some people will have headaches from staring into that for hours. PWM backlight dimming on modern LCD monitors usually runs at 200+ Hz, and 90 has been documented to cause problems.

Oculus says any less than 90fps will cause motion sickness....

Does the Sony running at 60fps have this problem?

side note: Alex Vlachos is the head of something-or-the-other-VR-development at Valve and gave a fascinating presentation at GDC2015 which GDC Vault has kindly opened up viewing of for free. This is where parent's 90fps comment came from.

What I found particularly interesting was their use of interpolation combined with efficient stacking of GPU API calls in advance of the next V-Sync to ensure the GPU hits the frame sync immediately. Their pipelined architecture predicts 2 frames in advance, updates the predictions for the frames with the latest head-trajectory calculations right before dispatch, and can blah blah go watch the video. He's an entertaining personality, talks fast to keep you engaged, and covers the content quite efficiently. In fact, I'm going to go re-watch it right.

Minecraft is about _user-driven narrative_, not designer driven narrative.

Skip the first 2 minutes of this epic talk on Game Design

* Attention, Not Immersion: Making Your Games Better with Psychology and Playtesting, the Uncharted Way
http://www.gdcvault.com/play/1...

It's time for the principal vendors to rebuild the list of assumptions of what gpus can and should be doing, design an api around that, and build hardware specific drivers accordingly.

For the most part, they've done that. In OpenGL 3.0, all the fixed-function stuff was deprecated. In 3.1, it was removed. That was a long, long time ago.

In recent times, while AMD introduced the Mantle API and Microsoft announces vague plans for DX12, both with goals of reducing CPU overhead as much as possible, OpenGL already has significant low-overhead support.

As dazzling as the game can look, this Chicago feels like a place you travel through rather than a world you inhabit. Pedestrians gasp and gawp at car crashes, but exhibit no real life.

That's because they only give us AI devs 1% or 2% of the budget. If you stopped harping on about how amazing the graphics are and realized that games are interactive art and that it's the "rules and logic" (AI) that make a game happen, then we can sacrifice just a tiny bit of those graphics and physics to give you a vastly better gaming experience.

Until folks start talking about the "Immersive Environment" and including the AI, your games will feel as wooden and false as ever. Give AI More Resources!

History disagrees with the sentiment that it was easier to "make money" as an indie in the 1980s, or 1990s than today....

In the 1980s the distribution channels were being established which meant either you scored a deal with a bricks and mortar retail store, such as Sears, Babbages or Toy's R Us, or you ziplock bagged your PC game and tried to sell them at swap meets and computer stores.

In the 1990s there were more direct retailers and amalgamations of bricks and mortar stores occurred. The shareware model emerged and ziplock bagging disappeared. If anything, the 1990's were a bit of a dark ages for indies as either you had a publisher to get into a store or shareware.

From the 2000s onward we have an increased number of target platforms, and increased demographic of game players (from kiddos to those who grew up playing games for 30+ years... see: http://dmitriwilliams.com/will... (warning: Word doc)) , and increased number of channels (e.g., bricks and mortar persists (barely), online services like Steam, bundles, etc...)

If you (have aspirations to) develop indie games, it may seem likely everyone is creating them and the market is saturated but it's the same mentality as a musician at a "Guitar Center" thinking everyone in the world is now in a band; no, it's just the community they choose to surround themselves in. The signal to noise ratio is such that indies can succeed if they spend time build a great game and heed the lessons of other indies in how to market it through these channels. (GDC Vault has many free videos on this topic, such as: http://www.gdcvault.com/play/1... )

I even have a personal example of a AAA dev who use to work with me, but left years ago to start his own 1-man shop. He was a graphic programmer who taught himself to become a better artist and has been making a living, creating games, for a few years now. Check out his studio: http://www.epacegames.com/ And can also site Discord games ( http://discordgames.com/ ); larger than a 1-man group but by making an awesome game and marketing it appropriately, have an opportunity to sell Chasm to eager players, an opportunity that would not have existed 20 years ago.

Here's a pair of links to talks Lyte has given on their systems. It's really interesting stuff. At GDC and a classroom presentation.

I've found Path of Exile to be the spiritual successor to Diablo 2.

Diablo 3 is more polished, has way better art style (aka "Blizzard" style), and is meant for casual playing.
* http://gdcvault.com/play/10153...

However the game play is way better in Path of Exile (barring the desync, and single-threaded game) TONS of build diversity, named and colored stash tabs, way better end-game system (maps). Plus you can't beat the price. :-)

D3 on the consoles is getting better -- definitely will be checking out RoS to see in Blizzard _finally_ understands Itemization.

* http://i.imgur.com/EHEKduL.jpg

I felt the choice of wording was a bit prematurely dismissive (i.e. saying it shouldn't apply to single socket CPU's or to Game Programming -- especially since that is the primary target of my concurrency research).

Also, we are not trying to write specifically to HLE. We are trying to write stuff that runs well on multicore systems and then layer HLE on top of it for an added performance benefit for when we do have lock conflicts.

I agree that well written applications don't have nearly as many locking conflicts to begin with and that's certainly our goal. We try to run most of our game using a multicore graph driven data dependency scheduler (also presented at GDC by my coworker).

But there are a number of systems (both internal and legacy) that do use locking that will benefit from HLE. It's about making the code run as fast as possible.

When we have to lock, we try to make it as fine-grained as possible (until you get diminishing returns in either performance or memory). HLE works well with existing algorithms (almost nothing to rewrite except to specify whether the CAS is acquire or release for a lightweight user space lock) and it is backwards compatible with an extremely low penalty for processors without HLE -- from the benchmarks I have seen, HLE code will run as fast as the original locking code (to within some white noise of most performance metrics on the unsupported CPU's) which should be fairly fast assuming you use RWL's, striped locks, and organize data algorithms to minimize contention.

HLE is a "no brainer" for ease of implmentation. However, a TSX RTM code path does require algorithm rewrites so perhaps that is akin to "writing in asm for a 15% improvement over C" (although some game programmers would find that tradeoff acceptable in small code funtions in low level libraries anyhow!).

As far as gamers are concerned, if we can give them a noticeable performance boost by taking advantage of a specific CPU feature without slowing down the code on CPU's without that feature, they will consider that to be a big win and love us for it.

Also, I don't see why you keep referencing global locks and spin locking as the only things that would benefit. Did you get a chance to read the presentation I linked to? Mind you, it's based on work I did 4-5 years ago and presented almost 4 years ago, but even back then we were well ahead of the starting point you seem to feel developers are using as a base.

We are already using fine-grained locking, striped locking, reader/writer locks, lock-free atomic SList, lock free allocators, etc. I am interested in having TSX speed up these advanced concurrency primitives on platforms where it is available. If AMD releases ASF, I'll look into accelerating with that as well.

It's almost an oxymoron if you are talking about a single-socket Intel cpu. You don't actually need the transactional extensions to make things go fast

Not true... I've written an entire concurrency system including a lock free library and a multicore memory mananger. There are a number of places where TSX offers a large speed improvement even on a single core.

If the purpose is to test code performance then it is better to test without transaction support anyway since transaction support is not a replacement for proper algorithmic design. Or to put it another way... if you code SPECIFICALLY for one of the two intel transactional models that means you will probably wind up with very sloppy code (such as using global spinlocks more than you need to and assuming that the underlying transaction just won't conflict as much). The code might run fine on an Intel cpu but its performance value will not be portable.

Are you even familiar with how TSX works? Hardware Lock Elision is a very simple replacement for atomic locking. You can write a very simple user level mutex using atomic operations that has a fallback to an OS yielding construct. In fact that's what we do in my concurrency library. Uncontested access is a single atomic op while contested access is an actual OS mutex. With HLE, all accesses can appear to be uncontested unless there is an actual data conflict in memory read / written to during the transaction. This cuts down significantly on OS lock calls. It's not just for spinlocks.

And besides... 'your company' ? Use a Xeon then, right? It's not as though it costs all that much more.

-Matt

By "my company", I mean the company I work for. Disclamer: Netherrealm Studios which is owned by Warner Brothers but thia is my personal opinion and any posts I make here do not reflect the official option Warner Brothers nor on Netherrealm Studios. We make video games and I write low level optimized code for multicore / multithreading libraries among many other things.

"Hobby Gaming" -- I understand the desire to make the distinction between video games and games that are not video games, but "Hobby Gaming" sounds like a futures market for hedging bets against folks with hobbies... Gaming their Hobbies.

I've always considered them all to just be games. I mean, I frequently paper mock-up the video games to see if they'll be fun and work out some logic kinks before creating an actual digital prototype. Many turn based strategy games start their lives resembling "Hobby Gaming", even in a playable state before being implemented in cardstock & pewter, or digitally with a video game engine. When I was a kid I would dream up new enemies and levels for Mario and tape together dozens of sheets of graph paper on my wall... I would take a paper cutout and "play" the levels -- "You put the string on where his feet are, then you can only jump as high as the string is long" Some of these paper levels had "teleporters" (go to page 4 [13,42] ), or rules that listed you couldn't go backwards... That was when PC game making was somewhat of a black art. Learning the the voodoo coding rituals without any instruction was hard (before the Internet), and I guess I didn't learn about how other folks came up with "game designs" so I used a paper based rapid prototyping system (and still do). In a FPS, each room can be "rendered" as a top-down 3rd person game on paper, and a string used to determine a "line of sight", or a grenade throw distance. You can get a good handle on approximately how the movement will flow through the level in about 5 minutes rather than spending hours in a 3D modeling suite... Need to reconfigure part of the map? Scissors and tape are faster than redrawing the lines.

What some call "Hobby Games" or "Video Games" are all just "Games" to me. Here's a GDC video about the action platformer Shadow Complex, Skip to 10:40 to see how the first "build" of the game was basically just made with digital graph paper, and just like a table top game they manually had to move the pieces to play it in that state... and it was fun! (so they say; I can only vouch for the end results, which are pretty fun). Computers can just move the pieces for you and keep track of more rules than a non-digital game can typically afford. That's the way I see it, anyway.

I think Table Top series should win. It's great to see what some of the various games are, and how they're played before picking them for game night. It's gotten some of my digital only gamer friends to broaden their horizons a bit too.

Writing for Portal is tough. Why you could even start out thinking a new portal wouldn't even have Chell, or even Portals! Ah, but you could be wrong, because that's exactly what the Portal 2 developers thought... They were wrong. Chell may not speak, but there is a reason it is she, and not some other, you play as in Portal 2; She's integral not because of her dialog (or lack thereof), but because of her identity. You may enjoy this Game Dev Conference talk from the writer's perspective on Portal 2: Creating a Sequel to a Game that Doesn't Need One

You might also enjoy this touching music video featuring the rat man.

Also, Portal 2 gives us the history of Aperture's founder Cave Johnson, his secretary Caroline, the origins of the Portal Gun (even explaining why it only works on some surfaces), and their role in the creation of GLaDOS. It's a hybrid sequel that covers tons of prequel material, so there's many more characters than just the Rat-Man to mine for a movie. Portal actually has a proper origin and story-line now.

Of course all that's irrelevant, since Abrams will simply ignore fixtures of the series and screw the actual universe six-ways to Sunday to solve any plot hole he makes for himself, like he did with trans-warp teleportation, red matter, and time-line forking time travel in Star Trek, won't even think twice about doing it either.

> Why would lag enable (item-related) hacks? I know Blizzard games have had some duping hacks involving induced lag over the years, but that's just crappy code.
Agreed; but it did. Duping in Diablo 1 was trivial -- just by dropping items on the ground and picking them up fast.

> As long as you don't trust your clients, there's just no opening for item-related hacks.
In theory yes, in practice no. If you don't trust the client for anything you
a) overload your servers
b) introduce > 100 ms responses that players find unacceptable
i.e.
See Bungie's awesome networking talk on "I Shot You First"
http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking

There's a Game Developers Conference video for available for free which relates experiments done by Valve with biofeedback integrated into gameplay:

http://www.gdcvault.com/play/1014734/Biofeedback-in-Gameplay-How-Valve

The primary purpose of Game AI is to provide entertainment for players, not create the most realistic behavior. Developers are not focused on strong AI, but may be focused on creating tools for reusable AI.

A panel of leading Game AI developers provided an AI Rant this year at GDC and discuss where they see things going.