The Origins of In Extremis – Part Three
Like any sort of anachronistic, well-opinionated, mildly deranged group of people, game developers hardly ever agree with one another. except in one point: game developing is hard. Capital-H, all-caps-deserving HARD. Of course, no amounts of reading other game’s postmortems can prepare you for when you have to confront that reality yourself.
But before that, lets wander a bit on some lighter stuff.
While doing my research, both reading the academic stuff as well as the fringe stuff on the net, and also trying to play every shmup that has ever being shmupped, I also started prototyping a bit of my early ideas. I had a clear concept of what the main mechanic for a game with a broader appeal should have, but playing more variations of shoot’em ups and coming with a more organized taxonomy (such as, defining the difference between a bullet hell and an old-school vertical shooter, for instance) helped the main idea to take shape.
According to that analysis, most shmups are composed, of a main mean of offense, like a regular blaster, plus a secondary/alternative firing option. They also possess a differentiating element, which is used sparingly, or with regular intervals, such as a smartbomb (which damages enemies and usually clear the screen of bullets), a special mode such as Hyper or Slowdown, or even something even harder to classify, such as R-type Forces. That element has the responsibility of giving the player an strategic edge, and also a sensation of cathartic release when used. Finally, there is always a score system, that can be simple as “shoot and not get hit”, or as baroque as the ones seen in Cave titles and some doujin games (Hellsinker comes to mind).
I wanted to steer away from some mainstays of the genre, especially ones that seems to adhere to arcade conventions that make no sense in an domestic environment. I was especially critical of smartbombs, since their use are essentially a get-out-of-jail-free card, which sometimes is a excuse for a designer to create an unfairly difficult game, and make the player rely on resource management to survive. But since their functionality operates like a panic button, they also can be very damaging to the flow of the game (dying in shmups usually restore all of your bombs, so dying with a full set of bombs can be massively frustrating).
Another classical element I found passé were power-ups, since, while the steady build up of getting more power-ups is somewhat satisfying (the Touhou games are great in this), losing all of power while dying is certainly not fun. Also, power-ups feel a bit lazy in terms of establishing a challenge, since in most shmups they are used, you spend most of the time with maximum power, so, why make the player be forced in less than the optimal power?
The shape of the main mechanic, (called “drive”, at this point) , eventually, became a mix of elements present in shmups like Jamestown, Espgaluda, DoDonPachi and Ikaruga, like risk and reward, slow down, and the presence of an special bar. The idea was that the main mechanic would be a power bar, that would accumulate as the player destroyed enemies. When full, player could go into drive, slowing down time around them (making it easy to dodge bullets), and making their aspects power amplified (increasing range, output, damage, and even functionality). Drive could also be canceled before the bar was fully drained by pressing the button again, resetting the multiplier, but clearing the screen of bullets and causing damage to enemies.
For the scoring mechanic, though, I opted for something, much, much, simpler; a timing based multiplier, that increased with every enemy destroyed by a specific amount, and decreased after a couple of seconds unless another enemy was hit. Considering this was planned to be a more entry-level shmup, I didn’t wanted to try anything more complex, but, despite it simplicity, all level planning and structure of the game is based on *always* giving the player something to hit, even if it is for holding the multiplier; so it’s also certainly not trivial.
If you found the main mechanic to complex or crowded with too much stuff, well, I guess you are completely right. Certain elements of the mechanic didn’t really gel together; the first attempt to do the slow down including dropping the framerate from 60 to 30, which caused a series of problems in terms of how it would be represented audiovisually (I didn’t really wanted to distort the music and sound effects, especially because timing and music sinchronicity were really important elements in the game flow – and also, at the time, I had no clue how said distortion), and, not mention, it was extremely clumsy. So, in order to simulate slowdown, the local speed of every bullets was reduced to half (player and enemy speed remained constant). This made more sense, but required some instance-specific code that was somewhat annoying to implement.
(mind you, though; the mechanic passed through a severe overhaul recently, after some batch of testing – gone are the bullet-speed-halting, as it actually made the game harder (because every other variable related to the bullets, such as the rate in which enemies fired them, stayed the same, leading to distortions in the bullet patterns- and it took me TEN FRIGGIN MONTHS, to realize this, mind you), and drive canceling is triggered immediately when hit, making staying in drive a sort of shield, while maintaining the sense of empowerment and catharsis of the ability. Another thing is that the tests showed that players had a hard time adapting to the whole world around them changing their speed, leading to a loss of a sense of control and spatial reference; in the end, aproppriate, and infintely more simple solution was found in just giving a slow button for the player ship).
Meanwhile, the other mechanics were pretty much though out already; there would be 12 aspects, each representing a different, well, aspects of player interaction, including unconventional stuff, like short-range weapons and helper-type objects, among others that were deconstructions of classic shmup weapons as thinly veiled metaphors. They could also be combined in any way the player wanted to, instead of being locked together in a specific ship design.
The stages were also planned, with their individual mechanics and thematics associations sketched out, thanks to an interesting dynamic made online; through a custom built website, people could associate images and music with emotion, sensations, or whatever was going through their minds at the time. This resulted on moodboards composed to guide the visual plan for each stage (with suggestions of palettes, predominant shapes and visual motifs), and helped figure out the game soundtrack (which is almost entirely made of Creative Commons songs – god bless the FMA). While the reception of this unorthodox method in the university was rather uneven, but it stands as one of my favorite thing about the academic side of the project.
I had the faint idea of making a 1.0 version, relatively feature complete, with all stages and aspects in time to submit for the Student Showcase of the IGF. The Student Showcase was a longtime dream of mine, because I had followed the indie scene for so long without ever becoming part of it, so I had some determination to at least get it submitted in a competitive state. Give or take a few national competitions along the way, whose deadlines could allow me to get the game into shape, I though it was a reasonable goal.
I was so, so very wrong.
Look, I was exactly naïve when it came to game development; I made several small prototypes during university, and well as a slightly larger project in a specific class, but my true trial by fire came in 2012, when I did my first for-real project, Pix, a jazzy black-and-white Pac-Man deconstruction about philosophy, Internet and a satirical view on microtransactions, staring a dumb but lovely pixel character and God as a narrator. I like doing weird stuff.
Initially, it started as a simple project to make me learn real code in Game Maker, instead of relying on the horrid drag-and-drop interface. The project soon grew, as I wanted it to figure in some festivals at the time (due to a mix of hubris and stupidity), and while programming some ridiculously ambitious game systems. This led some soul-squashing crunch sessions, as well as a series of failures in those festival (somehow I was selected as finalist in one, only to end up in the last place), that, along with some other personal issues, almost led me to a nervous breakdown. Hell, poor Pix remain incomplete till this very day because I couldn’t bear dealing with those nasty bugs again.
So having learned the lesson, I moved on to do exactly the same thing again.
The first batch of crunch was during the middle of 2013, when I wanted to get on the most important festival of my country. I managed to get a working demo with three stages and six aspects, which made some positive impressions in public tests. Sadly, it didn’t got in that festival, possibly due to the lack of visual polish (the visual element weights heavily in festivals in Brazil – a recent Demo Showcase of a festival here didn’t even accepted actual demos, just screenshots and trailers). Of course, rejections are never easy, especially after the work and time put on the project. After that, I went head-on the next goal, the IGF deadline.
Those months were a blur, in which I basically focused exclusively in getting it done, producing content as fast as possible. Now, In Extremis scope was much grander than a regular shmup; while most of them have around five or six stages, INX was planned to have eleven, each one of them with unique mechanics, bosses and enemies.
As the deadline loomed closer and closer, instead of working harder, what I felt was a sense of futility and desperation. It soon became obvious that even if I doubled the time I spent programming, bugfixing and analyzing, even if I gambled with my health as I did the year before, it would be fruitless, as the game was just too ambitious, too large, to be in a competitive state in time, specially due to my unwillingness to compromise my vision cutting content or reducing the amount of mechanics. I was a solo developer, with a cheap laptop, without any fixed place where I could just sit down and work, and it needed art, it needed sounds, it needed testing… So, I gave up on submitting to the IGF, postponing it for the following year.
By the end of the course (and also, the end of my academic life in the university), the project was, almost miraculously, feature complete; it had ten of the eleven proposed stages, with their unique mechanics implemented, all of the aspects working, and even the bossed very well sketched out. Of course, it had a bucketload of bugs, several empty sections, unbalanced difficulty and glorious, cringe-worthy programmer art. But it was done, and I was proud of it.
Of course, to actually get it done, it meant I had to forsake some of the academic compromises of the university, such as documentation and clear justifications for the design decisions. Of course, the low output of game projects in the university, and well as the idiosyncratic nature of INX also meant a lot of the tutors of the course simple did not “get” it. Couple it with the shoddy visual presentation (it was a design course, after all), and the end result was that the project wasn’t nearly as well received as I hoped, and it left me deeply frustrated.
Which leads me to where I am now, out of the shackles of academia, still working the game, from the confort of the only space available, the the living room dinner table. As of now, I have just recently finished the full content of the game (the double-length final stage and its parade of ridiculous bosses took almost two months to finish), and now, I’m focusing on polishing enemy waves and bullet patterns, the use of aspects, and trying to get a stable beta working (and squashing assorted bugs, of course). Still, there is a ton of work ahead, but now there are clearer goals, and possible even an end in sight.
Well, thanks for reading my little saga! Stay tuned in the coming weeks for more interesting tidbits about shoot’em ups, obscure metaphorical symbolism, and the truth of the universe that hides in a swirling bullet curtain. See ya!