Ludum Dare 39 - Universe Hopper

Sunday, 6 August 2017




Play On
Ludum DareItch.io - Newgrounds


Made in 78 hours for Ludum Dare 39's 'Running Out Of Power' theme. 
Click and hold to use your space grapple to find your loved one before your fuel runs out.

Postmortem:

@FlorinGusa: I think the project went well, we had a lot of fun putting the game together and coming up with game mechanics. We learnt a lot, at least I feel like I did. I'm proud of what we've accomplished with the game and looking forward to doing it again. I wish we spent more time on organizing code because almost everything kind of turned into chaos near the end. I'm also really proud of the other people who worked on the game, we kept each other from wanting to give up and there was always a great atmosphere. 

We also worked really well together, we kept each other updated on things we were working on and never really stepped on each others feet. There are a few things we could have done better however, I really regret not making more levels and adding more content towards the finish line. There are many ideas that the others and I had but never got to adding them. I feel like we should have worked more on the  sound effects side of things, the music felt perfect but the sound effects lacked for me. We should really focus more on sound next time around. Overall I think this project was a great learning experience in both teamwork and game development, can't wait until the next jam! 

@Sanojian:
This time around we split up our source files and notified each other whenever we made changes.  This cut down (but did not eliminate) time-eating merge conflicts.  Conflicts are almost inevitable in a project like this where all code is created from scratch but an avoidance strategy is hugely preferable to the dreaded git merge conflict error message.

Big timezone differences between members don't make things impossible, but they really make it harder.  We did not agree on a set time to work together so some of our members completely missed each other for the entire first day.  This led to some disagreements on the direction of the game, hard feelings about left-out ideas, and wasted development time.  Next time we should probably all agree on a time near the beginning to sit together for at least an hour and talk about ideas and come to an agreement.

@LaxVikingGames: As the artist for the project, this was my second Ludum Dare with the SCS team. I enjoyed doing the art, though I had far less time to contribute to the project than I did with Infectoids now that I've started a day job. Thankfully to make my job easier, Florin and Jonas supplied me with all the temporary art that I could style at my leisure, bringing you the game you see now.


Ludum Dare 38 - Infectoids

Thursday, 27 April 2017

We took a break from SCS this past weekend to participate as a group in Ludum Dare 38's Small World theme.

This is the game we came up with in that time, Infectoids.

Play it directly here.

Roadmap Going Forward

Friday, 24 March 2017

Hello everyone!

The first order of buisness, we now have a public Discord. Feel free to stop by and say hello, ask questions, or show your support.

It's been a while since the internal playtest. Feedback was good. The holidays came and went. We've taken this time to iron out where we want to go and what the road-map for the future is.

Public Demo is the big milestone we're aiming for. Internal playtests were favorable, and we really want to get the game into as many hands as possible while moving ahead. To support a wide release however, we're looking at restructuring some of the behind the scenes how matchmaking and server code works. Currently the engine takes every and any two connections it receives, and pairs them up with each other. For internal multiplayer testing, this works fine, but for a wide audience, some kind of server browsing will be necessary to see who is playing and be able to pair up with the people you want to pair against.

If the public demo goes over favorably, we have a few irons in the fire we are considering, mainly facing the realities of developing a full game, which means bringing on more people, considering sources of funding such as crowdfunding campaigns, and boosting our signal to get more notice by the public at large.

Looking For A New Programmer on that topic, getting out the public demo in any amount of time will be an undertaking in itself, so in that regard we've opened up our doors and are extending out feelers looking to bring another programmer on board in a permanent position. The team has agreed we're looking for someone who is experienced with Phaser already, who can slot into the process and hopefully stay with us until launch, do work on various aspects of the game from odds and ends, to helping with things like pathfinding and AI.

If you're interested, we have a post on the HTML5Gamedev forums with more information, or you can contact us at our email, on twitter, or on the new public discord.


Playtest Results

Thursday, 27 October 2016

The first wave of playtests has ended now, to promising feedback. Our initial playtest protocol was refined across the many playtests until we reached a smooth streamlined process, complete with local recording of matches for later review, a lengthy questionnaire covering various aspects of the game, and free-form comments from the playtesters.

Major points of feedback:
  • The Unit Watcher was not well understood. Pictured right, the watcher shows the same basic 'selected unit' info as any other conventional RTS, albeit in a more compressed format. Unit name, picture, health bar, defense, and attack damage against all other unit armor types is listed out vertically. The small blue dot indicates what type of armor this unit itself possesses. Sadly we are taxed for HUD space and cannot display this data anywhere else or in an expanded format without nearly a complete HUD overhaul, but I agree there is room for improvement.
  • Terrain defense and speed bonuses were also not well understood. Another problem area for playtesters was the effects and benefits of terrain on their units. Unique to SCS' gameplay, the type of terrain a unique is moving over widely affects its speed and defense. Continuing the Starcraft comparisons, a Stalker will always move the same speed anywhere on the map, and always deal the same damage any target it shoots. In SCS, moving through trees and mountains will buff up your defense with the cover they provide, while greatly diminishing their move speed. Inversely, roads make units move faster than they would otherwise, while providing them next to no defense against unexpected attacks.
    These two areas struck us as problem places that require attention, because these speed and defense buffs are integral to the core gameplay design, not something we are about to just toss out because playtesters didn't understand them. They need to be represented in such a way that its obvious and natural that a marine moves faster than a tank would in Woods or that a Tank cannot pass over Mountains the way a soldier can.
  • Some units were God Units. Part of playtesting is always the balancing, and while our initial balance was good, nothing shows its flaws like outside players given a chance to try to exploit it. Very rapidly we were shown which units were 'god units', capable of beating nearly any other or being too cost effective. Sidecar Scout Bikes rapidly proved themselves to be the single most powerful unit in almost all matchups, in large numbers even overpowering tanks meant to be their counter. Healing units such as Medics and Engineers also rated highly due to their ability to keep said Bikes and other units alive a bit too effectively, able to out-heal most incoming damage with ease. A quote from one of the playtesters:
    "Rush bikes, I win if my bike comes up before he can defend against it, I lose if he counters it."
  •  Without CO powers, it was easy to build game-winning momentum. In the current tested build, the key element meant to counteract steamrolling momentum is not yet finished so wasn't implemented, and as the players become more skillful with their unit composition, it showed. Rapidly capturing half the map/s points proved the income difference was usually enough to guarantee a win depending on player skill, as there were still some dramatic turnarounds when players out-positioned their opponents.
  • Improved unit control was the most requested feature by far, as basic commands such as Hold Position were barely implemented, and others such as Patrol completely nonexistent. Better player information also was highly rated, tooltips being second most requested as without previous knowledge of the game, there is very little to tell you what that an Attack Dog can't attack tanks, or what the tank with the long barrel is a Tank Destroyer.
Major planned changes consist of:
  • Locking the mouse cursor to the game screen. A common problem almost all the playtesters had was with the fact that the game doesn't lock your cursor into its own window. It runs in a browser but we as devs had become so used to using arrow keys to pan the camera that we didn't realize how much people relied on edge panning.
  • Tweaks to Attack-Move behaviour. Another oversight of ours was how ingrained the RTS standardized controls are to RTS players. For example, in Starcraft, you press 'A' to order an attack, then left click the location or target you wish to attack. in SCS, A is held down and then right click is used to issue the order, like any other targeted action. This confused several of our playtesters who were used to Starcraft's style, and while both have merits, it might be easier to follow their conventions.
  • Better Visual Feedback. Given that none of the playtesters in this circuit had experience with the game before, we found it very common for them to miss things that we thought were 'obvious' after having played the game for 1,000+ hours ourselves. Your headquarters being captured was the most prominent, as its loss spells your defeat. Playtesters wouldn't notice it being captured because the only 'announcement' of this was just a sinking bar next to the structure indicating capture progress.
  • Unit-building Structures beyond the HQ were universally ignored. This one is a bit tougher to rectify. In most matches, even when facing an opponent attempting to play a teaching match, playtesters wouldn't realize that structures other than their initial HQ could be selected and produce units, even when watching units appear from no where atop those structures for the enemy side. Even the experienced players in times of stress would default to only building at their HQ, instead of the multitude of Factories across maps.
  • Mousewheel to Zoom. This one is a bit tentative as it has to be done right or else the pixel art graphic style will get all blown up from mis-scaled pixels. We've squashed dozens of strange pixel glitching and artifacting in the past that scaling for a zoom is a can of worms to open up again.
Thanks to our rigorous quality controls, bugs were few and far between. High lag occurred when a match was run overseas from Canada to the UK, but beyond that there were next to no desynchronization issues. Occasional graphical glitches such as sprites overlapping that shouldn't popped up, but were easy rendering order fixes to be squashed,

As for moving ahead, the waters are still murky as we plan out when/how public releases will be done, the development schedule of features new and old, and evaluating this feedback and its benefits to further development.

Internal Alpha Testing

Saturday, 27 August 2016


Internal alpha testing has finally begun. Above is recorded footage of one of our first matches between myself and the programmer before we start to bring in outsiders to test. In this test candidate, there are:
  • No Collisions. Collision code is a bit of a rats nest and challenge to work so for virtue of time, we cut collisions for the tests rather than using the half finished, buggy collision code.
  • Land Units Only. Water and Air units are in the definitions but not fully tested, so they're disabled for play still.
  • Sound and music is all placeholders. You may recognize a few. The title screen music is open licence free, and the in-match song is composed by Scarlet Moon Productions.
  • Limited Hotkeys: As you can see in the video, I have to manually click on every unit to buy them. In future builds, you'll be able to buy units with keyboard keypresses like any other RTS.
Where are we headed?

From this point forward, we're going to be conducting test matches and tweaking the game balance and implementing juice and quality of life features from our testers feedback. Once the matches are all done, we will have more to show then.

Complete CO Overhaul

Tuesday, 5 July 2016


If you've been following us on Twitter over the past few weeks you'd have seen the steady progress fixing ant bits, spots, design issues, and general revamp and polish on all the existing COs.

The redesigns range from subtle (Bradshaw barely changed at all) to complete and total redraw of the Bomb Disposal woman. Of all the designs, the Bombsuit woman I did not expect to take as long as it did, while I left the Gasmask guy (Smiles) for last fearing he'd take the most effort.

Time Lapse of a CO

Wednesday, 8 June 2016

This week on Twitter I've been speaking to one of the developers of Fabular: Once Upon A Space Time and with their okay, spend some time drawing the Lost Count, a character from the game as a CO in Super Combat Squadron.

It took just over four hours from start to finish, starting with rough sketches that are cleaned up, shrunk down, and eventually turned into what you see on the right.

I recorded myself while working this time so you can see the full four hours just bellow compressed down into one ten minute video of the Lost Count from Fabular from conception to final product.





The Command Card

Thursday, 2 June 2016


Big design block on how the command card is going to work, as well as what kind of actions you can order your units to take. All the usual actions you can expect from an RTS are there, from Moving and Attacking to Patroling and Holding Position. 

The Building Queue

Tuesday, 31 May 2016


The building units design doc. Pictured above is the current design sketch explaining how unit buying/building was meant to work. It went through many iterations to reach this point.

It's all pretty cut and dry, but features that have been in flux since this point:

  • This design shows 4 units in the queue but we've begun to considered that we could squish them together with some overlap to fix more, as much as 8 or 10 without losing visible recognition.
  • The bar that fills up to show you progress/time before the unit is produced is quite small, so a building animation was also came up with to show building on the main game space.

Capture Logic

Friday, 27 May 2016

Today we're looking at capture logic:



Both the art and code behind capture points changed multiple times over the game's development (and still has some changes to go) before coming to the state it's at now. In the current iteration, we've settled on this push/pull design with directions and destinations.

For this example, we use Team Red and Team Blue, but this math works with any number of colors or players. Placing a unit on a Neutral un-owned capture point begins the capture process; filling a bar until its full and giving you control of that point.

Captured points provide income over time to their controlling player or team, or in the case of Factories, Seaports, and Airports, construction of Land, Sea, and Air units.

What happens however if your capture doesn't go off so cleanly? If your unit stops capturing for any reason, there is a short delay whereupon it begins de-capturing back to whatever it's default state should be; neutral or team-owned.

 If your point is almost captured back to Neutral but not completely pushed there, you can recapture your own point back faster than if you let it go completely to Neutral ownership and start to be captured towards the enemy team.

With a push and pull perspective, the point is always pulling towards a state, and units can either fight against this flow, or ride with it, aiding it to get to its destination even faster.

In the above design sketch, in examples A and C, the point's native recapture speed is suspended as the unit performs his capture. Unit capture speeds are based on how much HP the unit has; damaged units capture at much slower rates than healthy full HP units.

In B and D however, the capturing unit is actually assisting the point's inherent capture speed, adding his own speed to the mix and incentivising you to assist in recapturing points rather than just letting them time back out naturally.


Devblog 2.0

Friday, 20 May 2016

I'm proud to declare the retrofit of this devblog complete.

It took just under a month from start to finish. I realized that the blog's original look was aging badly and holding us back as production on the game ramped up, and that it was time to give it a new coat of paint to better represent the game.

The old look was grey and drab, as shown here.


So I took it upon myself to draw a new design. This is the design sketch I mocked up in Photoshop on April 24 as my vision of the new look.


As you can see, as it was implemented certain design aspects evolved into new shapes. Tapered edges turned out to be more trouble than they were worth. The Twitter widget was broken for a long period of time, finally fixed by disabling "Exclude Replies" as for whatever reason, this was excluding all our tweets.

I didn't do this all myself however as CSS and HTML are not my primary skillset by any means. A friend of mine Esther put in a few hours guiding me in the proper ways to margin, border, background, and generally improve the website as a whole, so they deserve 50% to 99% of the credit.

Along with updating the look, I'm also proud to announce our official Subreddit (now linked under the Forum button) as well also took the time to go over the Media and About tabs that had been long since neglected. They now contain more up to date screenshots, the pre-alpha trailer, and a blurb about the game and our team.


On-Going Update

Sunday, 15 May 2016

As you may have seen, the devblog is in the middle of undergoing some changes right now. The old look just didn't match the game's current vision, so some time and dev cycles are being taken to spruce this place up and give a better image for everyone.

In the interim the site may look a little messy around the edges until its all smoothed out. Buckle your pants for that!

Communication is Key

Saturday, 23 April 2016

With the addition of our new project manager, we've adopted a few new practices that have enabled us to start to develop again, primarily among them the Sprint methodology.

Every Monday we (digitally) sit down and have a meeting discussing the sprint; a small slice of the large pie to focus on for the week such as designing and implementing a new font, team-coloring all the GUI assets, or setting up an asset sharing platform for all the team members. 

Once we iron out the week's goals each morning we perform a stand-up meeting focusing on the big three questions:


  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What obstacles are impeding my progress?

This has proved invaluable to our productivity. It's almost become an in-joke to shout "My status is blocked!" Knowing what you've done, what you are going to do, and letting the team know if there is something you need them to do to progress something you are working on has greased the development wheels immensely.

Communication is key though; proper communication. Posting bug reports or screenshots to Skype logs is fast and easy in the moment but ends up lost in minutes as soon as something else is said. Trello is our acting bug tracker, backlog, and sprint manager, as you've seen posted before. It's very useful for sorting and tagging members to specific cards. We use labels for User Stories, Programming cards, Bugs, Graphics work, and general Tasks, all of which can be filtered by.

So what is in store for our next sprint? You'll have to check back to see the minutes Monday.

State Of The Game 2016

Thursday, 14 April 2016

Hello everyone, it's been a long time.

Where have we been? For a while, the game went on hiatus, but we are back now. We've brought a project manager on board and expanded the role of game designer. As of roughly three months ago, the game has resumed active development. A new programmer was brought in and with his help we have started to set up sprints and meet daily goals.


Trello, our team's management platform showcasing the active cards.

What has been done? Extensive bug fixing to make multiplayer stable and implemented tons of missing features to make game play closer to the vision, the map format has been overhauled to support a more user friendly format. The terrain atlas has been restructured and expanded from 512x512 to 1024x1024. The HUD was tossed out in favor of a new style. Collision maps have been added for the multitude of terrain types. We expanded and clarified the roles of game designer and project manager; who developed a more disciplined development methodology based on sprint and agile techniques.

Where are we going? The current goals are:

  • Internal Alpha - Internally we've been working hard to make sure the game runs smoothly and patching anything that prevents this such as multiplayer desynchonization issues.
  • Closed Alpha - Once the game runs cleanly internally, testing with a broader audience will begin initially only open to close friends to gather feedback.
  • Open Alpha - With the changes brought on by external feedback in place, we plan to release a demo version that, while far from feature complete, should have all existing systems fully functional including online matchmaking. 


Most recent screenshot of the game running, featuring an entirely new UI.

Update 4.5 : Pre-Match Lobby Concepts.

Tuesday, 14 April 2015

A lot of these are very much identical with only minor variations between them, but I figured I'd post all the iterations the lobby UI underwent before I ultimately returned to my first original design and added scroll buttons.


Update # 4: Match Lobby UI.

Sunday, 12 April 2015


First sketch of the pre-match lobby. I have a few concerns with this first initial design.

Design cues were inspired by games like Dota, League, and Fighting games like Street Fighter. I do wish we could fit the 'Huge central CO portrait that scrolls left and right to other COs' like how Dota uses, there's just too much other important information to show at the same time to have your single player portrait take up the center stage.

Not a whole lot of room for Team Chat, as you can see in the bottom left. This stems from the problem that CO. portraits cannot be smaller than those squares, so they take up a large amount of space. While we may only have 4 CO.'s at the moment, I plan on expanding this roster a great deal to the point that if the images are that large, some kind of alternative solution may be necessary as I'm not a huge fan of the scroll-bar. Search is nice to help alleviate that, but only works if you know exactly which CO you plan on being.

Super Combat Squadron will feature a map editor and custom user maps, so knowing the layout of the map you are about to enter is important, so the map preview takes front and center stage. Were this a 1v1 match, the banners on the sides with your teammate's CO portraits would not exist, and it would show you only you and your enemy. Right now the teammate banner colors should reflect their team color, and could use a bit more contrast.

CO powers are snug in the center of the screen. They change to reflect whichever CO you have chosen, and mousing over them/selecting them will bring up a tooltip that will explain precisely what they do.

My biggest concern right now is I don't like windows-looking scroll-bars, but I don't want to split the CO selection menu into another screen or something, so more room for CO's will have to figured out somewhere.

History and Future of the UI

Tuesday, 31 March 2015

The UI is one of the first things I started to work on before Super Combat Squadron even had a name.

The original development title we used internally was simply "Swat Game" despite the fact that the game did not feature Swat teams in any capacity. Even now the folder I keep my development assets in is called "Swat".

The earliest screenshot I can show you. At this point in time, there was no game, there was no code, Super Combat Squadron was nothing but an idea. The idea of hotkeys didn't exist yet, neither did a minimap. The hud was concepted out over top of a screenshot from AW.

In the bottom right you can see a small button for 'Move, Attack, Hold, and Patrol' commands, but this element would be dropped in later versions.




The next version after that. It looks the same over all, but here we've added the idea of a Minimap, the panel readout of information on the unit you are selecting has been expanded to represent the effects of the terrain on its stats, and already the MAHP button is gone, replaced by the Build menu. (now given a B hotkey)

No code existed still as of yet.





Above is the first major milestone in Super Combat Squadron development. AW background was thrown out. The idea of having 'Commanders' was finally given representation, and their ability to have abilities, shown by the atomic bomb with the Q hotkey. I tossed together a quick temp sprite based off of the Fire Emblem sprite heads and for the first time we conceived of having a much larger screen-space as things had started to become very cluttered.

Things moved rapidly at this point. The sprite art was deemed too small and thrown out in favor of the large sprites we'd eventually adopt. Nell from AW was used as a placeholder to judge the size of character sprites, and ideas such as a Day/Night cycle clock were experimented with at the top, and how many powers a CO would have, similar to a hero you would see in a MOBA game like League or Dota.

The Minimap has grown enormously but now we're struggling to find places for all the information that needs to be read out to the player at any given moment.

Starting to look familiar now isn't it? The Temp CO is moved to the right side, the information read-out stays relatively unchanged from this point onward however the Minimap square proves to be too small for practical purposes.

'Experience' points are tested out for the CO. as well as you saw in the previous design. No solid place for these has yet been figured out, and the name plate under the hero is still temp.



And now we've finally reached today. In concept art, we have our own nice font for things but that is as of yet not implemented in-engine. The CO is missing an experience bar, and a plaque with their name on it. The Minimap has grown ever larger. The Build button still exists in the bottom left but as of now it serves no purpose, building is done by clicking on the structure itself.

It's almost due for another strong evaluation again. We want to target both PC and Mobile markets so its important to consider things like 'When you only have a single finger to click, you cant do things like hotkeys, control groups, precise hitboxes for selecting things, or all sorts of fancy controls that the PC can.

Thing's that are unsatisfactory about the current HUD for me:

  • The CO's name has no place anywhere, and perhaps the CO image is too large as it is now?
  • They aren't shown here but I would like to have a bar along the bottom middle showing off the various CO abilities (yet unimplemented) and in the same location will likely be where CO. experience will be shown. 
  • Just as important as your own CO is the CO's of your enemies and allies. Popular MOBA place thumbnails of them in places like along the top bar or lined up on the left, which are both places to consider.
  • In every HUD version but the current, the number and types of units you have fielded show on the left, a feature I'd like to see implemented again, but the code is just not quite there yet. It In the same place should be read-outs on how many flags and building structures you posses as well. 
What do you think? The GUI is far from complete or perfect, and every version tweaks it slightly. Perhaps the Minimap will move to the bottom left corner and the info readout will become lengthwise again? Only the future will tell.

Update #3 - Updating Old Assets

Comparisons to AW are inevitable. We understood that from the start. That was partially the point. When your sprites are 16x16, blue, and cute military shapes, there's not a whole lot you can do to shake that comparison.

That being said, as the artist here I put in a great deal of time and effort trying my best to establish our own unique looks and designs for units. A lot of the early alpha artwork hit too close to home for everyone's comfort level, so over the last few days I've been spending my time going back and re-doing early artwork.

Attached bellow is a large pool of how I develop the units for Super Combat Squadron. It may look like from the outside that I just iron out a new unit bam all at once, but it actually takes a great many iterations and trial and error on my part before I stumble into a design I think works.


Top Left: The redesigns for the rocket car and long range Anti Air missle launcher. The originals as mentioned looked far too close to home and needed a complete overhaul.

Top Right: Very early artwork I did for the cars, APCs, and heavy rocket infanty. The nozzle on the gun took many attempts to get a shape I was satisfied with.

Bellow the two of those in the middle are the now outdated AA Machine Gun Tank and Heavy Tank designs, which all iterate too close to AW, and since then I've already designed the Heavy Tank into its new state, seen bellow in the Bottom Right.

The last unit who is going to undergo these changes is the aforementioned AA Machine Gun tank, which will be getting a new look in the coming days.

EDIT: While we're talking about it, I have another nice tidbit for you all. I keep all my work from the earliest designs, I have here the earliest building iterations to show off:


Many designs never saw the light of day, or were done simply for fun, like a random fist build. Maybe in the future they'll see use again, but for now they languish on my harddrive.

General Revamp

Tuesday, 17 March 2015


As I work on newer and newer commanders, the early ones start to look worse in comparison to the improved style of the later ones, so today I spent a great deal of today simply touching up all the commanders, fixing jagged edges I missed initially, changing parts I was unsatisfied with, and general polish.

As of yet they're still far from the final complete ready for launch final versions, but with each pass they get closer to that eventual state. These four will likely be the only commanders you see for a while as there are lots of other areas that need artwork, and four is a nice round number to do testing with once we've gotten to the point we can implement the distinct gameplay difference commanders bring.

Designing a Commander

Friday, 6 March 2015

Hey everyone, today I'm going to take you through the process I use to make the game's Commanding Officers.

As always, the first step is gather references. You might feel like you have enough creative juice in your head to do it from imagination alone, but it still helps. Once you have an idea in your mind, it's time to draw!

To the left is my first drawing. I did it entirely in black then masked out details afterwards, though the masking part isn't necessary. It's very important your character have a recognizable silhouette, as he or she will be among many other COs and you need to be able to recognize the character at a glance without wondering if something is an arm or a gun or a leg or something.

On the right is my second pass, now that I have the character design in mind, I go about drawing the silhouette for the actual game sprite. I draw at a much larger size than will actually be in game and reduce its size in the next step.




Now that I have the larger design, I shrink the artwork to match the same general size and shape as the other CO I've completed already, so that he fits on the HUD. At this stage I tweaked the silhouette slightly, adjusting his belt higher and fixing the pointy waist.

Color time! I slice off the parts that won't fit in the HUD and block out the general shapes and colors he will eventually use. The design is still in flux at this point, and I decide he looks better in a rain coat-ish jacket and adjust the design to match. The head is too small however compared to the other CO, and I adjust it larger as I add more details.


Almost done now. I polish the overall design and add team colored elements to it. I feel like he suffers too much from 'blueberry head' at this point the way his hat makes his head feel divorced from the rest of the design, which I fix in the final version.


 Last stage, final copy. The hat is unified, his saluting hand is cleaned up, armband shrunk, clothing folds shrunk, medals added and parts from the original design are re-implemented, like the design of his lower pockets.


I did experiment a great deal during this process, such as the shoulder straps from the original design, but they just didn't pan out looking nice compared to the original design.

Update #2

Wednesday, 4 March 2015


Plugging away at the game. Code-wise we've implemented many quality of life features such as arrows keys to pan camera and click+dragging the camera on the minimap.

The AI has gotten smarter as well, rather than bee-lining towards the enemy HQ, it now spreads out intelligently to capture points across the map.

Artwise I've made a handful of alpha explosions, working on some new CO's, and new units as always.





Progress Report.

Saturday, 21 February 2015

Hey everyone, brief update on how we're coming along.

I'm happy to introduce the first 99% done Commanding Officer, who is as of yet still unnamed but not un-arted.


As you can see, she went through multiple iterations to get to the stage she's at now, but over all I'm satisfied with the look and feel, the earlier ones were too stiff and amateur (but they were done relatively quickly at the time). I may make the earning team colored in the future as well, as at the smallest size it can be difficult to tell what team color she is.

I also have animations to show off. As usual, all designs are in flux as we develop the game to see what does or doesn't work:


Left side: idle/walking animations
Right side: shooting animations.
Not all units can shoot or have shooting animations as of yet, but in the future some of those will gain some.

All units are done with a very simple 3 frame cycle. Two frames for an idling animation, sped up when moving to give the illusion of walking. The firing animation cycles between the first and third frame, and no other art is necessary. I considered early on giving units animations for facing all four (or eight) possible directions of motion, but ultimately as the only artist it would be too great of an investment and compromised with this solution.




The engine itself is coming along nicely. It's playable but not yet solid enough to be called a game, despite its many game-like elements. In the coming weeks we plan on pushing out an alpha with all the core mechanics like unit building, base capturing, resource generation, and good pathing, but we're still some ways away from that.

Mountains from Mole Hills

Friday, 6 February 2015

Today I'm going to take you step by step through the design process I use when making tiles, using the new and improved Mountain tile as a showcase.

Step 1 when making any new artwork is always and forever: gather reference. Google Images, Deviant Art, studying how other games you like did it, whatever floats your boat. Maybe some people's imaginations are just that good to just go at it, but I always look at at least something before starting.

Once you've nailed down what you're shooting for, for pixel art my first step is usually to draw it in full size to get the forms down the way I like it before resizing.

It only takes a few minutes, but making this basic artwork at 512x512  helps me get started when I'm having trouble visualizing the appearance I'm going for at 16x16.

Working with my standard square brush I use for most everything, I paint out the mountain shape as it will look tiny.

Next, I take my artwork and shrink it down to the size it'll be in game. It won't look like what you see on the right yet though, as after being shrunk, Photoshop or whatever program you use will likely apply some kind of filtering to it. What I do at this stage is go (in photoshop) 'Image > Mode > Indexed Color.'

In this menu, you will be able to force your artwork to meet certain constraints, in our case, to use the existing palette I've made already. 'Palette: Local (Perceptual)' and 'Forced: Custom...' will allow me to load in my palette, which it will make the image match as closely as possible, and will resemble the image to the right.

After forcing it into my palette, you may notice the mountain artwork is a bit flat and drab. In pixel art, every single pixel plays a great deal of importance to the overall appearance, so I take some time now to clean up the compressed artwork into a better looking template for Mountains.

Once I've become satisfied with how the Mountain tile looks as it does on the left, we still aren't finished; it is a few sizes larger than 16x16, and is entirely stand alone. This Mountain will serve as a base and frame of reference for all the 16x16 mountain tiles I will make in the future.

Tada. Using the base Mountain, I stretch, squash, repaint, and remake until I've reached the artwork you see on the right. The mountain is 3 16x16 tiles wide and currently 4 16x16 tiles tall.

It's still missing a great deal of the variations required to work in any possible configuration in the tilemap, but using the Mountain template from before, I'll be able to identify the missing pieces and draw them into place for use with no effort while keeping the overall appearance consistent.