The Challenge
This post comes very late, as we start week 5. I have thought long and hard about this challenge and I still do not know what I can do for the challenge. The challenge, as stated on the course website 1, is:
One of the best ways to hone your prototyping skills is to reverse engineer the finished work of other practitioners you admire. This allows you to practise with the various tools and unpack the design theory behind the work in question.
To complete this activity, identify an artefact you feel is particularly interesting. This could be anything from an inventory system UI for a game to a museum website that utilises AR or VR. The more experimental and interactive the artefact you choose, the more challenging this prototyping activity will be.
Select one or two of the prototyping methods outlined this week and build quick prototypal representations of your chosen artefact. Note down any interesting characteristics of the artefact. Perhaps, you notice the colour palette is used in a certain way or the layout follows a standard grid system. Depending on your chosen artefact, you might want to annotate the dimensions and analyse the padding and spacing used. If you are creating a storyboard for a cutscene in a game, you could identify key components of the narrative arc or highlight various camera shots and how they are used to create drama.
This is an extremely open brief designed to allow you the freedom to choose an artefact you will find enjoyable to reverse engineer. We want you to dive in and have some fun. Don’t take the task too seriously – instead enjoy trying to get inside the minds of other creative practitioners.
For me, I have a very specific view on what backward/reverse engineering is, based on experience as a game developer, and quite often it involves figuring out how some effect or code works in order to use that knowledge in your own software.
The key word for me is “reverse”. Starting with an artefact and working back through it to understand it
So at the outset there is an unknown element which during the course of reverse engineering becomes a known element.
This known element can then be used for your own purposes which in effect is remediation.
What really threw me (and we’ll get back to this) is that all the examples I saw were really just examples of remediation. They took an aspect of a game, or level, or whatever the artefact was and simply walked through from “start” to “finish” either explaining what it was and/or how it worked or re-imagining it in a slightly different format. For me, as I have stated, this is just pure remediation. There is no unknown to be explored. The artefact was there in front of them to be explained.
So why did this throw me? It is because it distracted me. I thought I was missing some obvious point that everyone understood but me, and to be honest I still do, but I stand by my understanding of reverse engineering.
An Example
The best way I guess to explain what I understand by reverse engineering is take an example from my early career in the games industry.
There was a game on the Commodore Amiga called Zool, which had a super-fast scroll-routine, allowing the player to move at speeds more akin to games lie Sonic on the Sega Megadrive. Because of hardware limitations scrolling at this speed wasn’t deemed possible, and yet it was being done.
How this scroll routine worked was our “unknown”.
Myself and a colleague decided to find out exactly how this worked though, and with the help of an Action Replay cartridge and the hardware reference manuals we worked backwards through what we knew, and what we could see until after 2 or 3 days we managed to work out exactly how the scrolling routine worked.
Once we knew how it worked we remediated it into our own games, and the basics of that scroll routine I used in everything I wrote on the Amiga after that.
One Reply to “M1W3 – Challenge Activity (Pt. 1)”