Content Update #2 is Out!

I’m very excited to announce that Content Update #2 is out! To celebrate, I’m running a 60% discount. Until March 31st, you can get Hypergate for less than $4 USD from the Steam Store page.

This latest update includes:

  • 2 new ships
  • 3rd-person view
  • Removal of online DRM
  • Attachments (new upgradeable components that are separate from equipment)
  • Additional graphical effects
  • Improvements to both mouse piloting and controls customization
  • Several bug fixes

Most of these features come from player requests. (In reality, my to-do list was quite long, because it included a lot of nitty-gritty details like “test ending cinematic again”, “increase maximum particle count”, etc.) Players like to be heard, and I’m happy to implement features that improve their game play experience.

shot-151-compressed

So, what’s next in terms of Hypergate updates? Some feedback has already revealed a couple of minor, non-critical issues that should be corrected, so I’ll be releasing tweaks to those features in the very near future. I’m also still working on voice recording for another 10 campaign missions, scheduled for Content Update #3. My hope is that Content Update #3 will be released at the end of 2020.

But what about after Content Update #3? I’ve been giving this a bit of thought.

Developing a Hypergate sequel would be a great deal of fun. While I’d still aim for the intense, action/arcade-based game play, I think a couple of elements like being able to actually fly through a gate or navigate a specific route through the gate network would be a neat addition. At this point, I’m just fiddling around with ideas in my head to see what sticks. A sequel is still a long ways away, and in the meantime, there’s more Hypergate content to develop!

shot-148-compressed

Thanks for your support, everyone. I hope you enjoy this latest update!

One final note. Most of my posts lately have been about my technical progress on Hypergate. But if you would like to read about other aspects of my game development journey (creative design, sound effects, working with my voice actors, marketing, or even how to get started), please leave a comment below and I’d be happy to share my experiences and what I’ve learned on the subject. Otherwise I’ll just pick whatever topic I want and yammer on about that instead.

GN

Feb. 17 – Where I’m At

Content Update #2 is coming along nicely! Here is my to-do list:

  • ability to buy new ships
  • develop boost/engine sounds for new ships
  • ability to buy and use attachments
  • integrate attachments and new ships into LAN play
  • third-person fighter view
  • add third-person EMP effect
  • remove online DRM and allow offline mode
  • add short engine thruster contrails for extra cool appearance
  • add volcanic planet from new upcoming missions
  • validor first-person cockpit
  • nausica first-person cockpit
  • cruisers should explode into chunks when dead
  • graphical effect: film grain
  • graphical effect: chromatic aberration
  • player request: add mouse pilot sensitivity option
  • bug: fix an issue with mission warp-in sequence in 3rd-person view
  • bug: fix an issue that occurs with empty mission stats
  • bug: fix warp zoom when colliding with objects
  • bug: fix issue that occurs with laserbolt depth testing
  • bug: target leading in 3rd-person view needs tweaking
  • bug: fighters can get stuck in cruiser debris

Third-person view and the ability to buy new ships are the features I’m most excited about. I’ve also added some quality-of-life things, such as short engine trails and improved post-processing effects. Cruisers will now also explode into chunks. I should’ve implemented this a long time ago! It makes destroying them so satisfying you’ll need a cigarette afterwards.

shot-111-compressed

The player blows an enemy cruiser into several different pieces.

shot-100-compressed

The player will be able to choose between 3 different ships to fly.

Another major feature is actually a removal: I’m removing online DRM! Ultimately, I care more about providing a good experience for legitimate players than foaming at the mouth to viciously defend my creation like a rabid hyena. I don’t want anyone to suffer because they don’t have a good Internet connection! After Content Update #2, Hypergate players won’t need an Internet connection to play. Of course, the leaderboard and other online features won’t work in offline mode until a connection is restored, but this won’t inhibit gameplay at all.

shot-104-compressed

A new Hypergate location, Autumn Reach, will be an important location in Content Update #3’s continued story.

A new interesting feature I’m working on is attachments. These are micro-upgrades that you choose from to enhance specific ship abilities. Each one is upgradeable a total of 4 times, and you can equip only one attachment at a time from the Upgrade Hangar. By choosing the appropriate attachment, you can gain a slight advantage over your unwitting opponents. Here they are:

  • Emitter coil: Increase shield strength by a few percent
  • Hex wave package: Increase EMP time by a couple of seconds
  • Energetics projector: Infuse cannons with some extra damage
  • Heat sink: Increase heat dissipation by a few percent
  • Afterburner chamber: Increase boost speed by a few percent
  • High-energy sensor package: Increase gun and missile locking ranges

I’m optimistically hoping to release Content Update #2 at the end of March. Stay tuned and don’t change that channel!

GN

Jan. 11 – Where I’m At

Here’s a brief update on things! As I’ve mentioned previously, I’ll be releasing several updates to Hypergate of various sizes. Like all updates I provide for Hypergate, they are free and require no separate DLC-type downloads. They’re just straight-up updates, for your gaming pleasure.

Content Update #1 is already released. It included 5 new Instant Action locations, Steam Cloud Saves, 8 new pieces of equipment, and several other minor things.

Content Update #2 is what I’m currently working on. It will include a third-person view, two new ships to fly, and possibly some more graphical improvements or new equipment mechanics. I’ve also been toying with the idea of allowing the player to customize the colours on their fighter. Here are a couple of recent development screenshots.

shot-87-compressed

Content Update #2 will add third-person view.

shot-88-compressed

The Nausica fighter, coming in Content Update #2.

Content Update #3 is also underway, but requires a lot more work and time to complete! This is because it will include 10 new Campaign missions, and possibly the option of playing Instant Action as either the ISC or the Marauders. Voice recording for the new campaign missions—which will complete the story of the NIA—has started but several of the parts don’t have actors lined up yet.

GN

Doing Ludum Dare

I participated in Ludum Dare 45 this year.

Ludum Dare is a semi-annual competition where you attempt to make a game over a single weekend. There are two flavours. The first is the “Compo”, where you have 48 hours to make everything as a single individual (no teams). You must release your source code and all art must be your own (or, properly derived from existing assets that you have rights to use). The second is the “Jam”, where you have 72 hours, can work in a team, and enjoy slightly more relaxed rules.

I chose the Compo because it’s meant to be the ultimate test of your game development skills: 48 hours to develop everything yourself. The result of my work was Robo-Fort, shown here:

robofort-shot-1-compressed.gif

The theme for the competition was “start with nothing”. My application of this theme was that you started with nothing by having to push boxes and build a fort to defend precious cargo. You started with no fort, so you had to build one.

(Some folks, however, took this entirely to the next level: some entries had no graphics, resources, or even levels, and you had to find/build/buy them yourself in order to make the game playable. Now that’s creative! You should check them out.)

Before I started, I set a few ground rules for myself. I would still eat, shower, and sleep. I would also allocate a lot of time at the beginning to sort through my ideas and decide what I wanted to do. It turned out, this wasn’t a problem. When the event started, I was already an hour’s drive away from home and out with friends for a social obligation. That gave me plenty of time to let ideas marinate in my head after the theme was released. When I finally arrived at home, the event was already 3 hours underway and I had a fully formed idea of the mechanics and game play.

A rough timeline of my progress looks something like this:

ludum-dare-45-timeline.png

Here are some personal tips I embraced that contributed to my success in being able to finish Robo-Fort on time.

  1. I intentionally gave myself a ton of time at the beginning to sort through ideas. The 3-hour delay before I got home didn’t concern me in the slightest. That time to think before coding is required.
  2. My morning routine (breakfast, shower, coffee, etc.) helps me focus, so I made sure to still do that.
  3. Test continuously. I would periodically stop at natural breakpoints and just play the game.
  4. Slept 8 hours each night to keep me from writing bad code or (worse) making bad decisions.
  5. My goal was to have a minimum playable version done by Saturday evening (after about 32 hours).
  6. If I got stuck on a non-technical idea, I immediately set the project aside and did something different (like washing the dishes) to let me think. The worst thing I could do was waste valuable time coding when I didn’t have anything to code.
  7. Lastly, I allocated the final hours on Sunday for music, since I knew that this was my weakest “skill”.

Ultimately, the Compo is not just a test of game development skills. It is also a test of self-knowledge, because in order to complete your game, you must force yourself to be the best version of yourself you can be. Even if it’s only for 48 hours. Plus, the skills you apply for the Compo (e.g., think and plan before you code, know what you have time for and what you don’t, etc.) apply to regular game development, too.

Robo-Fort (LD45 Submission by Geoff Nagy) Sun, Oct 6 2_18_45 pm.png

Games are judged on the Ludum Dare website by the other participants over the following several weeks after submission according to a “karma” scheme: in order to get your game judged by other players, you also have to judge others’ games. This was a ton of fun and I played about 60 over the course of the next several days. It was really something to immerse yourself in so many different fun worlds, and in each game, the developers’ passion shone through. I played one of the games that ended up winning, and the winning title was well-deserved.

Robo-Fort ended up scoring 360th overall, out of 2613 submissions. That’s within the top 14%, so not bad. (And top 6% in the “Graphics” category!) Some folks had difficulty seeing my (rather broad, in hindsight) interpretation of the theme (“start with nothing”), so that’s something to keep in mind for next time. Overall, Ludum Dare 45 was a fun experience that I’d recommend to any reasonably experienced programmer or developer looking to challenge themselves and test their skills.

GN

Making My Models

Game art is really not one of my strong suits. I mean, don’t get me wrong – I think Hypergate looks pretty good. But first and foremost, I consider myself a programmer, not an artist.

Here’s a 3D model I built back around 6 years ago at the beginning of Hypergate’s development. (I couldn’t find the original textures.)

old-model-1

This was originally an enemy fighter.

 

Not bad, but I think my more-recent Hypergate art looks better:

ship-render

The Validor A, a new fighter in a future update.

Now, having worked previously with some truly talented game artists during my brief time in the VR industry, I know that my art skills don’t come close to theirs. But, I recognize that my improvements were only possible through lots of practice. And you can learn too.

The goal of this post is to provide a brief outline of my workflow for building and texturing 3D models for my games, including Hypergate. It’s a relatively simple, methodical approach that works for me.

Our case study will be the Validor A, the new fighter shown above that will be part of a future Hypergate Content Update. The focus here will be on high-level steps, not artistic design. This is also not a technical tutorial on modelling.

So, let’s get started.

1. Build the Model Shape

The first step – and really, the hardest – is shaping the model. Blender is my tool of choice. It’s free, has great community support, and is regularly updated.

I usually start with a cube and extrude. I’ll sub-divide a few faces and add loop cuts here and there. My approach is to first focus on the large details. My space ships tend to have big wings, gun turrets underneath, a cockpit, and a few greebles on top or below. I’ll start with the large pieces like wings and the nose to get the shape figured out. As always, I’m prepared to use Ctrl-Z as I iterate. The Mirror modifier in Blender is a great way to ensure that my design is symmetrical.

bare-model

Once the wings and nose are worked out, I’ll shape the cockpit. I’ll add greebles on the wings to aid the appearance of appropriate scale. This can be done using the Extrude command. I’ll extrude cylinders for turrets or antennae, and shape boxes into fins. Cylinders work great for rear thrusters, too.

2. Add Seams

Seams define edges where you want to cut your mesh when performing texture unwrapping. Think of it like slicing up a stuffed animal or an orange with scissors: if you wanted to paint each segment of the animal or fruit on a flat canvas, where would you cut to get the flattest and easiest-to-paint segments? The red lines in the wireframe image below show the seams.

seams-model

A rough starting guideline is that I’ll usually want to add seams on the natural sharp edges of my model. This minimizes the texture distortion and provides a bit of robustness if I’m going to use a lower-resolution texture. Of course, there are exceptions, and I always end up adding seams elsewhere as required.

3. Unwrap

Unwrapping is an iterative process. After adding seams, I make sure I’ve done it right by doing a simple unwrap and viewing the resulting UV islands.

uv-islands-model

Enabling “Stretch” for “Angles” in the right-hand Properties toolbox helps to visualize distortion.

Chances are, I may need to add a few more seams here and there and repeat the unwrap process to eliminate distortion. I miss seams accidentally on my first try all the time.

4. Adjust UV Islands

After I’ve unwrapped the model, I’ll apply a simple diffuse texture of a checkerboard with lorem ipsum text to my model. The checkerboard helps visualize scale and the text indicates direction. (Often my textures will include text like safety stickers.)

I’ll now translate, scale, and rotate the UV islands until I get the appropriate levels of detail for each component of the ship. Often I’ll group related UV islands together to make texturing easier later on.

In rare cases, I might need to go back and add more seams and do some re-unwrapping. “Pinning” UV vertices is very useful for ensuring that vertices I know to be correct won’t change during subsequent unwraps.

5. Exporting UV Layout and Texturing

My image editor of choice is GIMP. For small fighters in Hypergate, I’ll usually export a 2048×2048 image of my UV islands from Blender for texturing, although the final in-game textures end up smaller than this for reasons I’ll explain later. For larger objects like cruisers, I’ll usually export 4096×4096-sized UV layouts.

In GIMP, I start by adding a base colour layer (off-white, in the case of the Validor A). I colour individual UV islands, add some panelling, warning stripes, service panels, warning stickers, arrows, some text, vents, rivets, LEDs, and engine glow. I also add dirt and scratch layers. The “Layer Mask” feature in GIMP is a great way to add the appearance of worn-out paint or labels. This becomes the diffuse texture of the model.

uv-texture-mapping

I’ll also export emission, specular, and normal maps. These are just exported versions of the diffuse texture with the appropriate layers turned on or off, and further separately tweaked. The “Normal Map” plugin for GIMP is how I build my normal maps.

6. Applying Final Textures

By now, I’ve got diffuse, emission, specular, and normal maps for my model. In Blender, I’ll replace the original checkerboard material with a new one that uses these four textures. I’ll create four “Image Textures” in the “Texture” tab, setting their “Influences” appropriately.

7. Final Optimizations

2048×2048 is a pretty large texture size for a 10 meter fighter travelling at a couple hundred meters per second. This can eat up valuable GPU memory, takes longer to load from file, and is simply just an unnecessary level of detail. For small fighters in Hypergate, I usually export the following image textures:

  • Diffuse: 512×512 RGB PNG
  • Emission: 256×256 Greyscale PNG
  • Specular: 256×256 Greyscale PNG
  • Normal: 512×512 Greyscale PNG

This generally gives good results in terms of both level-of-detail and image sizes. Larger or slower objects are assigned larger textures to maintain good visual quality.

The model itself is exported as a Wavefront .OBJ file. I’ll export several levels of detail for each object. (The Decimate modifier is really useful here.) The small fighters typically have the following levels of detail, although it varies on the model:

  • High quality: 4,000 – 6,000 triangles
  • Medium quality: 2,000 – 4,000 triangles
  • Low quality: 1,000 – 2,000 triangles or less (I just set the Decimate modifier to the bare minimum that maintains the general model shape)

So how long does this entire process take? It depends. When I rush myself with this kind of work, it usually results in poor quality and more mistakes. A ship like the Validor A might take me about 2-3 days’ worth of full-time work, from start to finish.

I hope that this guide has been somewhat useful. Like I said, it is rather high-level. Comments are more than welcome if you have suggestions or would like more details on a particular step.

GN

Nov. 21 – Where I’m At

wallpaper-6-1920x1080

Several months ago, I released Content Update #1 for Hypergate. This included the following features:

  • 5 new Instant Action maps
  • 8 new equipment upgrades
  • Steam Cloud saves
  • Improved look-and-feel for the main menu system
  • Several other minor enhancements

The update was well-received by existing fans, and also brought in some new ones.

I’m currently planning at least one more major Content Update, scheduled for mid-to-late 2020. This update will include 10 additional missions and will complete the story of the Novan Interplanetary Alliance. These missions will contain additional story elements, but the focus of the gameplay will be the same: warp in and blow up anything that moves. The script is complete and voice recording has started.

At least 2 minor updates are planned as well. These will include additional ships to fly, as well as the ability to play as the ISC or Marauders in Instant Action mode. I’ve also been playing around with the idea of adding a third-person flight mode, squad commands, and “attachments”: small additional enhancements that provide unique abilities to upgrades you’ve already earned.

Updates to Hypergate will always be free. Updates will always be integrated into the main game, not just as separately-acquired DLC. I’m a big fan of “game ownership”. Once you’ve bought the game, you get everything else that comes with it.

In my mind, a video game is more than just gameplay. The complete video game experience should include occasional updates and developer support, bug fixes when required, and a listening ear for players.

So, Hypergate players have bought the game experience, not just the game itself. Extra content is part of that experience. It’s also a thank-you to existing players for taking part in the world I’ve created. (And also for trusting me with their hard-earned $10 USD!)

Check out Hypergate’s main website, or the Steam Page itself. 

GN

Nov. 26 – Where I’m At

Okay!

After some Asteroids Millennium-related stuff got taken care of (a bug here, an extra feature there), I experienced a day or so of mental peace where I felt absolutely no desire to work on any projects at all. I was peaceful and content, and it was horrible and boring.

Eventually, though, the desire to build something – anything – resurfaced with a fiery vengeance like last night’s curry and once again I knew no peace. Fortunately, because this is my normal mental state, I knew precisely how to deal with it: I started drawing up plans, prototypes, and mock-ups for a few different game designs, wondering what to work on next. While I won’t deny that I came up with some ideas that I would love to explore later in the far future, none of them really grabbed hold of me as much as the idea of working on Gateway again.

By now, I had learned a lot from Asteroids Millennium, which I considered to be very well organized. This was mainly just architectural stuff, the types of logs to keep, asset munging, etc., and it made me painfully aware that Gateway was lagging far behind what I now considered to be a sound structure, in terms of both code and project organization, at least for myself. So, for my first task, I dug my hands up to the elbows into Gateway‘s deepest, lowest dungeons of satanic code and vowed to cleanse the demons even if it was the last thing I did.

After a few part-time weeks of refactoring and some excessive use of the backspace key, I brought Gateway up to my Asteroids Millennium standards, or at least pretty close. And it felt good.

“Now,” I said to myself, rolling my sleeves up even further, “enough of this screenshot nonsense. Let’s post a full demo video and get this sucker to official alpha status.”

I’m not going to get into the development details, but it suffices to say that I once again exorcised my code into something fully playable. This included adding a few new minor features (such as the ability to destroy entire cruisers, which I always thought the game badly needed), improving existing features, and some performance optimizations. I also found an idiotic bug in my level editor that I’m amazed didn’t snap me in the ass until now.

Gateway is officially alpha, and here’s a game play video of a special demo mission that doesn’t appear in the single-player campaign. Oh, and it’s not called Gateway anymore, either. Apparently that’s the name of an interactive fiction video game from 1992. So I’ve tentatively renamed the entire project Hypergate, which sounds way cooler and probably won’t buy me a lawsuit. Surprise!

GN

Effective Level Editing

A few years ago, I completed a project called Dactyl. It was a 2D asteroids-shooter-type game. There were 25 hand-generated levels populated with mines, asteroids of various types, useful equipment, and automated turrets.

dactyl-01

To visualize each level before I implemented it, I used graph paper and a pencil*. Once I felt a level was complete, I plugged the object coordinates into a text file, and then fed the file into the Dactyl engine. And pop, out came a new level.

This approach definitely wouldn’t work in Gateway. The size of each level (up to about 20km!), especially considering the differences between, say, the 10 meter fighters and the half-kilometer battle cruisers, made drawing complex scenarios to scale next to impossible. Making changes to level designs would also be painful: erasing a group of 30 fighters and shifting them over a kilometer would quickly eat away at my eraser and my sanity. Besides, my hands aren’t steady enough for that kind of nonsense.

Dactyl levels were sketched out by hand.

Dactyl levels were sketched out by hand.

The solution for Gateway was to build my own level editor.

I’ll admit that I didn’t spend a lot of time investigating existing solutions. I was (pretty) sure that there was (probably, maybe) some level editor somewhere that would offer the right parameters and would allow me to drag, drop, and configure all of the game entities I wanted onto the Gateway playing field, but I really didn’t feel up to downloading and trying various existing editors only to find that each one was missing a crucial feature.

Ah, yes…implementing things from scratch rather than using existing solutions. I often do this with smaller projects for a number of reasons: (a) I believe in doing everything yourself at least once, (b) it’s often more fun, and (c) I can usually whip up something small in less time than it would take for me to learn to use an existing tool. (I recognize that this is a twisted combination of both laziness and diligence.) I also (d) like to be intimately familiar with the code I use, and this is easiest when it’s code that I write myself. Additionally, my own level editor could be completely customized for exactly what I needed it to do. (Besides, by the time I started considering developing my own, the back burners in my brain had already fired up and began doing the work for me. I think somewhere back there I knew very early that I’d have to write my own.)

I intentionally wanted to keep my editor’s feature list as minimal as possible, since I’d probably only use it specifically for Gateway (although it could be altered without much effort for similar games) and didn’t want to spend too much time adding features that weren’t absolutely necessary. I just wanted the bare essentials for designing levels quickly and easily…so, there were hard choices to make.

C# .NET would be an ideal choice for this project, since I’ve worked with it extensively on a variety of projects. This meant that graphical user interface elements like buttons or text boxes wouldn’t be a problem. The next thing I had to consider was whether or not I wanted a 2D or a 3D representation of the world in my editor. There were pros and cons to each.

Advantages of a 3D level editor:

  • Entities could be moved around the environment and viewed from the player’s perspective
  • Everything could be viewed as it would appear in-game: for example, depth or height would be easier to determine than it would be in a 2D, top-down view

Disadvantages of a 3D level editor:

  • Harder to implement than a top-down representation in terms of entity selection (picking), transformations, etc.
  • C# .NET does not feature built-in 3D support and would require using GLControls or something similar (I wasn’t adverse to this, but it was another layer of complexity I wasn’t sure was really necessary)

Ultimately, I decided to go with a 2D representation simply because the style of the game didn’t place a whole lot of importance on an object’s height or altitude within the game; the flight controls are more like flying an aircraft than a true 6DOF fighter (I did this to make the game simpler and more accessible to players). Thus, the world could fairly easily be represented in a top-down fashion. Of course, objects exist at many different “altitudes” in the game, but not to such a degree that it was critical that this be represented clearly in a level editor intended solely for myself.

Next, there were issues of scale to consider. I wanted to have missions that could potentially be around 20km by 20km in size. I also wanted everything in the editor world layout to be visible all at once without zooming or scrolling. Ultimately, I decided on a layout pixel size of 600×600, with every pixel being equal to 30 meters in real space. That was more than precise enough for my needs and resulted in a playing field of 18km by 18km.

My choice of scale had one unfortunate implication. The smallest unit of size that could be represented in my editor was 30m (1 pixel), but the fighters in Gateway are around 10 meters long, which was one-third of the smallest visible unit in my editor. Cruisers, being around 600 meters in size, could be represented to scale with 20×20 pixel sprites, but fighters posed a problem. I decided to simply make the fighter sprites larger than they would be in real space by several pixels in each direction, to allow easy visualization and selection with the mouse.

scale issues

Without some changes, the fighter sprites would absolutely be too minuscule to determine orientation, select with the mouse, or even see properly.

Next on the list was to decide the kinds of features I wanted to support in terms of building worlds. Tools like selection, translation, and rotation were essential. A ‘snap’ functionality would be immensely useful in terms of both moving (snap to grid) and rotating (snap to angle). Since I’ve used Blender a lot, I decided to support Blender-style keyboard shortcuts (which often don’t require modifier keys like shift or control) to make things familiar and faster: ‘A’ to toggle selections, ‘G’ for grab, ‘R’ for rotate, etc.

After about two weeks, I had a fully-working editor. It only had a minimal set of features, but that was all I needed.

sundial_screenshot

Level-building in progress. The player and a few wing mates are spawned far away from the action. The editor is just as much fun to use as it was to implement!

Team colours are represented by the highlights around objects. A grid in the background is used to determine distances. A few other tabbed panels are used for scripting music, dialogue, etc., and basically just contain multi-line text boxes.

Developing a level editor has been a very interesting and exciting experience for me. If anyone has experiences or stories working with level editors (including their own), I would love to hear about them in the comment section below.

GN


* As a side note, I have entire sketch books full of old game level designs from way back when. Maybe I’ll post some.

July 26 — Where I’m At

Well, here we are so far. A lot of work has been completed since the last progress report.

  • Voice recording and mastering is all done. That’s right. Every single line has been edited and made to sound like it’s coming over radio, so it’s all campaign-ready. I really enjoyed working with the individuals who were nice enough to offer their voice acting talents. (Finding enough actors was something I was initially concerned about, but many people were very willing to spend a half hour or so working with me to bring my characters to life. I’m very grateful for that.) There were a lot of bloopers filled with jokes and curse words. It made the editing process (which took hours upon hours) very entertaining.
  • The first 3 campaign missions have been built. These are shorter missions intended to gradually introduce features and familiarize the player with the controls, and are thus fairly simple. The remaining missions will be longer, but will probably be built quicker as I develop momentum (and gain familiarity with my own game engine…funny how that works). I have to say, it is incredibly exciting to see the action and hear my characters come to life in the way I imagined.
  • Various game play improvements. The targeting system has been improved, the computer players are smarter, bugs are being squashed…the list goes on.

Currently, my priority is getting the campaign finished. Building the missions not only advances the game towards completion, but also reveals bugs in the engine and helps identify game play issues.

Here is a screenshot from the third mission, Incursion, where a simple assault goes awry and the player’s forces are ambushed by the Coalition.

The player provides support during a mission to destroy a series of enemy network satellites.

The player provides support during a mission to destroy a series of enemy satellites.

Until next time.

GN

July 5 — Where I’m At

It’s only been a week since my last update, but there’s been a lot of good progress. I’ll keep this quick since there’s a few other things I’d like to tackle this evening. So, here we go:

  • Voice recording is nearly, nearly done. Unfortunately, I didn’t reach my goal of having all of the recording done by the end of the weekend. A lot was done this week, but I’m still looking for an actor for the last part (Admiral Banks). All of the other parts have been recorded, though, which means that I can go ahead and build the first eight missions.
  • Improved the cockpit. I decided that even my meager art skills couldn’t excuse the poor quality of the existing design. I spent a few days building and texturing a new cockpit model, which is shown below.

shot-1

  • Improved the missile system. The new system requires players to be smarter about how they launch their missiles; launches that are made too close to a target or not facing the target enough will only result in wasted ordnance.
  • Addressed a number of outstanding bugs and gameplay issues. All minor things, but there’s nothing like a quick demonstration to a colleague to make you realize there’s a lot that needs fixing. (“oops, that shouldn’t happen”, “still gotta fix that”, “that’s boring so I’ve left it until later”, etc.)

GN