Showing posts with label workflow. Show all posts
Showing posts with label workflow. Show all posts

Monday, April 18, 2022

Why I still use Unity

There's been some game dev twittering about Unity vs. Unreal lately. Why use Unity when Unreal is better?

The basic consensus is that Unity's advantages have been crumbling for years, and its attempt to challenge Unreal on high-end graphics has meant neglect everywhere else. But if you want high-end then UE5 Nanite / Lumen is light years beyond Unity HDRP anyway? And if you're making the typical aspirational photorealistic action game, you'll probably want UE's gameplay architecture and free photoscan assets too.

Most recently, respected developer Ethan Lee has weighed in. For him it's not about the graphics, it's about source engine access and engineering processes. Being able to pinpoint bugs in the core Unreal Engine code, fix them, and submit patches to Epic is how modern software development works. Comparatively, Unity is closed source, and even if you go to the trouble of filing a bug report you'll still have to wait a year for an official bug fix if you're lucky. This is important during the second half of a game dev cycle, when game making becomes a terrible slog -- when your game randomly crashes on Nintendo Switch for some reason and you have to figure out why but you're already so so tired.

So why on earth would anyone still use Unity? Everyone has their own situation, and here's mine:

Wednesday, April 28, 2021

MIF commission "We Dwell in Possibility" coming in July 2021


Manchester International Festival (MIF) just announced my upcoming project "We Dwell in Possibility", a queer gardening crowd simulation in collaboration with illustrator Eleanor Davis, to be released in July 2021. It'll be free and playable in your web browser.

This commission has been interesting because I'm learning and trying a lot of work that I don't usually do, which came about as a cascading chain of design constraints:
  • Mobile. My gay games are all well-suited for a mobile format, but tech platforms are increasingly sex-phobic and will block my content from their stores. But if I target a mobile browser, they can't really stop me. (This is the real reason why Apple keeps their iOS browsers so slow and broken: an open internet threatens their control over everything.)
  • Not-Unity, in 2D. If I want it to run well in a mobile browser, then it probably has to avoid lots of flashy 3D. I usually work in Unity and don't get me wrong Unity's WebGL build target is a miracle, but still not quite miraculous enough, so that's why I'm learning HaxeFlixel for this project.
  • Collaboration. I usually prefer to work solo and in 3D, but my 2D art skills aren't very developed. So what if... this time... I didn't... do the graphics? I've admired Eleanor Davis' work for a while now, and I'm super excited to have her here. Also I secretly hope this is just the first of many video game projects she works on.
  • Producers. MIF does something a bit unusual for its commissions -- they provide producers, which is very common for live events and commercial games, but rare in an art games context. For this project, my fantastic producers Shanaz Gulzar and Steph Clarke have been key for figuring out what the heck we're making, and will be instrumental for bringing this to the finish line.
The two takeaways I want to emphasize here are:

(a) even experienced developers / artists are always learning and growing... and according to the artistic-industrial complex, I'm entering a phase known as "mid-career"? oh dear

(b) grants, commissions, and public arts funding are what gives people space and time to do that vital growth... meanwhile, commercial works and solo side projects often force us into our comfort zone, which can act as a ceiling on that growth

Friday, April 9, 2021

Getting started with HaxeFlixel in 2021

Warning: this is a fairly technical game developer-y post. If you came here for gay sex, I'm sorry.

For an upcoming project commission, I'm making a 2D game with crowd simulation and simple controls that works well on mobile browsers. (Reminder: for iOS, that means WebGL 1.0 and no WASM.) The engine should be able to render and simulate 200+ lightweight game objects -- frame-animated sprites with simple collision, no fancy physics or shaders.

Which game engine should I use to maximize ease of learning and compatibility, and manage hundreds of simple objects on-screen? Here was my thought process:

  • Unity WebGL: way too heavy and slow for mobile browsers, and maybe overkill for a no-physics 2D game anyway. (Although the Lil Nas X 3D twerking game runs surprisingly well on iOS's WebGL 1.0, I wonder how much they had to optimize?)
  • Unity Project Tiny: as far as I can tell, Project Tiny and its DOTS dependency is still in early development. The random caveats and various in-dev inconsistencies with regular Unity would also be frustrating. And as with many other Unity side projects, its long term future feels really hazy.
  • Construct: seems ok, and I think I could've gotten used to the visual block scripting, but overall the pricing and licensing feels weirdly restrictive. I have to pay to use more than 2 JS files? I have to pay to use more than 1 font, or make an animation more than 5 seconds long? These are some really bizarre artificial resource limits.
  • Phaser: seems popular enough with decent TypeScript support, but I want the option of building out to a native executable without a weird Electron wrapper or something. Their monetization model (free open source base but you pay for "premium plugins" and tools) is one of the more generous ways to go about this, I get it, but it still feels weird to me and reminds me of Construct.
  • Godot: I've wanted to try Godot for ages, but in the end I felt like I didn't have a good sense of what its HTML5 Web export could do + learning enough of the "Godot way" and GDScript would've taken a while. It's also in the middle of a big break between v3.0 and v4.0, and ideally I'd like to wait until like v4.2 to commit to learning it.
  • Heaps: promising and some people get great results with it, but maybe still too early in public lifecycle for a total newbie like me, with not enough samples / docs / robust official tutorials to learn from yet. If or when I do try out Heaps, I'll probably try using Deepnight's gameBase project template.

In the end, I chose to build this particular project with HaxeFlixel. This post details my early impressions, thoughts, confusion, advice, etc. with learning it.

Sunday, August 9, 2020

new Quake map: "Smell It In The Street"

I made another Quake map! This one is called "Smell It In The Street" and it was made for the Doom Tintin map jam, a level design jam centered around using Quake mapping community member Tintin's texture pack that samples from Doom 3 textures.

Some brief level design thoughts follow:

Sunday, June 21, 2020

Hard Lads as an important failure



This post “spoils” what happens in my new game Hard Lads. If you care about spoilers, you should play it before reading. It takes about 5 minutes to play once, and maybe 20 minutes to play it to 100%.

In 2015, a phone video of young muscular White British men hitting each other with a chair went viral. Why make a game about this meme now? Some might characterize all my output derisively as "meme games", which is fine, but personally I’ve tried to avoid doing it on purpose. First, my games themselves should strive to be the original meme, and not merely a fan reproduction. Second, many memes are steeped in internet gamer culture, the only circle jerk I want to avoid.

However. I think British Lads Hit Each Other With Chair is one of those classic internet videos that merits special attention. It does so much in a single minute, and it's not about video games at all. So that’s why I made Hard Lads.

Monday, November 11, 2019

Practical primer to using Unity Timeline / Playables


I recently used Unity Timeline to do cutscenes in a game. Once you figure out how to use it, it works great, but that learning curve of expectations and setup is pretty annoying.

To review: Timeline is a sequencing tool. It's good for higher-level logic where you need to coordinate a bunch of objects at once. For many games, that usually means choreographing cutscenes or sequences. Many different engines and toolsets have sequencer tools and they all generally have the same workflow -- you make tracks and you put actions on those tracks. (see also: UDK Matinee, UE4 Sequencer, Source 1 Faceposer, Witcher 3's cinematic tool)

Note that Timeline is not an animation tool, it's higher level than that. Think of it like a movie director, it coordinates animation, audio, characters, and FX together, but doesn't actually make or process those assets.

In this intro workflow post, I'll start with SETUP TIMELINE, then SETUP DIRECTOR and MAKE CUTSCENES and CONTROL THE DIRECTOR VIA C# SCRIPT, and lastly how to MAKE CUSTOM TIMELINE TRACKS.

Monday, March 25, 2019

new Unity tool: Bobbin


I wanted to be able to write game dialogue in Google Docs (from my phone or tablet, or to share with external collaborators) and then automatically send those changes into the Unity project on my laptop.

To help me do that, I made a free open source tool called Bobbin, which is a relatively simple Unity Editor plugin that can automatically download the data at URLs, and import that data as a file in your Unity project. Again, it's very simple: every X seconds, it opens a list of URLs (as if it were a web browser) and then it saves all the bytes as a .txt, .csv, .png -- or in-theory, whatever file type you want. Note that this is just an automated download manager, you will still need to write your own game code to actually import, process, and use these files in your game.

The main audience for this tool is narrative designers, writers, localizers / translators, and designers / developers who need something fast and lightweight for syncing files with external collaborators. I imagine it also pairs well with text-based narrative plugins like Yarn Spinner, where in-theory, you could collaboratively write Yarn scripts in a Google Doc and then use this tool to automatically bring the script into your game.

(But if you're making a game that's going to make heavy use of spreadsheets, you should probably use something more robust like Meta Sheets or CastleDB-Unity-Importer, which can import your spreadsheet data as C# types with Intellisense auto-completion in your IDE.)

Anyway, I'm planning on a few more feature updates, like runtime support and/or better Google Sheets support, but personally I'm probably not going to expand the feature set much beyond that.

I hope you find it useful! And as always, feel free to submit any bug reports (or small feature requests) by opening an issue on the github.

Friday, March 8, 2019

Why you should almost always localize your games

screenshot from my game Rinse And Repeat, with a sexy shower hunk speaking in Russian subtitles
This post is adapted from a talk I gave at WordHack on February 21, 2019 in New York City.

It's hard to feel validated and respected as an artist or creator on the internet. One common (and unhealthy) barometer of "success" is to measure how many people play your game or look at your work -- did you find an audience and are you reaching that audience? I argue that localizing your project into other languages will help you find your audience. It might not be an audience you necessarily understand or communicate directly to, but for example, a large Russian or Chinese fan base might help offset the hurt of being ignored in English-speaking media, and so on.

If you believe these random stats I found, about ~80% of Steam users live in countries where English is not the main language. This roughly corresponds to the worldwide average, where it is estimated that only about ~20% of the world (native and non-native speakers combined) uses English, and about ~25% of all internet users use English. Note that these are all very generalized numbers with lots of assumptions, but let's assume they're in the right ballpark -- that means English-only games basically ignore 75-80% of the world.

Thursday, September 20, 2018

Fall 2018, teaching game development memo

Sorry I haven't posted lately, we've been pretty busy here at NYU Game Center with the start of the new semester. We're also currently in the middle of some curriculum renovation for our game design programs.

First, we're increasingly adopting JetBrains Rider as our code editor IDE of choice. It is free for students, common in commercial studios, and it's supposedly even used by the Unity CTO himself. While I find Rider to be somewhat annoying in its code style suggestions, its Unity-specific benefits seem to justify it as a teaching tool. We're also teaching source control with Rider's built-in Git support, instead of using a dedicated tool like SourceTree or GitKraken. (If this semester is a disaster though, I might go crawling back to VS Code and GitKraken.)

Second, we're starting to teach new game genres beyond mainstays like platformers. For instance, our MFA studio class now begins with a Fungus-powered visual novel project instead of a traditional platformer. This is partly a reflection of where contemporary game culture is at, where visual novels are perhaps more popular and relevant than platformers today -- but also a visual novel framing helps students focus on different development skills, like narrative design and pacing.

Third, we're gradually moving towards more of a "core studio" design school model, where every 3rd year student will be required to take core studio classes about making self-directed projects. Previously, undergraduate students would optionally enroll in these project studios, but we found that many of these students would opt out in favor of other electives -- and then they would feel unprepared to take on their capstone project in their 4th year. The goal is to normalize "bigger projects" for them. It's also a good opportunity for them to bond with the rest of the students in their class year.

As for my personal teaching load, I'm looking to debut a new class next semester about Let's Plays / game streaming culture. Game streamers are some of the most popular and visible figures in game culture, or even the larger internet as a whole, but I find that most of game academia doesn't really engage with it. It's partly a generation gap thing, where lots of middle-aged and elder millennial faculty (like me) didn't grow up with streaming and still view it as somewhat of an aberration / stain on discourse. However, there's no question that no one reads game critic blogs anymore (RIP, Radiator Blog!) and YouTube and Twitch are driving the big cultural conversations today.

As a discipline that seeks to engage with public game culture, we have an obligation to figure out how to analyze and teach this subject! So far, I'm still figuring out my course design, but I know I want to challenge students to become live game streamers themselves as part of their final project. I'll also be leaning heavily on T. L. Taylor's imminent book "Watch Me Play: Twitch and the Rise of Game Live Streaming" for most of the readings. Maybe next year I'll be able to report back on how the course goes.

Tuesday, August 28, 2018

Darner's Digest, vol. 2: Why I made two new Yarn tools


Darner's Digest is a series of occasional posts about the game dialogue system Yarn.

Last time, I talked about some Yarn community news. As I've written before, I've become a sort of community booster for Yarn and Yarn Spinner because I want to see it become a standard in game narrative design -- I think it occupies a nice middle-ground between frameworks that try to do everything for you vs. coding a system yourself.

This time, I'm making the Yarn news myself. I've released two free open source Yarn / Unity tools for people to use, and I reckon they're darn good:
  • Merino, a Yarn script plugin for the Unity Editor, with built-in syntax highlighting and playtest preview. With Merino you can easily test the flow of your interactive stories without leaving the textbox or the Unity Editor.
  • Ropework, a Yarn-powered visual novel template for Unity. With Ropework you can control scene changes, sprite rendering, and sound playback, all from Yarn scripts -- and you can basically make a visual novel without writing C# code.

Wednesday, July 18, 2018

Darner's Digest, vol. 1


Darner's Digest is a series of occasional posts about the game dialogue system Yarn.

As I've written before, there are a variety of different narrative system plugins to use with Unity. Fungus is a full visual scripting solution ideal for beginners, Ink is great for text heavy games with huge word counts (like 80 Days), and Yarn / Yarn Spinner is a lightweight extensible Twine-like dialogue system for games about occasionally talking to characters (like Night In The Woods).

I don't know what's going on in the Fungus community, and I loosely follow Ink -- they are running an upcoming Ink Jam to encourage new users, and the maintainer Inkle Studios is doing exciting dynamic narrative research in Inkle with their upcoming game Heaven's Vault.

However, I can definitely speak to more detail about what's happening with Yarn these days though, so here's my attempt to recap:

Thursday, July 12, 2018

Tips for working with VideoPlayer and VideoClips in Unity


Traditionally, game developers use Unity for real-time 2D and 3D games and shun any use of pre-rendered video, partly out of design dogma but also because the MovieTexture system was a nightmare. However, the recently overhauled VideoPlayer functionality means that *video* games are now much more doable. You can now feasibly make that Her Story clone you always dreamed of!

I'm currently making a video game that makes heavy use of video, chopped into many different video clips. It's been fun trying to figure out how to build basic video functionality like playlists and clean transitions between clips, except in Unity.

The thing they don't tell you about re-inventing wheels is that it's fun and exciting to re-invent the wheel, and it gives much more appreciation for the craft that goes into wheels. It was fun to think about how a live telecast cues up video footage on multiple monitors, and how a real-world broadcast works, and I learned a lot about why they do it like that.

Let's talk video in Unity.

Sunday, February 18, 2018

Mapping the sea floors of Subnautica


This post spoils the core gameplay and player progression in Subnautica, but not the specific story nor scripted plot events.

Subnautica is a long open world survival game set in a vast deep ocean. In it, you have to forage for food, manage your oxygen when diving into caves and deep sea trenches, and collect resources to build your own underwater base(s) and submarine(s) to find out What Really Happened Here.

Much like the other first person indie survival game The Long Dark, Subnautica features no combat, no world map, and essentially no NPCs or quests to complete for anyone. The few lethal weapons are either cumbersome and annoying to maintain (poison gas torpedoes must be crafted and loaded) or practical but anti-juicy (your knife)... but most importantly, unlike The Long Dark's focus on hunting, killing creatures in Subnautica *never* yields any reward or drops -- even when the game confusingly asks you to collect shark teeth but killing sharks never yields any shark teeth.

(Why? Well, there's a few story threads about how use of force cannot get you what you want, as well as a faint anti-capitalist / anti-colonialist message. But the smoking gun of authorial intent is in the credits: a dedication to the families of Newtown, Connecticut. The design lead has also talked about their no-gun philosophy.)

PC Gamer already did a nice roundtable about Subnautica's early climactic story moment, so instead I want to focus on Subnautica's most interesting systemic feature: its depth-based 3D level design, and implications on the rest of the game.

Thursday, February 8, 2018

Postcards from Unreal, pt 3: on spaghetti monsters

Unreal Engine 4
We're now a few weeks into the Unreal level design class, and things seem to be going OK. Our students have enough familiarity with Unity that they're able to digest a lot of the 3D workflow without too many problems. People are happily grayboxing here and there, and we recently did an intro to Blueprint scripting.

In the past, I've been pretty skeptical of teaching visual programming methods to students. Teaching a specific visual scripting tool always felt like we were locking students to that toolkit, versus learning how to code in C# or Lua or JS, which is a generalized language useful across multiple engines and multiple industries. Visual programming was considered a relatively niche practice, where you might mock-up an art installation in MaxMSP but not much else, and even Unreal used to confine visual programming to its Kismet level scripting system. (The precursor to Blueprint.)

However, that criticism of visual programming is gradually losing its power as this type of practice becomes more common in the game industry. Many Unreal Engine 4 devs (as well as Epic themselves) make heavy use of Blueprint for making games, a lot of Unity devs rely on the third-party Playmaker plug-in, and even upstart engines like Godot support a visual programming workflow. AAA texture generating darling Substance Designer also has a heavy node-based workflow. It's everywhere!

Wednesday, January 24, 2018

Watch and/or Read "GDC 2015: Level Design Histories and Futures"


GDC finally uploaded my talk from 2015 on level design history and futures... and already, the conservative gamer-gestapo is whining about how I have the gall to talk mention racism and sexism in a design history talk.

This prompted me to review my slides and notes from 2015, and I was surprised -- usually I hate whatever I write, but this time I was surprised by how the material mostly holds up. (I was also surprised by how much I anticipated the whiners' critiques and put disclaimers everywhere.) Really, the only thing I have to work on is, um, the frequency that I say "um", but you know, I'm working on it.

Personally, I dislike watching videos and vastly prefer reading talks, so for your convenience I've also uploaded my complete slides in a double-length PDF. The first half of the PDF has the talk slides, and the second half of the PDF has my speaking notes as well... here's also one last reminder, that I've edited / condensed this stuff into a shorter talk called "local level design."

Friday, September 29, 2017

Adventures in VR sculpting

I've been sculpting a lot in VR lately (via Oculus Medium) trying to figure out whether it's "the future" or not.

While I've worked in 3D for a long time, I'm used to building levels in a low polygon style with a 2D interface -- so for me, working "natively" in 3D VR has been strange and confusing, as I try to figure out how sculpting workflows work with 3D motion control interfaces.

When you are 3D modeling in a 2D interface, you can only move in two dimensions at once for every operation. Every stroke is constrained to 2 directions, so you learn to limit how much "each stroke" is supposed to accomplish. You begin seeing 3D in a specific "2D" kind of way. A lot of existing modeling software has evolved to fit this workflow, using operational systems that are non-linear and asynchronous -- what I mean is that each time you move a vertex or apply a bevel in Maya, you can always tweak or adjust that action later. Need to twist a tentacle in a weird way? You setup a spline, and 10 clicks later, you have a twist. It's very accurate because you're working very methodically in super super slow motion, decompressing time.

Current VR sculpting software doesn't really capture this "bullet time" dimension of working in 3D. Instead, it's very immediate and continuous. It's unclear whether VR will ever be able to support the high text density / menu complexity that most 3D modeling software needs.

If you have shaky inexperienced hands, too bad! You can't fine-tune or adjust your tool movements after you perform them, you just have to get better at doing more fluid, cleaner hand gestures.

Before, with a mouse, I could sort of do 100 different strokes and take the best bits of each one, and assemble the perfect stroke. But in VR, I feel like I can't do 100 takes, I get only 1 take, and I better not fuck it up! (Ugh. Why is this "natural" interface supposed to be so much better? Fuck nature!)

So now I basically have to become a much better fine artist, and learn how to move my body around the sculpture, instead of simply trying to developing the eye of a fine artist. Some of this frustration is due to the difference between a sculpting workflow vs a polygon workflow, but the inability to rest a mouse on a table certainly exacerbates it.

It also probably doesn't help that I'm taking on one of the most difficult topics of visual study possible, a human head. It's very easy to sculpt a "wrong-looking" blobby sculpture, as you can see in my screenshots! Fine artists usually spend many years in figure drawing workshops to train themselves how to "see" people and understand the many different shapes of our bones and muscles.

But I think this challenge has been helpful, and it keeps me focused on figuring out which skills I need to develop. How do I get clean sharp edges and defined planes in VR? Should I sculpt with blobby spheres and flatten it out afterwards, or should I sculpt with flat cubes and build-up my planes from the beginning? I'm still trying to figure it all out.

And if VR sculpting truly is the future, I do wonder how this will factor into a game development workflow. Maybe we'll sculpt basic forms in VR, and then bring them into Maya for fine-tuning -- or maybe it makes more sense the other way, to make basic forms in Maya, and then use VR only for detail?

I don't know of any game artists who seriously use VR as part of their workflow, but if you know of any, let me know so I can figure out what they're doing and copy it!!

(And hopefully in another month, my sculpts won't be so scary...)

Saturday, September 23, 2017

Writing stories / dialogue for Unity games with Yarn

I've been using Yarn for a little while, and I've grown to prefer it as my "talking to NPCs" solution for game development. If you're not familiar, Yarn and Yarn Spinner are a pretty powerful Twine-like plugin for Unity (though it could technically work in any C# game engine) that's geared towards writing video game dialogue, and it was most famously used for Night In The Woods.

Yarn is fairly lightweight, extensible, and it basically gets out of your way. Want to make a really big long monologue, or 100 little pieces of dialogue snippets? Yarn works well for both of those use-cases. (If you want something that's more focused on manipulating very long dense passages of text, you might want something more like inkle/ink, the system that powers the huge 750,000 word narrative game 80 Days.)

To try to provide more resources for other Yarn users, or potential Yarn users, here's a write-up with some advice and a short guide to working with Yarn...

Tuesday, December 27, 2016

On legacy systems and Kentucky Route Zero (Acts I-IV) by Cardboard Computer


A lot of people will say Kentucky Route Zero is "minimalist"... but I think that label is pretty misleading.

It packs every single scene with countless details and thoughtfully executes each of those gestures. Every playthrough you'll read tens of thousands of words, much of it expended on long evocative description -- this isn't actually a "minimalist" game, in terms of literary tradition nor in terms of what it demands from its players. Every scene is lush with history, detail, and allusion, and KRZ never patronizes you if you don't really get it. Instead, it patiently pushes you to grasp it as a whole.

This "whole" is something that carries over to the game's technical infrastructure as well. Everything is connected; the game frequently calls back to your previous choices, and awakens seemingly dormant "meaningless" choices. It is one of the most complex narrative designs ever attempted in a video game. Instead of a few discrete branches, there are dozens of small branches -- like Chivalry Is Not Dead, it is more "bushy" than "branchy."

Wednesday, September 21, 2016

The golden age of urinals

This is work in progress on a new project branching off an existing project... it's probably a game about cruising. I wanted the bathroom to feel old, so I did some research on old vintage public bathrooms -- and the Hinsdale urinals are widely acknowledged to be the supreme "Cadillac of drop urinals" so here they are. The bathroom itself is inspired by the bathroom in Old Town Bar in Manhattan.


Tuesday, June 7, 2016

Working with custom ObjectPreviews and SkinnedMeshRenderers in Unity


Unity's blendshape controls -- basically just a list of textboxes -- were going to cause me a lot of pain. After wrestling with broken AnimationClips for my previous attempt at facial expressions in my game Stick Shift, I decided to actually invest a day or two into building better tools for myself, inspired partly by Valve's old Faceposer tool for Source Engine 1.

To do that, I scripted the Unity editor to draw a custom inspector with sliders (based on Chris Wade's BlendShapeController.cs) along with an interactive 3D face preview at the bottom of the inspector.

The workflow I wanted was this: