Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Friday, December 6, 2013

Practice 2013: Well-Made: Back to Black Mesa

(by Robert Yang)
·         Tinyurl.com/backtoblackmesa
·         Writes about the art of FPS levels on his blog
·         Luigi was cut from Mario 64 because of hardware limitations and they needed it for more elaborate landforms.
·         Most of teaching game development is about teaching attitude. It’s not about being a great coder or artist, but being a great thinker, connector of fields, etc.
·         Half-Life = a new frontier in interactive drama, interactive storytelling, innovative deep amazing art, but Robert doesn’t really care about this. 95% of the game is about shooting things and jumping into small spaces.
·         The narrative in Half-Life is really an afterthought. The game was rebooted in 1997, a year before it released. Before the reboot, it was filled with a bunch of random levels. Valve still works like this and did the same thing with Portal.
·         Footnote: mythologizing crunch is gross. Valve crunched for 6 months before the game released, working 16 hour days. Two developers stayed up for 48 hours straight to get a feature in. We praise these developers as heroes, but we should not be encouraging crunch.
·         Half-Life’s Legacy = depth and diversity in environmental storytelling and scripted sequences, you just watched a bunch of people die in scripted sequence, and writings on the wall are not very subtle, the narrative was not subtle at all.
·         Half-Life was considered the Myst of video games, but really it’s just a Stephen King novel mixed with some Outer Limits
·         It’s not a debate about ludology vs. narratology. Half-life is 100% schlup.
·         How to love a game’s guts and you can too. Read through Half-Life’s source code, it’s beautiful poetry, Robert’s programming style is based a lot onHalf-Life’s code, the way he names variables and files, are curly braces on the same line or new line? is art center-aligned or top-left aligned? File structure is absolutely important.
·         Should the next-gen dumpster get two 1024x1024 flats? There’s a hundred decisions that goes into making one dumpster art. Fetishizing this process is gross, it’s amazing that we are even able to make games when we are faced with so many decisions.
·         Art history to games = AAA sandbox / open world = large sweeping pastorals even with post-apocalypse or urban setting, function and values are the same, awe and manifest destiny, the landscape is big and beautiful and it is yours, almost everything looks like Thomas Kinkade paintings.
·         Game development = code + asset + content + concept + design + workflow + politics = transcendence.
·         Black Mesa Inbound (the first level) and its legacy = work commute, nothing happens, slow foreshadowing, mindblowing, revolutionary, brave, there’s no shooting. In the beginning, you are on a tram and you just witness the facility going on. It’s also meant to be a tech demo (color lighting, character animations, size of the space, color palettes per texture).
·         func_tracktrains = have a platform, you lay out the path track, you have to manually drag them all out and tell each one which the next one was. The level was also made up of many different levels strung together (due to texture limitations).
·         The object ontology was by far the worst component. Half-Life had two sorts of objects, static brushes and dynamic entities, and you could not parent one object to another one.
·         Magic in motion = how did they glue a moving door to the moving train without parenting objects? When the train reaches the end of the track, it loads a new level, swapping out the old train with a new train.
·         Rachet & Clank – an online game that shipped without a patching mechanism, they sent an oversized EULA, you grab an EULA from the server which held important stuff and handler pointers, it exploited code executes and unpacked main code, this is how they patched the game.
·         There’s a set piece in Half-Life where you are attacked by a giant shark. The game didn’t have physics simulation, so the cage is actually a “train” using the func_tracktains.
·         Shark Cage behavior and scripting = the shark was named Ichthyosaur, added a trigger point to tell the shark to come eat you, has another sensor to tell the shark to not eat you (the level design made up for the lack of AI), the shark was technically a flying monster (by code inheritance), the shark moved based on node paths (simple pathfinding)
·         Valve’s design philosophy is that you should be able to see what is about to kill you, then see it kill you, and see it after it kills you. Team Fortress 2popularized the kill-cam.
·         Shark Cage health, damage, and tuning workflow = these variables were externalized to skill.cfg (a text file), but some things were also hardcoded like how long you can hold your breath underwater and the number of crossbow ammo you get. It’s a good idea to hardcode some stuff and softcode others. Underwater time is a good thing to hardcode because tons of puzzles probably are designed around it and it shouldn’t be changed so easily.
·         Smells are a type of sound. Monsters can smell your sounds.
·         Furniture in Half-Life is a type of monster, just so it can react to the player attacking it.
·         Well Made (instead of Well Played) = learn from the code of games.
·         “The technical” is relevant to everyone and you are wrong if you disagree and here is why = game development killed Luigi, game development affects game design so much
·         QGcon, a lot of children’s animations were hand-animated, they kept the cast small so they didn’t have to draw as much, created a lot of “loopy narratives.” Now with new technology, we have so many characters, wars, accumulation, instancing, mobs, etc.
·         Dead Island was a painfully mediocre zombie game. Looked at scripting files and one of the skill abilities was named “FeministWhore”, developer released a response where they said it was just a private joke for an obscure debug function, but this is a lie
·         “a computer language is not just a way of getting a computer to perform operations… programs must be written for people to read, and only incidentally for machines to execute.”
·         Pay a lot of attention to the things you’re making. Don’t be a jerk.
·         10 Print and Criminal Code: Procedural Logic and Rhetorical Excess in Videogames.
·         “Screen Essentialism” – there’s so much of a game that’s invisible on the screen
·         There are apolitical games that are actually not apolitical when you look at the code.
·         This is game development – cultural, political, social, technical, scientific, artistic, creative, diverse, relevant
·         Press Select
QUESTIONS AND ANSWERS
·         The tension between “crunch is terrible” and the horrible workflow of Half-Life being beautiful. Crunch usually happens because the producer didn’t do a good job. Do not hold people as heroes just because they can work late and long hours. This is also a concern for indies, and we should all be concerned about our work-life balance.
·         The finished water towers were really boring compared to the untextured surreal ones.
·         Code is so proprietary now. Robert is interested in open-sourced game code.
·         Well Made should be really great engine overviews.

Thursday, April 18, 2013

GDC2013 - Developing a Windows Store Game with DirectX and C++

  • Phillip Napieralski give a quick tutorial for developing a Windows Store game with DirectX and C++.
  • He showed off the Taptiles hub interface, which was built with XAML. The game is built under the hood with DirectX but uses XAML for the main menu interface.
  • Fruit Ninja, on the other hand, uses DirectX for its main menu UI.
  • XAML is a markup language that interacts nicely with DirectX in various scenarios.
  • Direct3D Visual Studio template is a code example.
    • It has two main classes (CubeRender and Direct3DApp).
    • The ^ operator is a 'handle." It's a WinRT pointer that is reference counted.
    • There are five classes to override and implement (Initialize, SetWindow, Load, Run, Uninitialize).
    • There are also two lifetime management events (Suspend and Resume).
    • You have five seconds to load or the OS thinks your app has crashed. He recommends to have a secondary splash screen in Run() for the loading sequence, rather than loading assets in Load().
  • He showed off the Marble Maze game example with additional features (store simulator, cheats, notifications with friends, share charms, and animated live tile).
  • Take full advantage of Win8 features.
    • Tiles - should have dynamic content like leaderboards, send updates to users, and can use Microsoft servers instead of from inside the app. Tiles are just an XML document and there are lots of templates to start with.
    • Toast notifications - immediate notifications defined in XML, needs a push server
    • Appbar - triggered by gesture (swipe from the edge), Windows + z keyboard combination, or right click.
    • Charms - make game social with ease, define a source and a target for the charm
    • Persistance - process lifetime management
    • Saving data - space available for roaming data, easily switch LocalSettings to RoamingSettings
    • Monetization - can include in-app purchases or set time periods for trials
  • Get Windows8 and Visual Studio 2012 (Express version is free).

Tuesday, April 16, 2013

GDC2013 - Job Graph: Task Graphing in Mortal Kombat

  • Gavin Freyberg, Director of Technology at NetherRealm Studios, talked about their proprietary multithreading engine.
  • All gaming hardware has multiple processors. The future is even wider and all games will need to run multithreading processes.
  • Task graphing defines game system flow in terms of tasks and dependencies between them.
  • Task and Job mean the same thing. Their job graph defines fixed function graphs, can have set of connection points between graphs, link graphs at runtime to form a meta-graph, keeps graphs independent unless dependencies state otherwise, and support child graphs.
  • Characteristics of job graph - object-oriented approach to asynchronous behavior, data-driven, runs on SPU, scheduling burden is spread across threads, graphs have single entry and exit points, has basic priority schemes, predication of jobs possible, dependencies are left empty, context data are embedded in instance, use lock-free code
  • It's important to create a visualizer of threads. The job graph visualizer is a standalone app that visualizes graph run. Its limitations are that it cannot have cycles in meta-graph, all depdency satisfiers must be known and well-controlled, and the perfect scheduling of jobs is NP-hard.
  • The job graph components...
    • The core system - fully data-driven, act on user-defined context data, dependencies are the glue that hold everything together
    • Graph leader - describes an instance (data offset, data counts), encapsulates runtime state (return state, internal branching state, external wait state, dependencies, predicate state, context data)
    • Token stream - describe execution of graph, are tokens for passing controls and job execution
    • Dependencies - atomic counter and a list
    • Work pool - contains multiple list of pending work, contains lock-free allocator for queues job data structures
    • Loop - conditionally acquire exclusive resources (pop work or release if exhausted), exclusive resource doesn't go to work pool until something needs it
    • Runtime system - owns the work pool, contains collection of instance lists, has special 2-pass instance launch process
  • Migrating code to the job graph was easy. It involves breaking code into jobs based on dependencies, using exclusive resources as a porting aid, increasing priority of the critical path, and setting up relationships outside of the meta-graph.
  • Results of job graph - explicit dependencies, low system overhead, supports runtime, allows conditional graph flows, can easily solve problems like 1 frame lag
  • The main problem with using job graph was its overhead. It uses up 3% of CPU spread across all execution units.
  • Mortal Kombat used a lot of middleware like Scaleform, fmod, and Havok. Middlewares were all encapsulated as a job in the graph.