Year of the… Dragon?

This year’s off to an interesting start: I have a new job (kinda – new company, tech, and projects, but same old faces and spaces), I’ve made a fairly consistent effort to pick up drawing and painting again, completed a short spell on jury duty back in January, I’ve been warming up to start running again in the spring, and now I’m writing here – something I intended to do a month ago.

The way things went at the end of last year left me with a lot of time on my hands. Besides a few job interviews, some scraps of work, brushing up on some technical areas that’d been left at the wayside, and a lot of tabletop roleplaying games, I was finally able to fiddle with a few long-standing ideas for personal projects. Between dabbling in Unity and Unreal I put together a bunch of weird game prototypes and experiments which I’d like to show off and muse upon here – I’ve been intending to since Christmas, but y’know – life.

There are other things I’d like to put into writing too, but writing takes a lot of time for someone as self-concious as me. Still, I’ve had the bug for it lately – strangely I’ve missed all of the essay writing and documentation that comes along with university projects. I think that writing can do a lot to help you put your thoughts in order, to take a step back and think about things more logically, and maybe even cement things in your memory. Moreover, I have a constant glut of ideas in my head – things I want to do and express but don’t have the time or skill to follow up on. It might be worthwhile putting those ideas into writing I suppose, however irregularly I manage it. And I might as well keep that record somewhere public, just in case it peaks someone else’s interests.

But it’s the Year of the Horse!

I’ve also gone off the deep end this year – gone off the deep end for a series of videogames in a way that I think I’ve only done once before. The first time I remember doing this was for Ys, a rather niche series of action/role-playing games by Japanese developer Nihon Falcom Corporation, dating back to the late 80s. After picking up Ys: Origin on Steam sometime in 2012 I struggled my way through its ‘Nightmare’ difficulty three times – once for each playable character. I fell so in love with that game that I proceeded to pick up every previous entry in the series, and a number of vaguely similar Falcom titles; I began with the games that played similarly to Origins – Oath in Felghana and Ark of Napishtim, then Ys I & II Chronicles+, Ys 7, Xanadu: Next, and the latest in the series that I’ve played, Memories of Celceta.

I loved Ys for its unusual mix of platforming, bullet hell, roleplaying, and hack-and-slash gameplay, for its tight controls, hardcore difficulty, and generally firm emphasis of gameplay over graphics and narrative. The characters and story in Ys games is typically cliche, simple, bright, colourful, and all you really need to support great gameplay. Only as I write this I’m remembering how the first gameplay footage I saw from NieR: Automata reminded me of Ys and its strange hybrid of genres – bullet hell, action, platformer, rpg – but that’s one aspect that’s not reflected in the majority of its lineage, the series I’m currently obsessed with.

My Current Obsession: Drakengard

Since Christmas I have played and completed (with some caveats) all three games in the Drakengard series, which likely has garnered a lot of attention of late through its frankly bizarre relation to the successful and brilliant NieR: Automata.

This bears some explanation for those who, like myself, weren’t paying attention until just recently: NieR: Automata released in 2017, developed by renowned Japanese game studio studio Platinum Games,¬† and is a sequel to the 2010 release NieR, set many thousands of years in the future, ostensibly (I haven’t played NieR yet) following from its Ending E. Likewise, NieR itself was a spin-off or sequel to Ending E of a the original 2003 release, Drakengard, set about a thousand years later on. Multiple ‘endings’ are a staple of the series, and their implementation is one of its most interesting facets. Drakengard saw two other ‘sequels’ in Drakengard 2 (2005) and Drakengard 3 (2013).

Unlike NieR: Automata, NieR and the three Drakengard games were not developed by a studio so respected for their stellar combat systems, and were not, by all accounts, well regarded either technically or from a gameplay perspective, even at the time of their release. Certainly, unlike the Ys series, the gameplay takes a back seat here, and that’s not the only difference. In every NieR and Drakengard game the characters are deeply flawed, damaged, difficult to read, and the story is a dark, complex mess that barely manages to make sense even when its not dabbling in social commentary or well-restrained fourth wall breaking. It’s not even the story necessarily that’s had me so captivated, but rather the manner of its delivery.

Despite all their rough edges (some would say near-unplayability by modern standards) I believe there is a lot worth discussing in these old games – as a game designer, as a storyteller, and as a human. I’ve been taking notes and thinking thoughts as I’ve played, and hope to write some of that chaos up into something palatable in the coming weeks – or perhaps a series of rambling articles like this one.

I still haven’t played Nier, and I’m going to take a break from the series as I ruminate on the journey so far, so it’ll be conspicuously absent from anything I write initially. I had considered continuing to play games focussed on dragons for the rest of the year, hence the title, but quickly realised that there are surprisingly few, and the obvious choices – the likes of Skyrim and Dragon Age – would eat up a lot of my time. I am going to dabble in some other games in the meantime though; I just started up Shadow of the Colossus this weekend, on the PS3, because I live in the past and the PS2 version is too expensive.

There’ll probably also be a conspicuous lack of an article dedicated to NieR: Automata, for a multitude of reasons: Nier: Automata is likely to get plenty of mentions as I cover the other games in the series, and desperately struggle to avoid mentioning any connections which might be considered spoilers for it. I’m happy to discuss the Drakengard series in depth not only because its age and flawed nature will likely prevent many people from experiencing it first-hand anyway, but because I simply don’t think ithat the nteresting parts of the other games is tied to the personal experience in the same way it is with NieR: Automata. It’s entirely possible, however, that I simply played NieR: Automata at a time when I was feeling particularly sentimental, and so was affected by it to a greater extent than is usual, but I know I’m not alone in having strong feelings about that game. And besides, lots of people are already over-hyping NieR: Automata; while I love it, I don’t want to contribute to that. Just go play it, and don’t stop till Ending E.

Advertisements

Status Update 2017

I’ve been quiet here for a while now, having been officially admitted into the UK games industry after the summer of my graduation. That summer I was offered a position as a Junior Programmer at Radiant Worlds to work on their then-secret project¬†SkySaga: Infinite Isles, which has since seen announcement, and extensive Closed Alpha Testing. Years later, having seen this project go through many changes and come so far since the time when I joined, this week brought the sad news that development is being placed on hold indefinitely.

During my time with Radiant Worlds I’ve had the opportunity to work in a wide variety of systems in a beautiful 3D game with real-time action, and great creative scope for players. It’s more than I had hoped for as a graduate programmer; I feel very lucky to have had the scope of experience I have within this project, and to have worked with such a friendly and talented team. Direct, player-facing gameplay systems have always been my favourite part of game development, and here I have had ample opportunities to work with those systems, including in character control, combat, animation and UI; but I have also worked closely with designers, ensuring that they have the knobs and levers they need, and lending a technical insight where required.

SkySaga may be on hold, but right now the company lives on, and in this time of uncertainty I, like many others here, am taking the opportunity to stretch my technical-legs a little – to investigate current technologies, and consider what skills I may need for future projects. I intend to stay on the road that I have started, remaining within the games industry come rain or shine. The team here is talented, and even if we are divided, I know that we will cross paths frequently in our professional lives.

Check out the videos below for an impression of what we have achieved over the last few years.

B2D2: Box2D Time Dilation Experiment

Hello.

For the last few weeks, amongst many other things, I’ve been toying with the idea of adding time dilation mechanics to the 2D physics engine Box2D (B2D). I honestly can’t recall what first moved me to think about this, and while I have ideas for game mechanics featuring similar time manipulation, I have none which would require physics simulation. Nevertheless, it’s been an interesting problem, and given me a reason to dig into and understand the internals of a physics engine. You can see a video demonstrating my progress so far below, and scroll down further for more information.


Implementation
Although the implementation isn’t very far along, a lot of time has gone into exploring the B2D code, thinking about potential problems, and finding the ideal place to apply temporal forces. I am not a physicist (theoretical or otherwise), so my model of time dilation is based upon intuition and practicality of implementation:

The idea is that each object has it’s own temporal velocity (TV) which functions as a multiplier for its passage of time. Therefore, a body with a TV of 2.0 will accelerate twice as quickly, move twice as fast; a motored constraint with a TV of 0.5 will output half as much force. A time dilation field (TDF) is a physical space defined by a B2D body, for which a temporal velocity may be specified separately to the ambient temporal velocity. Bodies are affected by temporal drag (TD) based upon standard fluid dynamics drag calculations, considering their velocity relative to contacted TDFs. Thus a body will gradually adjust TV to match it’s environment.

The drag model is intended as a graceful way to handle overlapping TDFs. I had previously considered a multiplicative model, where the area overlapped by two TDFs (a & b) has a TV of TVa*TVb, but this didn’t seem to make much sense to me, physically, and requires a more complex implementation. Instead, I use the analogy of sticks drifting in a river: the river (TDF) flows at a certain speed (TV), which pushes the stick (body) according to a drag function and a collection of variables. In the case where TDFs overlap, I treat it as the ‘river’ having other currents running through it: the body is affected by drag from both currents, so it’s TV should approach their average.

Issues
There is, however, an awkward case in my implementation currently, the logic behind which has become apparent to me as I type this: Two overlapping TDFs, both with a higher TV than a body within will cause the body to experience a positive force from each, accelerating faster than it should. This is true for two fields slower than the body too. This would not be an issue if drag was applied directly to the TV, as the current (relative) TV is part of the drag equation, but as it stands both forces are combined in a temporalForce variable to be applied later in the step.

Another significant obstacle in improving the ‘accuracy’ of this (pure fantasy physics mechanic) is the ability to quickly calculate a reference area for the drag calculation. Ideally, this would be the area of a body which intersects with each field, and then the reference area for ambient TV drag would be the area not intersecting any field. I am not aware, however, of an efficient method to calculate intersection areas, and the ambient reference area calculation is complicated when the body intersects TDF overlaps. Currently, bodies simply experience full drag force from any TDF they contact, and only from the ambient TV when they contact no TDFs. Another alternative would be to consider the intersection of fixture vertices with TDFs, though this would be problematic for large or highly irregular fixtures.

There are, of course, other issues and features yet missing. I have a pretty solid idea what problems I’ll face down the road, and some ideas of how to address a few of them:

  • Constraints are not yet affected by temporal velocity; I believe only their frequency and motor parameters may be affected, and their TV can likely be treated as an average of the associated bodies in most cases.
  • My implementation features an observer TV variable, and all movements are based on the relationship between it and the body TVs. This means that if the observer TV is 2.0, bodies with a TV of 1.0 will appear to move at (1.0 / 2.0 =) 0.5x speed. The catch here is that for accuracy, we need to integrate for the change in body TV between steps, AND for observer TV. Not only do I need to revise some calculus before I can confidently implement the latter, but it also requires that I either cache previous observer TV values, or maintain an observerTemporalForce variable.
  • I need to go over the TOI (Time of Impact) solver code and work out how exactly TV impacts this, as currently this area is untouched. Also, relevant: I need to revisit my old idea of modifying the position and velocity iterations based upon the the current maximum TV in a simulation. My intention there is to maintain stability in accelerated time streams. The problem is that in order to utilize the current maximum TV we would need to either apply temporal forces to TVs in a separate loop prior to island* solving. Alternatively, we can look into the viability of allowing iteration counts to vary between islands, or utilizing the maximum TV from the previous step.
  • By using the standard drag equation, TDFs could potentially be further configurable than they currently are, for example by adding a ‘fluid density’ variable. Currently my implementation uses a (rather high) hard-coded fluid density for temporal drag calculations, to ensure rapid speed adaptation.
  • I’d like to experiment with applying a shader which stretches geometry based upon TV and (spatial) velocity. There’s already a suddenly slowdown upon exiting an accelerated TDF which is reminiscent of warp-in effects from Sci Fi media, and I think this could make it look extra cool.

In all likelihood I’ll soon have to put this on hold indefinitely and focus on some more practical projects, but it’s been fun and informative, regardless.

* Islands are B2D structures into which bodies are clustered prior to solving, based upon their contacts and constraints.

Portfolio Update – AI for The Resistance

Hello.

A few weeks back I added a page for my dissertation project, a research/development paper on AI for the modern board game The Resistance, found here. I finished the last section about a week ago and have no removed the work in progress tags since I don’t think I need to make any major changes.

I’m not completely satisfied with how it turned out; it’s significantly longer than I had intended and skims over a lot of information. The intention was never to provide an alternative to reading the full paper though, only a summary of the work therein for interested parties to skim over. I generally find abstracts for longer papers to a poor job of this.

Lately I’ve been a little preoccupied with the job hunt, but I’ve been quietly toying with a little programming problem and indulging my other creative interests in art and language too. I recently hit my first exciting milestone in the programming project. It’s not much but it’s the culmination of some hours researching a foreign code base to work out the best approach, and I now have a solid understanding of all of the problems that need to be solved as I move forwards.

Updates soon :)

 

Portfolio Update – Game Behaviour

Hello!

I recently put up pages for two projects from the Game Behaviour module undertaken in the final year of my BScH in Computer Games Programming at the University of Derby, which I have now fully completed and received a very pleasant classification for.

You can now head over to the pages for Crispis and DropCakes, and The Frozen Firepits of Generic Dungeon Name for information on these projects, or to download the source code and executables. The former is simply a 2D physics sandbox built upon Box2D and a custom Entity/Component engine, and probably isn’t or much interest to many. The latter, however, you may find interesting if you’re into game design, classic roguelikes, fantasy games, and such.

The Frozen Firepits of Generic Dungeon Name (TFFGDN) was an experimental game design implemented for an artificial intelligence (AI) assignment; it did well, though the AI isn’t too interesting in my opinion. It’s a fusion of turn-based, physics-based mechanics similar to Snooker or Pool, and classic fantasy dungeon-crawler games where a party of adventurers of traditional achetypes such as Warrior, Wizard, Rogue, etc. enter into a monster-infest labyrinth seeking treasure. In its current state it’s not too thrilling; I had intended to implement magic and special abilities for player characters and enemies, which I think would make things a lot more exciting, but I just didn’t have time. I also feel like the physics could be tightened up a lot to increase the pace of gameplay, but I had to do a lot of fiddling with Unity just to get it working in the first place.

Come next week or so I’ll try to have some more information up regarding my dissertation project which was an investigation into AI for Don Eskridge’s The Resistance. Then I can get onto undertaking some small personal projects while I look for work.

SplashDash

Ho! Another delayed post; I said I’d get to this before the semester was up, but this semester hit really hard, and I just haven’t had the time or energy for it. Well, it’s not Christmas yet, so I guess that’s something, no?

The real killer module this semester was Game Development, which consisted of a single group project with three other programmers and seven(!) 3D artists. I started to put a page together for the game we created, “SplashDash”, today; I still need to go over what I’ve written with furrowed brow and fill out the Freerunning Implementation section, but there are already download links for Windows, OSX, and Linux builds, a gameplay trailer, and lots and lots of screenshots to see!

splashdash-title-001

SplashDash is a 3D, freerunning, score attack game, drawing inspiration from games like Jet Set Radio, Tony Hawks Underground, Mirror’s Edge, and de Blob.

Robots have taken over the world and subjected it to their ideals of order and optimisation. They’ve whitewashed all the walls and broken the spirit of the human population, who now go about their daily chores like mindless drones. The player is a teenager gifted with the ability to bring colour into objects with a single touch, and must use it to paint as much of the city as possible in the given time limit to inspire a human revolution.

My main responsibility was the implementation of the player movements, including running, analogue jumps, wallruns, ledgegrabs, vertical wallruns, wallrun jumps, and wall rebounds. I also worked closely with the programmer and artist responsible for the animations to try and make sure things looked as smooth as possible, and though some animation glitches remain I’m pretty pleased with the way things turned out.

The freerunning implementation is, honestly, pretty unrefined, as I’ve never coded such complex 3D movement mechanics, nor used Unity before, and time constraints on the project meant that I could not afford a lot of research or iterate as much as I would have liked. I opted to go with a system which did not require any hints or triggers to be placed into environment, so as to minimize the workload of environment construction. Let’s just say there are a lot of raycasts and a lot of vector maths involved; you can read more about it (once I’ve written it) and my other contributions on the SplashDash page.

We’ve all learnt a lot from this project – mostly about working with Unity, its flaws, quirks, features, limitations, and best practices, but also more transferable skills. We had some communication and organisational issues (which I’ve written about at length for a post-mortem as part of the assessment, and shan’t post online yet) that I think are easily solvable once identified; some simply by picking the right tools and channels, and others by encouraging certain practices. The project was also a good insight into the importance of sorting out your methodology and workflows out early on in a group project – I feel that with time invested in the right places at the start, things would have progressed more quickly, and in a more organised fashion.

splashdash-tutorial-wallrun-002

Anyway, I think it’s pretty effective as a proof of concept – or not, as the case may be. We all agree that the movement is the most fun part, and that a linear time trial or racing mode, on maps similarly constructed to the tutorial level, would probably be more fun (especially with some nice acceleration mechanics thrown in to reward good freerunning flow). But it is quite fun, all the same, and I think the concept deserves further investigation which, if I ever find the time to experiment with a proper non block-based painting system, I might just be tempted to conduct.

Edit: P.S: Mute the game and go listen to the Jet Set Radio OST while you play :P

A Note of Intent

Aaargh.

I decided I wasn’t going to bother posting another update here until I’d settled back into uni and sunken my teeth into some fresh projects I could write about. I suddenly find myself almost two-months into the final year of my degree and I’ve been rather too busy to give it a second thought.

So here’s a note of intent: I will, sooner or later, make a proper post about this semester’s projects, before the semester is concluded, including my dissertation project, which was signed off by my supervisor last week and is now awaiting my full attention…after two more urgent deadlines. For now, I’ll just leave a brief list of what I’m currently working on:

1. An essay on the sufficiency of services provided by modern operating systems for accessing detailed information about gaming peripherals [due two weeks from now – yikes!].

2. A Unity game about parkour and painting. Think Jet Set Radio meets Mirror’s Edge meets Tony Hawks Underground. This is a team project with three other programmers from my course, and seven artists from the University of Derby’s Computer Games Modelling and Animation course [due sometime around the end of the semester].

3. For my dissertation project I am to be investigating the posibility of applying various AI techniques to the board/card game The Resistance. This may include search trees and evolutionary techniques, and I will be using the competition framework and bots provided by AiGameDev.com last year.

These are the things I’ll be posting about and/or creating new pages for here when I get chance. All the other stuff I do I’ll likely post about elsewhere if I even have the time to continue doing things other than eat, sleep, and code.

I cook some nowadays, and bake a little; I still study Korean, and I’m trying to snatch back the graphic design and art skills I used to have. But I’d like to keep this blog focussed more on programming, and the larger projects I undertake.