Carmack’s App Reviews: Space Shooter
Carmack’s App Reviews are back. In his first review in
his new series of recorded videos and written posts, Facebook Reality Labs Executive Advisor and VR guru John Carmack shares his (brutally honest) feedback on Space Shooter, an arcade shooting game that recently launched on App Lab.
If you’d like to have Carmack review your Oculus Quest game or application, please complete this form.
Space Shooter
Space Shooter is at the level of many of the apps that I would review in the live sessions at Connect – an experiment / work in progress that would not have been accepted to the main store. With App Lab now live, apps like this can be distributed to anyone, so you can follow along with my commentary if you like.
Feedback can be divided into “execution feedback” that can be applied in an almost checklist manner, and “design feedback” that is much more open ended. Quality matters, and many frictional aspects can bury a great idea before it can hook users, but you can also be a flawless application that doesn’t deliver any real user value.
Execution Feedback
The splash screen on launch should be more about the game you just clicked on, not just the studio that made it. Since almost nobody made splash screen graphics at the optimal resolution for the headset screens, we have a new system feature that can automatically present it before the game engine even initializes:
https://developer.oculus.com/blog/instant-runtime-driven-splash-screens/
The UI surface is way too close to the user. In the app settings you can adjust your distance, which is necessary for grabbing the steering yoke, but it also adjusts the UI plane. Only the farthest distance is roughly OK for UI. In general, a user can comfortably look at about a 50 degree field of view panel without having to turn their neck, so interactions are best kept in that size. With curved panels you can have different “sub panes” visible, but you usually don’t want to spread a single concept over a very wide field of view, especially with a flat panel.
Using the user’s gaze direction for UI was standard in the GearVR / Cardboard world, but it is an anachronism on Quest, so you should use a controller pointer. To make the UI feel good, add a small sound and a controller haptic tick as the cursor moves over an active element to complement the visual focus change, and synchronize a visual blink with another sound and tick when the trigger is pulled. Act-on-press, not act-on-release. The controller beam should never extend further into the world than the UI panel.
The text font shows fringes at the edges of the glyph squares due to pulling in texels from neighboring glyphs. That should be fixed by leaving a completely blank “gutter” between each glyph and adjusting the texcoords. The edges of the glyphs also alias because the font texture is higher resolution than the displayed size and no mipmaps are present. There is a lot of depth to high quality text rendering; if the text is minimal, it can sometimes make sense to use a professional illustration program to produce high quality textures instead of rendering them in the game engine.
Pushing the thumbstick to the left or right should cycle options or through the help screens instead of being an action command.
During gameplay, pressing the Oculus button does pause the active gameplay elements, but window dressing like the moving Galleons continue. For a single player game, the entire world should generally freeze and background music should pause. The menu button should also pause and offer a return-to-main option.
Having an explicit “exit” option in the UI is discouraged. Users are expected to use the universal system level functionality to exit apps instead of learning a per-app option, and “exit” can be incorrectly interpreted as “exit to menu” instead of “exit game."
Sending the world spinning on death is uncomfortable. Motion sickness should not be used as feedback in a game; it lingers and doesn’t go away when you restart.
The banking of the world view when moving side to side also gets uncomfortable after a while. Using the yoke controls prepares the user for it, but using the thumbsticks makes it an issue. Reducing the amplitude and speeding the decay rate would help.
A two-hand control yoke highlights the lack of actual connection between virtual controllers. A one handed flight stick might feel better.
If you are going to have a physical cockpit modeled around the user, integrating the ship damage meter and score display into the cockpit display makes more sense than having them as floating UI elements.
On the space level, your shot models actually start inside your cockpit.
Almost everything that happens in a game should have synchronized audio and visual components – every shot, impact, and action. That obviously isn’t realistic for a space shooter, but it helps a game. In particular, wounding the enemies makes a small explosion effect, but no audio. The looping background music helps cover up how dead everything is at the moment, but you would ideally like to have the actions in the game providing a rich soundscape all by themselves, possibly augmented by smaller musical themes mixed in at key points in the gameplay. The voice reading of the help text isn’t very useful, but integrating voice more into the gameplay for warnings and action priming could be helpful.
One of the most straightforward ways to maximize the visual quality of an app is to use sufficiently high resolution textures that you don’t wind up with stretched out, blurry pixels. In VR, the user can always walk so close to a surface that it will be magnified, but you should strive to have everything near optimal resolution when the user is in the default position, and especially on UI panels. The radio buttons in the UI are far too low of resolution, and the cockpit is mostly untextured. You should be using ASTC compressed textures with mip maps.
Design Feedback
The basic idea of “take an old arcade game and put it in VR” is valid – the earliest first person shooters from Id Software were very much 2D games with a changed perspective that made them something new. However, the core game had better be very entertaining to make up for not explicitly designing to VR’s strengths.
The gameplay here can be summed up as:
You have a bounded, one dimensional range of motion and can fire streams of shots. There are inert objects (asteroids, etc) that kill you on contact and take many shots to destroy. Ship objects are similar, but also fire streams of shots at you that do partial damage. Nothing has any lateral motion.
That wouldn’t cut it on an Atari 2600 game. The VR treatment buys it a couple minutes of interest in waiting for something else to happen, but the core game is insufficient – you can just slide to an extreme edge and hold down fire to get unlimited score!
To explore the game design space, it may be worth using a non-VR environment that allows faster iteration, like a simple 2D view with sprite graphics. Classic arcade games can be expressed in a single file of high level code with the right support functionality, so modern designers have both the hindsight of history and a much more powerful experimentation platform to work with.
It feels strange to have a “space shooter” restricted to a one dimensional play field. If that is the core gameplay decision, it might work out better cast as a hovercraft, boat, or car of some sort.
A good shooter game lets a skilled player look amazing as they are skirting death and dealing destruction. With only left / right / fire commands, “looking amazing” has to involve either incredible timing precision or “reading the flow” and avoiding all the unwinnable situations coming at you rapidly. Adding some more expressive control options would help.
A first person perspective generally makes dodging gameplay worse than in a third person view, because you can’t see your own boundaries. You might help the situation with “near miss” sounds off to the right or left that help players gauge how close they were to a hazard, or “partial damage” effects on contacting the very edge.
The player / enemy gameplay from a Galaga style of game won’t translate well to a purely first person VR perspective with everything vanishing into the distance. It could work if you were at the bottom of a huge hill, where all the enemies crest over the top and come down at you, so you can see the flight patterns more clearly, or if you were moving forward inside a giant barrel structure. A “jump” mechanic might be interesting to add a little bit of another dimension to the play.
You can make an arcade game that is nothing but pure tactical behavior like Robotron, but giving the user some kind of strategic decision making ability can help. This can be as simple as the decision in Galaga to allow your ship to be captured, or even the introduction of a limited resource like smart bombs.
In general, it is better to interact with a larger number of weaker enemies that die in a gratifying way, than a small number of enemies that need to soak up a lot of damage. This can be a performance challenge. If you do have enemies that take many shots, at least make the interactions with every hit more satisfying – make the enemy model twitch and degrade, and add sounds in addition to the small hit explosions.
For an arcade style game, “notchy” levels are usually better than fine grained or continuous scales for health or damage. One, two, and three levels of things add more tension than a 100% meter.
Power ups are an important part of shooters and lets you turn up the “glory in the destruction” knob. Using a rare and awesome powerup can be more rewarding than completing a level.
Games need variation in play tempo. A steady state or monotonically increasing challenge doesn’t feel as good as bursts of danger interspersed with recovery periods. Explicit waves or levels are a tempo mechanism, as well as providing a complementary dimension to score.
There are significant tradeoffs between algorithmic enemy behavior and designer crafted behavior. You can make more awesome experiences with complete control, but you are unlikely to make and properly balance even a couple hours of hand-crafted enemy waves. If you go with designer crafted, a simple trick to stretch the value is to use mirror views of the patterns, which wind up feeling more different than you might expect. Mixing and matching macros of designed experience while ratcheting up speeds and swapping in more dangerous enemies can let you scale out the total experience time.
For anything vaguely arcade game like, having shared scoreboards will add value. Having daily and weekly resets, as well as the all-time-high (since last behavior changing update) list will allow more people to experience being on them. Implementing notifications for when a friend passes your spot can add a lot of engagement. It is completely irrational, but adding two or three zeros to the score makes people happier. Waves are small-integers, but scores are in thousands.