Blog

Post PAX Prime 2014

Post PAX

A ton of attendees dropped by to play the game or even to just say hello. Space sim fans and newbies alike gave Starfighter a shot and the response was mostly positive. Lines are a necessary evil, but it's always great to hear conversations about simulation games break out among strangers, or even the occasional, "DIVE! DIVE! DIVE!" shout echoed in line.

The game also won its first award ever, a Golden Sushi, from BigSushiFM. Thank you!

Bill Morrison, one of the mission designers on the X-Wing and TIE-Fighter series, stopped by to say hi.

Bill Morrison, one of the mission designers on the X-Wing and TIE-Fighter series, stopped by to say hi.

The MEGABOOTH

We've been part of the Indie MEGABOOTH for each of Starfighter's showings, and we're always blown away at the support we receive. A ton of great people volunteer their time to make sure the exhibitors themselves have a smooth experience. That's simply amazing to me. Thanks!

Combined with our fellow exhibitors, it reminded me why this industry can be so cool. It's just a bunch of awesome, talented people kicking it Bill & Ted style and being excellent to each other. 

 

Stuff To Fix

I generally use trade shows for focus testing first and for marketing second. When you have this many people play your game, you learn what to fix pretty quickly. Here are some of the major points:

Immediate Action Items

  1. Impact and Damage Readability - Some players reported having a hard time recognizing when they were getting hit.
    1. Some players offered feedback that the afterburner rumble was too high and maybe hiding projectile impacts. I'm going to lower the large motor rumble values and shift shield impacts over to the smaller motor.
    2. Screen space impact overlays seems like a hard problem in VR, so I'm going to find different ways to show direction and impact events without cluttering up the center of the screen
  2. Team Readability - I knew this would be a problem when I made the player's team red to match the rest of the "I'm the bad guy" tone of the theme and cockpit instrumentation. After a lot of consideration, I still believe in this call, so I'm going to find ways to teach it better. The good news is, once this was understood, players rarely got confused again.
    1. I chose to teach the players this information at the wrong time. I flashed tutorial text that said, "YOU ARE RED. ENEMIES ARE BLUE," when the player exited warp into the combat encounter. But in reality, this needed to be taught earlier, almost immediately.
    2. Most players that had trouble with this immediately clicked with the concept when you framed the teaching as "Red vs. Blue" instead of "Bad Guy and Good Guy." I'm going to try to find ways to frame this in a way that's immediately understandable.
  3. Performance - Starfighter wasn't hitting 75hz in VR unless it was in an ideal case. This hampered the VR experience, even though most players had no idea.
    1. I'm going to try things like using Unity's mesh combination commands on ideal areas like asteroid fields
    2. I'm noticing that projectiles aren't batching. This is probably something I'm doing wrong in ES so I'm going to read up on their documentation. The Keep Talking and Nobody Explodes! crew gave me some great advice on this. Thanks!
    3. The skybox is simple but pretty dense. I can save ES from drawing a bunch of polygons by breaking up the mesh, or even rendering the sucker out to a super high-resolution cubemap texture since I have plenty of texture memory to spare.
  4. Targeting - Starfighter auto-targets the nearest enemy light craft when your current target dies, but the concept of targeting is weird to some new players. This was never specifically taught in the PAX demo, but it's still something I'm worried about.
    1. I can bring back the concept of auto-targeting, using a scoring system to take a best guess at what you want to target based on your crosshair.
      1. Guessing player's intent is often super tricky and in the end, only noticeable when it isn't working correctly.
    2. Teach this better. The "real" tutorial has a section specifically on targeting that lets the player move at their own pace. I'm going to focus on this and do some more testing with it.

There's a lot more on my list, but this is the major work that lies ahead.

You Are Here

The Never-Ending Crusade To Orient The Player

As soon as you allow roll in 3D space, you start requiring more brain cycles with every task you ask of the player. In particular, you're adding mechanical interest to each of the following tasks:

  1. Tracking targets
  2. Avoiding Obstacles in Local Space
  3. Knowing your orientation and position at a solar system level

I mainly want to talk about #3 in this post, since that is what I have been working on most recently. Some games (namely Crimson Skies: High Road to Revenge, Halo: Reach) bypass this problem all together by disallowing roll, but that's not a method of player expression I was willing to give up.

You Are Here

In Starfighter, you can warp your fleet around to different landmarks in a solar system. A landmark may be anything including a belt, a planet, a jump node, or even a nebula cloud. The goal is to let the player make both planned and emergency decisions to jump to any landmark without looking at a map.

Credit: James Clayton / Ubisoft Quickly switching where you perceive yourself to be is hard, as many trees in Far Cry 2 have discovered.

Credit: James Clayton / Ubisoft

Quickly switching where you perceive yourself to be is hard, as many trees in Far Cry 2 have discovered.

Knowing what's going on locally and what's going on system-wide are two almost mutually-exclusive modes of thought. A player who has just taken shield and hull damage is generally not thinking about aiming themselves at a jump node to escape, they are thinking about shaking the attacker. Once they solve the survival task they then switch spatial perception to the solar system.

And their brains start from scratch every time this happens. Does this problem sound familiar?

So you need to help them make the decision of where to jump as quickly as possible. This is helped by abstracting out your solar system design and using the art to complement it.

 

Skybox Design

Baked skybox vertices, with the focal point of the skybox facing +Z

Baked skybox vertices, with the focal point of the skybox facing +Z

The old skyboxes were gradients mapped to spheres that simulated a glow coming from the solar system's star. It looked pretty cool and it partially helped orientation since you always knew where the star was, but that wasn't enough. Knowing where the star was gave you no hints about where any other landmarks would be as you turned toward it. Even if most landmarks fell along similar orbital planes, until you saw 2 or more of them, you would be in the dark.

After reading Simon Schreibt's articles on the Homeworld skyboxes and doing more research, I switched over to a manual approach for creating Starfighter's skyboxes. Later, Travis Baldree showed me how I could bake painted textures into the vertex data using almost any modern modeler. This is beneficial because it allows me to color correct the skybox before it is baked to vertices.

Each background is constructed to have a focal point along the positive Z axis. This is where the light from in the skybox/galaxy painting comes from. It's where the point of interest is. It's also where the horizon sits. 

The focal point orients you forward, and the horizon tells you which way is up. Starfighter uses this concept fully, having different color hues for each side of the horizon line. other times it even suggests sky and terrain (because why not?). 

The skybox from above, with the horizon helping communicate where the average orbital plane sits. This works from every landmark in the system.

The skybox from above, with the horizon helping communicate where the average orbital plane sits. This works from every landmark in the system.

Each improvement to the skybox on it is own is not amazing, but we're trying to scattershot as much information to the player as possible whenever they change spatial modes. This all adds up!

 

Landmark Rules

The player is not the king of Starfighter's jungle, but they are asked to take on the role of predator nonetheless. One of the most meaningful ways to help the player feel like a predator is to position them like one. This concept is used to great effect in many games at a variety of scopes.

Starfighter employs these same techniques, rewarding the player for positioning themselves to ambush (attacking from below) and positioning themselves to stalk (attacking from above). Gates are always positioned above the average orbital plane, so when players enter a new system, they are given an overhead view of the system to plan their next jump. Their prey, smaller fleets and miners (soon), are busy below at belts and planets. 

Jump gates are placed above the average orbital plane, and are always the furthest landmarks from the center of the solar system. This makes them excellent vantage points, and it's a view you get every time you enter a new area.

Jump gates are placed above the average orbital plane, and are always the furthest landmarks from the center of the solar system. This makes them excellent vantage points, and it's a view you get every time you enter a new area.

Rules like this also make orientation easier, because one knows that looking "up" will always lead them to the jump gates. And if your skybox looks like something familiar, such as a dry desert plain, you piece your orientation together even faster. While the player is on the average orbital plane (at a belt, for example), traffic between jump gates feels like airplanes flying overhead, another point of reference any player can relate to.

These rules are abstract and very "gamey", but they are necessary!

 

Why Vertices?

As described in Simon's article, vertex coloring excels at gradients. Seeing filtered pixels on skyboxes doesn't fit with Starfighter's flat-shaded art style at all, and creating skyboxes that are high enough resolution to fix that will take forever.

One can pick out the hexes/vertices, but that doesn't bug me. If Starfighter weren't flat-shaded it might!

Telling A Story

The relatively low-resolution spheres feel very much like painting thumbnails (which are FAST to create), and thumbnail-detail is just fine because it can still tell a story in a way the old gradient/procedural skyboxes couldn't.

This makes each system more memorable. Later, a player may say, "I have to return to the junction system with the creepy blue cloud columns," and not even need to remember its name! This would never happen before!

Homeworld 2 skyboxes. Credit: Relic/Cunningham and Walter-NEST for extraction/packaging.

Homeworld 2 skyboxes. Credit: Relic/Cunningham and Walter-NEST for extraction/packaging.

The grand masters of this were (of course) Rob Cunningham and his crew. Each level in Homeworld 1/2 were carefully crafted to make you ask questions about where you were as much as impress you with their composition. They are oddly surreal but they work.

This happens in other games (notably Halo, with the iconic ringworld hanging in the skybox), but Cunningham and his team managed to tell an incredible variety of stories throughout the campaign that still hasn't been topped.

Starfighter's don't hold a candle to any of these, but lessons have been learned!

 

May Update

nebulae02.jpg

Press

A few people have kindly written articles about a recent build of Enemy Starfighter. Check them out!

And a few others have streamed or uploaded some footage of the game! 

Thanks, everyone!

PAX

PAX East was awesome. If you stopped by to play or say hi, thanks! It's always fun to talk with attendees. It's also an incredibly useful focus test. I scrutinize each and every playthrough, watching how players respond to everything from controls to target readability. Needless to say, I learn a lot from each person!

Big thanks to the Indie MEGABOOTH, our generous sponsors, and the PAX Enforcers. You all rock, and I have no idea what we would do without you!

 

Progress

Even though the first batch of press builds went out only a few weeks ago, a lot of progress has been made on Starfighter since.

  • Federation fleets use a refined hybrid scripted/dynamic group objectives to move around the solar system. This system is a simple version of what we used on Reach for controlling squad movement. I'm (still) a huge believer in Bungie's approach to building combat encounters. If you want more info, check out Damian Isla and Max Dyckhoff's GDC slides.
  • Units can earn XP and level up. This is a crucial element of creating persistence and making you grow attached to your fleet. This will be hitting the test builds in a few days.
  • Lots of AI fixes with steering, weapon usage, solar system movement, and order response.
  • Asteroid fields use a better type of random generation than I was using before. This lets me create much larger fields, but right now it's at the cost of performance. I'm working on this!

 

Roadmap

  • Push the progression system, iterate on the best ways to give out XP, and determine the best way to let players level up their fleets.
  • Now that the solar system movement code is in a good spot, make this more dynamic by (re)introducing other inhabitants to the systems like traffic and mining ops.

 

Last Stand vs. Campaign

The only mode available in the public build is Last Stand. It is a wonderful testing ground for campaign features such as the bounty system and fleet movement. I don't, however, have some super secret campaign file that is floating around in my source depot.

What does exist is a stable of features at various stages of polish that I am dropping into Last Stand to push the gameplay in the desired direction. This is all done in response to feedback I get from my friends and testers.

Eventually, Last Stand will evolve into the campaign. It's not there yet, but it will be soon!

By not taking the kitchen-sink approach to adding features, I can keep Starfighter laser-focused and make sure that everything it does try to do, it does pretty well. 

Greetings, Starfighters

What's Shaking?

It's been a busy few months and too long since I've updated the dev blog, so here's what is happening in the world of Enemy Starfighter. 

  • Solar systems are now "real" and not simply skyboxes as they were before
    • Landmarks such as planets, moons, belts, and nebulae are generated outward from the star based on a simple set of rules
  • You can warp the Harbinger Fleet to any known landmark in the solar system (ANIMATED)
  • ...but the same applies to enemy fleets, some of which respond to your last known location or destination
  • Factions have been implemented, and each faction has its own set of traits that are applied to the unit
    • Traits modify unit stats or enable alternate weapons, making every weapon or ship I create stretch further
    • Some factions are always present in a solar system, such as Lane Marshals that run overwatch on jump nodes
    • Others factions are determined during solar system generation
  • Lots of bug fixing and polish on other systems
  • After a lot of iteration and pain, the game's overall direction has been focused even further

Grand Theft Starfighter

Watching, waiting.

Battle-planning has been replaced with hunting and hiding. Before, each battle was fed to you via a simple mission generator and menu. It wasn't dynamic, lacked tangible persistence, and it certainly didn't fulfill the fantasy of being a starfighter harassing the enemy deep in their territory. I can go into this in detail if people want, but I won't bore you with that here.

Now, when you enter a system you are told what flagship to destroy and are given free rein to hunt and deal with it as you see fit. Do you build up your forces and take out the flagship head on? Do you misdirect their escorts to a bogus landmark and then jump the vulnerable capital with a small group of beam frigates, knowing full well that you will lose them?

Once combat begins, gameplay is structured very much like a police chase with your fleet at the center of it. If you've ever played GTA or if you've ever done small-scale skirmishes in a game like EVE, you should have an idea of what to expect. In fact, a lot of what makes this game tick comes from countless hours I've spent running around in EVE's Syndicate region in an interceptor.

While a few of these systems are super rough, they are at least functional. They mainly need passes on readability and polish, which will happen soon.

Chatty Pilots

If you are watching a stream and go, "Damn these fighters are chatty!" you would be right! It's mostly because I use their VO to help me debug what they're doing. If they say a certain phrase at the right time, I know the AI is working correctly. This will be appropriately tuned and varied for the final game, I promise!

Escape Pods

pod_kill.gif

One thing missing from the game was a satisfying currency reward loop for killing fighters. The tumble alone felt good and you earned points for it, but a new layer has been added: the escape pod.

A majority of your currency is acquired from killing the crew of downed vessels. If you have an autoturret, it happens automatically. As a capital goes down, the famous loot-piñata situation occurs as the crew abandons ship.

It's one of the first things I've put in the game that makes people feel like a villain. Several people reported feeling conflicted about it. Good!

The Future

Here's the roadmap for the next month:

  • Iterate on the fleet AI and solar-system mechanics
  • Pass on the cockpit art (it is woefully out of date, and I know more about what my requirements are)
  • Create new models for units that share them (for example, the Federation torpedo frigate uses the pulse cannon model). It was done this way to get functionality working before worrying about the art
  • Start capturing footage for a new trailer/gameplay video

In the meantime, if you'd like to get a closer look at the goings-on with the game, keep an eye on the Twitch.tv channel. I also post tiny dev updates and images on Twitter.

Aleksander Rostov's Art

Aleksander Rostov was sketching and watching the dev stream in the background. As we were winding down, he posted this:

Be sure to check out his tumblr for more incredible art! 

11.10.13 Update

Control Freak

I've been spending a lot of time (probably too much) working on the game's input and controller support. Unity's input manager does a swell job for simple projects, but it doesn't let you do a few key things: 

  1. Build and load controller presets. I want to let the player say, "I'm playing with the mouse and keyboard," or "I'm playing with a Logitech gamepad," and have the game set up the best possible control scheme with no further effort.
  2. Edit subtle control elements like dead zones on the fly. Normally this is not important, but it is in any sort of sim.

There are cool 3rd party libraries that will help you with these problems, namely Rebind and cInput, but neither did what I needed without a lot of modification.  So I wrote a system that integrates with the command console.

 Config files are read from a folder, and will set up your controls based on a simple syntax:

controls.action.bind +weapon_fire space mouse0 joy1button0

If you've ever written configs for an id engine, this should look familiar. You can even write aliases that enter console commands and bind them to buttons, but I imagine this is more useful for debugging.

If this stuff makes you go cross-eyed, have no fear. Most players will never have to touch a config file. This is there for those with crazier control hardware or those that want to have the freedom to rebind whatever they want. 

Control debugger shows what actions are down, where my analog axes ACTUALLY are, and the final input values after the game has corrected them.

What You See Is What You Get

Games are interactive, and your input devices are the glue between them and your players. So draw your input on screen. I don't care how simple your game is, you will learn a lot about how it handles by being able to visualize what's going on. Don't be lazy. Your game will feel better because of it.

Once I did this, I learned there were deadzone bugs in the pitch/yaw control. I learned that my digital inputs hooked up to axes were overriding input when you let off the stick, making re-centering feel sluggish.  I had never drawn the mouse steering circle/deadzone, but when I did I noticed that long ago it had been written to be configured by absolute pixel size instead of relative screen size.

For a space sim, Enemy Starfighter is on the super lean side of necessary controls and even then, seeing this data helped out with the feel immensely.

 "Draw debug info," should not need to be said, but it's hard to be diligent about writing this code. It takes a decent amount time to implement a good visualization for the data you're trying to present, time that could be spent elsewhere. But with critical systems, it's almost impossible to have too much good information. 

10.25.13 Update

The "shop" and the upgrade system.

Press

A few outlets have been kind enough to give Enemy Starfighter a shout out! Have a look!

Thanks, everyone!

 

Twitch.TV

Brendon at BlendoGames gave me the idea to start streaming some of my dev work, so I gave it a shot. It turned out pretty well. There is a Marauder Interactive channel over at Twitch, so follow it if you want to get notified when it goes live. 

 

Dev Work

I've been working on a lot of small stuff recently: Things like tweaking AI behaviors for almost every ship, or working on the map UI so that subsystem selection is much cleaner.

I've also cleaned up one of my test scripts and turned it into sort of a last-stand mode which turned out pretty fun. I'm not sure how I'll integrate that into the game yet, but it made me polish a few underlying systems like my spawn points which is awesome!

 

VR Lessons Learned

PAX was amazing, and nothing helps you make your game better than a 100+ player focus test. Some players knew what to expect, others had no idea about the game beforehand, only seeing a chance to try the Oculus Rift. 

 I promised I'd write up an article about some of the techniques I used and things I learned. Most of this is purely anecdotal, but hopefully some people find it useful.

Lesson: Avatar Context Really Is Important

We would ask people how they felt after almost every playtest, mostly because I was terrified that all the spinning and swirling of the game's core combat cycle would be a one-way ticket to barfsville. We even had a trash can conveniently nearby!

It was not a problem for most people. Some players that seemed fine probably experienced that feeling of being "off" later, so I won't pretend we had anywhere near a 100% "success" rate for the VR experience.

But all VR experiences are not created equal. My wife absolutely cannot deal with the Tuscany demo or any first person shooter. But put her in the cockpit of a vehicle and she's fine. Before the Rift was released, we all figured that games where you're sitting down would fare pretty well. This means racing games, flight simulators, and the like. Luckily, Enemy Starfighter falls into this category.

Why? I'm not sure. It may be how movement is handled. FPS movement has been super unrealistic as far back as I can remember, so that probably causes your brain to be challenged when it's fully immersed in the VR experience. You're not expecting to accelerate or decelerate so fast, gently sliding to a stop. All those things that make certain engines feel great for FPSs on a monitor are now your enemy in VR.

I believe that your brain is good at wiring itself to the context of whatever's going on in the headset. It wants to play along! But with that comes certain preconceptions of how movement is supposed to look and feel.  Just don't violate those preconceptions and you'll be fine.

Lesson: Floating UI Is OK...

vr_real_hud.jpg

 ...if you take the time to respect the player's focus. Real fighter pilot telemetry is projected out to infinity. This is incredibly important! It means that your eyes don't constantly have to juggle focus between your target and the UI.

In some of my initial tests with the Rift, this actually contributed to my own VR sickness. My HUD consisted of text and mesh objects that floated above the dash in your ship like you see in so many modern sci-fi movies. But when you wanted to aim at the lead reticle, your eyes would constantly fight to resolve the depth of both the HUD element and the target ship. It felt awful.

So when I went back to implement Rift support for PAX, I did some research. There was a post on the Oculus developer forums stating that humans can't perceive depth (while stationary) past 800m or so. 

So I ended creating text labels (using nGUI), that are projected out into space 2000m from the camera. Then I scaled them up so they would be an appropriate size on screen. Finally, using a shader, they are told to render on top of everything else.

 This actually worked really well. It still becomes a problem when a target ship is REALLY close to your own, but at that point it's so much larger than the HUD element that there's no real fighting going on. The target ship itself just wins focus.

So if you have any sort of floating text or HUD, don't skimp on making this feel correct. It will probably require extra work that you don't want to do, but the results will make for happier players. 

This is the player's fighter, and those HUD elements are about 2km out from the cockpit camera.

This is the player's fighter, and those HUD elements are about 2km out from the cockpit camera.

Lesson: You CAN Manipulate The Camera

There is subtle screen shake on almost every action in the Oculus Rift demo. Shooting, boosting, getting hit, spinning out, and nearby explosions all slightly modify the camera's look vector.

Not a single person mentioned the screen shake. I won't kid myself though. It could have been what contributed to the couple of people that felt off, but I can't be certain unless I have them back for more rigorous testing.

The shake itself is not heavy. Every impulse is less than 0.4 degrees and decays over time. I also do not touch the camera's position during screen shake, only rotation (and even then I leave the roll axis alone). 

I DO manipulate the position of the head based on your ship's current acceleration (angular and linear), but this movement is heavily smoothed.

This transition is surprisingly easy on people's VR experience, even if they're upside down.

This transition is surprisingly easy on people's VR experience, even if they're upside down.

Moving in and out of the map mode controls the camera look vector as well, although only for a second or two. Surprisingly, even transitions like this seem to be fine, if a little fear-inducing.

So what gives? 

In addition to these transitions being short, I think it has to do with the fact that I never fully control the player's look vector. I never presume to completely lock the camera in a direction. When I transform a camera during shake or transitions, I always let the player use his head movement as an offset.

 The TF2 death camera is an example that fully controlled your view, and I can totally see why that would be weird. But in Enemy Starfighter, if you transition to the tactical map and are looking left out of the ship's cockpit, you are looking in that same direction offset from the tactical map camera as it pulls away from your fighter. 

Closing

The main thing I learned is that FPSs and cockpit simulators truly are different beasts in terms of what you can get away with in VR. Don't be afraid to experiment, test, and iterate. As I was working, I knew I had built up a tolerance to a lot of what makes VR seem weird, so I was extremely terrified as I did my first few tests with friends and family. Thankfully, it all worked out.

I've also received some really good feedback from a few people that have heavily worked with VR, and will be iterating on this experience to make it better.

Thanks to everyone who stopped by the booth at PAX!

 

Seeing Double, Coming in Hot...

We have something special planned for those that will be at PAX. Over the last two weeks Oculus Rift support has been integrated into Enemy Starfighter. Quite a bit of work has gone into making this experience work well in VR, and we'll be continuing to improve it before and after the show. 

We're still not sure how deep this support is going to go in the final game, but now that you can swap between regular and Rift-enabled modes, it should be easier to keep it integrated moving forward.

The following is a Rift-enabled demo video during some testing on a debug map. Apologies for the 720p resolution, as YouTube doesn't like it when I upload the native 800p video. Those 80 pixels matter so much on this hardware! Next time I'll try recording at 1080p.

 

It's been a really interesting design exercise too, because it forces me to analyze and clean up the UI in many ways. It's amazing what you take for granted when you count on even a full 720p (at least) screen. I think the whole game has benefited from this pass, because everything got a whole lot cleaner. Constraints are good! 

There's still a lot to fix, namely the popping looping sounds that I'm getting on exterior fighter engines (it's not the clip contents). My OCD is kicking in hard on that bug so there's a good chance it will be fixed for PAX. 

In the meantime, get ready to dogfight at PAX! Now to get back to work!

Fun fact: We looked into Enemy Starfighter air-sickness bags for the show.

Edit: Popping has been fixed!

PAX Prime

Our PAX Prime 2013 page is now live! We will be bringing a playable build of Enemy Starfighter thanks to the team at the Indie MEGABOOTH!  Check us out in the minibooth area on Sunday, September 1st and Monday, September 2nd

The indie lineup for this show is absolutely incredible, and we're super excited to be a part of this event. 

Peter Wartman's Art

One of the best parts of making this game is getting to meet all sorts of talented people. I logged into SomethingAwful and a message was waiting from me from Peter Wartman:

I needed to do some warm up sketches today, and, hey, new screenshot in the Enemy Starfighter thread.
What can I say, I really liked the shape of this thing.

 

Peter used one of the game's screenshots to do a warmup sketch/overpaint.

Peter used one of the game's screenshots to do a warmup sketch/overpaint.

It's not "official" Enemy Starfighter art, but it's officially awesome. Make sure you check out his tumblr, Shipwreck Planet, for more amazing ship concepts and comic art. 

New Website, New Screenshots

It's high time I cleaned this place up!

I dropped WordPress mainly because 99% of what it does, I don't need. This hosting automatically looks fine and is easy to set up and maintain, meaning I can spend more time working on the game (and boy there's still a lot to go).

Speaking of, it turns out there's a lot of work involved in making a space sim, even one that's lighter on the simulation part of things. But things have been quite busy here, and a lot of work has been done since the last YouTube footage was posted. I'm excited to show everyone what I've been working on.

In the meantime, check out the new screenshots.

 

blogpost.jpg