Here is the situation: You have created some sort of data model for representing objects in memory/on disk. Now you need the ability for objects to refer to other objects. I.e., an object needs to talk about another object. Some examples:

• A material object may point to a texture object and say “I want to use this as my diffuse map”.
• An animation object may point to a model object and say “I want to rotate this model around its z-axis”.

How can we accomplish this?

Here are two options:

• Names: Each object is referred to by its name. The name is a string assigned to the object by the user and the user can change this string at will (rename the object).

• GUIDs: Each object is referred to by a globally unique identifier (GUID). The GUID is assigned to the object on creation and never changes. It is guaranteed to only represent this particular object and no other.

Names are resolved in some kind of context (typically the children of the current object). Thus, to refer to an object that is “far away” from us we might have to use a sequence of names to navigate the object tree, e.g., ../../player/head/left_eye. Much like a path in a file system, this sequence of names provides a path from one object in our object tree to another. Note that in this post I will sometimes somewhat sloppily talk about the name of an object when I actually mean the full path to an object.

You might protest that there are other ways of representing references too. For example, an in-memory representation could just use a pointer. A disk representation could use a file offset. Combinations are possible too — for example (filename + offset) to represent an object inside a file. However, it is easy to become confused when considering the myriad of possibilities, so let’s put all of that aside for the moment. In this post, I’m going to focus on the difference between names and GUIDs and in the end we will see how the discussion applies to the other possibilities.

Side note: There is another interesting option apart from names and GUIDs and that is to refer to an object by the hash of its content. With this approach, the same content is always referred to by the same unique identifier (its hash) and if you change the content all the references have to be updated. If you start to think about it, most of git falls out as the result of this single design decision.

Names and GUIDs both have their pros and cons, making it hard to say that one is strictly better than the other:

Each of these points can be argued back-and-forth endlessly. Can’t we auto-assign names to make them easier to come up with? But how readable are names really if most of the things are just named box_723? Can’t we make a tool that looks up a readable name from a GUID? Can’t we also make a tool that automatically patches references when an object is renamed? Etc, etc, etc.

Again, it’s easy to get stuck in the nitty-gritty details of this and miss the bigger picture. To make things clearer, let’s take a step back and ask ourselves:

What is the fundamental difference between names and GUIDs?

Think about it for a bit. Here’s my answer:

A GUID specifies an object identity, but a name specifies an object’s role.

The GUID 90e2294e-9daf-45f0-b75b-01fb85bb6dc8 always refers to one specific object — the one single object in the universe with that GUID. The path head/left_eye refers to whatever object is currently acting as the character’s left eye. It does not always have to be the same object. Maybe the character loses her eye at some point and it gets replaced with a glass eye. Maybe we can spawn multiple instances of the character in different configurations with different kinds of eyes — flesh eyes, robot eyes, anime eyes, etc. Regardless of the setup, head/left_eye will refer to the character’s left eye.

In contrast, if we used a GUID to refer to the left eye and the eye got replaced, the GUID would still refer to the old eye we lost. And a single GUID couldn’t be used to refer to different eyes in different character setups.

The pointers and offsets that I talked about in the beginning of the post are similar to GUIDs, since they reference objects by identity. A pointer always points to the same object. In fact, you could see a pointer as a deserialized version of a GUID — a way of uniquely referencing an object in memory. Offsets too, uniquely identify objects. (But offsets are not permanent, so references must be updated each time a file is saved.)

A name allows for “late binding” of references.

To get from a name to an actual object, we need to resolve the name at some point. This involves matching the path against the object tree and finding the corresponding object. In contrast to a GUID, which always points to the same object, a name might resolve to different things at different points in time, or in different contexts. The reference isn’t bound to a particular target until the name is resolved.

When does this happen? You can decide that when you design a system based on your performance/flexibility requirements. For example, you can decide to resolve all references once and only once — when the object is spawned. This is faster, because you only need to look references up once, but it also means that in the case where the eye is removed and replaced, the reference won’t be updated to point to the new eye. So it’s less flexible.

The other option is to resolve the reference every single frame. This can handle objects being removed and/or replaced, but it also means having to pay the performance cost of resolving the reference every single frame.

With this new understanding of the fundamental difference between names and GUIDs we can take another look at the pros and cons we listed above and see if we can understand them better.

Names are fragile — they can break if objects are moved, renamed or deleted

Yes, this is the whole point!

The main reason for using names is to allow late binding. Late binding means we don’t know beforehand what the name will resolve to (or if it will resolve to anything at all). We can’t get the benefits of late binding without also getting the drawbacks.

For instance, in the example above, after the eye has been removed, but before it has been replaced with a glass eye, head/left_eye will not resolve to anything — because the character doesn’t have a left eye. Code that expects to find an object at head/left_eye might break.

A name might also resolve to something unexpected. For example, the eye might be removed and replaced by a little man. Code that was written to deal with an eye, or even with no eye, might break when it finds a little man in the eye socket.

In addition to breaking in this correct way — where a resolve rightly fails because the object doesn’t exist — references can also break in incorrect ways. The resolve might fail, not because there is no eye, but because the user made a mistake. For example, maybe the eye was named LeftEye instead of left_eye.

To an extent — problems like this can be mitigated by good tooling. For example, the tools might warn about unresolved references. The tools might also assist with renaming, so that if you rename left_eye → LeftEye all the references are updated to LeftEye too.

But note that there is an inherent conflict here. The whole point of using names is to allow the references to be more lax and flexible. If the tools are too anal with their warnings it kind of defeats that purpose. For example, it might be totally correct that head/halodoesn’t refer to anything, because the character starts out without a halo — she only gets that once she’s completed the Holy Mission. If a tool spews out false positive warnings about things like this, users will soon learn to ignore them and miss the actually valuable warnings about real typos.

Similarly, tools can’t be too aggressive about updating references when objects are renamed either. Suppose that you designed a really cool robotic left eye for the character. Then you decide that it would look better as the right eye, so you move it into the right eye socket and rename it from left_eye to right_eye. If the references are auto-patched, all references to the left eye will now be changed to the right eye, which probably isn’t correct. For example, if the left_eyebrow had a reference to its eye, and that reference was auto-patched, the left_eyebrow would now think it sits over the right_eye. On the other hand, some references could have meant “the robotic eye” rather than “the eye in the left socket” when they talked about left_eye and those references should get patched. Pretty messy and hard to make a nice UI for, although I’ve tried before.

Names are cumbersome — coming up with meaningful names for everything is a chore

As discussed above, a name isn’t just a string of characters, it is a description of a role, of a relationship. head/left_eye means the left eye object in the head of the character. If you gave it a nonsensical name like bob or an auto-generated name like Object_13 it wouldn’t say anything about the role.

To take advantage of the late binding feature of names you want to use meaningful names that match the concepts that you have in your game. I.e. if your characters can put on different helmets and backpacks you probably need helmet and backpacknames. If helmets and backpacks are just visual features of some character models, can’t be removed or swapped out and don’t have any gameplay purpose, they might not need their own names, they might just be part of the head and body.

You can think of this naming as sort of a “logical rigging” of the model.

So yes, if you want to take advantage of late binding, you do have to spend some time coming up with meaningful names and hierarchies. If all your objects are just named entity_2713 you are basically just using names as IDs. This has all the drawbacks of names (fragility, costly resolution) as well as all the drawbacks of IDs (unreadability). Don’t do that.

Names are expensive — they have to be resolved

Again, late resolve is the point of using names, and it will always have a cost. You can’t get the benefit of late resolve without paying the cost for it.

Of course, it can be more or less costly, depending on how you implement it. My most important performance tip is: be clear about the scope in which names are resolved.

I like to use fully qualified paths. I.e., referring to a character’s left eye would be head/left_eye. Referring to the left eye from the right eye would be ../left_eye. Here,.. goes up to the head and then left_eye descends to the right eye.

It can be tempting to fall into the trap of convenience and say that we should be able to just use the name left_eye to refer to the left eye instead of a full path, but it has scary performance implications. Instead of just searching our children for a name match, we now have to search all our descendants recursively. And if we want this to work from the right eye too, we not only have to search all our descendants, we have to search all our parent’s descendants too. Before you know it, you have to search the entire world for this left_eye. And even if we find it, how do we know it is the “right one” — the one the user meant? Maybe our helmet has a little statue on it, and maybe that statue has a left_eyetoo? How do we make sure we don’t find that one? Messy.

My preferred implementation for resolving paths is to first hash each part of the path (this can be done offline), and then at each step, we match the hash at that step against the hashed names of the current object’s children — either through a lookup table or directly. Maintaining a lookup table is probably only worth it once you start to have hundreds of children to match against.

Even though this avoids really expensive stuff like searching the entire object tree or doing string comparison, it is still a lot more expensive than just following a pointer (which an ID deserializes into).

Names vs GUIDs — The Smackdown

With this deepened understanding — who wins, names or GUIDs?

As discussed above, names have many disadvantages — they’re fragile, cumbersome and costly. But they have two main advantages:

• They express intent. When I refer to head/left_eye it is clear to the reader what I want to refer to. Thus names have a meaning that pointers/GUIDs don’t have. Recording this meaning can be helpful. When we complain that identifiers are unreadable, it is the lack of meaning we talk about — not just the fact that the identifier is a jumble of hex characters. But meaning requires explicit intent. If your object is named entity_23415 — there is no meaning in the name, it might just as well be called cc1b9a7b-a5bb-4355-8cf1-f78b74fe2774.

• They allow for “late binding” of the reference to an actual object. This allows new objects to “take the place”/”fill the role” of the originally referred object. Using this, we can “patch” objects in lots of interesting way. For example, we can take a character, replace its eye with something else and all references to the eye will still work. To do this with GUIDs we need to patch up all references too, so that they point to the “new eye”.

So which is best? It comes down to a judgment call.

My take is this — we’re trying to create a high-performance user-friendly game engine. Thus, we only want to pay the costs of using names (bad performance & fragility) in the cases where we really take advantage of their strengths (intent & late binding). In my experience — most of the times, we don’t need these features. For example, when you are placing a bunch of trees in a level you don’t really care about naming them and you don’t have any need for something else “assuming” the role of one of those trees.

For this reason, The Machinery uses GUIDs as the default way to represent references. When a model refers to a texture, it does so with a GUID. You can move or rename the texture and the model will still keep using the same texture until you explicitly point it to a different one.

But in addition to this, we also explicitly allow for name references in some systems — systems that we think benefit from the extra flexibility:

• Our visual scripting system has a “lookup entity by name” node, allowing entities to be referred to semantically (such as head/left_eye) from within the scripts.

• Our animation system is still under construction, but we plan to have a similar feature there, allowing animations to target loose and flexible things such as helmet/headlight/color.

Having two different “kinds” of references like this is in the engine by no means ideal. Whenever we are designing a system we have to ask ourselves: does this reference need the flexibility offered by names or is using a GUID OK? We are also possibly missing out on some flexibility — in the cases where we’ve decided to use a GUID, it is much more cumbersome for the user to achieve the kind of dynamic retargeting that names make easy.

Still, it seems like the best compromise to me — we get the performance and stability of GUIDs/pointers in the majority of the code, but can still use the flexibility of names in the situations where we think it’s needed.

See also

• Pixar’s USD format uses names for everything. From their viewpoint, having to occasionally fix broken references is worth the extra flexibility they get from using names everywhere. Of course, since they’re not primarily targeting real-time rendering, their performance requirements are different.

• I’ve written about this topic before, if you want to see how my viewpoint has shifted over the years. Note though that the focus of that article is a little bit different. In that article I’m talking about referencing assets/resources on disk, so when I mention a path in that article I mean a disk path. Whereas, in this post, I’m talking more about references in general and I’m not that concerned with exactly how things get serialized to disk.

There was a long journey from a tale about harrowing life of civilians in war – This War of Mine – to a game of society survival and city-builder in Frostpunk. Why am I mentioning the first game in a story about the latter? Because creating the first one was a great lesson for us, the team of designers, to learn how to build a heavy, emotional story filled with difficult decisions and ambiguous moral choices. This is what lies underneath in our strategic game that now is heading to Xbox One.

The Frostpunk: Console Edition story begins in late XIX century during the peak of the rapid industrial revolution of the times. For reasons not understood by scientists, Earth is getting colder and colder until governments have collapsed, organized communities are put to an end, and humankind faces the threat of extinction. You play as a leader of possibly the last society on the planet, trying to recreate a functioning civilization able to survive the unforgiving cold.

First thing you do is gather resources to start a heat generator (loads of coal are going to be needed!) and build a circular city around the huge heat-distributing machine. As people in Frostpunk often say, “Heat is life!” You’ll build streets, tents, houses, cooking houses, coal mines, steam-powered heaters, and lots of other facilities. You’re going to construct hunters’ huts and order workers to hunt down wild animals. The bigger your city grows, the more it will need to consume while sustaining the life of its inhabitants.

City-building is one of the first layers to discover and get you thrilled for the game. And then there’s me and the team of designers’ vision to be realized in Frostpunk – all that morally grey area when you make decisions unsure about consequences. The idea that you can actively rule the citizens by introducing laws and customs that would make them more efficient, better prepared or, ultimately, obedient to your orders. You shape the society accordingly to your will. You’ll learn the hard way if it’s right or wrong to force children to work. If you think that is wrong, what would be your decision when lacking hands to work while people are freezing to death and coal supply is insufficient? When Frostpunk’s story drags you in, you’ll be faced with such morally ambiguous choices.

We also knew that the game’s world had to be larger than the ice crater in which you build the city of New London, as we called it. We knew players would feel a need to seek for knowledge about what happened to the world. Large spaces of frostland have been designed, filled with places to explore and discover. And so, sooner or later, you’ll realize what you have in the city might not be enough to ensure survival. There will be a moment to leave the city and send scout teams to explore and investigate the frozen lands. There will be plenty of things to discover, perhaps other remnants of civilization, groups of survivors or deserted mines.

Now, creating a strategy game for consoles had us rethink how the game’s flow should work. Great efforts have been made to re-design interface and enhance gameplay flow to make all have natural and intuitive feel when played on a controller. We wanted to make sure that gamers not only received the same experience, but one adapted to consoles to make it work smoothly. I believe that had to be done (that’s why it took some time for our team) because the game has huge potential to keep you thrilled and immersed in its world. Follow the news here to learn more about Frostpunk: Console Edition!

At the beginning of 2019, the Humble Store started to offer digital codes for select Switch and 3DS titles. In March, it followed this up by adding a bunch of third-party Switch titles from publishers such as 2K and Curve Digital. The publishing side of Humble also said it would be adding more games soon from various other prominent companies.

The latest games now available on the store are from Sega, Capcom, Team17 and Headup Games. Unfortunately, this section of the website is still restricted to users within North America. As previously noted, the Humble Team is “looking into the future possibility of bringing in more countries”.

Here’s the full list of games now available on the Humble Store (thanks, Nintendo Everything):

SEGA

Puyo Puyo Tetris
SEGA Ages Alex Kidd in Miracle World
SEGA Ages Gain Ground
SEGA Ages Lightening Force: Quest for the Darkstar
SEGA Ages Phantasy Star
SEGA Ages Sonic the Hedgehog
SEGA Genesis Classics
Sonic Forces
Sonic Mania
Valkyria Chronicles
Valkyria Chronicles 4

Capcom

Capcom Beat ‘Em Up Bundle
Mega Man 11
Mega Man Legacy Collection
Mega Man Legacy Collection 2
Mega Man X Legacy Collection
Mega Man X Legacy Collection 2
Monster Hunter Generations Ultimate
Okami HD
Onimusha: Warlords
Street Fighter 30th Anniversary Collection
Ultra Street Fighter II: The Final Challengers

Team17

Mugsters
Overcooked 2
Overcooked Special Edition
Planet Alpha
Raging Justice
The Escapists 2
The Escapists: Complete Edition
The Room
Worms W.M.D
Yoku’s Island Express
Yooka-Laylee

Headup Games

Bridge Constructor Portal
Earth Atlantis
In Between
Runbow
Slime-san
Super Blackjack Battle 2 Turbo Edition
Super Treasure Arena
The Inner World: The Last Wind Monk
Tied Together
Toby: The Secret Mine

Do any of these games on the Humble Store interest you? Tell us down in the comments.

Today’s Deal: Save 67% on Crashlands in celebration of Levelhead release!*

Look for the deals each day on the front page of Steam. Or follow us on twitter or Facebook for instant notifications wherever you are!

*Offer ends Thursday 4/25 at 10AM Pacific Time

Click Here!

The Bing Maps Routing and Traffic Team is constantly working to make navigation and route planning easier! Hot on the heels of our previous announcement about traffic coloring, the Bing Maps team is proud to announce that we have made it possible for users to access traffic camera images along a planned driving route! You can now see traffic camera icons along a short to moderate-length route. By clicking on a traffic camera icon, you can view the latest image from the traffic camera at that location.

Confirming Traffic Conditions

In the example below, the orange colored segment of the route indicates that traffic on I-405 South is starting to get backed up. With traffic camera images now available, you can confirm local traffic conditions with just a click of the camera icon along the route.

Checking Extreme Weather Road Conditions

Gaining access to the traffic camera imagery not only helps with checking for traffic, accidents and general navigation, but can be invaluable to users when traversing areas impacted by extreme weather conditions, such as heavy snowfall, wind storms, flooding, etc.

Getting to and from the resort for your annual ski trip can become both challenging and dangerous when the roads are covered with snow and ice. This past February, Washington state was hit with unprecedented snowfall. Many sections of road near the Snoqualmie Pass were rendered impassible because of record amounts of snow, resulting in motorists getting stuck and stranded. With traffic camera images now accessible along the route, you can quickly check for dangerous road conditions before heading out.

In the example below, it snowed throughout the day at Alpental on April 13. The traffic camera image shows that the road was clear and safe for driving at 5:48 PM despite the snowfall.

Getting a look at the road ahead can help you avoid heavy traffic and tricky road conditions, so be sure to check out the “traffic” option with camera imagery on Bing Maps when you are routing your next trip at https://www.bing.com/maps/.

– Bing Maps Team

By Roger Fingas
Monday, April 22, 2019, 04:27 pm PT (07:27 pm ET)

A settlement has emerged in Sprint’s lawsuit against AT&T, which accused the rival carrier of “blatantly misleading consumers” with its use of the term “5G E” to market high-speed 4G connections.

“We have amicably settled this matter,” an AT&T spokesperson explained to the Dallas Business Journal. The exact terms of the agreement haven’t been made public.

AT&T will, however, get to keep using “5G E,” according to other Journal sources. If true, that would suggest Sprint was compensated or simply decided to drop legal action.

AT&T first began using “5G E” around early January, for instance showing the label on connected iPhones. That drew an outcry not just from Sprint but T-Mobile and Verizon, all of which have held off on the 5G label outside of authentic networks.

U.S. 5G is still in its earliest phases. Verizon has marginal coverage in Chicago and Minneapolis, and while AT&T did launch real 5G in December, that’s only in the form of a portable hotspot — phone support is still in progress.

iPhones aren’t expected to include 5G modems until 2020. That may be a result the now-ended Apple v. Qualcomm battle, as well as slow development by Intel. Indeed Intel dropped out of the 5G race shortly after the Qualcomm settlement.

The Nintendo Game Boy turns 30 this Sunday, and to celebrate this amazing occasion we’ll be running a series of related features this week, right up to the big day.

As the humble Game Boy’s 30th anniversary approaches, Nintendo’s classic handheld has never been cooler. If you want to make a statement about your love for all things Game Boy, then we have rounded up some of our favourite Game Boy related merchandise for your consideration.

Whether you are after a Game Boy themed t-shirt, keyring or alarm clock, fear not – we’ve got you covered.

Please note that some of the links on this page are affiliate links. If you click them and make a purchase we may receive a small percentage of the sale which helps support the site. Please read our FTC Disclosure for more information.

Used Game Boy Consoles

Of course, any self-respecting Game Boy fan needs an actual Game Boy console. Bonus points if you pick up an original DMG-01 model, but we won’t judge you too harshly if you opt for a Game Boy Pocket to cut down on the cost of AA batteries.

Game Boy Clothing

Once you have a Game Boy console in hand, you just need some related clothing to go with it. A t-shirt, a hoodie, a baby romper suit. Anything will do.

Lots More Game Boy ideas

If you want something more subtle to show off your Game Boy love, we’ve got lots more ideas for you here.

Which Game Boy themed item from our list took your fancy?

The Nintendo Game Boy turns 30 this Sunday, and to celebrate this amazing occasion we’ll be running a series of related features this week, right up to the big day.

As the 30th anniversary of the Game Boy’s Japanese debut approached, we here at Nintendo Life Towers were thinking a lot about the ol’ DMG-01. The appeal of that chunky lump of grey plastic endures to this day, despite multiple hardware revisions and being superseded by umpteen portables. Yes, it’s bulky by modern standards, and these days you’ll find a better screen on your average set of bathroom scales, but the OG Game Boy remains a reassuringly solid and comfortable bit of kit in your hands.

A quick survey around the office reveals that a few staff members are too young to have owned the original version of the console, but thanks to the backwards compatibility of the Game Boy line (right up to the Micro variant of the Game Boy Advance), there’s nobody that doesn’t get a dose of the warm fuzzies at the mention of the classic system and its huge library of games.

We’ve already heard what developers thought of the all-conquering handheld and now it’s time to listen to us blather on for a paragraph or two about what makes the Game Boy so special. So, grab a fistful of double-As and saddle up for a nostalgia trip…

Ryan Craddock, staff writer

Sadly, I’ve never owned an original Game Boy, but the Game Boy Color (close enough, right?) was my very first gaming console. I vividly remember being painfully jealous of my next door neighbour who had a Game Boy with a copy of Pokémon Blue, and my little, six-year-old self would go round every day, play on it for as long as I could (without saving over his progress) and then do it all over again the next day.

Eventually, my mum treated me to my very own Game Boy Color (which had only been out for a year or two) and a copy of both Pokémon Red and Blue. I’m not exaggerating when I say that Pokémon took over my entire life as a kid – it was everything – and that love for the series, and later Nintendo, has led me right to where I am today on this very site.

Being so young meant that I couldn’t collect the sheer number of games I do for consoles these days, so I can’t declare myself as a ‘super fan’ of the system as such, but the Game Boy family of consoles kickstarted my love for a hobby which has always stayed with me and I can’t give them any better praise than that.

Dom Reseigh-Lincoln, reviewer

The Game Boy wasn’t just a flashy toy to me. It was the start of a lifelong love of handheld gaming. And every game – even the bad ones – felt that bit more important because I could play them anywhere. It even got me into genres I might otherwise have never played. The cryptically named Soccer sent me football mad (including it’s amazing soundtrack). The Legend of Zelda: Link’s Awakening cemented the series into my being long before Ocarina of Time. And, of course, I spent endless hours playing WWF Superstars. My love of PSP, Vita and Switch all come back to that big yellow Game Boy that meant so much.

Gavin Lane, staff writer

It’s only very recently that I tracked down an original Game Boy of my own – back in the day I briefly played on a red Game Boy Pocket (which has since been lost to time or, possibly, distant relatives) before upgrading to a beautiful turquoise Game Boy Color at the same time I swapped Pokémon Blue for the enhanced Yellow version. It was on that which I played my select library of original Game Boy games. The one that really stands out in my memory (besides the brilliant Super Mario Land 2: 6 Golden Coins, of course) is the simply named Tennis.

No, this game didn’t have any ‘Super’ prefix or a new-fangled colon-subtitle to get you excited! Back in those days you could name your game after the sport it emulated and that was quite enough, thank-you-very-much; no bells, no whistles, just tennis. Even today I find the control you have over your shots impressive, and – blasphemous as it may be – it’s not Tetris I turn to for a bite of retro-relaxation, it’s Tennis.

Quiet, please.

Gonçalo Lopes, contributing writer

My experience with the original Game Boy is hard to compress in just a few short paragraphs but I am not one to shy away from the challenge. While I was a very happy Commodore Amiga owner at the time (1991), it was not the ideal digital entertainment platform in a world where my parents ruled the TV screen (never got a monitor for it, they were expensive).

I stumbled upon the first news of the Game Boy like pretty much everything else in a pre-internet connected world: through the magic of foreign press. A Game & Watch with interchangeable games and the innards of a souped-up ZX Spectrum with a 20+ hour battery life? You can keep your colour games, Game Gear and Lynx, I need something that could last me 300-kilometre bus trips and doctor appointment waiting rooms while still fitting in my pockets. Portugal was going into the transitional period of enforcing EU copyright laws (i.e. the end of over-the-counter piracy) and video game consoles were starting to at last show up in local toy stores. Sega nearly immediately took over the country with its usual flare and aggressive marketing, but Nintendo eventually began sneaking into toy stores and the Game Boy arrived fashionably late along with the outdated 8-bit NES.

As you might imagine, things on the playground weren’t easy for Nintendo fans; games became extremely expensive overnight and none of us could afford more than one system and maybe a game every couple of months. Most of my friends turned to SEGA and they simply could not comprehend why I was so happy to return to 8-bit and a system with only 4 colours and no backlit screen. However, thanks to my monthly investment in foreign press I knew exactly what was happening in the US and Japan, with companies like Capcom and Konami releasing portable miracles every other month. Even better, local toy shops began sneaking in (thankfully region-free) Game Boy imports onto their inventory so it wasn’t long before my humble collection grew outside of official European offerings.

I am still discovering nowadays new Game Boy games by exploring the Japan-only catalogue and I have played so many brilliant titles it is truly impossible for me to pick a single game as “the one”. But like most wonderful journeys it all began with my first game and to most people’s surprise it was neither Super Mario Land nor the packed-in Tetris (which I still replay often). It was a very humble first-party developed shmup called Solar Striker. I played it so much I reckon I still know every pattern and safe spot needed to defeat all end-of-level bosses. Further proof of my eccentricity, I never played or owned any Pokémon games; when those came out I was already knee-deep into Japanese Super Famicom imports.

Besides the undeniable staying power of the system, the beauty of the Game Boy remains that there is no ‘right way’ to enjoy its fantastic game library. There is something for everyone if you look beyond the obvious choices. Who knew that 30 years later it would find a whole new life as the weapon of choice among chiptune music artists? It was a luxury back then and obsolete or not, a luxury today and tomorrow; you simply can’t put down this brick.

Alex Olney, video producer

My brother and I both got a Game Boy Pocket each one Christmas back in what must have been the mid-nineties, which considering our age was unthinkable, as we usually had to share everything. Both of them are still both going strong today, but mine was certainly put through its paces in its heyday.

One fine-ish day, I was feeling rather unwell and so stayed home from school so as not to infect all the other small humans. Naturally the shiny electronic brick was used whenever this happened, but this was before I properly understood how to take care of the things that I owned and didn’t want to be damaged. As I was given some cold medicine from my mum, I didn’t really want to pause the game, so I dried drinking it from the tiny plastic cup hands-free. What resulted was the sticky syrup slipping southwards and landing on my console’s D-pad. It soaked in beautifully, and not wanting to let my family know what a complete boob I’d been, I tried to hide it and clean it up as well as I could. Over the coming weeks the D-pad was getting stickier and stiffer all the time, making Alleyway even more unplayable than it was before.

I’d resigned myself to the fact that it was broken, and nothing was going to fix it short of some miracle my dad could perform with some power tools behind closed doors. After a few weeks in a drawer however, the sugary glue had completely hardened, and although it could still be seen through the clear body of the device, one quick press snapped its bonds in twain, and although slightly gritty, the system was working perfectly again. These little buggers are borderline invincible.

Liam Doolan, news writer

I played a wide variety of releases during the original Game Boy generation, but one game I’ll always cherish is the 1998 action-adventure title James Bond 007, created by the now-defunct developer, Saffire Entertainment.

While the Pokémon craze was growing in popularity here in the west, somehow I found myself playing this on the side, on a regular basis. Compared to various other Game Boy games at the time – such as Pokémon Red and Blue – the design of James Bond was a little rough around the edges. Long story short, I ended up getting stuck in a number of difficult segments throughout the game due to its design but managed to persevere.

I eventually saw the credits roll and to this day, it’s still one of my favourite Game Boy games – and memories – of all-time.

Austin Voigt, contributing writer

My first experience with the Game Boy was in my next-door neighbor’s kitchen, and I remember it like it was yesterday. While my friend was my age, their parents allowed them to have a Game Boy, and mine did not (because they thought videogames were the devil’s work, apparently). I’d played the SNES copiously in my youth on my uncle’s system, but this was the first time I’d experienced handheld gaming that could just move anywhere with you – mind-boggling! We played Super Mario Land while listening to the Lion King soundtrack (yeah, it was quite a few years after the initial release – I’m a youngster), and I remembered thinking: “This is the future, people. Handheld gaming, music on CDs… what next?!” Ah, if only Little Austin could see what Nintendo’s doing now…

Darren Calvert, operations director

As I started my gaming life as something of a Sega kid with the Master System, like so many others my age in the UK, I have fond memories of the Game Boy as it introduced me to all the great Nintendo franchises long before I would go on to pick up a battered old Mattel NES for myself. While many of my cherished Game Boy memories were playing Vs Tetris against my best friend outdoors via the game link cable, I also remember being completely addicted to Super Mario Land at that time too.

A local video game store which we frequented used to have the latest issue of Famitsu on the counter for customers to browse and I remember how excited we were to see the first screenshots for Teenage Mutant Ninja Turtles: Fall of the Foot Clan which we promptly imported a whole year before it arrived officially in the UK. Gargoyle’s Quest was another fond import in 1990; we had no idea what was going on in the RPG section of the game, but it didn’t matter. We muddled through until we could get to the next slice of Firebrand platforming action.

The Game Boy was always with us wherever we went for many years, along with a stash of AA batteries of course. While the Sega Game Gear and the Atari Lynx did their best to challenge the humble Game Boy, nothing could beat its vast selection of games which were ideally suited to its small monochrome screen. 30 years later, many of these classic games are still great fun to dip into.

Those are just some of our memories, but that unassuming lump of grey plastic stokes the old nostalgia fires like Doc Brown’s Presto logs – share your own memories in the comments below and let’s all bask in the warm green glow of the (backlight-modded) DMG-01…