When last we left our narrator, he had been through the AI Summit, attending a few AI sessions, various math sessions, and a few Indie sessions. The following is more notes about the main GDC sessions, possibly with a few more links, since I've dragged my feet so long in getting this posted.
Day 3: Wednesday
Procedural World Generation in "No Man's Sky" - Innes McKendrick, Hello Games
"No Man's Sky" was definitely the PCG poster child for this year's GDC. This talk touched on a lot of the world generation tools, but stuff was going fast - I think I'll need to watch the video to make my notes make sense.
No Man's Sky was a "programmer driven" project, written in C++. Maybe C++ isn't the right choice for everybody, but it made sense for their project at the time. Cross platform PC and PS4.
"The player shouldn't know if a texture is made by an artist, or by an algorithm", and apparently, that abstraction applied to much of the engine, too.
Initially, they built a version with a 2d square grid stretched onto a sphere. This had several issues, including swimming textures, no static positioning, and some gameplay(?) was impossible.
Next, they opened up the Wikipedia page on Map Projections. None of them both looked good and were easily invertable. The Octahedral projection, for example, was interesting, but really took advantage of where Earth's oceans are.
So, they went to "sphere space". Now we don't have to argue about whether y or z is up, they both are at different parts of the world. Tangents are problematic, but triplanar projection worked pretty well.
Voxel data (et al) wants to be stored on a cube, so simulate on a sphere, but store on a cube.
Voxel data was stored in 1 meter voxels, 6 bytes per voxel in 36m x 36m x36m chunk.
Terrain is generated at runtime, not at loadtime - done in the background along with texture streaming. On the PC this was all done on the CPU. On the PS4, compute shaders did this work.
Since data has to be generated locally, they couldn't simulate erosion, they had to come up with PCG algorithms that approximated the results of erosion.
3d terrain generation applied a linear density additive factor to make mountains and hills look natural.
"perlin worms" used as a way to form caves underground.
"if you ask an artist, a tree is nice, but a tree plus a rock, plus some bushes, plus some pebbles, that's nicer"
Vehicle Replication in "Watch Dogs 2"
This game has open world driving with a 4-person peer-to-peer multiplayer topology. A lot of traditional prediction algorithms failed to work for them, because:
- cars drive fast; a 100ms lag is 2-3 meters of difference, possible a full car length
- cars collide with each other
- there are a lot of cars in the world
- the human eye is sensitive to changes in velocity
Seems like they did an awful lot of tweaking and tuning of interpolated data, including sending down other information, like turning radius, to better simulate. They didn't send extrapolated data (perhaps because that'd be too noisy for an arcade driving game?), which seemed like the obvious thing to try.
Creating Complex AI Behavior in "Stellaris" through Data Driven Design
TODO - my laptop's batteries were low during this talk, so I wrote notes on paper.
HDR in Frostbite
I learned more than I cared to know about sRGB, and I've forgotten it already. HDR is tricky stuff, and if you've got a big franchise, with lots of legacy assets, you might not be able to rebuild all your art for a new color space.
Hyper Light Drifter
They funded their game through Kickstarter, made a custom editor, for a game with no words.
The Kickstarter pledge page said something like $640k, of which they saw around $584.
Kickstarter Lessons Learned:
- fewer reward levels
- fewer physical goods
- focus on fewer platforms
- sorry, WiiU, Ouya
Kickstarter things that went right
- stretched the dollars
- kept finances simple
- kept overhead low
- went to events, like PAX and E3
- budgeted for fun things
- use backerkit if you're going to use kickstarter
The Editor
The game was built in the GameMaker engine, with support from the GameMaker team. That said, they veered off the path of supported features, and things seemed to work.
Stuff tiled on a square grid looked square.
They found that placing items and scripting them was harder than they liked.
Second pass: they tried building stuff in Photoshop. That was a little insane.
Third pass, made their own editor inside the game.
The editor looked a lot like an old Amiga graphics editor.
The game was almost wordless.
Some stuff was "non diagetic"; in the game, but not in the world
shops were surprisingly hard to communicate without words or numbers
Classic Game Post Mortem - "Oregon Trail" - Don Rawitsch
It's nice to see a guy older than me give a good talk. Don Rawitsch was one of the three student teachers that designed and built "Oregon Trail" back in 1971, which turned into probably the most successful educational game (and if you wanted to argue the most influential, or longest running title, that would make sense, too).
In December of 1971, three college seniors were studying to be teachers, and had to go through a student teaching portion of their studies. They were all roommates in Minneapolis, Minnesota at Carleton college:
Bill Heinemann, a math major
Paul Dillenberger, another math major
Don Rawitsch, a history major
Don was about to start a segment on "The US Westward Migration of the 1800s", and he wanted to involve his (elementary school?) students more than just "read the chapter, fill in questions on these worksheets".
Don was thinking about doing a tabletop boardgame, roll some dice, move some spaces, but one of his roommates suggested using the school district's mainframe instead.
This was the time of dialup, with a dial telephone, an acoustic coupler (think of WarGames, if you're a generation younger), a teletype with a keyboard for input, and a paper roll tractor feed printer for output. If you wanted to be fancy, there was a bell on the teletype. Output was 10 characters per second.
The game was delivered on time! December 3rd, 1971
Basic loop:
total up resource
choose strategies
- stop at fort, hunt, or continue
- how well to eat
events (typically misfortunes) occur
player reacts
each turn was 2 weeks, so a full game would run 10-12 turns
The game scaled as you went, so if you were at mile 950, you were in the rockies, so mountain things happened to you.
They documented the code with the above flowchart after having built the game - they were "agile" before that was a thing.
Simulated the chance of meeting outlaws on the trail - it wouldn't make sense to have too many outlaws too far from civilization.
By 1974, the game had gone dormant, and Don went to join MECC (Minnesota Educational Computing Consortium). MECC had their own mainframe, which schools in Minnesota could use.
Don revised the game, based on probabilities gleaned from historical documents.
Simple analytics: some of the best MECC programs might be run 200-300 times a day, but Oregon Trail was around 10,000 games a day.
1979 - ported to Apple ][ (green screen)
1985 - Apple ][ color version
1991 - Apple Macintosh
1995 - Oregon Trail II
2012 - iPhone "arcade" version (loosely connected, not a port)
Some things Oregon Trail did "right" back before anybody knew what that meant:
- give the player a degree of control (not just random)
- put the player in an engaging story
- simple user operation, sophisticated model
- resources balanced with obstacles
- multi-level learning: strategy, topics, process
Lessons for life:
- plan ahead; there's danger out there
- be patient; the journey is long
- if you persevere, you may hit your green valley
- even if the river is deep, sometimes you have to caulk your wagon and set out from shore
No comments:
Post a Comment