China’s game approval process has undergone a lot of change in the past year or so, including a full-on freeze for most of last year, but more changes are set to hit the program this month including some that expand its reach to cover HTML5 and instant games.

Releasing a game in China requires it to be submitted to regulators and deemed to meet certain content and quality standards before being greenlit to go up for sale, meaning that these regulations are important to know for devs interested in launching a game in China’s sizable market.

Niko Partners has summarized the new and existing regulations China’s State Administration of Press and Publication plans to have fully implemented this month to oversee that process. Each, according to Niko Partners, aims to address issues related to game quality and content, risks of game addiction (especially in minors), and self-regulation for publishers.

Those include some plans that already were put into motion in December 2018 like establishing an ethics committee to evaluate the social values of online games and to restart the previously-frozen approval process that issues licenses for new titles.

Newer policies include an undisclosed limit on the number of games approved per calendar year (less than 5,000 for 2019, by Niko Partners’ estimate), increased research and implementation of anti-addiction systems, especially for mobile games, and rules that require HTML5 games and mini-games like WeChat titles to seek approval before releasing.

Other new goals of the approval process seek to introduce and encourage self-regulation within China-based game publishers to check content ahead of approval, something that would come from more transparent information on the approval process itself, and goals that aim to promote games that “promote traditional culture” and feature “correct information regarding history, politics, and law.”

The full Niko Partners writeup offers more context for each of these, as well as a list of more specific content guidelines (“there shall be no images of dead bodies or pools of blood in any games,” clearly note if a game is part of a series or risk it being denied due to title overlap) that developers might want to check out as well.

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?