Epic Airship to Airship Combat
As our lease is set to expire in a few short months, and as I am starting to scout for a new home for us, I thought it might be interesting or even entertaining to muse and reminisce on the history of our migration through New York City as an indie dev team. Continue reading “A Migration History”
By now, everyone has seen the trailer. We’re very happy with it but we also want to let everyone know that there is more to come. We know you’ve all been waiting a while to see something new, and while our teaser was a looker we knew we’d get people clamoring for gameplay footage. This is a more technical post to give everyone a thorough update on all our core mechanics and what state they’re currently in. Some things are were in the gameplay trailer, some things are so new that they didn’t make it in.
The one thing that just came out of the oven is new ship controls. More specifically, we’ve erred on the side of realism and created an honest to god ship thrust model. We have friction, drag, and all the goodies that comes with real-world physics. Of course, we’ve simplified a few things so gameplay doesn’t get too out of hand. The main one is that all ship motion assumes it has a left and right engine. We decided not to try to model a rudder system so having two engines on either side of the ship becomes essential in turning. You can put your ship into discrete levels of forward or backward thrust, so far 7 to be exact (from -3 to 3). This basically means both the left and right side engine(s) are at the same power. Turning the ship lessens the thrust of one side and increases the other. With this, you can expect realistic ship movement. For example, it’ll take some time to come to a full stop but we’ve toned down some of the realism to ensure maneuverability and a fun control experience. But since everything is still based on a realistic system, everything just operates as you would expect it to a phenomenal degree.
This is something that I’ve been not only thinking about but experiencing myself. The opportunities and problems afforded and created by the addition of different dimensions (mostly in the traditional sense like 2D to 3D but the definition is loose) becomes both amazing and daunting. I’ll keep this confined to map and level design.
Starting with making 2D Flash games, level constraints are quite straight forward. You only have two degrees of freedom (x, y axes). Take for example the ubiquitous platformer: movement is defined by floors. 2D platformers are easy to grasp whether due to its simplicity or its commonplace nature in games. I remember drawing Sonic the Hedgehog levels before I could spell Sonic without looking at the box. Walking on terrain is a simple game that we all know because we’ve played these games as children–skipping over cracks in the pavement, hopscotch, and etc… Creating levels for 2D games are fairly straightforward and are easily produced on paper by drawing simply lines to represent the ground. There is easily a standard for designing with these constraints. The information that is required to effectively convey the workings of a level can easily be read and drawn on a piece of paper for an everyday platformer.