How to Make an RTS

I had made other games before, but for a while I had wondered how to make a game where you could control different units separately or together. The issue was that I had always had the player character react whenever a keyboard or mouse input was detected, so if I had made multiple player units exist at the same time, they would all move and attack whenever you gave an order. That solution was simple, although it took me many months or maybe even years to think of: give each unit a variable: “selected”. When you click on a unit, selected=1, and when you click on another unit, selected=0. Then have the keyboard and mouse inputs only work if for the unit taking the orders, selected=1.

This is really all you need to know to make an RTS, as long as you know basic programming. The ability to select and deselect units in different ways, and their reactions when they are or are not selected gives you lots of options to build an RTS around.

Some tips to avoid issues when making a more advanced RTS:

  1. Centralisation– centralisation makes your code simpler to edit without having to make the same changes to multiple instances. It can also make it more efficient.
    1. control– some behaviour needs to be embedded into each individual unit, especially when they’re acting on their own such as for AI. Anything else, such as general army orders and player input should be handled by a single object that goes through each relevant unit and tells them what to do. You also don’t want them to act differently given the same order. This also allows you to have GUI buttons you can click on without clicking on units that would separately detect they’ve been clicked on, which is how SBMS currently is.
    2. input– similar to control, input should be handled by a single object, instead of having every unit and button do their own checks to see if they have been pressed. When you have 200 units in a match and more buttons, that’s 200+ unnecessary lines of code running 60 times per second, making your game run slowly.
    3. GUI– try to have a single object draw the UI and anything else in the game that needs to be standardised.
    4. databases– store relevant and related information together so you don’t forget where some of the information is, or lose access to that information later on
    5. functions– for anything that has to be done by many different things, such as checking if an enemy is visible, avoid directly checking the relevant variable. Instead, make a function that checks it and returns an appropriate response. That way, if you ever need to make enemy visibility more complicated, you don’t need to go to every object and script that checks it and change their code; instead you can change the one function, and all relevant things will perform.
      1. Don’t make too many functions and forget their names and then make new ones because you thought you hadn’t made one yet.
    6. Don’t centralise anything that would work better as an individual object. Too much centralisation can get things lost in very long lists or tons of scripts. Know when to add another object to handle more specialised things. Having just one or two other objects can help reduce processing power and memory usage, by avoiding having too many scripts or variables in a object when you only need the object for some of the things it contains.
      1. If you have a piece of code that’s being used a lot, be careful when replacing it with a function. The scope of a function should be as large as possible without doing anything extra that will sometimes be useful and sometimes won’t. Don’t copy extra bits and then realise that sometimes you want the extra bits of code there, and sometimes you don’t. If this happens, your function is trying to do too much, and you should make it smaller and take that extra code and put it outside the function, only when scripts need it.
  2. Planning– planning is essential for any game. Think of all the systems you will need and how they will interact before you build things that need to be modified later.
    1. multiplayer– sometimes multiplayer is best achieved when building the game to allow for it.
      1. input and networking– getting input directly from the keyboard might not work depending on how your systems do multiplayer, so input data will need to be sent to a host computer as a variable, which is then processed as input for a specific player’s units.
      2. unit behaviour– if you build a game where the enemies are hard coded to be computer controlled, it might be hard to then allow a player to use them. This is also true if you want to give a player control of enemy units in a single player game.
    2. efficiency
      1. Always try to minimise what individual units do. There are a lot of them, so even if you don’t want a lot of units on screen, do whatever you can to make sure they run as few lines of code, which are as minimally intensive as possible. Players with slower computers than yours will probably notice, and it will give you leeway if you ever want to add some intensive features later.
    3. naming– avoid duplicate names, not just for two similar units or abilities, but also between a variable used for some ability, like “power”, and the name of an ability, unit, script, or image that might also use the same name.
      1. Resource types- a prefix is useful for different resources, so spr_power could be the sprite you use to draw power, while obj_power is a player unit (object) in your game whose name is “Power”.
        1. Keep the prefixes short, so “bg_mission_1” is better than “bkgd_mission_1” or “background_mission_1”
      2. Don’t name your missions “mission 1”, “mission 2” etc. If you ever decide you want to add a mission in between others, your numbering will be completely off, which means you won’t just have to rename all the maps to one number higher, you’ll have to rename any variables associated with those maps. Use descriptive names instead, like “New York Alliance Naval Base”. Probably something shorter than that, but unique and memorable.
      3. Be careful with arrays. Sometimes it’s a good idea to store all relevant information in a single array, like having the index of the array refer to a unit number or mission number. Other times the number of the row or column is not clearly assigned to anything, in which case it may be better to make a new array.
  3. RTS Design
    1. Strategy and Tactics Depth– Strategy is not the same as tactics. An RTS, as we see it now, is not really about strategy as much as it is about knowing a few optimal strategies and being fast and accurate in your keyboard and mouse skills in order to pull them off. This is exactly what I wanted to get rid of, because it involves marginally more strategy than an action game might. StarCraft is not a strategically or tactically deep game, but chess is, and to a lesser extent something like Total War, where it’s not just about micromanagement and dodging, but unit formations and compositions (as opposed to the limited unit variety of rushes in StarCraft). Strategy is large scale and largely planning based, tactics are reactive and smaller scale. Mech Commander and Dawn of War 2 and X-Com focus on tactics, while Civilization and Total War and other games focus on grand strategy. Decide where you want to stand, and be very careful when trying to mix them like RTS does, because it might be too much to handle, which is why RTSs are so shallow. Tactics and strategy are about giving the player multiple viable choices and letting them decide which they would like to go for instead of having optimal choices. The more choices they have and can make for themselves, the better.
      1. Unit and Ability Design– a lot of cool abilities might make sense, but also might not lend themselves to tactical play. For example, deployable airmechs in SBMS can return to their mothership to repair as much as necessary. This reduces tactical play by giving you a unit that never dies if you’re careful with it, making it a tank with no penalties for taking damage. This is contrary to how every other unit is a tactical asset whose healthpoints and death actually have to be taken into account when making decisions. Abilities that require quick reactions are usually not tactical, while planning ahead is. I put some delays on abilities in the sequel so that you could activate abilities ahead of time instead of having to wait until the last second and time them perfectly. I made Valkyrie’s Magshield-B run on energy that lasts much longer than in SBMS, but does not recharge. This means that instead of mechanically having to reactivate them whenever it runs out, you have to plan ahead to make sure the shields are used at the right time, but also have plenty of error allowed because of the long duration.
    2. Economy– I took out economy altogether in SBMS because I don’t find it interesting at all. I like the idea of slowly expanding and finding and collecting new resources, i.e. the logistics and strategic choices in it, but I don’t like having to manage an economy during battle. Exploration and base building benefit from it, combat only benefits it when defending/attacking resource gathering is fun, but in competitive play it becomes restrictive and is a good way to shut down someone from ever being able to fight you. Instead I allowed people to get to the fun part without having to set up the infrastructure to get there.
    3. Resources– Unfortunately I made everything cost one resource, which means you have to be very careful about what you spend your money on. It’s easy to waste it and not even know until late in the game you figure out you needed something and bought useless things and basically cannot progress in the game.


SBMS started with player units being made separately from enemy units. All their behaviour was run with different sets of code, some of which I copy-pasted. This has the advantage of not needing to check which type of unit it is. Since then I’ve added an all_units object which is the parent of player_units and enemy_units, which contains certain variables I want both player and enemy units to have, and in the sequel game it contains most behaviour and graphical drawing for the two types of units. This means that I can make uniform changes to all units instead of having to do it twice, once for player_units, and again for enemy_units. The problem is that now it has to run an extra “if statement” to check what type of unit it is, since enemy units sometimes shouldn’t be drawn at all if they’re invisible. Instead of using an “if statement” which would take up processing power to pick which colour the units should be drawn in, I gave player and enemy units a preset colour variable, and the all_units object just draws in that variable colour, which can be changed at any time without having to constantly check what that colour should be.


Player and Enemy units had checks to see if the player had selected them with the mouse. This meant that the more units you had active at one time, the more times the mouse button was being checked. Since collisions take up lot of processing power as they need to check every pixel of the unit’s model, the game could not handle many units at all. For the sequel I got rid of those checks, and now only the UI object checks when the mouse button has been pressed. It does a single collision check and will select the one unit you pressed, instead of every unit in the game asking you at the same time if they were being pressed. This should improve game speed a lot.


All abilities in SBMS are drawn by each individual unit. There’s a script that handles it, so it’s standardised, but the reason this isn’t handled by the UI object is because ability buttons on the UI need to change colour/sprite and show different numbers depending on what state the unit or ability is in. This requires some specialised “if/then statements” to check for how much energy the unit has, if the ability is active, if the deployed unit is dead, if the cooldown is active, etc. I’m not sure how to have this logic put into a centralised object, so I let individual units check to see if they’re selected, and if they have priority amongst the selected units, one of them draws the ability buttons it has. This could be handled by an object dedicated to that ability, or by a pre-made script dedicated to that ability, but this did not seem to be a good way to approach it. The drawback to this is that I have to modify each unit that has the same ability to make sure their ability button UIs act the same way, and that every player unit in the game is constantly checking to see if they should be drawing their buttons. It’s possible to have the UI draw ability button sprites, hotkeys, and a single variable for units by simply having those variables stored in the unit and the UI pulling them when it needs it. This would drastically reduce processing power used, but I don’t see how I could have the buttons changed depending on other variables, since that would require individual logic for each ability that does not fit into the rigid structure of a standardised UI drawing script.


I have most mission, unit, ability, and other things’ data stored in a central object called “game”. But, I stored some data that I didn’t think I would always need, like unit model-numbers (like the “F-22” part of the American fighter plane, the “F-22 Raptor”) in the Assembly room’s object. This means that I can only access that information in that room, and it’s unavailable anywhere else in the game. The “game” object is permanent, so everything in the game can get information from it.

The “game” object currently has 49 scripts containing all the database variables of missions, units, etc. I think there are far too many, although I remember where most are in the list, I think the (maybe half?) of these scripts that are unit related could go into another permanent object.


I have a lot of data stored in single arrays with many rows and columns. Unit names, sizes, sprites, descriptions, costs, etc. are all stored in a single array. Each column (or row, depending on how you visualise the array in your mind) is numbered based on the unique unit number that each unit has assigned to it. Valkyries are unit 1, Wraiths are unit 2, etc., so if I need to draw the Wraith’s blueprints somewhere, I just use the variable game.unit_types[2,4] to get that sprite. The problem here is, you need to remember that blueprints are stored on row 4, names are stored on row 0 (game.unit_types[2,0]), etc. Recently in the sequel I changed the unit abilities array, which stored the ability name and hotkey like this:

unit_abilities[i,2]=’Magshield B’

This meant I had to use even numbers to get ability names, and odd numbers to get the hotkeys from the array. The sequel has it like this:

unit_abilities[i,1]=’Magshield B’

This took a lot of testing and searching to change every script and unit that ever tried to access the information in the way it was previously stored.

Tagged with: , , , , ,
Posted in Game Philosophy

Response to a Warframe Analysis

This was written in response to the following video:
I don’t mean for it to sound rude but I am quite surprised you view the game sometimes in the exact opposite way that I do.

There is so much bias in this. I don’t disagree with your overall point but I am very surprised at some points. You somewhat admitted them but I still feel the video is misleading.

1) “Welcoming to new players… You’re not going to need to dive into one-hundred page FAQs to figure things out”

I didn’t have much trouble, but this game is extremely unfriendly to new players due to few tutorials, convoluted systems, and hiding data and instructions. It’s a good thing they introduced endo and added more tutorials.This game practically needs the wiki to be played. Bosses are often invulnerable with no instruction or even hint of how their gimmick works in a hectic and unforgiving environment where you often can’t test hypothesis and take the time to get close and notice the glowy (does juggernaut even glow?) spot. Mods and abilities sometimes have vague descriptions, weapons don’t show you all the stats or inform you about mechanics they use, stances don’t tell you about what each move does.

2) “Warframe does a spectacular job of making all of it’s content attainable in a reasonable way through nothing more than gameplay”
“Blueprints for those will drop easily and quickly enough…”
“There is no gambling involved in Warframe”

Running tens to hundreds of the same mission is -not- reasonable, easy, or quick. It is definitely a matter of gambling, just with time instead of money. Wasting players’ time (sorties giving endo or boosters I don’t want, or giving me a riven only for it to be for a bad weapon) is not acceptable. You’re right that we can buy what we want on the market, but either for money via buying plat or for time via grinding mats or things to trade for plat. Oh and 3.5 days just waiting for a new frame to build.

3) “And if and when you do decide to shell out some of your hard earned cash it provides solid value that feels commensurate with the amount of money you spent”

The dollars per plat is not even slightly worth it. I’m hesitant even at 75% off to buy those rip-offs. If you consider the dollar price of in game content it’s often just as bad as other games charging for microtransactions. I paid 30 plat for what was advertised as a giant poster and turned out to be tiny. At the smallest unit of platinum purchasing, I’d have to spend $5 for 75 plat just to buy that one, at most two posters.4) “not constantly trying to upsell you or lure you to its storefront”

Except most cosmetics, weapons and frames show a plat price to straight out purchase unless you want to grind for days hoping parts will drop, wait twelve hours for it to build, grind for some argon which you can’t stockpile, then wait three whole days for. That was almost certainly done to make you fed up or impatient so you click on the very obvious “Rush” button to spend plat to speed it up, or buy argon, admittedly hidden away in the marketplace though.

5) “Movement is tight”
Except for getting stuck due to poor collisions.

6) “It’s going to make you want to grind”
No, no it really doesn’t. I avoid grinding at all costs, while many people grind weapons they might hate just to rank up for convenience and quality of life improvements.

7)“Bosses… are going to drop something worthwhile on a near constant basis. Even when the boss drops a part you already have you can sell it for resources that are far from chump change. You never feel like you’re being shorted. There’s never a situation where you’re fuming because you’ve just spent an hour on a mission and the boss only dropped loot that you already had or was below your level.”

I don’t know what kind of experience you had but this is all the opposite of mine and many other peoples’. Bosses drop resources and worthless mods most of the time. Ones that I have more of than I will ever need, and the rare times you get frame parts, they only sell for credits, of which I have 12 million. So it is chump change and I usually feel like I’m being shorted. Good luck getting Mesa, Ivara, or Equinox, or just primes.

8) “You can pick a piece of loot and not rely on drops at all.”

This is objectively false for anything that needs rare resources to build or parts to drop from loot tables, which ism I think, every worthwhile item.

Tagged with: , , , , ,
Posted in Game Philosophy

Interpreting Feedback: Asteroids and Laser Wars

Theres a theory that consumers don’t know what they want to buy. I think this is for the most part cynical and disrespectful, but it is based on something true. Most people don’t always know exactly what they want at all times because it can be difficult to think of solutions to problems or needs they have. It’s not their job to tell developers what to make though, so developers need to interpret feedback they get.

I was told by a few different people that SBMS looked like the game Asteroids. I was a bit confused, and almost offended because Asteroids isn’t even a strategy game; it’s a very simple shooter, so this isn’t a comparison I would have ever made. Upon letting that idea “bake” a bit, I realised that they might have thought this because they only saw objects shooting at each other in what they might have assumed was space. Someone else described it as “laser wars”.

I think the problem is that they are used to mechanical-skill based games where you simply attack the enemy, so their first thought here is to directly go for the enemies without a plan. They then see the lack of mechanical skill involved as a simplification of shooter games. It’s like a shooter, but aiming and firing are automatically handled for you, so you simply tell your units who to attack and wait for them to finish fighting.

This is understandable, but completely missing the point of the game. I think this is the same reason people find the game so hard. Some have even suggested to give the player an equal number of units.

The point of the game is that you cannot win just by direct passive combat. The core gameplay involves tactics, not reaction time or accurate aim. Missions are supposed to be lost if you simply let your units fight without much thought. The fun of the game is supposed to be the tactical manoeuvres and choices that allow your weaker force to overcome a more powerful one.

I don’t think I ever really made this clear. I set out to make an RTS that was more tactical because that’s how I like to play RTS games, but never realised that I had to explain that concept to others. Since RTS has been twisted into a micro/macro game genre, it’s normal for people to want an even footing. I’ll need to explain that early on, instead of just saying the game is more tactical.

Maybe I misunderstood the “Asteroids” and “Lasers” comments, but even if I have, it’s led me to be clearer about how the game works.

Tagged with: , , , ,
Posted in Game Philosophy

Button Reference

Tagged with: , , , ,
Posted in Media

Slizer: BMS v1.18b18

Release Date: /5/17
1. [b17] Mute sound hotkey is now the pause button instead of S
2. Added Selected images for buildings
3. Added a second art style for ground based guns
4. Plasma Tower now uses the tower model
5. Mission 2 Princeps missile ammo reduced to 1
6. Mission 2 some Hastatus units have had their missile ammo removed

Tagged with: , , , ,
Posted in Patch Notes

Slizer: BMS v1.18b17

Release Date: 17/5/17
1. PAV fixed using the old ambush code, crashing the game. Detection decreased from 0 to 1
2. ABMS mode fixed crashing the game
3. Praetor and Enemy Praetor secondary attack speed reduced from .04 to .028
4. Unit stats box in game now has a button and use the rebindable key
5. Fixed Mirage images being selectable with the group hotkeys
6. Fixed enemy units still drawing a circle when selected
7. Updated maps for mission 2
8. Fixed partial grid lines having been deleted and optimised it
9. Added all the missing weapon plans, weapon information is now a script also used in the Library and set the loadout number to start at 1, remobed the “Weapon Loadout” text, set the weapon type to be an image, reduced the height of the box
10. Fixed the “Basics of Battle Management Systems” in the BMS Help section in the Library using the weapon types image, fixed the Ambush image showing the wrong second image, updated the PAV and Ambush images
11. Removed the Sagitus’ duplicate weapon
12. Added a detailed map for missions 2, 1-12, the option to switch to it
13. Added plans for the Aquila and Reaper
14. Fixed the escape button in the System Settings
15. Fixed an extra Mainbase spawning in mission 10 by fixing the Planning object always spawning at least one unit
16. Spear Lanzer targeting speed decreased from 15 to 10 5, accuracy decreased from 40 to 10, Pummeler accuracy decreased from 15 to 5, targeting peed decreased from 10 to 5
17. Dodging now decreases more slowly with respect to distance from attacker
18. Updated the unit stats box to move the weapon targeted text next to the target name
19. Fixed the unit stats overlapping the unit description in the Assembly room (known bug left in to fix later) and added a sub box when not moused over, added unit stats for aircraft an battlecruisers and buildings in the Library, and added battlecruiser and building stats being saved in the database along with units’ and enemy units’ stats
20. Removed the initial Starmaker and Starslash units given to the player at the start of the game
21. Removed the Urdswan from the Degaulle in the Fake Slizer Base mission, increased EMP mine stun duration to 60 40 seconds, added dialogue and an ending
22. Added Gunbarrow and Wing Guard plans
23. Fixed army orders applying to unselectable units
24. Adjusted the game intro rectangle being too big around the title
25. E-mails for Allies noow have standardised e-mail names, fixed “One of your officers, LTC. Markov [is currently] under investigation.”, added e-mails for mission 6, fixed e-mail name ‘Admiral [’ and added ‘Trael Winder []’, pulled back e-mails one mission after mission 6
26. Added Pummeler, Rammer plans
27. Added grid coordinates drawn on the grid the mouse is in
28. Added Selected glow images for normal unis
29. Mission 2 enemy Praetor now has its secondary weapon removed, Princeps missile ammo removed, some Hastatus missile ammo removed, and edited the mission briefing to say this

Tagged with: , , , ,
Posted in Patch Notes

Art Assets for Sequel

The artist’s current progress on the new maps.





The Original Maps:

Posted in Media, News, Uncategorized

Alternate Mission 2 Backgrounds

Original (v1.18b17)

Original (v1.18b17)

Tagged with: , , , ,
Posted in Media

Short Story- Grip

A: Captain, you are Blanc’s boy aren’t you?

B: Admiral, sir!

Blanc salutes in shock.

A: How are you doing?

B: Very good sir.

A: And what would you be working on at the moment?

B: I’m handling the logistics for the transfer, it’s all going smoothly sir.

A: They have you pushing pencils? Surely you must have better things to do. Who put you on this assignment?

B: I’m not sure, we all handle these sort of things. I suppose we take turns, now that I think of it.

A: I will talk to whoever is in charge and have you put on something more fitting. It is a real waste of good talent.

The admiral never talked to anyone about it. It wasn’t that he never meant to, or that he forgot, it was just more of a singular, isolated statement.

B: [At first hesitating, surprised] You are too kind sir. I’m just doing my job.

A: Non sense, I have seen your dedication. Not like that Russian Colonel. I have to wonder how he has got as far as he is.

B: Do you mean he did not earn his promotions?

A: Come now, a lazy Russian, a colonel? You are smart enough to know something is wrong there. His attitude insults hard working Frenchmen like us.

Blanc is listening, contemplating what the Admiral is saying.

A. Oh well, what ever it is, we will never know. I would ask him myself but it is not my concern, unless there is reason to investigate.

The Admiral inhales, making that face as if concluding and preparing to leave.

A: Keep up your good work Captain.

The admiral turns and takes a step. He pauses just before Blanc responds.

B: Sir!… Thank you, sir!

Not having paid attention to what Blanc said, he considers and then puts his hand out. Blanc, lightly confused, looks down, and lowers his hand slowly from his forehead to take the Admiral’s strong grip. He tries to reciprocate the strength, but as he considers gripping tighter the handshake is over.

Tagged with: , , , ,
Posted in Media

Gundam Iron Blooded Orphans Season 1 Analysis


It’s OK. It’s not a great Gundam series or a great anime. It has great moments (though not as good as Gundam Wing or Gundam 00) spread throughout an OK story that takes a bit too long too progress, and doesn’t really develop a lot of the themes it has, possibly to just introduce them for season 2.

It’s very slow. Not much happens. Very few fights. By the same point in Gundam Wing or Gundam 00 there would have been major plot reveals, which don’t seem to he happened in this, or if they have they haven’t bee particularly impressive. It’s a fairly simple plot. The events on mars, in space, in the colonies, and on earth feel like they could have been done in fewer episodes. Some episodes has no fights at all, and barely any story progression. All they had was basically characterisation, and while that’s not a bad thing, it’s better if that’s not the only thing that goes on in an episode. Some episodes, while not bad, had me feeling that while the episode wasn’t boring, I was waiting for something to happen to accompany the characterisation. Like eating a single ingredient as a starter, enjoying it, then being told the meal is over, and wondering where the rest of the different types of food were.

The fight scenes were good, but they never quite reached the high standards of Gundam 00. They were infrequent though, and on average a bit duller than other Gundam series. The lack of clearly separated Gundam mobile suits from other mobile suits did not help. While they did say that Gundams were amazingly powerful, the gap in the power level between them and mobile suits wasn’t as big as in other series. As a result the Gundams weren’t too impressive, especially given that there weren’t that many. This was likely a choice to go with the original Gundam 0079 style rather than the Gundam Wing style of a team of Gundams. The lack of energy weapons was an interesting choice, but simultaneously the old weapon style has drawbacks making the weapons less impressive. To make up for that the Barbatos had some interesting weapons. While the Barbatos was interesting in both design and use, it wasn’t quite enough to impress me. It’s hard to get that feeling of a succinct team of distinct Gundams like in Wing, or the clearly defined roles of Gundam 00. It didn’t even have a clear set of enemy Gundams like in Gundam Seed. But it worked.

The themes of poverty and literacy were good and I thought fairly original since most shows do not deal with these things, especially having an illiterate child soldier as a protagonist. They didn’t quite develop these themes much though, or any of the other themes very much. It didn’t do the revolution theme nearly as well as in Gundam Wing, and the child soldier theme could have been used more too. Gundam 00 made me feel more for the child soldiers, despite not focusing as much on that theme. It also had a theme of underage marriage and harems/prostitution, but again not much was made of it.

The deaths as usual were fairly emotional, except for Biscuit’s. I just didn’t feel like they built it up enough. He had sisters who he wanted to put in school, his brother died after severely disappointing him and selling him out. If they hadn’t made it so obvious then I might have been more surprised. I think more importantly, while he seemed like a nice guy, he didn’t have much of a personality. I assume they meant for him to be very likeable, but he wasn’t exactly an unnamed analogous character from Gundam 00. When someone said he’d have time to tell Orga later, it was clear he wouldn’t have time. I would in fact say, a lot of the characters lacked dimensionality. They definitely had some, but they seem very singularly motivated with a bit of softness. There was also a character that’s hinted at being homosexual, which is an interesting addition that I don’t think has been done before. I felt more for the deaths of the enemies, especially towards the end, since they were handled with more drama. Similarly, some characters who almost died towards the end I thought were handled better than Biscuit’s death. Biscuit’s death wasn’t done completely wrong, as the events that led up to it would have been good if they just weren’t so transparent, and if he was a more interesting character.

The enemies are far too often stereotypically arrogant. They suffer from the fallacy of feeling indignation and wanting revenge for their comrades’ deaths. I think that perhaps every single Gjallarhorn character who they fought suffered from this cliché. They really overdid it in that regard. Mikazuki’s clear disregard for their pride, while entertaining, seemed to have been the only reason this was set up as it was. I don’t think one should -want- to see arrogant people being proven wrong, as if it were a perverse, almost sadistic addiction. When done tastefully it’s fine, but they really went out of their way to make Mikazuki a sociopath. I assume that like the other themes, they wee only setting it up for season 2, which is why they didn’t develop it much in season 1.

The Alaya Vijnana system was a nice choice for t signature technology of the series, but again wasn’t quite used as much as the Zero or GN systems in Gundam Wing and 00. It was done tastefully though, they didn’t make too big of a deal of it. Again, it seems fine since it’s more so being set up for season 2. Not much was done with the colonies either.

The demon theme was good, especially as a contrast to the angel theme in Gundam 00, both of which were fairly subtle. Such themes are better done subtly, but since I didn’t recognise most of the names, I’m not sure to what extent they kept the (few) Gundams or other mobile suits in this theme. The whole story arc seems like a continuation, or contrast to Gundam 00. The organiation that maintains peace, Gjallarhorn, is analogous to Celestial Being who had an angelic theme and were “above” national blocs. A small, militaristic group such as Tekkaden, with more demonic features, is in a way a counter to that, almost as if Treize had started his coup d’etat in a victorious but corrupt Celestial Being.

I would not say there was a lot of missed potential, although that may be true, because I think it was an acceptable choice on their part to make it like this. It wasn’t worse, it just chose not to pursue some avenues that it would have done really well. I think it was mostly to set up season 2. The biggest problems for my taste were how slow it progressed, the lack of depth for some characters, Biscuit’s relatively unmoving death, and the lack of distinct Gundam design themes. Not a bad Gundam series or a bad anime, just a bit disappointing and a bit lower down on my list of favourite Gundam shows.

Tagged with: , , , ,
Posted in Uncategorized
Slizer BMS v1.17b1
Slizer Battle Management System Windows game
Slizer BMS v1.17b1