Remar Games
www.remar.se/daniel
News
Games
Game guides
Resources
Ludosity games
Doom II levels
Quake levels
UT99 levels
SMM2 levels
DDR Simfiles
Pics
Links
About/FAQ
Introduction - Sector 1 - Sector 2 - Sector 3 - Sector 4 - Sector 5 - Sector 6
Sector 7 - Sector 8 - Sector 9 - Sector X - Sector Y - Sector Z - Misc secrets
Unlockables - Weapons - Items - Enemies - Bosses - Trivia - Text dump
Trivia
Tons of extra stuff related to the game's production, including coding.
Retcons
Iji 1.7 changed some of the game's lore. Notably, the Komato have never encountered another species besides the one they stole Nanotechnology from, and it's made more clear that Iji's Nanofield is a regular Tasen Soldier's. High Command is no longer referenced as an entity that can receive information immediately regardless of distance to the Earth, nor make relatively small-scale judgments, but have representatives aboard the invading Komato fleet instead. A logbook in Sector X also alludes to the fact that the Komato (and presumably the Tasen) have beaks.
Finally, some players found that Iosa's personality or motivation had changed in 1.7, but she's still the same character I always envisioned her as - she just didn't have a lot of screen time before, and one of the new endings expanded on what would happen if she was left alive to do as she pleased.
In the original release of 1.7 the Imperial Army and High Command arose from an extensive series of conflicts, rather than the Komato being organized and having a large military from the start, but I changed this back in the Spelling fix version of the game. It just bothered me that I had changed such a detail for no reason.
Timekeeping
This is the way the Tasen and Komato measure time, using Origin/Earth as a template. It was meant to be vague so I didn't have to be very precise with the story.
Starturn = year; how long it takes Origin to make a full orbit around its star
Longturn = month, unknown how many make up a Starturn
Turn = day; how long it takes Origin to make one rotation around its axis
Cycle = hour, unknown how many make up a Turn
Shortcycle = minute, unknown how many make up a Cycle
Pulsecycle = second; whatever the Komato pulse was when they came up with it
Ternary
It's simply base 3, written from right to left. This picture should make it clear how the ternary in the game works:
Totals
The least number of kills after completing the game is 0, and the maximum is 600. The maximum number of successful cracks is somewhere around 740, but neither of these are really possible due to the Tasen and Komato fighting each other. The minimum / maximum amount of player damage and failed cracks are both 0 / 999.
Dark blue nodes
Looking carefully at the cracking interface, the number above each column shows how many dark blue nodes that column will carry (in ternary). Since there's a set number of them in each column, the game can't generate an impossible maze.
Stealth updates
While the game was in production, I changed the image seen on my "Links" page every time I completed a Sector. Since I drew the Sectors on paper and taped them to the wall, I added the same detail to the image on the links page.
Sector Z
Sector Z originally contained sprites, levels and enemy behaviours ripped from Super Mario Bros, Zelda 2 and Metroid. Around the time I built Sector X, Sector Z was completely remade.
Asha
Asha's style of speech in battle (in particular the "You're mine!" shout) was inspired by Lunar in Mischief Makers. His name is derived from Iji's voice actress' surname.
Null driver
The Null driver is so named because it doesn't "fire" anything, rather than referencing a kind of computer driver. In version 1.2 of the game, it was found in Sector 2 after beating Sector Z, by cracking a certain box while the seconds timer was a multiple of 10. Seriously.
Kataiser family
It wasn't brought up in-game due to cutting dialogue during production, but Iji's father had two wives, the second of which had Mia. At some point during revisions, Sonia Plait was written to be Iji's mother before the idea was scrapped. Iji was also originally supposed to find the corpses of Mia and their father in Sector 2. According to an old doodle I rediscovered, Iji's mother's name was Amanda.
How does that work anyway
When either Krotera, Asha or Iosa use a superweapon, their Nanogun flashes, letting you see its insides.
Get with the times
Most of Iji was developed on an 850Mhz computer with a 16MB graphics card and 256MB RAM.
Crackers
The three Komato crackers with the silly nicknames describe the Nanogun's inner working in complex ways that makes no sense to the player, who solves a puzzle to achieve the same thing.
Doing rewards the other way around
While talking to reallyjoel, I decided to reward the player with the best unlockables when completing the easiest tasks, and saving the novelty unlockables for completing things like the Ultimortal difficulty. I figured I should give most people the most satisfying and interesting rewards instead of placing them out of reach, since most players who beat the game likely only do so once on Normal.
Technical: Animations and models
I built 14 3D models for Iji, rigged them with forward kinematics skeletons, animated them frame-by-frame and rendered them flatshaded in parallel projection. The resulting frames were edited to fix stray pixels and adding speed lines. Since I used no inverse kinematics, making anyone plant their hands or feet on the ground was a tedious process. Iji's secondary outfit was hand-drawn on top of her 45 regular animations, and due to the ancient version of Blender I used (buggy camera and animation tools, and no undo button) the amount of work involved nearly stopped the project several times.
Technical: Proxima's cords
Like the electric sparks from defeated enemies, these are just a few lines of code in a draw event. Three hypothetical dots (X and Y pairs) are in a chain. A dot wants to be a certain distance directly underneath the previous dot in the chain, but doesn't get there immediately every frame - it divides the distance to its desired position with 1.5. Lines are then drawn between the dots.
Technical: Hero 3D
I made Hero 3D in five days, being my first idea that fit the criteria of a game that can be drawn on top of Iji, doesn't scroll the screen and uses no video memory. The game draws and calculates everything including the walls and collisions with simple mathematics. It does use Game Maker objects for anything that moves, all sharing a 32*32 hitbox (taken from the "default block" in Iji) and are told to move around the screen according to where the player is "flying".
Technical: Graphics optimization
Not only is Iji's graphical style made to resemble games like Another World, the few colors used in sprites and backgrounds means that they take very little space. In fact, the majority of the game's size lies in the sound effects, and the tilework and instance placements of the Sectors. Many effects and the entire final boss use lines, circles and polygons instead of sprites. What I didn't know was that some operating systems would object to Game Maker's way of doing this and slow to a crawl, which is the main reason the 1.7 update was made - porting the game to a different version of Game Maker solved that problem.
Technical: Tile optimization
Most Sectors have only one tile layer. Though the "outsides" of the Sectors use a repeating background tile, the interior was originally full of 32*32 tiles, mostly plain blue. I made a single 128*128 blue background, then took a 128*128 tile out of it and started replacing 4*4 chunks of blue 32*32 tiles with it. This essentially means that for every 4*4 tile chunk replaced, I had reduced the number of tiles by 15. Then I took a 128*96 tile out of the same background, and repeated the process down to 64*32 before repeating this for other strutures like doors and walls. This made the Sectors load 25% faster and saved around 2.5 MB of the filesize.
Technical: Block optimization
Like the tile optimization, I replaced large chunks of the invisible collision blocks lining the Sectors with 128*32 and 32*128 blocks. This results in an average of 1/3 to 1/4 of the original number of collisions being checked and knocked 0.5 MB off the game. Another detail are the hovering ammo packs, nanofields etc. When these land on solid ground, they turn off their own collision checking.
Technical: The final boss
Tor is drawn with 2D polygonal shapes defined through vertex lists, rotated using sine and cosine with lookup tables with precision down to 1/3rd of a degree. The animations were created in a special Game Maker project I wrote for building and animating the boss frame by frame, pictured below. Tor consists of 10 bones and 270 vertices distributed over 35 shapes and 21 circles. The vertex lists were inputted manually, derived from a 3D model I built first. While making the 1.7 update, I noticed that Game Maker 7.0 draws polygons differently from GM5.3A, and so I had to repair and split a lot of polygons to get them to behave again, after modifying the animation tool to help me with the task.
Technical: Instance deactivation optimization
When something is "deactivated" in Game Maker, it basically exists in an invisible, frozen state of what it was before it was deactivated and cannot run code or check collisions. Most instances in Iji are constantly activated and deactivated a bit outside the screen, but this needs to be done with care - activating the entire Sector is out of the question. The following is how I solved it in Iji, executed every 8th frame:
#1 Deactivate a box around the screen. This makes sure everything deactivates behind Iji when she walks from one place to another.
#2 Activate a smaller box around the screen. This makes sure things get activated in the direction Iji is going, as long as this box stays well inside the previous one there won't be any "trails" of activated instances left behind.
#3 Deactivate all children of parent obj_deactivateme. These are things like enemies and pickups affected by gravity.
#4 Activate an even smaller box than in #2 around the view. This is crucial; since the collision blocks are activated further out, then all enemies are deactivated, and finally all enemies inside this even smaller box are activated, it makes sure no enemy will fall outside the collision blocks due to them being activated/deactivated at the same distance.
#5 Activate all children of parent obj_activateme. These are rare things that might otherwise break, like teleporters.
There are a few special cases, like when Iji first enters a Sector or when teleporting, but both of these only affect one frame of the game, and the screen is completely black or white during that time to hide the slowdown on slow computers.
Technical: Enemy AI
The AI for most enemies follows these priorities:
Attack rival race > attack Iji > get any health in sight if injured > run from Blits > walk around and do nothing.
Let's take a Komato Annihilator as an example. Iji and each enemy shoots invisible projectiles, called visioncheck objects, in largely horizontal directions. When Iji's or a Tasens' visioncheck objects hit the Annihilator while it's looking in the direction the visioncheck came from, it gets "angry" and gets permission to chase its target and fire. The "target" in question is the ID of the enemy who fired the visioncheck - each enemy embeds its ID into the visioncheck projectile itself.
Once the Annihilator has acquired a target, it has ten seconds to hunt it down before turning docile again. As long as the target keeps hitting the Annihilator with visionchecks it'll reset the ten second timer. If the target is at great range, the Annihilator uses the Shocksplinter or Plasma cannon, but if the enemy is within the short range of the Hyper pulse (192 pixels) or the Splintergun (512 pixels) it may fire that instead. The Plasma cannon is specifically not fired if the player is over half a screen away, no matter who the target is.
If Iji has cracked the Annihilator and it fires the Shocksplinter or Plasma cannon, it will explode before leaving the barrel. This sets a variable called "oops" in the Annihilator that tells it to avoid using these weapons again.
Enemies have a very limited idea of team combat. If a Tasen spots Iji or a Komato, it will send out a burst of special visionchecks which alert any other Tasen they hit to the original Tasen's target. These visionchecks will make an allied enemy angry regardless of which way he is facing - this lets a Tasen or Komato "call" for his nearby friends. Similarly, Iji firing or an enemy exploding also sends these visionchecks out, giving the illusion that the enemies operate both by sight and hearing.
When it comes to how an enemy decides what action to take, it operates by states, alarms and orders. An "alarm" sets itself to a random value each time it has counted down, and then it also tells the enemy what order to execute. Orders are things like stand, walk, fire, and charge projectile. Game difficulty level, whether the enemy is "angry", what weapon set it has, what its short and melee range distances are, and if it's been cracked will affect what order it takes, and how long it will take for a new order to be given. Also, if an enemy is angry but has been given the "walk" order several times in a row (3-5 times depending on the enemy type), it will automatically fire a weapon as its next order if it has a viable target. This is known as "idling" and doesn't apply to Scouts.
If an enemy is not angry, it will react to the visionchecks sent out by red Nanofields which lets them search out health after a fight. Sometimes when building a level, I placed Red Nanofields where enemies could see but not reach them, resulting in the enemies repeatedly walking back and forth while writing logbook poetry about the unattainable treasures in life.
Summary of working on Iji
If you're curious, here's the complete project logbook (124KB). Right-click to download it.
According to my logbook, Iji was born sometime in July 2004. The first sprites made for the game were Iji herself and a Tasen Soldier. I intended to write a simple platform game, but it resulted in spending weeks writing what's now the base for the game's controls and collision detection. It was at first going to be a survival game where you're mostly chased by a large, tough monster, but this soon changed.
As I added ideas, characters and content, the ambitions for the project went off the scale, and I realized I'd need years to finish it. I took month-long breaks as motivation was hard to find. I released two small tech demos in April and October 2005, but they were pretty much terrible.
Each Sector took weeks to build, not counting the new content for each one. The exception was Sector 5, built in three days. In summer 2006 I set the deadline "before 2008". At this point the game was past halfway complete, and I started playtesting more, and also started working faster.
Sector X was a huge undertaking due to the number of special cases and the mid-boss, and my computer crashed twice ruining hours of tiling work. I was prepared to spend a lot of time on the final boss though. When I got to drawing the cutscenes, I had burnt myself out drawing Ultimortal and had lost what little skill I once had. In the end the 74 cutscene drawings took three months, and implementing them into the game took five days. By now it was December 2007, and it was obvious I wasn't going to meet my "before 2008" deadline.
The voice acting and processing was a lot of fun. The actors didn't take long to get into the right mood, and I often had a lot of clips to choose from. After the voices I worked on finishing up the remaining details of the game. I also put it through a lot of in-depth beta testing, conducted in person. I usually walked away from each test with several pages full of things to fix before the next. I recommend this testing procedure - don't describe it, make no excuses, just sit behind silently and watch them play. Even better is to have one person play and their close friend look on, and they'll discuss what they're seeing more naturally.
In the meantime, my musicians worked really hard to finish the soundtrack. I was beyond impressed with the final score. Two weeks from release I was fixing game-breaking bugs I've never seen before, so I knew I'd be updating it later, especially if I was going to add all the things I hadn't had the time for. Around the release I nearly broke down and had trouble sleeping for weeks out of anxiety for how the game would be received, which got worse when the feedback was mostly negative. But I lurked on the most negative and caustic forums discussing the game to find out ways to improve it, until it evolved into what it is today.
In total workload, Iji landed at estimatedly 3500 hours with around 75000 lines of code, 4247 sprite images, 75 cutscene pictures, 2111 background tiles, 21 songs and 190 sound effects and voices. None of it is high quality by itself except the soundtrack, but it appears people eventually accepted the game for what it is. I'd rather perform to the best of my current ability and finish a large game than wait until my skills have improved, because then I'd never have done anything at all, and I'd never have improved either.
Version 1.7 of Iji started out as a complete slog, as I converted the game from Game Maker 5.3A to 7.0. It required significant code rewriting, in particular when it came to graphics and sound (side note: GM7's sound system is just about broken), and replacing the text drawing. After the porting itself, the other updates and improvements took another six months. In total this version bumped up the stats to around 4000 hours of work, 90000 lines of code and 90 cutscene pictures.