Strike Tactics is now almost feature complete with a fully working core game, single player (vs. AI), multiplayer and map editor. I have been playing the game a lot, multiplayer and single player modes. I'm really happy with the core gameplay, but I'm still a few weeks away from sending it to people who have pre-ordered for early access. The biggest hurdle left is performance. I'm pushing for a smooth experience which means 60FPS with not much going on and between 30-50 FPS during the big battles with lots of units. To me, performance is everything. So I am willing to cut a lot of the cosmetics for a smoother framerate. Other than that, there's a lot of misc bugs that really only show themselves after you play hundreds of games. I've not quite played hundreds of games yet, but I'm getting there!
Even though it's a few weeks out, I'd like to start making a list of people interested in playing the alpha. Only people who have pre-ordered would qualify.
Once you opt in for the alpha, I will give your account access and send you a link to the game when it's ready. You only need your account info (which is provided after pre-ordering). You can then play single player (against AI) or multiplayer against other alpha testers. Because there will be such a low volume of people, I will set up a discord app for the game to help you look for people to play and to discuss the game with me and other alpha testers. Although there is a lobby chat system, I think the discord app will be more congenial. I will be in there all day so if you can't find anyone, you can always play against me.
Anyone who is a part of the alpha (which will eventually transition into the beta) will be recognized in some way in their game profile or in some other way.
If you'd like to sign up for the alpha, please email me using the contact link at the bottom of striketactics.net. Be sure to include your email or username which you entered in when you pre-ordered.
Today I recorded 3 pre-alpha games of Strike Tactics. The game is still in a very rough, early-draft state, so if there's something you don't like or something you feel is missing, I wouldn't be worried - there is still a lot of work that needs to be done before the game nears a finished state.
In this first video, I play a medium AI in a desert map called "Oasis."
I win the game by amassing heavy ground units (silencer, demolishers and gladiators). As you might be able to tell from the vid, there are some kinks that need to be worked out. The pathfinding, in particular. I recently redid the pathfinding system. I had a perfect system before, one in which units would never bang into each other, but it had a major flaw - it was heavily grid-based, which gave ground movement a very stiff, robotic appearance (great for mechs, horrible for hover vehicles). This new pathfinding you see in the video does not have that problem - units can move off the grid. But the drawback is that it's a lot harder to prevent collisions. I know I can get this new system working so that units never collide, but it's going to take some time. Problems like these could easily be solved with brute-force (a true physics collision system, in which positions are constantly checked and compared on every frame), but in the browser, I don't have that luxury - not enough CPU power with so many game objects. As such, all ground collision needs to be solved algorithmically, with something smarter than a traditional, brute force collision detection system.
In this next video played on a volcanic map called "Eruption," the AI sort of got me pinned down by constantly bombarding my base with bombers - to such an extent that I couldn't build more silos to increase my population cap. For an unknown reason, the medium and hard AI both seem to favor producing bombers - a bug I haven't quite worked out, or even had time to look into.
Lucky for me, the Battleship is extremely overpowered right now so pooling all your resources into producing them is an easy win. You can see the power of the battleships in this video - I roll through the enemy AIs base in less than a minute. In the final game, battleships will certainly be powerful but by no means this powerful! I also show off some peregrines which are aces of the sky type units with air to ground homing missiles and machine guns for air to air.
Air units are difficult to control now, because they are constantly moving and moving fast. I plan to combat this issue by causing them to land after being in the air for a certain period of time. That way, it will be easier to select them. I also might attempt air unit formations someday which is something never really seen in an RTS. The math will be difficult buy I already have some idea of how I can accomplish it.
This final video is me getting absolutely destroyed in the early game by bombers at the control of a hard AI. Like I said, the hard AI sure loves those bombers. Enjoy!
Pre-Alpha, March 2017
The pre-alpha will all about nailing down the core gameplay and will include mostly people I personally know. The map editor as well as games vs. AI (easy, medium and hard) will be complete. This is the first stage of allowing other people to playtest the game, so a lot depends on it.
Alpha, late April 2017 (feature complete)
Anyone who pre-ordered will be invited to the alpha. You'll be able to test different game modes (free for all, standard), play against AI and play multiplayer against other alpha testers.
Beta, late May 2017
After taking lots of feedback from the alpha, I'll have a more refined version of the game and will begin letting more people play. The process will be gradual as I use dedicated servers and therefore need to build everything to scale. The best way to test scalability is to have lots of sample traffic and lots of data. By the end of the beta, I'll have a plan in place for scaling and will be improving gameplay at every step of the way.
Public release, July 2017
The big shebang. There will some sort of free version of the game anyone can access without registering. And if they like what they see, they can purchase the full version to access all game content. I was thinking about creating some kind of game mode that was RTS-lite, which would be free. Basically, a game mode that had all the combat and unit control mechanics, without the resource management. Something like nexus wars in SC2 or CBA in aoe2. RTS-lite gameplay serves as a good introduction to RTS mechanics for people who aren't familiar with the genre.
By the time of public release, I'm hoping to have all the major bugs worked out, cross-browser compatibility, AWS instance scaling and a highly polished version of the game. I will continue to work on the game indefinitely but I'm making a big effort to assure the public release is relatively bug-free and complete, by consumer standards.
All of the maps in ST are created in-engine using the map editor:
While the UI needs work, the functionality is complete, which is essentially to create, save and load maps for use in Strike Tactics games.
There are hundreds of map objects you can use to make maps, including trees, rocks, plants, mountains and water; all in 4 different primary biomes: desert, snow, grass and volcanic.
One of my goals for the map editor was to make it really easy to make maps. Most of the maps you see in the trailer were made by myself in a matter of minutes. This is mostly possible through the use of custom seeding functions. You can seed any object on the map by hitting a "Seed" button, which will randomly place the object on the map:
You can seed one particular object, or you can seed a category of objects, such as "All Desert Plants".
Currently, the buttons seed a pre-defined, fixed number, which is based on the size of the map. Eventually, I will add functionality so editors can change that number at will.
I've always had this idea of getting rid of tile-based ground textures. In the Feudal Wars map editor demo I accomplished this, by creating a complicated system in which textures were blended together with a brush tool and the HTML5 canvas. The brush would essentially create a hole in textures, so you could see the layer underneath (the brush tool was in fact, an eraser!). Then I would move around the layers based on which texture you wanted to draw with.
This method was problematic because:
- It involved so much bitmap data manipulation, performance was atrocious on computers with bad graphics cards
- To save the maps, I had to literally save the blended images created in the map editor
For the Strike Tactics map editor, I've devised a much better system. Instead of creating custom textures for each blended image, I create one single blended image from each texture, which is used as an overlay. The blended image is created in-engine from the base texture:
The benefits of this system are tremendous:
- Maps can be procedurally regenerated using a set of instructions (i.e. I don't need to save the literal images in the map files, hence 100KB map files instead of 10MB map files)
- Performance is awesome - I only need to draw a single BMD for each texture used, and copy it each time it is placed on the map
All map objects have z-indexes, which determines the vertical stack order in which they are rendered. For example, a tree has a higher z-index than a mountain and will therefore be shown on top of a mountain:
If you place a mountain on top of a tree, the entire texture is instantly re-ordered and redrawn and the tree will still be drawn on top:
Eventually, I'll add functionality for custom z-indexes, so you can control the vertical stacking order.
I learned a lot from making the Feudal Wars demo. The more sprites you have, the worse performance gets. Thus, I've completely redesigned the map generation system for Strike Tactics. Instead of creating sprites for each individual terrain object (trees, rocks, plants, etc), objects are rendered to textures which make up the base texture tiles on the map. With this system, you can have 1 map objects in a tile, or 500, and the performance will be exactly the same.
Place as many objects on the map as you want, without having to worry about it slowing down performance.
Tech trees are a staple of the RTS genre. In every game, there must be a feeling of progression - from weaker units, more primitive defenses and smaller production, to stronger units, more advanced defenses and larger production. Part of this progression involves researching technology and having access to different unit types, after certain pre-requisites have been met. You can't begin producing advanced ground until you've built an advanced ground facility. You can't build super weapons right out of the gate, etc.
Although I have ideas for what techs, I've saved this particular game mechanic for last. You sort of need to have the full picture to get an idea of what technologies would improve gameplay and create that feeling of progression. Thus, I am waiting until all of the units are completed before inventing techs and have nothing to show on that front.
I can say, however, that it is a major goal to have technologies that don't infulence gameplay in an artifial way. To me that means the effects of techs should be apparent within the game's graphics. If aircraft can move faster as a result of a tech, perhaps they should have a different color burner. If cannons gain an increased blast radius, their explosions should be larger. Simply changing unit stats without giving and indication to the player is a lazy way to implement tech upgrades.
RTS games need to convey continues streams of highly detailed information in realtime to the player. Sometimes, fancy graphics and design gets in the way of that. Take a look at this screenshot from the RTS game 0 AD:
No doubt the scene is impressive with high amounts of detail and lots of action - but I'd venture to say this high level of detail is detrimental to gameplay.
Consider the following questions: How many units are fighting each other? How many units are on each side? Which sides are fighting? Which soldiers are melee and which are ranged?
Your brain needs to answer these questions in a matter of milliseconds. Even if it takes 100 milliseconds longer to mentally process, due to the visual complexity, it has a profound effect on the experience of playing an RTS game. If you have difficulty believing that, try playing a game in which user input is processed after a delay of 100 milliseconds. We've all experienced what that's like in an online game with moderate latency. Visual complexity, too much of it, creates a sort of mental latency.
Now take a look at a scene from the age-old classic AOE2:
I'd argue that while the AOE2 graphics aren't nearly as impressive as 0 AD, they are more conducive to gameplay. The design, however modest, serves its purpose. Here we see a bunch of archers on horses and trebuchets attacking buildings. At a glance, the scene is so much clearer and easier to understand than the screenshot from 0 AD. This of course, is not by design, but a happy accident: the makers of AOE2 were limited to pre-rendered 3D assets (using 2D sprites) and pre-rendered terrain, given the limitations of computing at the time. The simpler graphics just happened to work better for gameplay.
Now take a look at a screenshot of units attacking buildings in AOE3:
It takes a moment to understand what is going on here - doesn't it? If I were an alien from outer space, and had nothing to go on but the screenshots from AOE2 and AOE3, I might think AOE2 was the newest game in the series. Poor adoption of 3D realtime is a technological backpedal from using 2D sprites.
Because of its continued success, Microsoft is still making expansions for AOE2, almost 20 years after it was first released. The original sells so well, you can still buy a copy at walmart. AOE3, despite being made many years later, and with better technology and funding, maintains a fraction of the following AOE2 has.
Similar examples can be drawn from the likes of C&C and Red Alert. As soon as these titles made the switch to 3D realtime rendering, the gameplay suffered. I don't think anyone would argue that RA3 was better than RA2 - or that AOE3 was better than 2. The sales numbers alone would disprove that notion. Whatever happened to the Dune franchise - the one that started this whole RTS thing? Dune 1 and 2 were released in 1992, Dune 2000 in 1998 - to great success. But after Emperor: Battle for Dune was released, the first in the series to use 3D realtime, Westwood never made a game again.
This phenomenon is not observed in other genres, such as FPS, where even the most primitive 3D realtime implementations are better than 2D with a 3D viewport (e.g. Doom classic vs CounterStrike 1.6). This is because the human brain is much better at processing 3D information from the first-person perspective. After all, your brain processes first-person perspective in everyday life. You can however, observe this effect in other genres that use the isometric camera - e.g. Roller Coaster Tycoon 2 vs Roller Coaster Tycoon 3. Why did these franchises peak at the height of pre-rendered 3D tech and flatline just after the transition to 3D realtime? Hmmmm.
In this forum discussion on none other but the 0 AD forums, the poster talks about edge unison vs. distribution and what it means in visual ergonomics. He came to the same conclusion I have, but in different words.
I do not mean to say 3D realtime has no place in RTS gaming. I only want to suggest that it is much more difficult to make a proper RTS game with 3D realtime. Starcraft 2, a game rendered in 3d realtime, has absolutely none of the visual problems 0 AD has. But Starcraft 2 is expertly designed by the people who wrote the book on RTS - it succeeds visually, in spite of the difficulties of 3D realtime, not necessarily because of it. The high poly 3D models, the level of contrast between terrain and units, the overall visual distinctiveness of game objects and anisotropic filtering all work together. No wonder it took 5 years and 12,000 builds to make. SC2, and the original Total Annihilation, are the only two 3D realtime RTS games that have stood the test of time - in my book, at least.
Other common mistakes made in RTS game design is one of scaling. In the late 90s - the RTS golden age - developers couldn't implement zooming because of the limitations in computing at the time. Nowadays, you're hard-pressed to find an RTS game that doesn't have some absurd level of zooming. The effect on gameplay is catastrophic. Supreme Commander might as well be called Icon Wars, because you are forced to play the game completely zoomed out - at least, if you want to compete online.
While giving players the ability to zoom out this far sounds good on paper, it makes for very boring gameplay. The emotional climax of any RTS game takes place while watching and participating in battles. If the meta requires you to be zoomed out to play effectively, so that the battles are tiny dot wars, well, that pretty much sucks the fun right out of it.
Note that you can only zoom in, and not out, in any Blizzard RTS game. Blizzard didn't fall into that trap. Blizzard knows better.
Somewhere in this podcast series about the making of Warcraft 2, Bill Roper, one of the lead designers, discusses the decision to not show too much information on the mini map, so players would not be tempted to play the game through the mini map. This set a precedent in RTS games. And the same concept is applicable to zoom: showing too much causes the player to not be able to experience the game as it was intended.
Let's take a look at a screenshot from the most recent incarnation of Total Annihilation: Planetary Annihilation.
Here the units models are quite good, and visually distinct from the ground underneath. But the scale, dynamic lighting and map curvature obfuscate the information to such a degree that the information isn't so easy to digest, at a glance.
I understand the pressure game developers feel to innovate - it certainly looks impressive, and no doubt, they sold a lot of copies of PA on the strength of this visual style. You can build and move to different planets? Win! Zoom all the way in or all the way out to see everything on the planet? Win! But I question whether these innovations ultimately lead to more fun and engaging gameplay.
No zoom out and a flat map might sound boring on paper, but at least we know those things work. My goal with Strike Tactics is to use what works, and not fall into the trap of over-innovating. Just because you have the technology to do something, doesn't mean you should. Game developers must exercise restraint - and constantly question whether a feature harms or strengthens gameplay - regardless of how appealing it seems on paper. After all, what good is any of it if the gameplay isn't there?
Strike Tactics is a top-down pre-rendered 3D game. The pre-rendered part is by design, but also, by necessity. Many of the CPU limitations RTS designers had in the late 90s are also limitations I have in the browser. But because all game assets are pre-rendered, the units can get away with extremely high poly counts, which serves to give them visual distinctiveness and contrasts them from the terrain.
The fact that the game plays in the browser has limitations, but it also removes the temptation of rendering everything in realtime and upscaling everything to an absurd degree.
I have a lot of theories as to why the RTS genre has lost the popularity it once had. The unsuccessful transtion from 2D to 3D is just one facet - there are many more. At some point after the RTS golden age, because they had the technology, developers started making enormous Michael Bay-style RTS games, advertising bigger, badder and MORE, but neglected the fundamentals. The fact is, the human brain can only process so much information before everything on the screen becomes a meaningless blob of lasers, smoke and metal.
Game developers must excercise restraint.
Top-down vs. Isometric
Originally Strike Tactics was to be isometric as the engine was created from a fork of Feudal Wars (my previous project, now on hold), which is isometric. However, after a bit of experimentation, I decided to break away from the mold of the isometric/dimetric perspective. My reasons are purely practical. I can get away with smoother rendering and freely rotate my graphics without having to worry about perspective. It also completely solves the problem of unit occlusion: if the camera is pointed down from directly above, no game objects can block other game objects (unless they are underneath another game object).
Unit occlusion has been an age-old problem in the RTS genre. It's normally solved by showing unit sillouttes, on the objects behind, which looks tacky and can be taxing on performance. I solved this problem with Feudal Wars by reducing the opacity of any object that was blocking another object. Note the castle and tower has reduced opacity to show the units behind them. I thought this technique was at least better than using silhouettes.
In a medieval game like Feudal Wars, a camera tilt is a necessity, because human beings - the primary unit in these kinds of games - look horrible from top-down. Like so:
Mechs, aircraft, tanks, however, look great, if not better, from top-down:
This is because tanks and aircraft are generally designed to be aerodynamic, which makes the side facing the direction in which they move take up less space on the vertical plane, and the side facing the camera, take up more space on the horizontal plane. As a result, you see all of the detail of the object when looking directly from above and less detail, the lower the camera is on the horizon.
Top-down is the biggest risk I took regarding game graphics, because there isn't any real precedent to lean on. There aren't any well-known (if any) top-down RTS games, even going all the way back to Dune. RTS games have always had a tilted isometric, dimetric or similar camera, and for good reason. A tilted camera allows you to see more angles of the object. So I knew it would be a challenge to get everything looking pretty and interesting from directly above. Nonetheless, thanks to some extremely skilled designers, the visuals for Strike Tactics, I feel, are in a good spot. I'm happy with the aesthetics and feel going top-down was the right move.
There are 3 different kinds of super weapons in Strike Tactics.
The Disruptor Cannon
An extremely long range artillery unit with massive firepower.
The Ion Cannon
More firepower than the disruptor, but at a much closer range. The Ion Cannon is also highly mobile as you can see in the first few seconds of the game trailer.
The radial gun
An area-denial unit which is stationary, but shoots a fury of cannonballs in all directions if an enemy unit approaches. I'm debating wether these cannon balls will be aimed by the gun, or if their destinations are completely random. The radial gun will be able to effectively deny both air and ground units in something like a 1,500 pixel radius.
Turrets play a large role in Strike Tactics gameplay. Because all units are ranged, and because air units are bread and butter, as opposed to support units, wall offs (via buildings) and walls really aren't viable as defensive structures. Instead, turrets are the main defensive structures. Currently there are 3 types of turrets:
Laser turrets - broad role, moderately good against air and ground
Bombard cannons - excels against ground, bad vs. air
Flak cannons - excels against air, cannot target ground
Why can the anti-ground turret shoot at air, while the anti-air cannot shoot at ground units? You'll find a lot of these little discriminations in Strike Tactics. In order for ground units to be viable, they must have enough inherent advantages to neutralize the extreme disadvantages they have in the mobility department against air. Other inherent ground advantages include more firepower, more health and guns which can fire while the unit moves.
Another turret unit is the Disruptor cannon, which is a large, artillery cannon. Because its incredible range and firepower makes it practical to use offensively, it is under the classification of a super weapon than a defensive structure.
I am considering implementing wall structures you can build. Except to make walls viable in a game where air units are prevalent, and all units are ranged, the wall structure would perform the following functions:
- Goes into the ground if a friendly unit needs to pass through (see supply depot in starcraft 2)
- Deflect enemy projectiles with shields that raise as an enemy projectile passes through, while allowing friendly projectiles to pass through.
If implemented correctly, these shield walls could act as a counter to mass-ground forces (movement obstruction) and heavy artillery (such as the Disruptor Cannon). They even could be effective against air units if turrets were strategically placed inside the perimeter of the walls. Air units swooping by would need to be positioned on the right side of the wall to effectively do damage. I am very much committed to finding a place for walls in a futuristic RTS (i.e. an RTS with mostly range/air units), but this I see as a secondary feature which will come later in development, after base unit roles have been established.
Units in Strike Tactics are capable of following rally paths which are created by shift-clicking locations on the map.
Production buildings are also capable of setting rally paths, so that newly constructed units will travel along a rally path once complete.
Actions can be queued for workers by setting rally paths. For example, you can build 3 silos by shift-clicking the silo placement on the map.
By default, if a worker is busy building and you tell it to build another building, the building is added to its queue as a rally path. If you want a worker to stop working on building to do something else, you will need to manually move the unit (to cancel action of working on the building) and then give it the new action.