next »

[JMStark]

Final Trailer:



Trailer #1:











Vacuous delivers balls-to-the-wall hard, twitchy action game play based around guiding a space-bomb-ship through obstacle courses. Back in high school, I developed a small game called Vacuum and Force as a physics project; Vacuous acts as the spiritual successor to that title. I’m usually not too keen on making the same thing again; however, in the case of Vacuum and Force I had always felt that I hadn’t come anywhere close to tapping its full potential. Through Vacuous, I intend to rectify this.

Original soundtrack by Joseph Elliott.

It is out now! Get it here: https://jmstark.itch.io/vacuous

Website: http://www.jmstark.net/games/vacuous/vacuousWebsite.html



Original Post

With Vacuous now out of the prototyping stage and issued into full-scale production, I thought it was time to start a dev-log on its progress for the purposes of organizing my thoughts and raising awareness (shameless marketing scheme). With this log entry, I will quickly describe the base premise of the game and then discuss some of the development process for the prototype.

In Vacuous, the player controls a spherical space-ship with four thrusters.



Each thruster corresponds to a given arrow key (or d-pad direction). Using these thrusters, the player carefully guides the ship through a series of hazards in an environment devoid of gravity and friction. This ship houses a touch-sensitive bomb; if it bumps into anything it explodes and the stage must be reset.

I have no ambitions to drench this relatively simple, arcade-y concept in a sludge of story stuff. My intuition says that Vacuous will be better without such (I mean not to dis narrative components in games generally speaking, mind you). All I will introduce is a basic premise revolving around freedom fighters in a gravity-less universe using millions of these bomb-ships to remotely destroy mind control devices installed by a corrupt state. The player’s task? Destroy all of the mind control machines. Thus, beat all of the game’s levels to win.



This screen capture from the prototype displays the variety of elements which compose the levels in Vacuous. Lasers, cannons, spinning walls, force fields, attractors, rejecters, and a few others which will remain nameless can be seen in this prototyping stage. Do not use this image to infer what the actual level design will look like; I know what is shown here is a mess. The purpose of such a chaotic stage was to test the interactions of game elements at a maximum complexity, looking to see what interactions would create problems.

Another interesting part of the prototype development involved the creation of a system which allowed for easy scripting of world elements to translate, rotate, and scale, allowing for all sorts of different hazards to be implemented swiftly. The nodes (small circles with arrows) in the above image are used to define and control this behavior.

For Vacuous, I decided to go with Game Maker Studio as my main development tool for several reasons. First, I have a strong familiarity with older versions of the software. Second, I got the Standard version for free and the Pro version for $25, making it a significantly cheaper option than Unity (an engine for which I had developed two Vacuous prototypes, one 3D and the other 2D). Third, though I roughly have the programming experience to either start from scratch or pick-up a free framework, I don’t have too much interest in all the extra work that path would entail (and so far, I don’t see what major benefits it would offer a rather mundane project such as this). I am interested to see how well Game Maker can handle my use of HD sprite work, since most games I see made with the program use pixel art. So far, it fairs well.

I hope that Vacuous can reach the level where I feel comfortable releasing it as commercial product (a first for me). For my next goal, I need to design a tileset system which allows for both well designed and beautiful levels, amongst other things. Onwards!

(Check out Vacuum and Force here to get a sense of what the game play of Vacuous will be like: http://www.indiedb.com/games/vacuum-and-force)

[JMStark]

In my last post I mentioned that I had created two prototypes for Vacuous using Unity. Let me make a correction; I had actually made three prototypes. One of those prototypes utilized the 2D part of the Unity engine and was identical to the prototype I developed in Game Maker Studio. However, the other two were attempts to create Vacuous using 3D graphics.

The first 3D prototype took a safe approach; essentially, it played the same as the 2D prototypes, but used 3D graphics. I believe the common term for this design choice is 2.5D. I dropped this style due to my inexperience in developing 3D assets, which would significantly slow down development time and give less-than-okay results art wise. Furthermore, the added visual complexity of 3D backgrounds and stages would more than likely harm the actual play. Even now as I try to develop 2D assets for building levels, I have had to make the decision to stay away from isometric platform styles (Commander Keen, Rayman Origins, Donkey Kong Country, etc.) since they add confusion as to where collisions occur, especially when there is no gravity. In Vacuous, understanding clearly and quickly where any deadly collisions may occur is vital.



My second 3D prototype for Vacuous tried to expand the original idea so as to take full advantage of being rendered in three dimensions. Instead of four thrusters, the ship was given six. This allowed the player to guide the bomb-ship on all three axes. While the idea was interesting, it made the issue of the player being unable to easily predict possible collisions even worse. Besides that, the added axis made controlling the ship too complicated. I experimented with playing the game in stereoscopic 3D using the Oculus Rift to properly judge depth and collisions, but that only offered marginal help (and the resolution of the OR actually ruined some of the clarity of what was occurring in game).

So, I decided to stick with 2D.

[Christian]

Can never have enough twitchy arcade games. And moving hazards are the best. Can't wait to see more

[JMStark]

Can never have enough twitchy arcade games. And moving hazards are the best. Can't wait to see more

Hahaha, well, when I read that description from someone else I see how vague a description that was. Glad to see it got you interested though!

After two days of screwing around with ideas and what not, I have developed a tileset system for Vacuous. While creating a tileset that can be used to construct more artificial environments is usually easy, building one which supports more natural spaces is challenging. The best solution, as can be seen used in some modern 2D platformers, is to use a dynamic node based system which allows for any sort of curves and angles to be implemented. However, for me to properly implement this would require the creation of my own custom level design tools, a task which does not fit my limited time schedule. Instead, I took inspiration for a solution from an obvious source: Super Mario Bros. 3. In that title, Nintendo was able to create rolling grassland hills and curvy cavernous interiors using square and sloped tiles exclusively. I could do the same; the question was, what tiles did I need to draw?

In previous projects my tilesets would be incredibly large for a single wall type (even excluding slopes) since every single permutation of edge and corner combination quickly added up. Below is an example from a fan game I developed called The Pac-Man:



Of course, these tiles themselves, depending on the nature of the wall pattern, can be derived from smaller tiles each representing edges and corners. For previous games, both creating and using these tilesets was incredibly time consuming. Since for Vacuous I intend to use hand-drawn 1080p quality assets, this method for creating stages was infeasible. Thankfully, Game Maker Studio seems to have added more features to room editor since 8.1, now allowing developers to set the rotation and scaling of placed objects in a room. Considering this I devised a method for crafting levels with the below tiles (shown in the original sketches):



Three different lengths and types of rock edges, an inner corner, an outer corner, 1:1 slopes, and 1:2 slopes (each with an upper and lower portion) make up the outer edging of a stage’s walls. Then, in the space behind the edging, I use a large, tiled texture fill in the walls. Each of the edging elements are rotated in the room editor, meaning they only need to be placed in memory for one orientation. The only hazard this brings is in regards to the addition of coloring and lighting, but careful thought allows that problem to be resolved (or so I think). Using this method I am able to create the rocky, floating mountains of the first environment in the game.

Besides this stuff, I added a whole bunch of other features into the game such as parallax scrolling backgrounds and stage completion. Though day by day development feels a tad slow (especially when I am doing art, a task I am certainly not a master at), I already have a semi-polished, playable demo with several levels after only two weeks of official development. Next week, I am going to start implementing the interface and overall menu structure.

[The Translocator]

You don't need that many tiles for a tileset for one ground type if you were working in Gamemaker when you made "The Pac-Man", because you can create transparent tiles for each edge or corner and simply overlay them onto the standard tile by deselecting the "Delete underlining" option in the room editor. This won't help much if you've already created the tileset, but hopefully it will help in the future- you only need to create the distinct sections once.

[JMStark]

You don't need that many tiles for a tileset for one ground type if you were working in Gamemaker when you made "The Pac-Man", because you can create transparent tiles for each edge or corner and simply overlay them onto the standard tile by deselecting the "Delete underlining" option in the room editor. This won't help much if you've already created the tileset, but hopefully it will help in the future- you only need to create the distinct sections once.

Yep, this is exactly the solution I've chosen for this project. Though to be fair, The Pac-Man contained tilesets which did need to follow this format, since their pattern couldn't be derived in that way.

Today, I do not have many words to share, but rather some footage (in .gif form) of the game. Hopefully this shows off how the art I described in my last post is implemented and clarifies the kind of play that can be expected from the game.

[JMStark]

This week I have planned to sort all of the basics regarding menus, settings, and saving/loading systems. A strange order of development I know, but I feel more confident developing game content when I know it meshes well with a pre-existing access infrastructure. While I will probably come back to these elements of Vacuous in the future when I need to waste time polishing stuff up, I intend to cover all the important stuff this week.

So far I have implemented the intro sequence which gives the company name and then flows into the title screen. In order to do this, I had to sort out the branding I intend to use, including my company logo (secret) and the title text of the game (also secret-ish).  I’m okay at design, but I’m not much of an artist. Since I’m running a faster than usual development schedule as just one dude, many decisions fall to the whims of intuition instead of meetings, research, and statistics (for better or worse). A game’s presentation is important both commercially and artistically. Part of that presentation is the branding.

Below are some sketches I did of potential text for the game title on the title screen. The one I chose to use is the one which is least crappy (I think…):


 
Those first ten seconds of a game’s opening have a profound impact on the user, both as a newcomer and veteran. As a newcomer, the opening sequence and title screen set the tone. As a veteran, they stand in the way of playing the game. The tricky design challenge is to balance the two; a short enough intro sequence not to bug those who boot up the game every day, but within that small time period, able to communicate all necessary information to the player and get them intrigued by the game to come. Another question regarding the opening sequence involves what parts of it can be skipped; a long opening cut scene, for instance, can both draw in new players and also be entirely passed over by veterans.

Next, menus. The most fun part of video game development.

[Guitarmatt21]

I like the two simple text ones in the middle of the screen, they are more how you say... vacuous in nature.

[JMStark]

Heh, yeah, its one of those which I chose to go with, for the reason you mention.

[JMStark]

I have been hard at work creating the menus which allow the user to access the game. Why develop these so soon? Well, I do want to get all of the boring menu/infrastructure bits out of the way so that I can focus on the actual production of game content. I also feel that these parts of a game define the patterns that the game production must follow. A little hard to put into words, but I can give an example. I want to develop the world map system before I create a ton of levels, since the way the world map works determines what levels need to be developed and how they get integrated into the game (both for general access and save systems).

For the menus in Vacuous I decided to just hard code everything using one object that runs controls a finite state machine. Abysmal architecture, but the menu system is simple enough that I can get away with a lazy hack job. At the very least, the menus do have slick and snappy animations. When that stuff is finished (sometime this week), I will show it off.

Anyways, here I present a screenshot of an early level in the game:

[JMStark]

Below I present how the front menu of the game currently looks:



There are quite a few interesting objects of significance to point out from this screen. First, the game’s title logo makes its first appearance. The thin lines and spacious kerning reflect the emptiness the title speaks of. And in an attempt to also quietly convey that Vacuous has a science fiction theme, the letters themselves are similar in composition to the letters on a digital clock (though they cannot be strictly derived from one of those screens). This version of the title logo also has a few odd letter segment spacing issues which have been sorted out in a later version.

My intentions were to keep the menu screen clean and simple in a way which was non-intrusive, but pretty. As a non-artist, I think I have done okay, but I might need to add a little more background life somehow (the distant sun currently has some animation in that its glow fades and grows along a sine wave). I have made the tiles and titles of the menu animate slickly as they transition from menu page to menu page, giving a polished, alive look, but have also made sure that access to the actual game play from the game boot-up is under 30 seconds.

One incredibly subtle thing of note to point out here is that in this screen the game is actually running at a 4:3 resolution (1024x768). While the game is developed with 16:9 in mind (I get the impression this is now the default aspect ratio for entertainment media), I also have made sure that the game works fully with both 4:3 resolutions and 16:10 resolutions. If it so happened that another aspect ratio beyond those warranted support, adding it to the game now would be trivial.

Finally, I have fully added gamepad support. In the menu screenshot, keyboard button prompts can be seen.  If the player is using a gamepad, button prompts based on the popular Xbox controller will instead be used. The only uncertainty here is the legal ramifications of using facsimiles of these buttons in my game. If anyone knows whether or not Microsoft will screw me over on this, I would like to know! (I am guessing not, since I developed the assets myself and they only loosely resemble the Xbox 360 buttons, but with lawyers you never know).

With most of the menu fully operationally now, the next step is to finish the world map screens and the save/load system and then get to work building the actual game.

[JMStark]

This week I finished the level selection system and built, playtested, and finalized all of the levels for the first world. With these two achievements out of the way, I feel comfortable saying that Vacuous is around 10% complete.

Let me talk a bit about the design behind the level menu. I love Super Mario World, and I especially love its world map. It is colorfully drawn and tells a story about the game world, but most importantly it fills the game with a sense of adventure and mystery. I have once before tried to emulate what this game captures in a previous game (The Pac-Man, shown below), but had to cut it due to performance and development time issues, resulting in a final game with no hidden secrets whatsoever.



With the map system (if you could call it that) for Vacuous, I decided to focus on both ease of access and yet still allow room for a bit of that Super Mario World-like mystery. I ended up with a concept which I pitched to myself as being “a bingo board combined with a traditional world map.” The level select screen consists of a grid of preview tiles such as these below:



Beating a level unlocks all of the levels adjacent to it, giving the player alternative stage options to choose from if they get stuck on a particular level. Some of the tiles on the map are hidden however; these are the secret levels. They are only unlocked and made visible when the player collects a mystery orb in one of the adjacent stages.

Further secrets will be unraveled as the player beats secret levels, though I haven’t fully ironed out the details of those yet. However, I do hope to implement layers of secrets, similar to how Special World is hidden behind Star Road in Super Mario World.

Now the fun part of development begins; from here, most of my posts on this dev-log will be about environment art design, game element programming, and level design. I’ll also be ironing out some business stuff on the side and get a website up and running.

Also, it is approaching the time when I get a musician involved in the project. If you have any interest in this role, contact me! I’ll provide more details privately.

[JMStark]

As a way to brainstorm the different environments that will appear in Vacuous, I have been sketching up some rough concept pieces. There is actually more going on with this process than just thinking up a cool idea for a place in the game; with the concept art, I try to consider what system of assets (like the tile sets I discussed earlier) will need to be created in order to construct the environment. I also think about how efficiently I can construct new levels with these assets and whether or not the scenes consist of objects that I can actually render in my drawings in at least a semi-appealing way.

Furthermore, the order of environments in the game is very important to consider. Thematically, there should be some sort of escalation in the types of environments the player encounters as they proceed through the game. Likewise, for gameplay purposes worlds whose themes tend towards challenging play should be placed further towards the end. Mario titles start with grasslands and end with volcanic wastelands; Sonic titles start with bright beaches and end with high-tech factories, etc. Not to say that this thematic progression has  no alternative, or is not worth subverting, but when it is executed well it lends itself to world building in a subtle, brilliant way (from what I have planned, Vacuous does actually subvert it to some extent).

And now, a selection of the concept work:

[JMStark]

The alternate world rears its ugly head.

[afilionComposer]

Looks amazing so far!

Sent you a PM

[JMStark]

Today I got to add a really fun feature to Vacuous: alternative color schemes. I’ve always thought that good looking color schemes can serve as satisfying unlockables. They allow the player to personalize how the game looks. In some of the Kirby games I played on GBA as a kid, the player could find spray paint that would then allow them to change Kirby’s color palette. This feature in Vacuous is inspired by that.

I am quite a fan of color, so I had a good time coming up with alternate ship palettes. Here is a tiny sampling of the color palettes I was able to come up with:



Each color swap has a unique name associated with it (above are Clean, Rust, Serpent, and Water). These palette names add an extra bit of character to the color selection.

[JMStark]

Part of today I spent time experimenting with control schemes and thinking about them really, really hard.

Even though I had designed Vacuous with keyboard input in mind, I wanted to implement support for game pads such as those for Xbox 360, PS4, and Xbox One. A large audience of PC gamers (including myself) have shifted over to using primarily game pads for computer games due to the large amount of console ports and the increase in living room PC gaming. Both this and the possibility of porting to other platforms in the future (PS4, Xbox One, Vita) led me to take game controllers quite seriously.

Vacuous is an odd case that actually plays better with keyboard arrow keys. Since the entire game is about balancing the forces applied to the ship via thrust in a gravity-less environment, player input involves quick and light taps on the thrusters to get the ideal net velocity. The arrow keys, with each being separate yet very close together, provide the most ideal input mechanism for this.

I first tried the control scheme of just assigning each thruster a d-pad direction. This worked okay, though not as good as the arrow keys. The d-pad is designed to be held down in one direction only, instead of being tapped in many directions rapidly.

The second control scheme I tried was assigning each analog stick axis direction to a thruster. This was awful. Just like the d-pad, the analog sticks are meant to be held in only one direction. But unlike a d-pad, the analog sticks were even further removed from the tapping form of input, making it difficult to do any precise maneuvering. Analog sticks are amazing and have great features, but the design of Vacuous is unable to take advantage of any of them.

The third control scheme I tried, and the best one, was a bit nontraditional. I assigned each face button (A,B,X,Y) to a thruster.  This worked close to as good as the arrow keys; the analog between the two is pretty clear. Both are separate buttons which are conducive to lots of tapping. However, it is very odd to use the face buttons for movement (odd in a good way!)

At the moment, Vacuous recognizes both the d-pad arrangement and the face button arrangement as input. The real worry is in regards to whether or not a certain control scheme makes the game unplayable or unbeatable. I'm going to venture to guess the analog stick scheme did. And in this regard, I also have at the moment decided against implementing fully customizable controls; Vacuous is a very simple, four button game and I have already implemented every possibly reasonable scheme to select from. It is interesting to think that if in a game like say, Half-Life 2, if the player were to assign each function to a random key (even movement controls), the game itself would become completely unplayable (an interesting thought, not an argument against customizable controls).

I have applied a similar, but not identical kind of thinking to how I handled the alternative color schemes I discussed in the previous post. It would have been pretty easy to just give the player a bunch of HSV sliders and give them the possibility to make every color scheme conceivable. However, as a player it is often times easier to just choose from a selection of fine-tuned color schemes which all look good rather than trying to come up with one.

[JMStark]

Most of the work for the past two weeks has involved lots of polishing, some businessing, and a bit of making-world-2-ing. Of these three activities, I can talk about polishing.

First, I fixed several bugs. Currently, my development process is an absolute mess (and I just took a software engineering class in college too). Basically, at the moment I add everything I can think of for a certain feature to work and then try to see if it does. If it doesn’t, I add the missing parts. Sometimes this might break horrifically later down the line.

I added additional functionality to the level selection screens to inform players as to which levels they must beat in order to progress and which stages are optional. I also added unlock messages, where if the player unlocks a world or skin after having beaten a level, the game informs them of such when they return to the map screen.

Part of the polishing had to do with intro, death, and conclusion sequences for the individual levels, something that many gamers and beginning developers don’t even notice as a part of the game. When a level begins, the screen fades from black into the starting section as the player’s ship teleports into position. Once the black has fully faded and the ship has fully phased in, the player gains control. This sequence is very quick (less than a second, actually) but adds an extra layer of professional flair to the game and even a bit of narrative context.

The death sequence has been made to be quick, so as to lower player frustration and waiting. First, on ship impact, the game pauses for a very brief moment (1/60 of a second). This is similar to what the Mario games do, showing the player very clearly that they indeed made a mistake (lowers frustration by showing the valid collisions at play) and helps add shock to the explosion to follow. After the quick explosion, there is a fade to white and then fade from white into the stage intro. To accomplish this pause, I take a screen of the current game state, save it to memory, deactivate all of the current game instances, and then display the screenshot I saved. This caused a game crashing bug simply because I forgot to delete the screens, leading to an overflow of whatever heap is allocated by Game Maker Studio (or whatever happens behind the scenes there).

Finally, the winning sequence involves celebratory text as in the example below:



Again, this text helps ever so slightly to provide basic context and world building. I might add more flair to the victory sequence later, but that depends on whether or not sound the design is able to do the rest of the work.

My current goal is to finish creating all of the graphical assets, gameplay elements, and menu systems before I return to school so that the only major development task I need to accomplish when I am more burdened is level design, the part I have the most motivation to do. Let’s see how this goes!

[JMStark]

Both world 2 and world 3 (normal and alternate) are asset and code complete (barring bugs which are sure to show up in later iterations of testing). As I wait to evaluate whether or not I should look into using a different process for creating art (right now it is basically pencil sketch > scanner > ink and paint in GIMP with Bamboo tablet > done, but I’m thinking of using a tablet computer screen for a better feel), I am doing some level design for world 2.

Recently I have had to code additional gameplay elements into Vacuous to properly pace out the introduction of new ideas. Core to my design philosophy is the pursuit of being highly economical and responsible with how I treat the player’s time; never do I want to waste it with hours of traversing an empty game world or mindlessly proceeding through a checklist of items to collect. Every single level has a new idea and experience. For practicality reasons, this doesn’t mean that each stage has a unique programmed game play element, but each level does tout a fundamentally unique arrangement of elements exclusive to it alone (World 1 has 32 levels, and I’m estimating the total game will be anywhere from 250 to 400 levels in size when finished). The player consistently encounters unfamiliar challenges, each with the purpose of growing their skill and pushing them forward (ever so slightly) as a person.

When adding many systems and objects into a game, the programmer must think through all the possible interactions that those elements can have with each other. If this is done, these elements can then be combined in the level design confidently to create a slew of interesting scenarios, some of which might be discovered through emergent behavior. To keep track of all of these interactions I set up a symmetric matrix within a spreadsheet like below:



As I need to return here and there to code new game objects for a world, having this documentation is very useful for being reminded of how everything responds to each other, and then having a list of which other objects the newly programmed one must be taught to handle. Oh, and here’s a look at world 3:

[JMStark]

It has been a while since an update in here. Do not fret, progress on the game has continued steadily and I have reached the 1/3 point in regards to art, the 7/8 point in terms of code, and the 1/8 point in terms of level design. Beyond this, the menus, infrastructure, etc. is all done. So content content content until January seems to be the norm from here on out.

I just released a trailer for the game which should really help to let people know how Vacuous plays and drum up some more interest in the project:





Along with this, I also spruced up the first post a bit to be more welcoming/official/exciting. Sometime here down the line I'll have some more video content showing World 3. Onwards!