Category: programming

(Re) Introducing Galactic Night

My vow to stop making EV-likes has had mixed results. Here, I’ll discuss some of the more interesting aspects of a recent EV-Like, Galactic Night.

Perspective on perspectives

While I did make a serious run at doing a vehicle game in Godot, it was hard to get around just how excellent the affordances of what I’d already built were, and what was lacking in Godot 3. But it didn’t start there. It started with an observation:

First Let’s Play google gives you for “EV Nova.” I haven’t listened to the whole thing, so I can’t vouch for it. But it’s got footage of the game.

Ships in EV Nova (and MPEVMVP, for that matter) are sprites rendered from 3d models. They are rendered with perspective so that when the front of a ship faces the screen, it appears larger than the back. It’s subtle on some ships, obvious on others.

Perspective camera isn’t the norm for sprite games. Most games with pre-rendered sprites use an isometric camera; here’s Starcraft as an example:

First result for broodwar gameplay. The Terran Siege Tanks are the best example of isometry.

For games where the units are in a rich world with lots of points of reference, rendering them in perspective might look wonky. Too much perspective might look wonky under any circumstances! However, the decision to use perspective in the sparse world of Nova lends the ships a sense of scale.

2.5d games that use a full 3d world instead of sprites tend to either use a perspective or isometric camera. It’s easy to implement either in Godot (and other engines) by changing the camera’s mode. But I was curious: could I implement something with a vertex shader that would deform a mesh such that it appeared to have perspective, even while rendered in an isometric view? Perspective, I should note, not truly relative to the camera, but relative to an imaginary camera ‘rendering’ the imaginary ‘sprite’?

This is difficult to convey with words, so I built a demo:

What’s interesting about this, at least to me, is how difficult it is to notice what’s going on. Your brain seems to happily accept the very unnatural perspective. At least mine does. But if you look closely, you can see that no matter where the spaceship (and thus actual iso camera) move, the spinning cubes maintain their fixed perspective, just like sprites in an old school video game.

Flying around was fun, I wanted to do more stuff. It got out of hand. It’s a whole game now.

More Ship Shader Fun

Using a 3d pipeline offered the possibility of using some nice 3d features, exploiting the fact that the textures and effects were in-engine rather than an external pipeline. Nova has engine glows and weapon glows; I implemented those too.

Nova also has an (unused) feature where you can stain your ship a different color. I wanted to try something similar, but nicer:

You can check out the full ship shader here. Note that in GD4 you can split shaders into multiple files, so the important parts are the perspective transform here, and the color swap logic here.

Union Bytes Painter allows for multiple texture layers, so it’s easy-ish to make separate textures for lights, engines, weapons, paint, and a base. It’s a little clunky for exporting though – I need to show/hide layers and export a few times. Still miles better than the Blender workflow I used while working on Flythrough.Space.

Flat Space

I wanted to create a nice set of planets and nail the EV Nova look, so I followed tradition and picked up the venerable LunarCell, which was also used to render the planets for EV Nova. This creates (gorgeous) 2d planet sprites:

Only problem? Lunar Cell doesn’t create masks, just planets on a black background. Solution? This remarkably simple shader:

https://github.com/EamonnMR/galactic-night/blob/main/entities/spobs/Spob.gdshader

You’ll notice though that that’s a 2d shader, and the game is 3d. That’s the neat part – the background is a 2d canvas! We use this class to make sure the sprite in 2d space tracks the correct position in 2.5d space:

https://github.com/EamonnMR/galactic-night/blob/main/component/FollowerSprite.gd

The background itself is basically the same shader I used in Survive Space but with additional special effects you can cue up to make hyperspace more exciting:

I wanted to visually represent folding space, and the looped background made for a unique opportunity to do it. The shader is of course just dropping specific images (Screaming Brain’s awesome Nebula backgrounds) on a couple of layers, but it would look better looped if I did something with Perlin noise.

Procedural Generation

Flythrough.Space used a handmade universe I originally drew on graph paper. While charming, that took a whole lot of work for very little gain at the end of the day. For MPEVMVP I used universe maps generated by Mag Steel Glass’s spreadsheet. Which is fine by all accounts, but I wanted the player to be able to generate new universes on the fly. That’s where I ran into my new best friend: Delauny Triangulation.

Compare:

(source: https://preterhuman.net/software/escape-velocity-macintosh/)

(wikipedia)

Ok, you need to look a bit closely, but in both cases, you’ve got a point cloud that is stitched up by non-overlapping lines. So to generate an EV map, because there’s a library function for that all you need to do is feed it a set of points and get your EV map’s hyperlanes!

https://github.com/EamonnMR/SurviveSpace/blob/main/procgen/Procgen.gd#L87

That same strategy carried over to Galactic Night, with some modifications, namely the division of space into quadrants to provide a difficulty curve, and the separation of growing biomes from growing faction influence. In Valheim, the game I imitated most on Survive Space, all three are effectively the same; a biome is a difficulty level is a spawn location for various monsters. In Galactic Night, spawns can depend on biome (for asteroid types) faction (for where to spawn enemies or allies) and quadrant (more difficult NPCs.)

Codex

The codex window loads up a folder tree of bbcode (weirdly, Godot’s rich text boxes support this) files and displays them. Item fluff that would usually be embedded in the interface in an EV goes here, a much more conventional placement for a modern game. I never did get around to writing a system for unlocking entries.

Retrospective

I’m proud of the technology and writing that went into Galactic Night, and some of it will certainly be recycled for future projects. I’d be happy if people get any use out of the code or design concepts tested out. I’ll close out with some final thoughts on how the project went.

I think the perspective looked really good, but some people definitely found it jarring. In future projects, it should definitely be an optional feature.

Doing the textures in Union Bytes painter became a slog. Small UI issues compounded over the course of several objects, and it stopped being fun.

Upgrading from GD3 to GD4 mid project was a big hiccup, but ultimately worth it because the syntax of GDscript is far nicer.

Though the procedural universe was really fun to tweak and play with, I don’t think it provided enough stuff for an exploration focused game. Games like Minecraft and Valheim exploit the inherent human desire to play around in a virtual space, and an EV map doesn’t really provide that; in a game like this the contours of the explored world are unique spaceships you find, well written place descriptions, missions, graphics, and the like. I never found a way to work in that level of diversity. Also, I never found an effective way to hint to players that, for example, getting lostech will allow them to increase their tech level and make more options available. Sure, it’s there in the manual, but who’s gonna read that! The upshot was that it felt like a big empty map with nothing particularly interesting going on in it, and no motivation to strike out and try to do stuff. Oh well.

Dependency Injection (like pytest fixtures) with a Python decorator

If you’ve used Pytest, you’ll notice a neat little pattern. If you want a particular fixture, you just ask for it, seriously, check out the docs:

@pytest.fixture
def fruit_bowl():
    return [Fruit("apple"), Fruit("banana")]


def test_fruit_salad(fruit_bowl):
    # Act
    fruit_salad = FruitSalad(*fruit_bowl)

test_fruit_salad gets called when you run tests, and it will automatically pass the result of fruit bowl to test_fruit_salad. This pretty much blew my mind when I first saw it.

The following decorator helps you achieve something similar with your own functions. It lets you do something like this.

@opt_in_args
def request_a(foo: str, *, a: int):
    print(f"Foo is {foo}, a is {a}")

@opt_in_args
def request_b(*, b: str):
    print(f"b is: {b}")

@opt_in_args
def request_both(*, b: str, a: int):
    print(f"b is: {b}, a is: {a}")

request_a("Blarg")
request_b()
request_both()

Note that the * args just mean “everything after this is a keyword argument only”, it helps guard against accidentally passing in bad kwargs and you should always use it, but the above program will work the same without it. The output of the program looks like this:

Foo is Blarg, a is 123
b is: foobar
b is: foobar, a is: 123

First let’s look at the implementation of the decorator:

import inspect

def opt_in_args(func):
    def wrapper(*args, **kwargs):
        signature = inspect.signature(func)
        opted_in = {}
        optional_kwargs = {
            "a": 123,
            "b": "foobar",
        }
        for kwarg, value in optional_kwargs.items():
            if kwarg in signature.parameters:
                assert signature.parameters[kwarg].annotation == type(value)
                opted_in[kwarg] = value
        return func(*args, **kwargs, **opted_in)
    return wrapper

Let’s look at a few specific lines to illuminate what it’s doing:

def opt_in_args(func):
    def wrapper(*args, **kwargs):

This is standard decorator magic. The outer function has the function in-scope, the wrapper is (because we return it from the decorator) what actually gets called in place of the wrapped function, so we capture *args and *kwargs so we can pass them along.

signature = inspect.signature(func)

Note that we imported inspect at the top of the module. Inspect lets you introspect on python functions, and in this case we use it to grab the signature. signature.paremeters will now have a key for each parameter the function accepts; we can now write any code we like based on the params.

        optional_kwargs = {
            "a": 123,
            "b": "foobar",
        }
        for kwarg, value in optional_kwargs.items():
            if kwarg in signature.parameters:

This approach is totally optional. There are any number of ways you can enumerate the optional kwargs. You can make another decorator and supply functions which are only called if they’re requested (I think pytest fixtures must be doing something like this) or you can have a bunch of ifs to decide what to instantiate and put in.

                assert signature.parameters[kwarg].annotation == type(value)

This I just put in there to show one way you could enforce typing on the keyword arguments. This is of course also optional; you could write your decorator to only care about the name by removing this line.

                opted_in[kwarg] = value
        return func(*args, **kwargs, **opted_in)

We create a dictionary called opted_in and populate it with the additional kwargs we want to pass. The final line of the wrapper function calls the wrapped function with the args and kwargs the caller sent, unmodified, and finally with the opted_in args the function asked for in its signature.

For such a slick effect, this is a surprisingly easy decorator; decorator magic often is.

Making a Hovertank level: Godot map editing

(Updated to reflect that this has been released! https://github.com/EamonnMR/hovertank-22/)

Hovertank is an honest attempt to bet big open 3d environments with AI agents running around working in Godot, using HTerrain and Godot Detour. I hope this is helpful for anyone who wants to make something similar in the future.

See also: https://hterrain-plugin.readthedocs.io/en/latest/

Set up terrain nodes

Create a new inherited scene from the “world” scene.

Add an HTerrain element to your level. Make sure it’s collision layers are 1 and 8.

Create a data directory in the levels folder

Apply a tileset to your HTerrain by dragging tileset.tres into the texture set slot, or making a new one from scratch.

Edit the terrain to your heart’s content using the generator and the tools.

Bake navmesh

You’ll need to repeat the next steps each time you edit the terrain mesh

From the “Terrain” menu up top, select “Generate mesh (heavy)” and select an LOD of 4. At least that’s what I’ve been using.

It will create a node called “HTerrain_fullmesh.” This is the node that the pathfinding library uses to actually determine where AIs can go. Hide this mesh; if you need to see the navmesh turn on “visible collision shapes” and you’ll see it (and it may lag real bad!)

Note that the flattened areas have nice clean navigation, but the more sloped areas don’t. You can use the flatten tool to cut paths across the map. Make sure you enable “pick” on it, it’s much nicer that way.

Place Entities

The prefabs folder has enemies with preconfigured weapons you can just drop right into the scene. You’ll want to drag them a bit closer to the ground though.

You can also place buildings this way. Careful not to accidentally parent stuff to random entities you’ve already placed – entities in Hovertank expect to be parented to the world.

You can set up objectives by adding the “ObjectiveMarker” component to an entity.

When all of the entities with objective markers are destroyed, the player has won the level. You can add the objective marker to any enemy or building.

The incursion spawner will spawn the entity you provide in “spawn” whenever there’s an incursion with the selected severity. Put one of the monsters in there by dragging its tscn file in to the spawn field (only monster at time of writing is our friend Kochab) (Incursions were removed, but you can see how it worked in older commits — Ed)

Add your level to the list

Add an entry to the big literal with all of the levels pointing to your level’s TSCN file, give it a name and a description, and it should show up in the dropdown in the main menu.

Practical Godot Networking: MPEVMVP technical discussion

Godot’s High Level Networking tutorial (and book chapter) do a great job of explaining a peer-to-peer networking setup. However, many games want to be server-authoritative, and to set up a multi-area game, you sort of need to. Luckily, you can use the same primitives to build a server/client game. This is just sort of a brain dump of my notes that may be helpful in navigating the MPEVMVP source. Feel free to post any questions you have about it; I love to talk about this stuff.

The technical requirements that deviate from the basic tutorial they hand out are as follows:

  • Server-authoritative client/server game
  • Multiple levels that players can switch between
  • Players are able to join a match in progress

In case you haven’t tried it, the project is here: https://github.com/eamonnmr/mpevmvp. The gameplay is similar to Asteroids (and, well, similar to Flythrough.Space): it uses RigidBodies to simulate movement, you can shoot other players to force them to respawn, and you can press “J” to initiate a hyperjump after you’ve pressed “m” to select a star system from the map.

Godot’s Networking Golden Rule

A remote call (rpc, rset) is going to be called on the remote node with the same node path. That includes name of the node, the name of the parent, etc, all the way to the root node. You can set a child node’s name with set_name but if a similarly named child already exists, an @number will be added to your node. This is a major source of bugs for networked projects, so be careful. You cannot set a node to a name with @ in it. So in effect, you cannot use Godot’s auto-incremented names (since they append @increment) to sync between the client and the server. For this reason, I used a uuid library for generating node names.

The need for the same structure on client and server despite the fact that the server held a whole universe while the client only cared about one system is a major source of complexity in the codebase.

Server Authoritative

I implemented the Client and Server as singletons that exist on both sides. The reason for this is that it makes it really readable; when the client needs to send something to the server you write Server.rpc and when the server needs to send something to the client, you use Client.rpc. Besides this line of communication, I’ve used rpc and rset within various nodes to update and alter the client versions of themselves. This always happens inside an is_network_master block, to ensure that it’s being called on the server version of the game.

The one thing we do need to gather from clients is input, and for that each client has a PlayerInput node, network_master’d to them. They rset_id input up to the server. The server copy of the player nodes looks at this remote copy of the player_input to determine it’s behavior, then pushes its state back down to all clients.

Multi Level

Suppose you want to have multiple different levels/worlds/rooms in your game. The trick is that you need to mesh the following two constraints:

  • Node paths need to be the same between client and server (see discussion above)
  • The server needs to have different node paths for each level

The trick, then, is to send the client to the new level by loading the appropriate level and making sure it’s named appropriately. There’s one wrinkle though: different 2d physics worlds need to use a Viewport class, but you don’t want to add additional viewports on the client for performance reasons (tried it, it was way too slow.) My solution was to add an extra layer of nodes called “universes” in the comments which are a Node2d on the client but a Viewport in the server. They are managed on the server by ServerMultiverse and on the client by ClientUniverse. Client Universe cares about a single “universe” child whereas ServerMultiverse handles multiple children.

Sending Entities/Switching Levels

In order to join a match in progress or switch to a level that already has stuff in it (or, indeed, switch a player into a level) we need a robust way for the server to move fully-formed nodes to the client. Godot does not provide a generic “send this node” method, so we need to write one for ourselves. The approach I took was:

  • Assume that the ent will be instanced from the same scene that the ent on the server is
  • Write a “serialize” and “deserialize” method that allows it to dump a dictionary with all of its important state and recreate itself from that dictionary.
  • Make sure the node on the client side is assigned the same name as the one on the server side.

So when a client’s level is switched, they dump the current level and recreate the new one by loading in the scene and then, node by node, deserializing the state sent from the server. As it turns out, this means that any state can be synced freely, and it enables us to dispense with the lobby entirely and let players join and leave at will.

Sync In Multiple Levels

Each level owns the process of syncing its state to clients in that level. Scenes within the level can declare a method that serializes their state for a net frame, and the level gathers all of those up and sends them. The client receives the frames from the server, and the individual scenes use the content of those frames to interpolate their position. To save bandwidth, I only do this for ships and guided projectiles, everything else moves deterministically. This whole process is derived from the teaching of (and better described by) this video.

Player Lifecycle

Because we’re using the player’s presence in a level to determine if we should update entities in that level for that player, when a player’s avatar is destroyed the world seems to stop for that player until they respawn. This might be desirable in some games, but I think most games at least want to show the player the immediate seconds after their own demise. So what we do is replace the player with a ghost.

Tooling & Workflow

GDScript is based on Python 3 and the most basic syntax resembles it. ‘func’ in place of ‘def’, no ‘self’ and no list or dict comprehensions or other advanced features. It feels like the python of basic python tutorials. However in exchange for this, you get one thing python 3 does not offer: true static typing. In Python 3 you can offer a type hint for a function argument but it is not truly enforced. GDscript enforces the types at compile time and boy does it ever catch a lot of bugs. You also get the ability to define classes with typed members, similar to what you get in Python with Pydantic. Overall I like gdscript and the things I miss aren’t dealbreakers.

The lack of a vi mode for the editor hurts. I know I could just use the godot plugin for vi, but I actually really like staying inside Godot’s editor. Despite the slightly crowded layout, it’s really very nice. The autocomplete to node paths is a killer feature that makes dealing with complicated trees less of a pain.

Conclusion

Building a multiplayer game in Godot is possible but by no means easy. The high level multiplayer API despite its gotchas works well, but you need to implement the sync logic yourself. This shouldn’t be too surprising as games have very different needs when it comes to net code. I hear that a similar mechanism for frame based sync and lerping is going to be more built-in in godot 4, which would be sweet. The puppet system (which I initially used; you can see a version in the tutorial) seems to be useful only for very low latency situations, so I regret that it’s a first-class feature because it may lead people down a rabbit hole of net code that will not work for most games.

MP EV MVP Retro

What I’ve learned from breaking my own rule.

I remade a game again

EVMVMVP is the awkward initialism for my latest project; a multiplayer EV-like. You can download it here, and look at the source code here. I know I said I shouldn’t do it, but I really wanted to learn Godot and having a multiplayer server with multiple levels seemed like a really interesting problem to tackle. Implementing a bunch of stuff I already know pretty well but in a new engine and language has been a fun ride. I’ve jotted some notes down about the project so far. I’ve saved a deep technical discussion of Godot for another post.

Using an engine is well worth it

After flythrough.space I decided that I wasn’t going to build too much from scratch next time, not was I going to fight against tooling. The options I considered for FTS where Panda3D and BabylonJS. However over the course of that project also tried out Unity and Godot for small side demos and ended up liking Godot (and it’s permissive license and thriving community) enough to go all-in. In retrospect this was the absolute right move and I regret nothing.

Working With Onyx’s Sprites

I’ve been staring at these sprites on and off for something like fifteen years, itching to put them into a game. The original models used to render them are long gone, but Onyx (in a tutorial) explained how to separate out the engine glows. Working with these sprites feels like stepping out of time. They’re from the 90s. There are dithering tricks here I wouldn’t even imagine. They use a tiny palette but they’re so damn weighty. Present. Metallic when they need to be, plastic when they want to be. They tend towards the Star Wars / Used Future look. They invite stories to be written about them. And the planets are just absolutely lush too. Something about that limited palette…

Testing with real people is essential

I’ve been nagging more people to play this one. On the one hand, it’s much easier to convince someone to play your game if you can play it with them. On the other hand, you really need to do that testing or you will (like I did) find out that the sync method you’re using is totally busted and you need to replace it with interpolation. Furthermore, you’ve got no idea if your game is fun to anyone but yourself unless you subject it to ruthless testing by people who will give honest feedback. It becomes very easy to get settled in and work around horrible UI issues you’ve coded because “well, I know how it works.”

The ability to test solo is essential

Wrangling people for a test is hard. You need to be able to fire up an instance of your server and client with minimal effort or you’re going to wait too long and leave a bunch of bugs that you’ll be scrambling to fix when you finally get people around to test with. And absolutely nothing is more frustrating than the stars aligning for a test only to have a showstopper rear its head at the worst possible moment.

Procedural Generation

I had a conversation with a coworker about EV games and roguelikes. They made a claim that I’m not sure is true but definitely opened my eyes-they thought that the star maps in EV games probably had been procedurally generated-once.

Actually hand-crafting a full EV map is a bit of a process. One thing I never finished doing in FTS was populating all of the systems.

Meanwhile, Mag Steel glass has developed a really cool universe generator spreadsheet. I figured I could leverage it to make a map. Traditional EV games require you to specify exactly who spawns in what star system and FTS carried on that painful tradition. For this one I had simpler rules; factions had starting locations and then grew “influence” where planets (or stations) would belong to them and their ships would spawn. If two areas of influence overlapped, they’d fight.

Document enough for people to get up and running locally

Port forwarding is a lost art. There was much grumbling when my friends and I went to go start a game of Valheim; luckily I’d learned to properly port forward as part of this project! If you need a server for people to play your game, you can’t rely on your master server; you’ve got to give people an option to join localhost and put it in your manual/readme. Having images in the readme also helps show people what your project is about; this is especially important for games.

You don’t get cross platform for free

Using cross platform technology does not absolve you from cross platform testing. All of your target platforms might have the same features but they may all have different bugs for you to work around. I’m developing on linux out of what is probably just bloody mindedness at this point, so when I did my live demos on windows I often learned exciting new things like ‘your sound exports are busted’ or ‘only one computer can be assigned to a given port by a given router’ or ‘you need to version bump the editor for correct mac exports.’ Guess which one of those lead to an incredibly embarrassing platform bug report!

Video Tutorials are worth it

Part of my commitment to overcoming my stubborn hangups was relenting and watching video tutorials. I still strongly prefer written tutorials as a medium but the content is moving to video. For example:

This (and the followup on extrapolation) gave me enough to totally re implement my networked movement.

Working In Public

I post progress updates on discord channels full of fans from the old days, and regularly demo the game with friends. This has been a source of motivation and helped me stick to a more iteration focused (and less “well, I’ll go off for a month and make all of the models/textures/features”) work habit. I’m not sure I’m going to do this for every project; part of why I did it for this one was I wanted to spur participation and that didn’t really happen. Very few people who I didn’t know personally went to the trouble of getting the game running. Part of that is because it wasn’t immediately approachable (you need to host or find a server then run another client to join it) and wasn’t immediately grippy (ok, I can buy a ship, now what?) Any amount of friction is going to turn away potential players, and if you’re used to playing rough unfinished demos this can become a blind spot. But beyond even that, getting someone to try something new is just plain hard.

People respond to Video

At the end of the day, pictures and text don’t cut it for sharing a game. Games are animation. People are used to watching streamers. You need a video of your thing and it needs to show off what the thing is about, including how you interact with it and why it’s compelling. This was my attempt:

Have features and fixes gone in since that video was made? Sure. But it’s still the best tool to show off what the project is about.

Parting Shots

Has the project met its goals so far?

  • Learn the Godot engine: ✔️

I’m comfortable with the technology now; expect future prototypes to be more rapid.

  • Use Onyx’s Sprites in a game: ✔️

I used most of the ship sprites themselves and lovingly separated out the engine glows for even the ones I didn’t use, in case someone in the future wants to use them again. Cosmic Frontier mod anyone?

  • Build a reusable platform for multiplayer EV-clones: ✔️

Maybe this is a partial check. If someone has an idea and that idea is based on multiplayer EV gameplay, I’m confident that if they’re willing to learn Godot they could at the very least copypasta big chunks of the MPEVMVP codebase and get something running. Or they could fork it, replace everything, add missions, remove multiplayer, and make an EV clone real fast.

  • Discover if EV gameplay works in multiplayer: ✔️

Learned important lessons about how much bullet hell spam a networked game can handle, and as a straight dogfighting sim it let me figure out what is and isn’t fun in PVP EV.

  • Build a game people want/like/play: ❌

As far as I can tell, nobody enjoyed playing this besides on demo night. The service I think people want this game to be is beyond the scope of what it can be with a team this size.

4/5 ain’t bad. Thanks a bunch to everyone who tested it, gave feedback, and flew too far to find the center of the map again.

Flythrough.Space Retrospective

I’m not going to rehash don’t remake an old game, but the principle very much applies. Flythrough.Space is a 3d remake of the EV series, and as such suffers from the “remastering someone else’s game” problem. That said, it was a long and involved software project, so there’s got to be something to take away from it, right?



Content Design

Don’t do content design up front. I had reams and reams of content for this project, a holdover from an even older project, making the oldest data seven years old! And the design of the map dates back to an EV Nova TC I attempted in 2005 or 6. The first plan involved using the graphics from Onyx’s Old Shipyard, back when the whole thing was going to be sprite based. FTS, while using the existing data, was 3d from the beginning so needed its own entire suite of assets.

I ended up using Blender because it’s Free Software and I wanted to keep the toolchain as free as possible. I wanted anyone to be able to pick up the same tools and build more content. It took me a while to become minimally proficient with Blender. One thing that ended up looking really cool was making rough textures with blender’s texture paint then applying a “paint” layer in GIMP with clean lines but dusted up with a rough brush and a makes for a worn look. The ships aren’t exactly up to modern standards, but I’m proud of the results nonetheless.

The planets turned out pretty good. Never did nail clouds though.

inshes.png

Technology

Flythrough.Space started out with very basic requirements. I wanted to do the game in 3d, I wanted menus, I wanted to be able to write object oriented code and I wanted to be able to break code into multiple files. Web was a platform I’d been working on for my whole career up to that point, and I wanted to make the game very easy to pick up and play, so web it was. There was a long period of using babel and Angular to compensate for the shortcomings of JS, but eventually we got all the goodies right in the browser! Once I was working in vanilla ES6 with no precompiler or other baggage, working with the code was pretty much a joy.

ECS

I tried to build an entity/component system. All of the game’s behavior is implemented in “systems” which are functions that get run each frame, requesting entities that have specific components to work on. For example:

export function velocitySystem(entMan){
  // Provides inertia.
  for (let ent of entMan.get_with(['velocity', 'position'])) {
    // Do physics
  }
}

The game state all belongs to entities or the player save object. This turned out to be a fairly awkward way to program a game. It was very nice that, say, velocity or AI could be added to any entity pretty easily. But there just weren’t that many different classes of things in FTS. A class hierarchy wouldn’t have become overly complicated, considering the small number of different entity types in the final game (ship, beam, planet, asteroid, projectile, explosion.) One major drawback was how it changed the code layout of the project. If you want to see what code controls the behavior of a ship, you need to browse several different files and it’s extremely unintuitive. Likewise, if you want to know what parameters a ship can have, there is similarly no single place to check out. There is no FTS bible. One possible evolution would be to put every possible ship param into the implicit base class, but then you’ve got a few parameters where absence matters…

Collisions

I wrote a primitive collision library myself, and my attempt to integrate a proper one later was frustrated by a lack of the primitives I needed, specifically objects with no rotation components.

The crowning achievement of the collision system is the line segment collider. Managing to implement (not invent, mind you, merely implement) allowed continuous collision detection which made combat work much better. It also enabled beams, which are a staple of the genre.

Missions

The missions system leverages ES6’s actually very nice text interpolation to make nice templated text. It uses eval all over the place to do it. It’s a bit fiendish how it works, and it works very nicely for stuff like “deliver cargo” but to add features like “go blow up ship” you’d need to add something in the system code to spawn ships depending on active missions. Probably wouldn’t even be so hard, but it’s low hanging fruit that I haven’t picked. Missions where a very late addition, right before the Alpha release. The json to define a mission looks like this:

  "smuggle": {
    "short_name": "Smuggle ${cgo(this.cargo.type)} to ${this.dest.spob}",
    "desc": "Some shady exporters need ${this.cargo.amount} tons of ${cgo(this.cargo.type)} moved discretely.",
    "offer_if": "true",
    "offer_state": "missions",
    "cargo": {
      "type": "${get_illegal_cargo()}",
      "amount": "randint(5,10)"
    },
    "dest": "get_spob_same_govt()",
    "reward": 14000,
    "accept_modal": {
      "text": "The dockhands quietly load the mislabeled containers of \"${cgo(get_legal_cargo())}\" into your hold."
    }
  },

But that sort of thing only covers random cargo missions. I’d designed the world for FTS without giving too much thought to how it would become involved in any sort of story, besides the idea that the Loyal Suns wanted to take everybody over and the Itaskans wanted you to visit every homeworld. This is a problem because in EV games, you’re supposed to play missions to unlock faction ships, and most of the ships in the game (especially the ones I’m most proud of) where faction ships. My inelegant solution: all ships available all the time. No dynamism. Nobody wins or looses. Some people just fight sometimes and if you hail them they’ll give you the slogans of their government. I think that without plotlines, there isn’t much of a hook. There’s certainly no endgame besides grinding up to an Absolver, Nightshade, Capital, Taoiseach, etc.

Data Driven

Every ship, star system, etc is defined in json files. Many previous game attempts had done a lot of work on making a perfect data loader. In this case, I was able to leverage Javascript’s own builtins to make something I’d consider basically perfect (or at least perfect in that it represents an idea taken to its full extent.) You can declare another object as a given object’s prototype and it just works, inheriting values that aren’t overridden. Objects are created on screen by instancing the data (with some enhancement, of course, but it’s all fairly easy to follow.) There’s no intermediary data is what I’m getting at; the javascript objects in the data directly translate to javascript objects in-game. Upgrades work by acting like a diff. Getting all of this to just work was one of the funnest parts of the project and will be the hardest part to let go of.

Community

The babylonjs community, by way of their forum, was extremely helpful. Having real live people who want your project to succeed and can help you use the tools they’ve built is a joy. I would definitely recommend treating community as a critical feature when picking frameworks and libraries.

That said, you also need to cultivate a community around your own project. That’s one angle where I failed in a big way. It isn’t easy to get other people to demo your game. Starting with something very you can get right into, rather than starting a player out as some sort of lowly level one wimp in an RPG might make a lot of sense. I eventually added cheat codes in the form of querystrings (bonus points if you can find them by looking through the source) so players could start in more powerful ships (and so that I could test them without grinding.) But without a large number of testers, tons of bugs slipped through the cracks. It took me way to long to realize that using Control as the fire button simply wasn’t going to work on mac, for example.

If you want to use FTS

I tried to do with FTS what Ambrosia never did with EV: make a totally open system that anyone can pick up, make a game, and truly own that game with. FTS is licensed under the GPL so if you throw in your own assets and release any code changes, you (yes, you!) can make a commercial EV Clone with it. The game scenario lives in the data and assets folders. If anyone has specific questions about how to implement something, I’d be glad to help. But I realized something: nobody is going to mod your game if they don’t love your game. Making a game easy to mod needs to be a secondary concern to making a great game. If you really truly want to build technology rather than a game, I would recommend partnering with someone with a vision for an excellent game, which brings us to our next point.

Putting the cart before the horse

I thought I knew exactly the game I was trying to build from scratch. However I was building it largely in a vacuum and I certainly wasn’t going back to EV Nova to see how the ship movement and turn speed compared. This was probably a mistake. I was so mired in what I could achieve technically that I wasn’t stopping to ask if the game I was building was actually fun or not.

I should have spent the bulk of the development on the basic combat loop, making sure the ship handling was fun, the AI was correct and tight and fun to play against, and the game balance was decent. Instead I focused on creating tons of content and features because I was trying to work from a feature checklist. Feature parity with a twenty year old game does not a compelling game make, as it turns out. On paper, FTS has what it needs, but I feel that it does not live up to that potential.

It’s a mistake I don’t intend to repeat. Future projects I’d like to get in front of people faster, I’d like to be less stuck on design decisions I didn’t even make, and I’d like to have the emotional fortitude to disengage from a project before it takes up half a decade.

In Appreciation: Termux

I’ve been playing with Termux quite a bit in the last couple of days. Being able to do development-any development-while standing on the train is an awesome feeling. I think the site undersells what it is-it’s your compiler in your pocket. It’s ssh in your pocket. I’m redoing my website on my phone (the mobile experience is crap at the moment) by editing the sources in vim, then hosting it locally with Python.

Beware of side effects on default arguments

Check out this quick interactive session:

Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(y, x={}):
...   print x
...   if y:
...     x['y'] = True
... 
>>> f(False)
{}
>>> f(False, {'x': True})
{'x': True}
>>> f(True, {'x': True})
{'x': True}
>>> f(False)
{}
>>> f(True)
{}
>>> f(False)
{'y': True}
>>> f(True, {'x': True})
{'x': True}
>>> f(False)
{'y': True}

What’s wrong with this picture? Notice that when I call f(True) we assign something to the default argument x. When we call f again, it replaces the default x = {} with the previous value of x!

I suppose the moral of the story here is that in order to avoid side effects, you should not mess with arguments you’re passing in, even if they’re just the default arguments.

Python list comprehensions

If, like me, you learned python and programming at the same time, you may have missed out on advanced features that, while awesome in python, won’t carry over to other languages you’ll “graduate” to using. One of these features is a list comprehension. It lets you in a compact (and readable) way write loops that take a list and return a list, and does not require lambda syntax. They let you write this:

list_squared = []
for x in [1, 2, 3, 4, 5]:
    list_squared.append(x ** 2)

like this:

[x ** 2 for x in [1, 2, 3, 4, 5]]

This really shines when you’re transforming and extracting data – you can also stick an ‘if’ at the end, turning this:

odds_squared = []
for x in [1, 2, 3, 4, 5]:
    if x % 2:
        odds_squared.append(x ** 2)

into this

[x ** 2 for x in [1, 2, 3, 4, 5] if x % 2]

It might not be a huge improvement in amount of code (or LOC, since you’ll want to break complex list comprehensions across multiple lines) but it saves you from potential mistakes, typing ‘append’, and (importantly) having to declare and use another variable name. I consider that a win.

If you found this post exciting, generator expressions will blow your mind.