My excitement has been growing for VR and that’s spilling into my development of COOPERRATA. Now I want to add VR support once I get my hands on my pre-ordered Vive next month.
How does that work? COOPERRATA is primarily a tactical-ish FPS for mouse+keyboard (or game-controller). I don’t want to port that to VR, that would be klunky and compromised. Instead I’m thinking a sort of asymmetric co-op where VR players can join in together with mouse+keyboard players.
My current thinking is players could use VR as a support role: A VR “hacker” type that assists the other players as they make their way through a level battling robots and AI antagonists. That’s not set in stone, because room-scale VR is so different I really need to experiment and get a good feel for it before I lock any one design down. It’s a starting point though and I’m pretty excited about it.
The game would still be fully playable without VR players, but will let players of both types drop-in and out at will, changing the dynamics of the game in-progress. Cooperate in multiple ways.
I was planning on sending out private alpha keys this week, but I’m delaying that until after I restructure for these changes. I fully intend to release COOPERRATA this year regardless in one form or another, possibly on Steam: Early Access.
In response to some gentle prodding from friends, I’m starting a series of articles (†) about my thoughts regarding game design and game development. If you’ll excuse the difference in tone + topic, this first article is personal: About me and my journey making games; How I got from point A to point B. Writing my own narrative feels narcissistic, so I’ll leave the story about Pong in my childhood for the footnotes (††).
I make Games. I made my first computer game on an Apple IIe in high school: A “Skytrain simulator”. It was terrible. I kept making games on computers, but never once in my teens and twenties did I think of myself as a game developer.
I ran a BBS where I met awesome people who also made games. I hosted Joust tournaments and LAN parties.
The first time I self-published was a game on my own BBS. It was flawed and a user coded a terminal-side pathfinding bot that solved it. After the web arrived I ported some of my BBS games into web-games. Gates Motel had a moderate amount of success as an assassin-themed web-game with a few thousand users, some of them paying a yearly fee. I still felt like an imposter because it was inspired by Murder Motel, a popular BBS game by Sean D. Wagle (or Sheldon Pasciak? BBS “door” games were often re-worked and credit gets fuzzy, my apologies). I say inspired by, but mine was a different game (not a clone) of the same genre. I should have been more proud of it.
I had a foolish angry-young-man phase. I worked as a semi-angry games journalist at Electric Playground, where Victor Lucas (who is still doing great at what he does, kudos to him) wondered aloud a few times why I wasn’t applying for game-dev positions at EA, Radical, Relic, etc. as my friends were.
I met amazing and notable game-related celebrities. I could drop names but that would be false-pandering. I’m a terrible social animal and I’m sure only a few of them remember me, or worse I may have rubbed them the wrong way. Semi-angry journalist isn’t a good personality trait and it still pops up now and then.
After that, I tried to be a regular joe in regular jobs. I worked in a bank. I did web-design. None of that worked. It wasn’t me.
When I came back to games, the imposter syndrome was gone.
I had absorbed a lot of knowledge about the games industry and the related disciplines: From spending time in so many game studios as a journalist, plus just hanging out with friends in their work-environments. I finally took a AAA game-dev job and shipped a game with my name in the credits as a “mission designer”. I’m comfortable and confident making games. I can dip my hands into each part of game development and not do a disastrous job of it.
I’m 47. Damn I was slow to realize this: I should have been publishing more of my games all along.
I try to share more of my work now, though I’ll admit I still publish far less than I produce. I may be a slow learner, but I’m there. I’m discerning. I know my tastes. When I cook up something appetizing enough, I will share the results.
Currently I’m working on COOPERRATA, a co-op shooter for up to 5 players. I also have a couple of temporarily shelved projects: Obscuron I intend to rework as a room-scale VR game, whenever I can afford / get my hands on my own Vive (or Rift + Touch controllers). Awareon may stay shelved since it’s too big (it could consume me).
My next posting will be less about me and more about games, I promise. ;)
Footnotes: (†) I’m filing these articles under my COOPERRATA dev blog because it just feels right to do so, even though these are not directly development notes.
(††) I played Pong when I was 4 years old in the year that it was released, in a grocery store. I migrated from the arcades to consoles to computer games. At 18 during a Dodgeball incident I mashed up my right-hand and I have a slight disability as a result. I find it difficult / painful to use the bumpers on modern game controllers, so I don’t play console games as much anymore.
I’ve been holding my development on Unity 5.1.4, but thanks to a quick response from the Unity QA Team on a bug report: I’m going to bite the bullet and move forward with Unity 5.3.0.
The bug in question hasn’t been fixed yet, but I’m confident it will be. It’s a Canvas scaling bug with Unity’s UI, that occurs during script-triggered resolution changes while using a reference resolution. If I stick to native resolution for now, I can hold out.
Another Unity UI bug is washed-out / bad tinting in linear color (†), which you can see in my example screen crop here. This bug has been occurring since 5.2.x but I believe Unity is changing the linear color implementation (to L2? I have seen it mentioned) for Enlighten (the lighting system). That’s probably related to the delay in fixing this. I’ll just have to cringe and put up with this bug for a while until they get to it.
Unity 5.3.0 does come with some features that I really want. I use Allegorithmic Substances for textures, and 5.3 adds visual parity: What you see in the Substance editor matches in-game. There’s also a significant fix related to an asset I’m using that repairs a memory leak.
I’d like to settle on a “stable” release of the Unity engine to develop on. Chasing a moving target in production can get out of hand and I don’t enjoy re-factoring quite enough to have it prompted by changes in the engine. There’s a good chance that I’ll be sticking with 5.3.x, although I’ll have to see where I am along in development when 5.4 arrives sometime in March 2016.
Michelle has reminded me that most people don’t find login and patching systems all that thrilling compared to gameplay and art posts– I’m in a gleeful mood regardless because I’ve completed my game launcher, with a fair shine of polish to boot.
I still have to clean up the in-game menus somewhat, but this is the last variation of this screen you’ll see on my stream for awhile.
I’m looking forward to getting back to that gameplay + art stuff.
Sometimes coding feels like Rimmer in the first episode of Red Dwarf. Like I’ve covered myself in this accumulated code and it’s a big mess of gibberish. There’s a temptation to slap down that palm-print and ship-it! Which isn’t always a bad thing. Most of the time though, a good refactoring is in order.
I intended to roll my own patching system into COOPERRATA’s launcher, but DarkPatcher from the Unity asset store seemed robust enough to handle the task. One problem: It has an expected flow for patching which is different from my original plans. So I could either kludge it in, or redesign my launcher.
This is a good excuse for me to take apart what I have so far and re-assemble it in a more orderly fashion.
I used to think refactoring was a chore and doing it right the first time was how the coding gods did things. Although perhaps that’s how Greek gods spawned so many tragedies– Well I don’t really know how it works for other people, but I’ve come to embrace iteration. Sometimes that means a good rewrite, or at least a rearrangement.
I enjoy refactoring now. Sure, it’s not as exciting as making something fresh, and it certainly doesn’t have that rush I get from prototyping. But there is a catharsis to it. I’m more comfortable about code I’ve written all over my body, after I’ve rewritten it a second time.
When it comes to working on game UI, I try my best to follow the Principle of Least Astonishment. Yes that’s a real thing. It’s more fun to say than “user expectations”.
I would expect the TAB key to switch between text inputs. It’s amazing how quickly I get irritated with any app that doesn’t respond to the TAB key properly. It’s not working in my COOPERRATA prototype, so I need to fix that.
Unity’s UI system has an automated navigation feature, but it’s mainly for gamepads, doesn’t use TAB and breaks overall on text-inputs. Nor does it use TAB. It also leaves highlight ghosting on buttons, which is their design, but not what I’d consider expected-behaviour– in fact nearly every tutorial I read / watch suggests turning navigation automation off, but that’s not what I want either.
So I intend to modify Unity’s navigation feature. That’s a daunting task. Unity provides source code (on BitBucket) for their UI system (yep, they open-sourced that part of Unity). So I could make changes to the system directly, but maintaining my own DLL variation of the entire Unity UI is an idea that gives me nightmares. Instead I could extend some classes, that would probably be wise. I’ve poked around on that, but it also seems like a headache.
I think the route I’m going to take is to write my own overseer code that will toggle the navigation system on / off as needed (to avoid that ugly ghosting) and add some controls for text inputs specifically.
This is the kind of task that reminds me of that game development adage: The last 1% of your work takes 50% of the total time. These little details that seem mundane or simple end up consuming more effort than you expect. I’m tackling this one early on, rather than leaving it for the last 1%.
Though I’m very tempted to wait until Unity adds tabbing as a feature, but it’s been on their to-do lists for more than a year.
I have just over a week left on my supposed month-long “Prototype Jam” for COOPERRATA. I say supposed: If you’ve read my posts so far it’s evident that I’ve played hooky on the actual prototyping. Instead I’ve been laying down a foundation of UI, cloud services and a chat system. Truth be told, I’m quite pleased with my efforts. I tell myself I’ll be able to use that foundation on any game I make, but to be honest I’m pretty set on creating COOPERRATA in-full, regardless. Gameplay prototyping will just have to start after this week or so.
Today I set up a simple changelog / news website for COOPERRATA (you’re reading it, unless you’ve caught this via my G+ post), which I will also reference in the “news” tab of the game’s launcher. There’s a switch in my brain that cements any idea once I’ve registered a domain for it. So there’s that.
On that note: I’m cross-posting between the website and Google+. I do wish Google+ used Markdown (rather than its odd less-featured system) for text markup. The website itself is generated via Hugo + my templates. I’ll code a script so web-posts will automatically be indexed for the game-launcher news as well. Automating as much as I can.
Meanwhile my whiteboards have been wiped and re-filled with COOPERRATA notes. I might as well call this production development.
My work continues on COOPERRATA: the menu simulator. Sarcasm aside, I’ll start making it into an FPS relatively soon. I promise you’ll only see a few more of these UI update posts. Well… maybe a small handful.
I’ve added some “cloud” features with related online indicators. I’ve also implemented tooltips and clearer animations on my tabs.