Taming the AtGames Flashback

TANGLEWOOD vs. the AtGames Flashback Console

Moving on from the – thankfully almost resolved – troubles of the AtGames Firecore, my QA team and I continued running through our stash of other weird and wonderful Mega Drive clone consoles, when once again we were rudely interrupted by the postman with another AtGames machine. You can thank our friends over at Bitmap Bureau for this one – the makers of Xeno Crisis, another successfully Kickstarter funded game for the world’s greatest videogame console. We’ve been pooling our resources together to help our projects along, and they’ve sent us an AtGames Flashback HD to play with!

It’s an entirely different design to the Firecore, right from the ground up. It looks more the part, a slightly shrunken Mega Drive 1-style casing, which houses an ARM-based Android system (as opposed to the Firecore’s proprietary probably-a-system-on-chip core) running a software emulator this time, with HDMI output pushing 720p, bluetooth gamepads, a scanline filter, and a slick new menu system. Nice to see things have improved! The audio from the built-in games sounded crisp and in tune, and the new HDMI output was a game changer with regards to visual quality, so we had high hopes for TANGLEWOOD running on it. How naive of us…

TANGLEWOOD fired up in complete silence. No intro theme, no menu UI sounds, nada, until we started the sound test and noticed that PCM sound effects and PSG sound was working. FM emulation was DOA, then. At least the PSG was in tune!

The Investigation

It was probably sensible to assume that we’d have to start over with our diagnostics, since the system is completely different from the Firecore so none of our previous findings would be of any use. We gave those special registers a quick poke just in case the manufacturers had carried over the concept for convenience, but there was no response.

Cracking open the case to look for clues immediately revealed an unexpected aide – the board was straight-up sporting a mini USB port!

Since it’s an Android based system, and we are wishful thinkers, we hooked it up to ADB to see if would respond, and to our surprise it did, root and all! A quick Google search showed this wasn’t new information (should have looked there first…) and the machine has already had a bit of probing from the SEGA fan community, but unfortunately it was all related to getting more games on the machine; nothing revealed anything about the emulator powering its games, and no sign of any other games suffering from the same problem as ours. We dumped the whole flash to poke around with and closed it back up.

The first thing to check was if any of its built-in games had been modified to work around any issues. With the flash dump to hand we were able to extract the ROM files, and started firing each one up in our modified megaEx build to log any unknown register pokes or other out-of-the-ordinary behaviour. Unlike our Firefore diagnostics, this unfortunately showed nothing.

The next thing to check was if any other games in our library suffered from the same issue. Popular games probably would have shown up in Google results if they had compatibility problems, so it was wise to start with some lesser known titles. We have quite the collection of homebrew carts! We tried things like Daytrip, Escape 2042, and some feature test carts, which all worked, but Miniplanets was silent!

Miniplanets and TANGLEWOOD share a common denominator: they both use the Echo Sound System from Sik – a rather superb Z80 driver for music, SFX, and PCM playback for the Mega Drive. Echo also comes with its own test program called Echoster, so we fired that up, and verified it suffered from the same issue.

Luckily, Echo is open source. Unluckily, I’ve never touched a line of Z80 assembly in my life, and those of you who already follow my blog will know I stopped writing devblog posts when I got to the PSG chip – I’ve never actually touched the YM2612 either! One 12 hour crash course in Z80 later (thanks, everyone at Plutiedev!) and I was totally not ready to track down a bug in a language I barely knew, on a chip I barely knew, on a clone I barely knew, at 3 o’clock in the morning. The first issue was figuring out how to debug anything on the Z80, since it has limited ways with which to communicate with the 68000 – it would require some sort of status byte or command queue to send data back to the 68000 to display info on screen. With limited time, I needed some debug output – or at least some way to identify if a particular line of code had been hit – available from the Z80 itself. It’s capable of sound output, so how about some sound queues to tell me if a condition was met? It’s primitive, sure, but it does the job.

Armed with a z80asm assembler, Echo’s source, and SEGA’s Mega Drive Programming Manual, I managed to follow the example register table for a single piano note:

With a PlayPiano routine written, I got a piano note when interesting code was hit! Jog on, printf()!

From there I was able to determine which parts of the codebase were being executed within Echo, and check some assertions – the initialisation, instrument loading, and note on/off routines were all being called. One thing I’d noticed was that once my debug piano note had played, all subsequent Note On events from that channel also triggered the same note, which meant that the AtGames was fully capable of producing sound output from Echo, but the instrument data didn’t seem to be written (or overwritten, after my piano had been loaded).

After some head scratching and fruitless attempts at tinkering with the instrument loading code, this desperate attempt at getting an answer worked:

    ex af, af'  ; Backup A+F
    ld c,iyh    ; Load top byte of IY
    ld a,c      ; To register A
    cp $40      ; Check it's $40
    jp z,.ok    ; If correct, bail
    call Piano  ; IY is not $40XX
    ex af, af'

On a genuine Mega Drive, this code ran silently. On the Flashback, it played a piano note.

Interesting. For those who have been following along with my assembly adventures, this should be quick to explain – the Z80 has a bunch (actual terminology) of 8-bit registers used for arithmetic and counters, and a handful of 16-bit registers used for addresses. The 16-bit registers have pairs of 8-bit counterparts allowing access to the upper or lower byte. For example, IY is a 16-bit register, IYH allows access to the top byte (IY High), IYL allows access to the bottom byte (IY Low).

In Echo, the YM chip is accessed via four ports – $4000 and $4001 for modifying parameters of channels 1-3, and $4002 and $4003 for modifying channels 4-6. During Echo’s initialisation, this happens:

ld iyh, $40

This keeps $40 in the upper byte of the IY register for the entirety of the program, and the lower byte is set to $00, $01, $02 or $03 when needed, depending on the channel being accessed.

The Fix

It turns out the AtGames Z80 emulator doesn’t correctly emulate loading to/from IYH! Another quick test determined that it does, however correctly emulate loading to/from IYL. The simple fix to the problem is just to initialise the IY register in full:

ld iy, $4000

Easy! TANGLEWOOD now boots up with the main menu playing, and all is well! Almost. Once again, the SSG-EG feature of the YM has not been emulated in this machine, resulting in the same screeching and whining as the Firecore when playing notes configured with it.

Thankfully, we already have a simple way to test if we’re running on this machine and disable SSG-EG during initialisation – just try accessing that IYH register:

ld iy, $1234
ld iyh, $40
ld a, iyh
cp $40
jp nz, .disableSSGEG

And that’s a wrap!

Taming the AtGames Firecore – Part 1

TANGLEWOOD vs. the AtGames Firecore Console

During the Kickstarter campaign for TANGLEWOOD, I made a very big promise – that TANGLEWOOD would run on just about every SEGA Mega Drive console, clone, emulator, and home arcade setup available. A golden rule I’ve been throwing around was “if it runs Sonic 2, it will run TANGLEWOOD” – no problem, since the game doesn’t perform any demo scene-style tricks or timing sensitive manoeuvres, nor does it rely on any hardware quirks or undocumented features of the various chips involved. It’s a big and ambitious game from a design perspective, but as far as pushing the hardware goes, I backed off a bit in order to uphold my promise of compatibility.

This proved quite a challenge, then, when once fateful afternoon the postman knocks on my door to deliver a box of goodies for our QA team to get busy with – some 6-button controllers from various third party manufacturers, a white label flash cartridge with SD slot, and an intriguing little black box with “At@Games” written on the front.

It was the first AtGames Mega Drive model that was sold en-mass here in the UK at our Argos stores – at its heart was AtGames’ Firecore technology. I’d had previous experience playing Streets of Rage on this thing in a noisy gaming cafe in Nottingham. The hustle and bustle of the venue did a good job of hiding the Trojan inside the little horse – its horrific audio. Just how bad was it? I didn’t believe the tales depicting it as the worst console ever released, since the Internet loves its hyperbole, but in this case everybody was right. All of the audio is pitched down, at differing values between FM and PSG, and there was some horrible screeching when some parts of soundtracks played.

TANGLEWOOD was shocking. It sounded like a horror game – dreary down-pitched FM, twisted PSG slides, and high pitched screeches where there should be PCM samples. I have a promise to keep, so I’m not taking this lying down.

The Investigation

Some quick searching around revealed that the menu ROM has already been dumped by a team of Russian hackers over at emu-land.net. The ROM seems to make use of 128kb VRAM mode, writes to ROM space, and pokes some addresses outside the usual Mega Drive range which crashes most emulators, but I’ve been working with megaEx (my fork of Mega by Lee Hammerton and Jake Turner) which happily executes broken code, instead logging to file anything it doesn’t understand. As expected, the graphics were garbled, but by pressing buttons I could hear the menu navigation sound in the background, so all was well.

Some modifications to the logging later, and I had a dump of unknown reads and writes when booting up the AtGames menu ROM:

Byte 0x00 written to cart address 0x00000000
Byte 0x0E written to cart address 0x00000001
Byte 0xFF written to unmapped address 0x00B01008
Byte 0x07 written to unmapped address 0x00B01009
Byte read from unmapped address 0x00B00010
Byte read from unmapped address 0x00B00011
Byte 0x00 written to unmapped address 0x00B00010
Byte 0x40 written to unmapped address 0x00B00011
Byte 0x53 written to unmapped address 0x00A14000
Byte 0x45 written to unmapped address 0x00A14001
Byte 0x47 written to unmapped address 0x00A14002
Byte 0x41 written to unmapped address 0x00A14003
Byte 0x00 written to cart address 0x00000000
Byte 0x0F written to cart address 0x00000001
Byte read from unmapped address 0x00B0001A
Byte read from unmapped address 0x00B0001B

Writing to address 0x0 seems a bit odd (it’s cartridge space), those in the range 0xB00000+ are not in any known Mega Drive space or any of its addons, and 0xA14000-0xA14003 are just the TMSS (the emulator hasn’t implemented it yet). This bit is particularly interesting:

Byte 0x30 written to unmapped address 0x00B01054
Byte 0x20 written to unmapped address 0x00B01055

From the Russian forum, although Google Translate makes a mess of it, you can make out that it changes the FM frequency, and the value 0x2820 is provided as an example. Writing this alone doesn’t work, it seems that those word writes to 0x0 are some sort of latch to tell the AtGames to pay attention to writes to 0xB00000+. Adding this to the top of my ROM seems to fix the FM frequency:

    move.w #0xFFFF, 0x00000000
    move.w #0x2620, 0x00B01054
    move.w #0xFFF7, 0x00000000

Simple enough. Latch 0x0, write 0x02620 to what seems to be the FM frequency register in the AtGames machine, un-latch 0x0. The example 0x2820 provided by the Russian folk didn’t seem to be quite in tune, 0x2620 sounded closer.

The PSG was still very out of tune, and there was still harsh screeching from some notes, so we needed more. I modified TANGLEWOOD’s sound test screen to include an address poker – an address (starting from 0xB00000) and its current value is shown on screen. Up and Down cycles the address, Left and Right cycles the value, and Start writes the new value.

After some experimentation I had a vague idea of what some of the registers were responsible for:

Locks up the machine

Affects PSG pitch, bingo!

Cycles through various video modes

0x00B01002 - 0x00B0104
Various graphics output options, all resulting in a fuzzy, black and white display

Possibly NTSC/PAL flag, but my TV has no OSD so can't tell for sure

Seems to do a palette shift

Screen Y offset in pixels

Screen X offset in tiles

Changes screen to green/blue tints, possibly RGB order

Slows audio down to a crawl, PSG glitches and screeches

Locks up the machine

TV displays "no signal" but audio continues to play

Adjusts VDP tile width

Adjusts FM frequency - changed FM music pitch

Adjusts FM and PSG clock - changed FM and PSG music tempo

So, with some trial and error, I managed to find the relevant addresses to change audio clocks:

  • 0x00B00018 changes PSG frequency. The bottom 2 bits seem to be a fine tune setting (4 steps), whilst the rest of the byte seems to be a divider (for PSG, frequency*2 = one octave).
  • 0x00B01054 changes FM music pitch, already known.
  • 0x00B01055 changes FM and PSG clock, speeding up and slowing down the music tempo.

The Fix

Using the very scientific method of playing my game’s original soundtrack from a laptop, and listening to the AtGames sat next to it, I settled on the values 0x7A for the PSG freq, 0x26 for the FM freq, and 0x20 for the FM/PSG clock.

The code:

    ; AtGames audio fix
    move.w #0xFFFF, 0x00000000  ; Latch 0x0000
    move.b #0x78, 0x00B00018    ; Write new PSG frequency
    move.b #0x26, 0x00B01054    ; Write new FM frequency
    move.b #0x20, 0x00B01055    ; Write new FM clock
    move.w #0xFFF7, 0x00000000  ; Un-latch

Here’s the new and improved main menu theme tune:

It’s not 100% done yet. The next step is to fix the screeching sound from some of the instruments. After listening to some of the tracks, I’ve managed to determine that the affected notes all used the SSG-EG mode in their FM operators. It seems AtGames didn’t emulate this properly (if at all), and my only option – without adding more precious time to this – was to disable SSG-EG in all instruments as a test – which worked fine.

I’d like SSG-EG on the other consoles, so the plan is to disable SSG-EG on the fly in the audio engine if an AtGames is detected. I’ve yet to figure that part out, and so far it’s been easier said than done – reading from any of the AtGames’ config regs at 0xB00000+ hangs up a genuine Mega Drive, and reading from 0x0000 on the AtGames returns the first word of the stack vector rather than allowing us to read back the latch, which means we can’t verify that the latch was written/denied to check if it’s a port.

If I get time, I would like to investigate these registers further, and properly document the behaviour of all values written across the range. Perhaps we could fix other issues with this model, so homebrew and ROM hacks will be safe on the AtGames Firecore!


Mega Drive Assembly Workshop and Hello World Sample

Hello! It’s been a long while since I’ve posted a programming article, since I’ve been pretty busy getting my game finished.

I do intend to return here with a full new set of tutorials (now that I know what I’m doing…) but in the meantime:

SEGA Mega Drive Assembly Programming Workshop

I’ve uploaded the slides from my workshop at the National Videogame Arcade last year, which details step-by-step the journey to getting Hello World on screen, plus a few extras like memory management, and bonus slides on sprites. You’ll need this pack of resources to go with it.

SEGA Mega Drive Hello World Example

For people trying to get started quickly, I’ve also created a peer reviewed, tried-and-tested on hardware, Hello World sample, all in one file.

Assemble with ASM68K.EXE:

asm68k.exe /p hello.asm,hello.bin


SEGA Mega Drive Assembly Programming Workshop at GameCity Festival

I’ll be running a workshop teaching the basics of 68000 assembly language and the SEGA Mega Drive at this year’s GameCity festival! It’s on Thursday 27th October, 11am – 2pm, at the National Videogame Arcade, Nottingham, and will last for around 3 hours.

Who is the workshop for?

  • Those who have never written a line of assembly before
  • Those with little or no understanding of how a CPU works
  • Some higher level programming experience is required – functions, variables, logic and flow, signed and unsigned numbers
  • Some higher level debugging experience is required – breakpoints, stepping, watch windows, swearing
  • A basic understanding of binary and hexadecimal numbering is recommended (I’ll provide a quick refresher, though)

What will be covered?

  • The basics of the 68000 CPU
  • The basics of 68000 assembly language
  • Writing your first line of assembly
  • Building your first ROM
  • Debugging assembly
  • Basic arithmetic, branching, looping, and logic
  • Initialising the SEGA Mega Drive
  • The Mega Drive Video Display Processor
  • Programming the VDP
  • Palettes, tiles, maps and sprites
  • Turning the screen pink!
  • Creating a font
  • Displaying “Hello, World!”
  • Porting Crysis 3

What will you need?

Tanglewood Tech Demo 0.0.11

I’m pleased to announce the very first tech demo release of Tanglewood!

The demo represents the first milestone in Tanglwood’s development. It is a proof of the engine, editor, toolchain and content pipeline, the basic mechanics of the game, controls and platforming behaviour, the art and animation styles, and some early puzzles.

These two levels have been a sandbox for mechanics and puzzle testing since development of the game began, and with a little work they’ve been turned into functional showcases for Tanglewood’s early progress.



This is a prototype of a game in its very early stages of development. Some assets are placeholder, and all tech is a work in progress. The look, feel, quality and feature set may not be representative of the final product.

The tech demo contains tests of the following features:

– Nymn: basic movement and platforming, sleep/wake up behaviour, running, walking, jumping, pushing (animation missing), rolling, gliding, death
– Fuzzls: all alert states, physics, and rolling behaviour
– Djakk monsters: initial encounter logic, A.I. behaviour tree, tracking, attacking, search patterns
– Colour abilities: yellow (glide) and green (time slow/cloak)
– Flues: varying output velocities and hold durations, multiple occupants, linked flues
– Boulders: physics, rolling behaviour, cracking and respawning
– Director Cam cutscenes
– Time of day system
– Static blockades



It’s an early tech demo/prototype, so expect to see these problems and more:

– Missing fall animation
– Missing push animation
– Framerate drop during Djakk monster encounter in Level 1
– It’s possible to get Fuzzls stuck against walls if they’re rolling fast enough to jump over flues
– It’s possible to get the Fuzzls in Level 2 stuck by rolling them back to the flue at the start
– The Djakk in Level 2 can reach the flue on the right-hand side if left alone in search state for a long time
– It’s possible to get Nymn to sleep in mid-air by jumping at the end of a level
– It’s possible to push the boulder in Level 2 whilst using time-slow ability (boulder won’t animate)
– Footstep sound effects take priority over others, which may result in some SFX cutting out whilst running (ambience, Fuzzl SFX)
– Many known sprite/background draw priority glitches, and tile flipping errors
– Dead Djakks use the older placeholder palette (yellow feet/teeth)
– Occasionally the wrong instruments are chosen for an SFX (emulator only)
– Double-tapping C with the cloak ability will choose the wrong palette



Download link over at the Tanglewood forum

Tanglewood: Introducing Djakk Monsters

Introducing Djakk Monsters

There’s a reason our friend Nymn is so keen to get back home before dark. That reason is a huge, snarling, fearsome beast that emerges from its cave at night, with the blood of its last victim still dripping from its teeth, and an insatiable appetite for Nymn’s face.

djakk_0Djakk monsters have been a threat to Tanglewood for as long as its inhabitants can remember. The lore speaks of an ancient tribe of hunters who saddled them up and rode them right to the edge of the forest, hunting the Djunn kind for as far as they could smell. Long gone are the bad rulers of the lands, but their big ugly pets remained.

A Djakk fight is a long and drawn out challenge, they are expert trackers and will chase Nymn to the ends of the Earth for a taste of his innards. As the player you must be quick, be forever wary of the Djakk’s presence (however much you think you’ve lost it underneath you), and never underestimate their ability to break through obstacles or foil your traps. They’ve seen it all before.

Getting rid of a Djakk will need to be done in different ways for each encounter. In the demo I’ve been working on, a precariously placed boulder is primed ready to drop on the unsuspecting beast’s head, but that’s just a set-up scenario to show off the mechanics quickly. The monster will roar on sight, then immediately give chase, but if he loses you he will wander over to the last place Nymn was spotted to sniff out your tracks. This can be used very much to your advantage, as a way to coax a Djakk into standing on a particular spot – as long as you’re cunning in your escape.


I have plans for some of the Djakk encounters to last entire levels, and maybe more. They provide an interesting narrative reason for keeping the forest floor out of bounds until the creature has been defeated. Flues, Fuzzls, and all other tricks and traps inhabiting the surface would be unusable, making whole sections of the game, pickups and secrets inaccessible unless Nymn figures out a way to dispose of his unwelcome companion. More importantly, Nymn is looking for somewhere to sleep to wait out the rest of the night terrors, and with this thing around it’s unlikely there will be anywhere safe to rest.


The Djakk posed quite an early technical challenge for the game engine; it’s the largest sprite sheet in the game so far, which is costly both in subsprite count and bandwidth to transfer animation frames. Many of the routines featured in my Mega Drive coding tutorials for sprite management were too slow and naïve in implementation, and it’s taken me quite a while to rewrite them to cope with these huge creatures. The work has certainly paid off, I’m quite proud of our Djakk so far.

Future plans for the Djakk include the ability to traverse the terrain, perhaps being able to leap across a crevasse or run up a ramp to reach higher. There’s also the possibility of weak tree branches, both as an added threat to Nynm and an advantageous point to coax a Djakk onto, to see it fall to its death. For the moment we’ll be keeping it simple, this huge sprite sheet is tricky for our artist to maintain, so we’ll squeeze what we can out of the animations available first.

See the ugly fellow in action in this short demo video:


Tanglewood: Colour Switching

Colour is everything in Tanglewood. It is a life force that can be given, shared, stolen, or used as currency.

Every animal and plant in Tanglewood has a distinct colour, and that colour may play an advantage or disadvantage to the player. The organic world may respond in a positive manner if Nymn is a matching colour. For example, a length of twisted vines blocking your way may open up for Nymn if you find a way to switch to the same colour, or even move or entice a matching coloured creature to sit next to it.

Monsters may behave differently depending if you are a matching or opposing colour, and will either give chase or hang back on the assumption that you are a member of their pack.

In Nymn’s case, his colour is his power. Born a red fellow, he can’t do many things by default, but when transformed into a blue, green or yellow creature his world is opened up to bigger and better possibilities.

In the previous article I mentioned that the humble little Fuzzls will reward Nymn for helping them back to their nests. A Fuzzl will allow Nymn to take its colour for himself, transforming Nymn to match, and allowing him to use the special ability provided by that colour.


This week we’ve been implementing Nymn’s first power colour – yellow. This particular colour gives Nymn the ability to glide over long distances to previously unreachable areas.

Here’s a clip:


Tanglewood: Introducing Fuzzls

Introducing Fuzzls

Tanglewood’s world is alive with the strangest of creatures, from little to large, good to evil. The Fuzzl is a neutral, furry, confused, and easily startled member of the club.

fuzzl_64_blueFuzzls began life in a tech demo for a physics game written back in my University days, and since then they’ve been crammed into almost every game design I’ve been a part of, but until now have never made it past the concept stage and to fruition. They’ve finally found their permanent home in Tanglewood, or not, seeing as they too are lost from home, and need Nymn’s help to get back to their nests.

Fuzzls sleep at night, come back during the day!

Fuzzls sleep at night, come back during the day!

Nymn can roll these little ones (if they’re awake…) back to their nests. The Fuzzls dish out handsome rewards for your efforts, but those details will come in a later post. They can also use Flues; if you drop a terrified and unsuspecting Fuzzl into one, they’ll fling sky high up into a tree branch!

Fuzzls aren’t the smartest of creatures, but they play a large role in Tanglewood, and have quite a history. They were once domestic pets of various races, including the Djun. Some of the more advanced – but now extinct – species used Fuzzls to power contraptions, as counterweights for lifts and hoists, and even to hug for stress relief, but now they’re left alone to live out their lives sleeping, or getting startled by their own shadows.

Nobody knows what they do, what they eat, how they mate, what goes on in their little minds, if they can communicate, or how they still exist as a species without being able to perform basic functions of their own. They just… are.

I’ve captured a short video showing a Fuzzl’s basic behaviour. It’s in its early prototype stages so there are a few quirks to sort out, but the basics are all working. Enjoy!


Tanglewood: Introducing Nymn

Introducing Nymn

Nymn is Tanglewood’s protagonist, a shy creature from a family-oriented species called the Djun race, who survive in packs, live underground, and only emerge during daylight. Night time is dangerous for Nymn and his fellow Djun, since many of Tanglewood’s less desirable characters emerge after dark to chase, intimidate, hunt and eat any strays who should have retreated underground.

Unfortunately, this is exactly the situation Nymn has found himself in. Lost, alone and missing his family, Nymn is desperate to find a way to get back to his underground pack before nightfall sets in and he becomes the victim of a sadistic hunting game, which will almost certainly end in his demise.

Controlling Nymn

NymnThe small teaser video from last week showed Nymn walking through the world for a small glimpse of the environment, but the gameplay itself will be faster paced; Nymn is a quick and nimble creature who can walk on two legs, and scurry along quickly on all four. The platforming experience of Tanglewood is one that I’ve spent a lot of time perfecting – it’s important to me that Nymn’s controls and physical behaviours are accessible and familiar to fans of both legacy Mega Drive titles and the modern platforming games by which Tanglewood was inspired. Since my initial platform code demos in January I’ve added a whole suite of movement features, and spent many hours tweaking and perfecting movement behaviour and response.

There are a lot of variables at play here – walk acceleration, run acceleration, max walk velocity, max run velocity, floor drag, in-air drag, gravity, critical mass, walk-to-run transition speed, forced deceleration, jump impulse, step heights, multiple jump ground heights… you get the idea. There’s a few bits left to do, too, such as a separate acceleration value for controlling Nymn’s left/right movement whilst in air; a practice that has dwindled in favour of physical realism, but was synonymous with platforming games at the time and would be sorely missed.


Nymn’s animations are something that we are very proud of. The character design has been through several iterations, and endured many tiny tweaks in order for it to appear as smooth as the hardware allows, and we hope it shows. There’s still a lot of work left to do to iron out some of the creases, but we’re getting there.

I’ll leave you with a small sample of Nymn’s basic movements:



Follow Tanglewood on Twitter: @tanglewoodgame