next »

[Geti]

Over two weeks we made a game called "Station Raiders" to properly test out Unity and the 3d workflow; Overall we learned a lot but fell a little short of our goals.

Stations can be quite dark, but you can spot them in the distance against the night sky.

We'll take a slightly more "free form" format with this postmortem, as we've just come out of a long week of work on KAG.

MM:

The goal was to create an FPS inspired by the game 0space about a bunch of space dudes exploring abandoned space stations in search for treasure. The game was at first to be more competitive with Quake 3 style railguns. We quickly decided we don't want to make another deathmatch game and started focusing on making the game more collaborative and enjoyable in singleplayer. The idea was to add traps and enemies the player would face. This didn't end up in the final game for 2 reasons:
1. Not enough time and resources (we wanted it done in 2 weeks).
2. The most fun thing about this game turned out to be exploring the space stations and making calculated jumps in 0 gravity

The game was made in Unity. It was my first FPS game I ever made. The hard part for me was getting the math correct for the camera. There is no static ground normal in this game. The math in the end turned out to be simple, the biggest issue was confusing Unity's transform with local transform. Reading Unity docs and googling for solutions was the most time consuming part of working with Unity. Time spent on actual coding was amazingly low. Which felt quite good (I really don't miss engine coding:)).

In terms of time estimates and reaching goals we made a good decision to remove "bullshit" and just focus on things that work. The 80/20 rule works wonder for actually getting a game done on time. I think too much time was spent on assets, they could be accomplished with simpler methods and achieve the same effect. The time spent on assets could be used to make more random levels.

The biggest dissapointment was Photon networking which works great out of the box but trying to add anything custom results in complete failure. We can't add high scores because it doesn't support persistent data. We couldn't sync the space stations because Photon doesn't easily sync non-prefabs. I spent an entire day trying to sync the stations in some way but all attempts failed. I might give it another chance for the next project, although I think we might need Photon Server or just node.js and sockets...

Max:

I found this project to be a lot of work, but learning unity has been quite rewarding - seeing what workflows work with the technology and what workflows don't.

Creating the art assets took too much time, and I still feel like I'm learning my way around the software. Some parts went very quickly (writing the shader was quite fun and took only a day, though a lot of the functionality wasn't used due to time constraints) but some took ages (finding a baking workflow that worked being the major one, but also finding a way of tiling rotated assets in 3d). I would be much more confident doing this again from scratch, but while learning everything anew it was quite a struggle.

I think postprocessing could have been used to great effect on this project (adaptive gamma would make looking out into the sky much less of a strain on the eyes) but we were restricted from using this because Michal's machine couldn't cope with the performance requirements. Making more optimised versions of the postprocess shaders involved rather than using "stock" could potentially help a lot with this.

Coding in unity was nice once we realised we should just roll our own tech. It was very easy to build nice separate components and have them interact, though there's the standard amount of "big engine" bullshit whenever you touch something engine-side. The maths classes especially are really solid, and the easiness of exposing or hiding something from the inspector is lovely.

I feel like we kind of fell short on consistency with this one, so if we touch it again that's what I would focus on - making sure the raider motives make sense, and that there's some sort of permanence to strive for. Zero grav movement is cool and all, but without something to buy with the money you sell from the graphics cards, it's kind of in a state of limbo.

Bottom Line:

Of course, we always wish we could fit more into our games, especially on such short deadlines. We're hoping as we get more comfortable with the technology we can continue to push the envelope, and with SR we are happy with how many of the aspects of the game came together in the end.

All in the pursuit of sweet, sweet graphics cards.

Future directions for development may include co-op, persistent highscores and more treasures to collect and stations to explore. We'll see how that goes.

You can play the game here: https://cartridge-us1.thd.vg/station_raiders/

Have fun!

[Armageddon]

It would be perfect if the roll function worked and if the air pusher was behind you. I tried many times and couldn't reach either of the other stations. Also the mouse isn't locking to unity so I have to move the mouse from the edges of the screen to click and push which rotates me too far back.

I love the art assets and HUD though, I hope you keep developing it.

[Geti]

Bizzare that the mouse locking isn't working. Try right clicking the window?
Did you try QE for rolling? The auto-roll is scaled back as much as we can to avoid screwing with people's jumps.

The air pusher being backwards was an intentional difficulty decision, we found it was too easy to get anywhere if you could "pull" your way there rather than having to turn away in between shots. It'll make more sense with a multiplayer aspect, as you'd be able to push other players. Would probably have helped to finish/include the model for the gun ingame

We'll likely develop it some more, but we need to get 2 more games finished to launch the larger overarching project this is a part of. Glad you enjoyed what's there and hope that we can continue to pique your interest in the future, haha.