Showing posts with label unity. Show all posts
Showing posts with label unity. Show all posts

Sunday, January 1, 2023

Unity WebGL tips / advice in 2023

I recently released a Unity WebGL game and the process was a bit painful. Here's what I learned...

In summary: 

  • I was using built-in pipeline and didn't try URP. (HDRP is definitely out of the question btw)
  • Unity WebGL support isn't bad, and WebGL performance is even OK, as long as you treat it like a ~2015 mobile device in terms of capability and performance. Don't throw a lot at it, especially because iOS browsers can't do a lot...
  • ... because it's 2023 and iOS WebGL performance is still pretty shitty even with Apple's promised ANGLE WebGL 2.0 support. You should expect to do a lot of mitigations and workarounds just so iPhones and iPads don't explode. Meanwhile, Windows and Android browsers are generally solid and reasonable. (In case you can't tell, I'm pretty annoyed with Apple.)
  • Here's what'll happen to you: your WebGL build tests on your desktop browser will work fine and you'll be pleasantly surprised... and then you'll try it on an iPhone and it'll be a mild disaster where you spend a week or two fixing all the various ways it explodes.

(Note: this is current as of Unity 2021.3.11 LTS + iOS 15.)

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:

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.

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.

Sunday, November 4, 2018

The first person shooter is a dad in mid-life crisis

OK I know Heavy Rain isn't an FPS but I like this screenshot so I don't care
Every semester for our introductory Games 101 historical survey class, a different NYU Game Center faculty member presents a survey of a game genre. Matt Parker lectures on sports, Clara Fernandez-Vara talks about adventure games, Mitu Khandaker talks about simulations, and so on.

My personal lecture happens to be on the first person shooter (FPS) genre. In my lecture, I trace five main currents through the FPS genre:

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.

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, 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:

Tuesday, October 13, 2015

Tips for implementing / coding an in-game options or pause menu functionality in Unity

 

I recently implemented an in-game options menu in Unity. Mine looks something like the thing above. A surprising amount of the required functionality is already implemented in Unity, you just have to write some code to hook into it. In the cases when Unity didn't already have a static variable for a particular setting, like mouse sensitivity or menu language, then I'd implement my own static variable that worked with a specific PlayerPrefs key.

Anyway, here's a bunch of workflow / specific API calls that I found very useful when I did it...

Thursday, September 10, 2015

Scripting the Unity Editor to automatically build to Windows / OSX / Linux and packaging the files in ZIP files.


I'm getting ready to release my next gay sex game, which means a lot of builds and testing. This game, in particular, has a lot of particular framework and infrastructure that involves copying over specific files directly into the built data folder. I don't want to have to copy over the files manually over and over, so I bit the bullet and decided to write an editor script that automatically does all this stuff for me, for all 3 desktop platforms that I'm targeting. This is really nice because it saves me a lot of time when making builds, and it also makes it more the whole process more foolproof since it prevents me from forgetting any files -- Unity is automated to include them for me!

Here are the main snippets + explanations of those parts of the pipeline, with the full script at the end of this post...

Saturday, March 28, 2015

Implementing real-world real-time stamina / energy cooldown timers in Unity C#

In Hurt Me Plenty, I implemented "real-world" cooldown timers, which persist even if the player restarts the program. The cooldown period elapses in "real world" time, not in game time.

This resembles stamina delays in many popular free-to-play games, but it also connects with the design tradition of using real world system clocks to dictate game logic -- maybe certain Pokemon emerge at real world night, or you witness events that correspond with real world holidays, or perhaps you can even kill a boss NPC by setting your console's system clock forward by a week.

Much like the implementations referenced above, mine is quite weak and vulnerable to circumvention and cheating: I simply save a system timestamp in the game's PlayerPrefs, and then check that saved timestamp upon loading the game. If the difference between the current system time and the saved timestamp is less than zero, then the time has fully elapsed and the game continues.

Friday, February 13, 2015

How to make stuff look at stuff / demystifying turns and rotations, and working with quaternions in Unity C#

Julia set fractal thing of a quaternion function... I actually don't really know what that means, but it's pretty.
This is kind of a blog post more for my Unity students, but I figure other people on the internet might find it useful -- let's demystify working with rotations in Unity, and explore some useful techniques for doing so.

There are 2.75 ways to store rotations in Unity: (1) quaternions and (2) euler angles (directional vectors are the 0.5, and some math functions secretly take radians instead of degrees, that's the 0.25)...

Euler angles are the typical 0-360 degree system taught in most junior high / high school geometry classes, while radians are in "units of pi" and represent the curvature of a circle. Then there's quaternions, which are scary 4 dimensional representations of a rotation that you may have never heard of / can barely spell! Fortunately, you don't need to know quaternion math in order to work with rotations, Unity will handle conversions for you.

Okay, so first let's explore a most common problem: how do you make stuff look at stuff in Unity?

Monday, January 5, 2015

Some Unity 5 beta impressions


I'm making a small Thief-like with integrated level editor (3rd time's the charm!) to test (and teach myself) four (4) main feature-sets of the Unity 5 beta -- physically-based shading, integrated image-based lighting, real-time global illumination, and the UI system introduced late in Unity 4.6 but might as well have shipped in Unity 5. Here's my opinion so far:

Tuesday, October 28, 2014

On branching dialog editors and narrative design tools


I was prototyping a game concept with branching dialogs for conversations and/or CYOA story events, so I started looking at various solutions on the Unity Asset Store. Dialoguer looked the most decent, but generally all of them just made too many assumptions or enforced bad workflows, and seemed to ignore what made Twine so accessible.

So I've decided to make "Bramble", my own editor plug-in and system for Unity! Here are some factors in its design:

Sunday, December 1, 2013

Reading public Google Drive spreadsheets in Unity, without authentication


I'm working on a project with a collaborator who doesn't use Unity and doesn't really have an interest in game development (gasp) but it is still important that she can add/edit item data for the game. From a practical workflow perspective, I probably would've kept the item data separate from the game code anyway, to make it easier to balance and tweak stuff. This is usually the stage at which you'd make your own level editor or game database editor or something, but maybe there's a better way -- we can just tell Unity to read from a public Google Docs spreadsheet and parse the data. That way, anyone can edit the game levels or localization strings or whatever from anywhere in the world, and the game client will update data seamlessly.

A lot of this post comes from Clark Kromenaker's great post on accessing Google Docs services with C#, and a lot of my setup process is the same as his.

However, my particular project didn't need any data kept private, the game itself didn't need write access to the documents, and authentication looked like a pain (e.g. using OAuth 2.0 requires you to open a browser window so the user can okay the permissions? Yeah, no thanks) so I worked out how to access read-only publicly published Google Drive spreadsheets without any logins or anything.

Wednesday, September 18, 2013

Teaching struggle.

The other day, I sat down with a student in my Unity class to review some course material and answer some questions. They were wondering why their code wasn't compiling. Their code looked something like this:


Tuesday, September 10, 2013

Hacking blend transition masks into the Unity terrain shader.

It is a truth, universally acknowledged, that grass rarely fades linearly into dirt. Grass is often quite clumpy. I wasn't satisfied with the non-clumpiness of my grass in a certain project, so I hacked Unity's terrain shader to add some blend mask support. You could probably use this technique for cobblestones, bricks, debris, gold coins... whatever you want to remain clumpy when overlaid on top of another texture.

First, let's think a bit about how Unity's terrain system renders the textures you paint on it:

Thursday, May 30, 2013

Design futures: AutoBrushes, levels that build themselves, and the politics of procedurality.



If Bethesda's detailed GDC presentation about modular level design kits for Fallout / Skyrim showed me anything, it's that modularity is actually a huge pain in the ass -- and not the good kind of ass pain either. Why should we keep building 3D levels in this slow, totally unnecessary way, with a workflow that's at least a decade old?

I remember a time when level design was slightly faster, and that time was the time of the brush. What if we could combine the benefits of modularity (variety / adaptability / abstract detail out of design) with the benefits of a brush-based workflow (simplicity / speed / focus on "platonic forms" of design)?