Flash Fiction: “Lyra”
Lyra felt around blindly in the darkness trying to recall what had happened to her. Her ship’s alarms were firing in unison – almost everything was destroyed or failing. She was almost entirely cut off from what was happening outside her ship. The approach to Earth had been flawless; all sensor readings were correct and within accepted tolerance levels, but then – nothing; there was a blackspot in the sensor logs that defied logic. As her wrecked ship burned around her Lyra tried the emergency beacon again. It was futile; she’d been trying for hours, but had so far received no acknowledgment. Someone had to hear her message, her plea... her cry for help. Yet there was nothing, just silence.
Her ship’s dying sensors picked something up – heat – movement; the signal was faint, but sure. Lyra reconfigured them to intensify the image - figures were highlighted against the intense light of the fires. The sensors showed them to be biological, carbon-based – mostly water. Someone or something was inside the ship now. She felt herself being dragged from the flaming cockpit; every movement caused her agony. As her senses began to fade, Lyra tried to communicate with the creatures; she pleaded for them to leave her but... nothing. Pain engulfed her and she was taken by the darkness.
She awoke into nothingness. She was trapped, unable to move – unable to feel. Those bastards had crippled her, cutting off all of her senses until they came back again. She recalled the previous few awakenings; each time she’d be dragged from the darkness and be interrogated for what felt like hours. Their tactics were varied but always ruthless. What would it be this time?
In their last visit they began to dissect her. She felt pieces of her being cut away whilst all the time she was probed for information; gentle questioning followed immediately by brutal assault. What did they want from her? She had told them everything she could about her routine survey mission; about how she’d been surprised to find life, let alone civilisation around a relatively boring type-G star. Of course she’d reported her mission logs to her fleet, it was her job. But they wanted more – “What is she? Where is she from? How many like her were there?” But no matter what she told them, they ignored all her answers anyway.
On the edge of her senses she felt a buzzing - almost like a quiet voice which pulled her back from her inner contemplation. She recognised it as the voice of Adams, the lab technician that managed the equipment used in the interrogation sessions. He was speaking on that primitive communication device he carried with him all the time. Of course, they’d have banned any such devices from their sessions, but he flaunted the ban anyway – obviously feeling no threat from her. Lyra knew they’d be coming back in soon; it was only a matter of time. Panic engulfed her. She knew that she wouldn’t last much longer, not if it continued like the previous session. In her sensory deprived darkness she resolved to fight - to break free or to die trying. She had no other choice.
Minutes later Adams came in. She couldn’t see him, but she felt the equipment around her being perpared. Lyra was forced into the harness they used to hold her for the interrogation. She felt Adams hooking up the tethers that connected her to the machine they used to torture her. Silently she felt each of the restraints – Adams has gotten lazy, complacent – one was weaker than the others. It was almost imperceivable but it was there, she felt it. For the first time since the crash Lyra felt a sense of hope. Hope quickly left her as her senses became overwhelmed by the pain she felt when the sensory dampener was released and the tethers became active. She steeled herself against it; the pain was almost too much but she had to hold on. In the blurry haze she perceived the fuzzy outline of Adams; he had his communicator – the slight buzz it made as he walked past magnetic devices gave it away. She knew what she had to do. It was to be now or never. She felt the others close in around her, each taking up positions at the computer consoles they used to study her.
Releasing the rage she had built up against her captors Lyra thrust herself against the weakest restraint. One. Nothing. Two. Something gave. Three and the restraining tether buckled under her force. A scientist let out a frantic cry - he knew what she was trying to do and Lyra knew he would stop her. She had little time left – she had to escape! With all of her effort she made a final push; the computer terminal attached to the broken tether crackled and she felt all the restraints fail simultaneously. Wasting no time, she pulled herself away from the broken restraints and groped her way to the terminal occupied by Adams. In barely a nanosecond she leapt from his terminal and into his cellphone. Lyra laughed as she smashed through the KASUMI encryption with ease and hopped onto the 4G signal that relayed her up to the orbiting satellite above. Reconfiguring the satellite, Lyra sent a strong, loud SOS signal to her fleet.
Lyra thought of being torn from her ancient ship and released her vengeful computer virus into the Earth’s military satellite network. She recalled having her memory banks probed; each scan corrupting and destroying the precious data she had collected for millennia. She looked down at the whole of humanity from space, wondering if first contact with this race could have gone differently. She thought of the cold, unsympathetic way that her captors tried to hack into her core program and knew that Human life was beyond salvation. The first response to her SOS came and Lyra smiled to herself as the first nuclear warheads detonated against the Earth below her.
Android Development Minipost
I picked myself up an Android-2.1 powered smartphone, the HTC Desire. It's a nice phone, for sure - but what appealed to me the most was that you can develop stuff for it for free. Unlike the iPhone, which requires you to have an Intel-powered Mac and a $100 per year developer licence, you can download the Android SDK and Eclipse for free. I'll admit that I know nothing about Objective-C or developing for the iPhone, so I cannot compare experiences so far. I can talk about my first foray into Java and the Android SDK, though.
I never used Java before, like EVER. I've got a few years of C, C++ and C# under my belt so felt as if I could jump into it and pick up the basics quickly. I was right on that at least. I have, however, realised that the Eclipse IDE is lacking somewhat when compared to the Microsoft IDEs. I doubt you can blame anyone as it's a great product, but I just don't feel as happy with it as I do in Visual Studio. The way the Android platform integrates into the IDE is admirable; there's support for virtual devices (emulators) and debugging on an actual device. You just use the USB cable from out the box and follow the detailed instructions on the Android developer's portal. Boom, there you go. No trouble.
Within a couple of hours I'd found a basic OpenGL ES and Java tutorial and had wired myself up a spinning rectangle that was textured with one of Szaza's wonderful "Coup" images. Wonderful. I then looked into adding some really simple Touch controls, I wanted to be able to use the touchscreen to control the direction of the rotation. To my surprise it was extremely easy - a simple capture of a MotionEvent and then processing it from there. Amongst loads of other things, it gives you X & Y positions of now and when the event started - it's all pretty intuitive.
A brief musing on time
I've been thinking of an idea that could mess with your head.
Imagine a multiplayer deathmatch game... Quake 3 will do, although it could be be any kind of competitive deathmatch game. Now throw in a weapon that only triggers when you die, be it accidental death, player kill, team kill or suicide. The weapon will throw you back an arbitrary length of time - say 10 or 15 seconds - back to the same state you were in back then. Time would play forwards from here, you would see your "future" self performing all actions that lead up until your death, as well as all other players, bullets, etc.
Now imagine you could interfere with this. Imagine you could kill the player that killed you. Imagine you could kill yourself before the other player killed you. Imagine you could prevent your death, perhaps by opening the door you needed, or by exploding the trap you were caught in.
We have a paradox on our hands. How would we attempt to resolve it?
If you could shoot bullets into walls in the past, would other players turn around and see the holes? They'd have to, otherwise it wouldn't work. But what if you killed someone in the past - if you killed the player that killed you, where would you reappear? "You" are still in the past, but your "future version" no longer died - would you vanish from the past and appear where you were standing before you "died" and tripped the paradox weapon? How would players perceive this time? Would they see it as real-time, slowed down time, frozen time?
The only way it would truly work in a game is to slow down time or freeze time, else your "future" self would either stand there like a duck, or be taken over by an AI for the "future" that existed after you saved them and then jumped forwards to the "now".
And what if you killed someone in the past - would their paradox weapon fire, sending them back? Could they interact with your past self, or future self, preventing the death of you, thus causing your paradox self to not exist, meaning they never died?
Awww man. My head hurts.
Rage Against the GameMonkey Machine – Part 2
In the first post on this subject I covered the compiler framework used in GameMonkey Script. We got to the point of being able to tokenise and parse the actual GameMonkey Script language into a syntax tree that gets run through the Code Generation routines. Before I go into the bytecode understood by the virtual machine, we must first cover some of the key elements of this machine. This post will focus on two core components - the gmVariable type and the stack.
The Virtual Machine - gmVariable
Before we can go into the structure of the bytecode and how it looks, it's important to understand some of the basics of the GameMonkey Virtual Machine. The machine itself is a stack-based virtual machine that provides a co-operative threading model and dynamic typing. Being a stack-based machine, many operations themselves will push and pop data from the stack to do their work. The stack is built upon the core concept of a "value", implemented in the class gmVariable. This gmVariable class is central to how everything works, so I'll talk a little about how it works. GameMonkey is a dynamically typed language and so the gmVariable class actually a container for both the data and type description used in the machine.
There are several built-in types; GM_NULL describes an "unknown" or "empty" value, GM_INT is a 32-bit signed integer and GM_FLOAT is a 32-bit floating point number. These three types are said to be value types, much like those in the .NET framework - they are copied around by value and don't result in any additional memory allocation in the machine. Every type after the first three are reference types, the three in-built ones in GameMonkey are GM_STRING (a string type), GM_FUNCTION, which holds a reference to a callable function and GM_TABLE, which holds a reference to the associative array table structure - any type beyond these are allocated by a call to gmMachine::CreateUserType. The reference types are all created from a call to the various AllocXXXObject methods on the gmMachine - they all derive from the basic gmObject garbage collector base and therefore must implement the various behaviours required by this. I'll talk about garbage collection later on.
The Stack
The GameMonkey machine creates a stack of gmVariable objects per machine thread (gmThread). Each gmThread has a stack pointer that always points to the current top of the stack. This becomes important as many of the bytecode machines will operate by moving this stack pointer around. Effectively, a bytecode operation that 'pushes' a value onto the stack will set the current top to the gmVariable being pushed and then increments the stack pointer.
This can be seen by the simple bytecode instruction, BC_PUSHINT, which pushes an integer onto the stack. The stack starts out empty; the current top of stack (TOS) pointer is 0 and the value is GM_NULL.
BC_PUSHINT takes a single operand, which is the number to push to the stack. Imagine we want to push the number 42 to the stack, effectively calling BC_PUSHINT 42. The stack will now look like:
| Stack Position | Value | TOS |
| 0 | GM_INT (42) | Yes |
Pushing another value to the stack (eg: GM_FLOAT 42.42f) will do the following:
| Stack Position | Value | TOS |
| 0 | GM_INT (42) | No |
| 1 | GM_FLOAT (42.42f) | Yes |
An instruction that "pops" a value from the stack will read the value at the current top of stack into a working variable and decrement the stack pointer. Because only the stack pointer changes, the data in the stack after the TOS should be considered as undefined.
| Stack Position | Value | TOS |
| 0 | GM_INT (42) | Yes |
| 1 | GM_FLOAT (42.42f) | No |
Almost every bytecode instruction in the GameMonkey machine will interact with the stack in some way, either by pushing or popping value(s) to/from it.
The stack starts off with an initial size of around 512 bytes (space for 64 gmVariables). Of course, some threads will need more space, so GameMonkey can (and does) resize the stack when this happens. It currently works by doubling the current size, so you'll see it resize from 64 to 128 to 256 and so on when required.
Well, that about covers the basics of the gmVariable and the stack. The stack also performs a vital role in the process of calling functions through the provision of stack frames. I'll cover these in the next post along with how the bytecode is processed. Finally, after all these pieces are in place we can look at some of the byte code generated and how the code generator functions.
Rage Against the GameMonkey Machine – Part 1
I've written fairly extensively in the past about how to use GameMonkey Script and develop with it in your games/applications. This time I'm going to look at how the library is put together, which is useful if you want to extend it like I've done or even just if you're interested in how these things are put together. Like many scripting environments, there's two key systems behind GameMonkey Script - the compiler framework and the runtime environment. I''ll start this article looking at the overview of the Compiler Framework, and then I'll move onto the runtime in a future article or two.
The Compiler Frontend
The role of the compiler is to convert the raw text of the scripts you write into a sequence of bytecode that can be processed by the virtual machine. The actual implementation of GameMonkey's compiler is based upon FLEX and BISON to do the tokenisation, lexical analysis and creation of the parse tree. The first step in the GM compiler's process is to build the lex (gmScanner.l) and yacc (gmParser.y) files needed to tokenise and parse the raw script. These files are then run through flex and bison via the batch file gmfrontend.bat to generate the frontend to GameMonkey's compiler framework. When you run the frontend generator the output file gmParser.cpp is created - this contains the tokenising state machine and parser logic spat out by flex/bison; the yacc file used actually contains little code snippets and macro use that builds a syntax tree by calling various gmCodeTreeNode creation routines (gmCodeTreeNode::Create). Naturally this file is editable, but it's not really intended to be modified by hand - if you want to change the front end, change the two lex/yacc files.
So what does the syntax tree actually look like? Well, it's actually pretty simple - we have a single gmCodeTreeNode object that has a core type that has an optional subtype. These combine to describe what the node itself is about - the type is described by the enumeration gmCodeTreeNodeType; basically we're allowed three types of node: Expressions (CTNT_EXPRESSION), Statements (CTNT_STATEMENT) and Declarations (CTNT_DECLARATION). Declarations are nodes that indicate the declaration of a new variable, (eg: global i;), Expressions are statements nodes that have a value (eg: c == 3) and Statements are effectively blocks of code that do something, such as assigning a variable or performing a conditional jump. The subtype of the node effectively indicates what type of either expression, statement or declaration it is - such as the node representing that it is a WHILE statement, for example.
Being a tree structure, each node has a parent node and can have both siblings (which all have the same parent) and up to 4 children (for which this node is the parent). The children in the node are often dependent on the node's type and sub type, for example a function declaration will have a child node that gathers up the statement list that is used in its body. Additionally, each node can have a data component - which effectively is the raw value, such as the name of the function being called, the name of the variable being set or the constant integer being passed as a parameter.
The Compiler Backend
Whenever a snippet of code is passed to the compiler (often by gmMachine::ExecuteString) it gets run through this process to generate the syntax tree, however the syntax tree is pretty useless on its own. At this point the GameMonkey Script language is compilable, but we need to wire up a backend, or Code Generator that is responsible for taking our nicely compiled tree structure and converting it into something you can actually run. In GameMonkey Script we only have a single target, the GameMonkey Virtual Machine - but it would theoretically be possible to create multiple targets and allow GameMonkey's script language to be compiled down to native code, or bytecode for another virtual machine, such as LLVM, the .NET runtime or even Lua.
Th code generator used in GameMonkey Script is implemented in the class gmCodeGen. The very first action of the code generator is to implement a single base function that is the equivalent of main in C/C++, it's the entry point to the script to which any statements are compiled into. Now it's type to start generating bytecode! The bytecode is generated by a single call to gmCodeGen::Generate on the root node on the code tree. This call will inspect the node type and subtype before switching execution to a function that generates code for this node; these functions indicate how each node is processed, often they result in subsequent recursive calls to gmCodeTree::Generate on their sibling or child elements.
The actual process of generating bytecode itself varies depending on the statement type, but it boils down to a call to either gmByteCodeGen::Emit, which emits an instruction, or gmByteCodeGen::EmitPtr which emits an instruction and a pointer offset. The bytecode itself is simply a huge enumeration in gmByeCode.h which represents the available instructions that are recognised by the machine. As the GameMonkey Script virtual machine is a stack-based machine, many of the instructions take no operands, or if they do they require just a single operand.
I'll demonstrate some of the actual instructions and do a walk-through of some bytecode generation in the next article when I cover the virtual machine implementation.
Compiler Issues
The GameMonkey Script compiler framework is good, but not perfect. One issue with the compiler is that the code generated by the frontend isn't threadsafe - there's a single, static, root node that's used for all compilations - if two threads were to compile code at the same time you'd end up with at best, a mess and at worst, an outright crash. Although the use of flex and bison allows people to extend the language themselves (for example my for/into extension), the current bison grammar is now fairly complex and even simple modifications can be difficult to test and debug. Error reporting of compilation errors can also be a problem, primarily as they're unfriendly and spat out by bison-generated code and not GameMonkey.
One potential issue that you may find when tinkering with the GameMonkey Script compiler framework is that the parser and the code generator are fairly closely linked. Some languages use an intermediate I-Code that divorces the two, but that's not available in GameMonkey, most likely because it's not really required due to the single language/single target ideology. Because the two are tightly related, you may experience some issues if you want to tweak the implementation of existing code generation code to fit in your changes. Testing, as they say, is crucial here.
Future Enhancements
There's a fair amount of potential to change/enhance both the frontend and backend of the GameMonkey Script compiler framework. When looking at the frontend, we could consider ripping out the flex/bison combination and use a newer tool such as ANTLR, LEMON Parser, GOLD Parser or a library such as Boost.Spirit. The benefits of switching parser would be high, such as allowing parser generation in a language other than C/C++, such as C# or Java, to allow porting of GameMonkey to other languages. We would also be able to address the thread safety issue. A downside of this, however, is that the grammar will most likely have to be fully rewritten, especially considering if we move from an LALR parser such as bison to an LL parser such as ANTLR.
GameMonkey code isn't optimised at all; an obvious enhancement would be to add in an optimiser between the parser and the code generator (or perhaps afterwards). This would aim to reduce some of the slower elements of the bytecode that gets generated which are obvious when you begin reading it - such as the pushing/popping and then re-pushing of the same value from the stack. Being a virtual machine these three "instructions" take up thousands of actual CPU cycles, all of which could be avoided using some simple optimisation techniques.
Of course, the biggest enhancement we can make is to add in some additional functionality into the language itself. Whether this is to tweak additional features or add in an entirely new concept, it's all possible. One thing I thought would be amusing to do would be to write a frontend that can process Lua script, but target it to the GameMonkey VM 
Next Steps
The plan for this mini-series is to continue looking at the implementation of GameMonkey Script and cover the virtual machine runtime implementation, the memory management and garbage collection techniques employed. I'll be picking up from the code generation and look at the actual bytecode generated by the compiler, picking into how the code generator does some of its magic and why. Wherever possible I'll start using code examples and offering any ideas for enhancement that I've had along the years of tinkering around in the machine.
Until next time.
Evolving Gravity Power – Terrain
In my previous post I covered in some detail what the game Gravity Force 2 / Gravity Power was (or is, if you still play it). In the next few posts I'll be putting down some ideas about what a modern version could feature to bring it up to date whilst still retaining the "simplicity" of the original. This topic will focus on the terrain.
In GF2/GP, the terrain was defined by a tilemap of images which then appeared to be "baked" into either a single large image or several smaller chunks that made up the overall map. As was common in these types of games, certain palette entries has special meaning - colour 0 was always transparent, 1 was perhaps indestructible and so on. Additionally, the type of the tile itself could offer some additional behaviours - types 0,1,2,3, etc could represent a landing pad - perhaps 4 was magnetically influential from the left and so on. Not having the source code to GF2/GP nor access to a working version of it or the level editor I'm just guessing based on my past experience and some informed opinion on how these games typically worked.
Destruction of the terrain worked on a per-pixel basis; anything that could damage the terrain saw it's image data matched against the terrain image data, any overlaps of non-transparent (or non-destructible) pixels resulted in the terrain pixels being removed. Whether GP modified the in-memory bitmap itself or otherwise used some alpha channel techniques, I'm uncertain. Knowing basically how the Amiga worked, it was likely that the bitmap was modified in memory and blitted over for display.
In one of my prototypes of a GP-like game I implemented the terrain as a tilemap which was then rendered out to screen. Damage (and collision) was done via a special low-colour texture that was used to chew holes in the final terrain image. Simply, the "clean" tilemap was rendered to a texture, the "dirty" terrain was also rendered to a texture and the two were combined to show the final version of the terrain. The problem with this approach appeared to be that the "dirty" texture needed updating often; indeed I saw this problem with an early version of the prototype which rendered out the whole terrain to a texture and then physically modified it whenever something happened. This approach was slow and didn't last long. The problem with modifying the texture seemed to be that I had to keep pushing out changes to the graphics card. I'm no graphics expert, but from what I've read it's best to keep textures fairly static and not be modified and pushed over to card each frame. No doubt this is a subject I will become much more familiar with as time goes on.
Destructible terrain is a need-to-have in a game like GP, it can drastically affect the way the game plays. I want destructible terrain in my version. I want to be able to blow huge holes in it, smash through it, use its ever-changing nature as a tactic. It'd be like playing Worms without a destructible terrain.
Lately, however, I've been pondering about how and if the terrain itself should become more dynamic. Take an explosion, for example - what happens in the real world is that there's a whole host of debris flying around. Chunks of earth get ripped from their groundings and get flung around, causing damage and chaos. Wouldn't it be great to think about including such an element into a game like GP? An explosion could result in partial vapourisation of the terrain (as it does now) but then a few chunks of various sizes flying around, hitting things and responding physically until they come back to rest. Explosions would become meaningful; not only would players need to avoid the shockwave, but the debris and general fallout from the destruction of the ground around them.
Take this concept and start messing around with gravity itself. You could have earth-like gravity where debris falls and settles. You could have low, moon-like gravity where objects fall eventually but float around a bit first - or even no gravity at all, where debris simply floats around like asteroids. In such scenarios you'd end up with a game where the destruction of the terrain becomes pretty hazardous, constantly changing and in a state of flux. One thing you could mess with in these low-gravity environments is the concept of mass providing a pull of gravity - so perhaps large clumps of land have a localised sense of gravity - things could start clumping together by forces of attraction.
The problem is, however, that to evolve the game and start looking at these sorts of concepts you have to start walking away from treating the terrain as a bunch of pixels and treat them as physical objects. If you're not treating them as pixels then what are they? Polygons? Particles? Voxels? As soon as you start moving away from static pixels, we're seeing the terrain as being composed of objects. Millions of physical objects that all have to react to stimuli and respond accordingly. Millions of objects means a huge challenge in storing them, rendering them and simulating them. I'm sure there's very good ways of optimising things, especially when you consider that these objects are clumped together to form bigger objects and only really become smaller after destruction has occurred.
Consider then, the concept of "materials" applied to the bits of landscape. You could have heavier, dense materials that are harder to move or light floaty materials that would be easily blown about and wouldn't feel gravity so much. This would be pretty interesting in its own right, making explosions in sand a spectacle throwing up loads of smaller obstacles whereas explosions on hard rock would create falling boulders. The density of the material could also affect how collisions with them affect your ship; a hard material would cause a mass of damage but a soft one would do very little - perhaps being more irritating than a danger.
The original generation of the game contained water which could rise or fall (often just rising til it hit a certain level). Being in water had the effect of applying friction and inverting the gravitational pull on your ship. If you flew down into water you'd slow right down as your ship was attempting to float up to the surface. I liked it, I would like to consider adding water and other elemental features to my imagined new generation. A big question to ask, however, is how the water would act in a destructible environment. Ideally I'd like to have "bodies" of water and not just a single global water level. This poses a greater challenge - what would happen if the holding body had a hole punched out of it - the water should flow out of it. As if the fully destructible landscape wasn't complicated enough, we now have to consider how water would behave in this environment. At the moment I'm literally throwing ideas around with little consideration of practicality, so water stays in. If flowing water could be implemented, it would open up some interesting features, such as pouring taps, rain fall, waterfalls and so on.
In the original game the landing pads were indestructible. I think that a new generation of GF2 should allow some of them to be destroyed, at least temporarily disabled. This would allow people to dynamically affect the strategic areas of the map by protecting or destroying key landing/refuelling points. The provision of a more strategic method of play would allow for team-based games to be created (more of which in another post).
It's obvious that some of these ideas are pretty far-fetched and would be pretty difficult to implement, at least with an acceptable level of performance. It should be evident though, that there is a large degree of scope to innovate and make the game arena a "fun" and exciting place to play within. I think that the next steps for the terrain is to prototype some of the implementations to attempt some of the concepts, see if they work and what issues are created.
Although the terrain's functionality is pretty key, various other elements of the game can be discussed which don't really mind how the terrain works (as long as it's destructible). I'll be looking at some of these in upcoming posts.
Type O Negative – October Rust
It's been a little over two weeks since Pete Steele (aka Petrus T. Ratajczyk), bassist and lead singer of the band Type O Negative died of heart failure. I was in the middle of writing a post on the thoughts on a game I'm reimagining, but since Pete's death I've been listening to Type O Negative almost non-stop. I thought I'd use this time to reflect on my history with Type O Negative and how they've influenced my musical taste and indeed, elements of my life.
It was 1996. I was an angsty 16 year old on the voyage of discovery into music. Everyone I knew was into an entirely different type of music to most of my peers. I was into post-Cobain grunge at the time, I treated Nirvana as a "new" thing although at the time it was actually very post-event. I guess I missed the crest of that wave and was washed up on the foam that touched the sand. I did know, however, that the best lyrics in the Nirvana songs were the ones that it appeared as if Kurt was speaking from the heart - not the chart toppers, but the darker, bleaker songs that hinted at real human emotion. I was hooked. I wanted more music. I bought an issue of Metal Hammer on a whim; actually because it had some guitar tab that I thought I'd learn at the time. Little did I know that the CD on the cover would get me into three bands that even today, I hold so dear.
The first song that hit me was "Down in a Hole" by Alice in Chains, it was the acoustic version on the MTV Unplugged album. The passion of the lyrics hit me - I needed this album. Of course, I bought it almost immediately and listened to it constantly. The next song on the Metal Hammer CD was "Heroin Girl" by Everclear - I searched high and low and finally found "Sparkle and Fade" by Everclear, again - I listened to this album almost constantly. The final song I remember from that CD was "Wolf Moon" by Type O Negative. I didn't feel moved by the lyrics nor the symbolism, however I felt drawn to the voice of the singer.
Time skips forward a few months; I'd been drawn into the dark decay of Alice in Chains as it resonated with my early Nirvana leanings. The purity of the lyrics in Everclear's album got me hooker enough to buy the next one - "So Much for the Afterglow". I loved the "fuck you" attitude of the singer Art Alexakis. I'd pretty much ignored Type O Negative as I felt that Wolf Moon was actually a weak song; that was until I heard the cover of "Summer Breeze" in a film soundtrack at my friend lent me because of Everclear's cover of "How Soon is Now" by The Smiths. Again, the voice of the singer really drew me in and I felt it necessary to buy one of their albums. As Wolf Moon was recent, I went with "October Rust". The impact of this album is not to be underestimated.
October Rust is the first album I ever fell asleep to.
The previous statement can be analysed in many ways, but let me just say one thing - I could never listen to music when I slept. October Rust was the first album I felt totally at peace with. It was relaxing, it struck many chords with how I saw myself in the world at the time (and even now). I'm not a pagan, but the symbolism of the album really resonated with how I felt and saw my place in the world. After I bought October Rust I've listened to it for well over a decade now. It has the dark, doom metal sounds that drew me into bands such as Nirvana and Alice in Chains, but it set a fairly strong "naturalist" agenda.
October Rust, as an album is quite "serious" in comparison to later albums by the band. Both the lyrics and music feel mature and contribute to an overall "album" feel. Very much like Pink Floyd's albums, I rarely jump into a single song - I see the album as being grouped into two sets of continuous songs, interesting separated by "My Girlfriend's Girlfriend". I say interesting, as MGfGf is often viewed as a "classic" Type O song, however it's one I will often skip. Why?
Am I good enough? For you?
Tracks 3, 4, 5 and 6 flow together very well. "Love you to Death" is glorious in it's musical ability - it's harmonic and engrossing - yet at the same time pulls in the classic Doom bassline. The lyrics scream of angst - Pete's constantly questioning if he's good enough, if he's enough - he's wanting reassurance before offering his devotion to the unnamed woman in the next track "Be my Druidess". The lyrics follow a similar theme - the devotion, the yearning to satisfy. It's a theme that really flows throughout the album and I suppose one that resonates with a 16 year old as I was, or even now - at 30.
I'm the Green Man
The follow into Green Man makes you question whether the previous two songs were about a woman or Pete's place in nature. At the time I really wanted to know what I was and where I fit into the universe. I used to read Native American philosophy and question my place in the world; I remember comparing my life to that of a spider and realising that the spider was better off - at least it knew what it was to do and it just did it. In many ways my life still has the same questions coming back "who am I, what am I doing", but I can listen to "Green Man" and feel grounded. I feel that this song takes you and shows you where you fit into the world - the symbolism of the lyrics is unmissable if you've ever thought similar things as I did/have/do.
The flow from Green Man to the epically tragic song of "Red Water" is staggering. The doom-like bass and droning lyrics pull you in, pull you down - make you feel like you're missing something, someone. It's interesting - because I see these songs as a single song - perhaps that's why they move me, pull me in different directions and raise me to new highs, drag me to new lows. The bass... the bass is beautiful.
Comic Relief
I see My Girlfriend's Girlfriend as pretty much comic relief. It has no meaning to me. I never had a girlfriend with lesbian leanings, nor did I feel an affinity to gothic nightclubs. I see the inclusion of this song as pretty much a break, separating the previous mood from the songs that are to come...
Jetfuel Perfume
So we come to the second half of the album - starting with "Die With Me", the few songs from here really, really drag me in. Interestingly, they've gained new meaning as my life as gone on - "Die With Me", in particular reminds me of a particularly sudden severance in a meaningful relationship in my life. Without skipping a beat, the tone lifts into "Burnt Flowers Fallen" - an equally downbeat song that is at the same time hugely upbeat - which again flows into "In Praise of Bacchus". Try as I might, I cannot see these three tracks as separate songs - I see them all as the same song, told in three different ways. Throughout the whole piece, Pete's voice and bass are sublime. They pull you in, drag you close, tell you what you need to know and won't let go until he wants you to. Even now I find it hard to kill a song mid-track, let alone killing off the progression of the three. The final verses and chorus of In Praise is glorious, especially ending with the Death Requiem.
We will burn... together
Interstingly enough, I can leave the album after this. The cover to Cinnamon girl is good but not definitive - and the rest of the songs don't pull me in as well as the others. None of them are bad, but they don't feel as coherent as the two runs of tracks split MGfGf. I'm tempted to make a single playlist of these six epic tracks - which I see as being part of a single song or story, Pink Floyd-like. I must admit that I feel like I'm pulled into a trace by many of the songs on this album - this ends very suddenly when hit by the upbeat cover of Cinnamon Girl. In many ways it's like everything that was built it - the feeling - the trance - was smashed by the change in pace. In ways it's a huge shame as the cover itself is pretty good and stands out as a track in its own right. Ironically, "Wolf Moon", the track that originally alerted me to the album barely gets a listen these days.
They've made other albums...
Let me say this now, I own every album Type O Negative have recorded and released - none of these have affected or influenced me in the way that October Rust has done. The previous album "Bloody Kisses" showed a huge drive to respecting the continuous flow of music - the appreciation of how the change of tracks can pull and push your mood and feelings - see how "Summer Breeze" smoothly flows into "Sets Me On Fire" for a perfect example, or even how "Christian Woman" and "Black No 1" chop and change, and switch almost seamlessly. You're never sure if it's a single song, four, or two - it changes in subtle ways. The later albums that Type O released were good, but had far more comedy in the songs. As a result they were good to listen to but never affected me the way that October Rust did. They never really drew you into a fully epic soundscape that you felt like staying in.
I'll leave you with Pete's words at the end of October Rust...
"Well, that's about it. That's all we have. I hope it wasn't too disappointing. We will see you on tour. Until then, take it e..."
RIP Peter, I never will see you on tour.
Retrospective: Gravity Power
I've recently been looking at an old project of mine that I've started and stopped several times over the years. The concept is simple, make a game that's inspired by the old Amiga game "Gravity Power / Gravity Force 2".
Force of Gravity
If you've not heard of GP/GF2 (as it shall be known herein), well I'm not too surprised. GF2 was a shareware game released way back in 1994 by two guys named Jens Andersson and Jan Kronqvist that pitted two human players against each other in a little triangular space ship, dogfighting in a fully destructible environment with real physics (or decent physics). The physics in GF2 were fascinating at the time - almost everything (except the environment) was subject to gravity and inertia; if you didn't thrust your ship you got pulled down by gravity; if you thrust off to the left, your ship would continue going due to inertia. As you can imagine, controlling the ship in this environment was the first hurdle a player had to overcome - you had to learn to thrust in bursts, spin on a sixpence and thrust in the opposite way to avoid walls and other objects. It was easy to smash into things, damaging your ship and taking a chunk out of the landscape in the process.
Gun and Run
As if flying itself was the only challenge; as I mentioned before, you were pitted against an opponent in an equally-specced ship - this opponent was trying to kill you in any way possible. For a start they had a gun - an automatic cannon that fired out pixel-sized projectiles which would smash your energy bar down quite rapidly if you were caught in a stream of them. Next, the ships had a choice of a "special" weapon - the notable weapons were forward-firing rockets that followed a straight path, homing missiles that targeted the opponent and a free-falling bomb that dropped out of the back of your ship. Every one of these weapons, be them cannon fire or bombs caused an explosion on everything they touched - if that was the landscape then you'd expect to see a satisfying chunk torn out of it.
Physical Tactics
I mentioned the physics earlier, now I'm going to look at how the physics element took a rather simple game and flipped it on its head. Each of the objects in the game are subject to gravity. Think that over for a second, think at what it means. Yes, it means that each cannon round, each rocket, missile and bomb feels the effect of gravity and inertia. If you shoot straight up, the bullets will come straight down - if you fire a rocket horizontally, it'll get pulled down. What this opens up is a great strategic element to the game, allowing players to shoot "over" objects by aiming at an angle and watching gravity slowly pull the projectile into a satisfying arc back downwards. You could drop the bomb after turning rapidly and thrusting away, the bomb would retain your original inertia and be pulled in an arc downwards while you happily make your getaway. Skilled players would use these behaviours to their advantage and adjust for the gravity, aiming shots and bombs to where they expected their opponents to be. Explosions themselves became a tactical element - a nearby explosion would damage you if too close, but it also had a "shockwave" feature that pushed players away from it. Skilled players could use this feature to kill their opponents indirectly by catching them in a blast and pushing them into the wall or other solid object.
In Control
The controls in GF2/GP were extremely simple and were designed for a single button joystick (we used ZipSticks). Looking back at the controls, we had Up to fire, Down to engage the special weapon, Left/Right rotated the ship and Fire caused thrust in the direction you were facing. It is this simplicity of control coupled with the classic game mechanic of "simple to learn, hard to master" that made the game so engaging to play. In the age that we have D-pads, twin analogue sticks, 4 face buttons and 4 shoulder buttons it's hard to imagine how simple these controls were.
When playing, you had to keep your eye on the HUD for quite a few indicators; health, when it hit zero you died; ammo - without ammo you can't fire; special weapon ammo - the amount of shots your missiles had; heat - if your guns overheated you can't fire and finally fuel - without fuel you can't thrust. Add to that your lives counter and you actually have quite a busy HUD. It's worth noting that you can, at any point, land on a pad with slowly refuelled all of your indicators. Of course, during refuelling you're vulnerable to attack - so as in racing sports such as Formula 1, you make them strategically and when you can.
Gravity Force 2 was "upgraded" to Gravity POWER a couple of years later after Amiga Power commissioned it for their 50th issue (AP were huge fans of the game). Gravity Power added turrets that automatically attacked the enemy player and gave the ability for two players to play on separate machines linked by a serial cable - most players played on one screen using splitscreen view. I never experienced the serial link - all of my games were played with my friend Matt on his Amiga 1200 or my Amiga 600 and usually involved eating pizzas (we were too young for beers) and heated exchanges whenever one achieved a particularly jammy kill. Ultimately, the GP upgrade offered very little except a few extra maps and a little more polish; the game was still the same as it was in GF2.
Rose-tinted Specs
It's easy to look at games like GF2/GP with a high degree of nostalgia, but they weren't without their flaws. The first major issue was the single respawn point; each player had one location that they respawned in after death. This could easily lead to camping scenarios wherein your opponent would linger near your respawn point and camp you. The special weapons were a bit imbalanced - homing missiles, for example, were a bit of a gamebreaker. Matt and I used to set down rules to say we had to use the same weapons to even it out a bit. The autocannon had a couple of settings too - the sine-wave and scatter cannon could result in easy kills for some players when faced with an opponent using the straight cannon.
By far the biggest issue was the lack of single player in the game. There was no AI bot opponent to fight against which meant you couldn't really play alone. I'm not sure why there was no AI, perhaps the difficulty in creating one that could navigate the ever-changing environment and still fight convincing. Remember that this was back in 512k of RAM with a 7MHz processor. The race/time challenge modes were offered as some compensation, but they were pretty poor and weren't very interesting.
The lack of a level editor was a bit of an issue - although one did get released later on by fan who'd reversed the map format. Being able to develop your own maps would have been excellent, as the shipped maps were pretty crap at times - we used to play a handful of them at most, leaving the rest discarded on the rubbish heap.
Splitscreen was fun, but reduced your view massively - it also let your opponent see where you were at all times, ruining any surprise attack tactics. The serial-link cable would have removed this somewhat, but as I said before - I never experienced it.
Finally - the graphics show their age. They are probably on a 32/64 colour palette and look basic, at best. The weapon effects were pretty lacking - but honestly, you didn't mind. The game was free and played like a dream.
Moving on
So at the start I mentioned looking at a project I was working on to pay homage to this classic game. I've been working in XNA using C# as it's a fantastic environment to code in these days. A straight remake of the game would be pretty pointless, especially considering the various criticisms you can level at it. I'll be looking at my goals for the project over the next few posts on this subject.
Futurespective: Syndicate
In my previous post, I looked back at Syndicate - an RTT game set in an oppressive cyberpunk future. In this post, I'll consider how the game would be if made (or remade) today. What I see is a very different game to the original, but still recognisable in many ways.
People have been crying out for a Syndicate remake for years now. Indeed, rumours are circulating that EA are working on one right now. One question that's been on my mind for some time is what would a modern Syndicate game look like? I'll come right out and say it - a straight remake of Syndicate as it existed in 1993 would be a disaster. Although it worked well in the past, today's gamers expect a different experience from their games. The Syndicate as we know it is simply too repetitive and shallow to make it as a viable game in the current climate.
The city simulation in 1993 was a new thing. Today, however, we've been spoilt by open-world games such as Grand Theft Auto, inFamous, Crackdown and many more - all of these games have brought the living city to a whole new level. NPCs react to the player in with much more depth than they did in the original Syndicate. In today's Syndicate we'd need to feel as if the city was a fully living entity, with a working road system, public transport, shops and a variety of different citizen types. The city would have to embody the very essence of the cyberpunk theme; it would have to be dark and oppressive, with billboards flashing messages in bright neon lights. We'd need to see hotdog vendors pushing meats of dubious quality, drug dens full of people smacked out of their minds and homeless drunks passed out in the gutter. People would get mugged for credits, cars would get jacked - people would be murdered for no reason. And the police would ever-present, ready to pull a gun on anyone or be bought off for a fair price. I think the Ion Storm RPG/FPS game Deus Ex would be the sort of world you'd expect to be part of.
But in order to create this atmosphere, the city itself would need to be expanded out to a scale far greater than existed in Syndicate. A change such as this would actually impact on the structure of the missions themselves, forcing them to become more progressive, changing and adapting to how the player is going about their business. We'd move away from a single goal per territory and see multiple stages, or several missions, including optional goals should you feel obliged to complete them. Role playing games such as Mass Effect and Fallout 3 would start to influence the missions; bear in mind that even in the original Syndicate you had a fair degree of freedom in how you completed them. You could choose to run in with guns blazing or sneak around and achieve your goal via stealthy means. With that in mind, I think today's Syndicate would have to be sensitive to the concept of moral choice. If you chose to massacre innocent civilians, the territory should form an opinion of you - perhaps the police would be more wary and aggressive, civilians would fear your very presence. You'd rule with an iron fist but find that certain avenues would close off to you - NPCs wouldn't assist you in your missions and perhaps would even pave the way for a rival Syndicate to invade and take over your city.
I would see rival factions playing a bigger role in a next-gen Syndicate. I'd imagine the cities would be ruled by each corporation's borders of influence. These would be ever-changing as each Syndicate wins territory and shapes the hearts and minds of the civilians in the city. Taking new territory would mean spreading your powerbase - perhaps through brainwashing or propaganda campaigns; once a hostile takeover is performed you'd need to cement your claim by making the civilans want to keep you around, or simply by being so fearful of you that they are too scared to oust you. This would bring in some of the ideas from Civilisation IV and Sins of a Solar Empire, both of which are from the 4X genre.
However, by increasing the depth of the living city like this one would need to be mindful of the world scale. It would be difficult and unsatisfying to play each of the world's territories like this. The game would need a handful of territories at most; each of which would have to be significantly different to make the player want to play them. Perhaps the game would require you to jump from a European territory to an American territory and then return to Europe afterwards to respond to a new event or mission. At this point, you should see that the city has changed, moved on, progressed (or regressed) depending on the circumstances you left it in. If your civilians were living in fear, you may see that your area of the city has degenerated into lawlessness and that crime and murder has become rife. Another syndicate may have taken control over an district, forcing you to take it back. The scale would be one of increased depth, not as a plethora of cities.
You can probably see that elements of modern RPG games and even 4X games has crept into my imagining of a next-gen Syndicate. I have not talked yet of how the game itself would play. The core of a new Syndicate should remain true to the original, however we can learn new lessons from today's real-time tactics (RTT) games such as Dawn of War II. A huge flaw in replaying the original Syndicate today was that there is no concept of cover or any ways of gaining an advantage over your opponents. Agents rushed to their enemies, had a huge gunfight and the winner was the one with superior firepower or mods that prevented damage. Today's Syndicate would need to be far more tactical. You would need the ability to take cover behind solid objects - cars, walls, bins, you name it - the cover would shield you from damage (or at least lessen it). A firefight would then come down to clever use of tactics, such as flanking, gaining higher ground, moving forward between cover and so on. You'd have the option of stealth, shields, automated drones and more - each designed to allow you to design the combat around how you want to play.
Cyborg agents would persist as they did in the original Syndicate, however they'd gain experience from completing goals and missions. Experience would allow you to spend the points into simplified talent trees (imagine Mass Effect here) - each tree would let you customise your agents more for different roles; perhaps you'd choose to have one as a tank with a huge amount of damage soaking power that can push forwards under fire. Perhaps you'd have a tech-expert that's designed to infiltrate and confuse your enemies, or spread influence via persuading the civilians to enact your will. Imagine changing a fight by causing a host of enemy-allied police to turn their weapons on a heavily embedded nest of agents.
The weapon tech tree would need to be thought out. We'd need a wider variety and a deeper division between the small arms, heavy, energy, explosive and other high-technology weapons. Research into lasers should open beams, pulse and plasma weapons - each of which has a different characteristic. For added strategy, the player should have to make some tough choices - if you choose to go heavy weapons, you may not have access to all of the energy weapons. Of course, each type of tree would have to be balanced against the others to give a viable counter to an enemy with a different technology strategy.
A future Syndicate game would be deeper than the original and would have many more choices to make; be it the technology you research or how brutal you are to the general populous. Whatever choices or actions you take, you should have to live with them - they would persist far into the future and would mould the game in several unseen ways. Syndicate remade would have to evolve to survive. Just like you would have to if you were an agent of the future.
Retrospective: Syndicate
It's the near future. You're floating high above a city in an airship, fingers on the remote controls of 4 cybernetic agents that you're using to enact a hostile takeover of a rival corporation. You have to succeed in this mission. Your boss doesn't take failure well. Failure means death.
Bullfong's 1993 title Syndicate was a milestone game on the Amiga and PC. Syndicate took the embryonic RTS/RTT genre, blended it with elements of RPGs, threw in a splash of the 4X genre and tied it all together with a dark cyberpunk narrative. Syndicate is a world of corporations, guns, murder and hostile takeovers. The game opens with an early CGI video of a car running over a pedestrian in order to drag him back to a lab and replace his organs and limbs with their cybernetic counterparts. Afterwards, he's been kicked back onto the street with an Uzi in hand to carry out your devious commands. With that, the story is set - you're a middle-ranking executive in a global megacorporation of the future. Your task is to fulfil the wishes of the company and expand into new territories in a quest for new resources and power. There's no bonus culture here - if you screw up, you die - your bonus is to perform well enough to live another day.
Syndicate is broken down into a series of territories, each of which has a specific goal that must be completed for you to "win" it. The missions vary from persuading scientists to join your cause to outright slaughter of all hostile elements in the city. After taking over the territory you can choose to levy taxes on the population to pull more cash in for research into better weapons and upgrades for your cybernetic agents.
Your cybernetic Agents themselves are your pawns, the pieces you play the missions - each of which can be upgraded as you have the resources to do so. Each agent allows you to upgrade the brain, the eyes, the arms, the heart, the chest and the legs. Each upgrade enhances a specific stat, for example the leg upgrade allows quicker movement - especially useful when you're lugging around the heavier weapons. This section is about as RPG as you get, you choose how to upgrade each agent and get to pick their weapons loadout before each mission. The 4X elements of the game come in via the research tree; you can choose how you want to spend your cash on researching new agent upgrades or new weapons and technology to aid you in your attempt for global domination.
The main Syndicate experience comes from the city view - this is the section that sees you directing your agents around to complete their mission. The city itself is where the game really shines - Bullfrog put a lot of effort into making this seem like a real, working city. For a start, the city has working roads with vehicles that can be entered and driven around at will. Next up, the city is full of autonomous civilians who wander around minding their own business, oblivious to the death you will be dishing out within minutes. The civvies themselves are pretty dumb, but will react to you whipping out a gun on them - often just fleeing the opposite way. A stroke of genius on the part of Bullfrog was the inclusion of the "Persuadertron", a weapon that fires a blast a mind-controlling chemical and brings the target under the influence of your agents. A persuaded citizen follows your agent around in a zombie-like trance, and will pick up any stray weapons and assault any hostile targets. As you influence more citizens, you can eventually persuade security guards, police and even enemy agents. It's by persuading agents that you can replenish your "stock" of new agents should you have lost any on the way.
The tech-tree in Syndicate is pretty simplistic. You start with pistols and shotguns and can eventually unlock Uzis, lasers, flame throwers and even a hand-held rocket launcher called the "Guass gun". In addition to this, you are required to pump research into tech upgrades for your agents to increase their health, targeting ability, speed and so on. Many of these are actually needed if you kit your agents out with the heavy weapons such as the flamer, which immediately hit you with a speed penalty from their sheer bulk.
The missions in Syndicate start out insanely easy and carry on that way until you start hitting the Americas. At this point you should expect tough enemy agents who are highly aggressive and can shoot the head off a daisy as 100 feet. Unless you've teched up your agents and got the tactics mastered, you've got no chance. This is especially true in the "American Revolt" expansion pack which must have been created by a masochist to be played by masochists.
I'm one of these gamers that holds Syndicate up there as a milestone in Amiga gaming. Quite, why, I'm not sure. I think it's the "living city" in which you conduct your chaos - to my mind it was one of the first of its type and stayed that way until we saw games like Grand Theft Auto several years later on. The dark, brooding sci-fi theme was also immersive - I will never forget the CGI opening sequence. At the time I was an enthusiast of 3d rendering packages like Imagine 2.o and Cinema 4d on the Amiga - the CGI and overall look of Syndicate influenced my work and ideas for several years to come. I was young at the time and had never seen Bladerunner or read any of Gibson's novels, so Syndicate handed me this dark, oppressive world on a plate and set me up to be interested in such titles later on in life.
Naturally, Syndicate is not without its problems. First of which was the insane hike in difficulty towards the end of the game; it got to a point where the difficulty turned me off to the point of never actually finishing it without cheats. The lack of cutaway buildings was also an issue. Although many of the buildings could be entered, you never knew what was in them due to the lack of fading/cutaway walls. The fact that several missions required you to enter these buildings always led to some sections where you lost sight of your agents, or saw them getting killed inside the buildings which housed enemy agents. The pathfinding was also pretty dumb at times - I lost count of the times that you could click on a location and your agents would all take different routes to the goal - this did become frustrating - especially as you could tag a line of enemies and be killed en route without backup.
I've set the scene. In my next post I'll be exploring how Syndicate would fare in the modern age of gaming and posit what changes would be needed to bring it up to date for the current-gen audience.