The goal of the Games Community Group is to improve the quality of open web standards that games developers rely on to create games. To achieve its goal, the Games community group will:
Track specifications and vendor implementations related to open web games.
Recommend new specifications to be produced and find group homes for them.
Refine use cases to communicate specific needs of games.
Suggest refinements or fixes to existing specifications to better meet the needs of the game development community.
Explore capabilities —APIs, semantics, techniques for rendering, processing, personalization, customization, interoperability, etc.— that developers can leverage to localize games and guarantee that they are accessible.
Evangelize specifications to browser vendors.
Document how to best use open web standards for games.
Evangelize open web standards to game developers and game development best practices to web developers.
Group's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Chairs, when logged in, may publish draft and final reports. Please see report requirements.
Exactly one week ago, on Tuesday April 30th we had a meetup where we discussed web presence at the Game Developers Conference that happened in March in San Francisco.
Official guests included Erik Dubbelboer from Poki and our very own Noël Meudec from Meta, but more folks were sharing their experiences from attending the event as well.
Check out the video or the transcript above as we talked for almost a full hour, and there are multiple interesting stories shared by participants.
Next meetup idea: OMG
At the end of the call we’ve mentioned the Open Mini Games project that originally was aiming to fix discoverability, but it’s more than that: we’d like to welcome game developers, engine creators, and publishers to actively work on refining the idea of seamless export from game engines into publisher platforms – a unified way of storing game metadata that would make life of game developers so much easier.
With platforms like Itch already full of web games, and companies like Discord investing their resources into this topic, we can and should collaborate for the benefit of everyone. If you’re interested in joining, please reach out!
Our recent bi-monthly meetup happened January 16th when we talked about the use of generative AI to create games, with Georg Zoeller being the invited expert and leading the discussion.
You should check out the recording or read the transcript as Georg’s thoughts on the topic sound very interesting.
We do hope to meet two months from now, around the middle of March, but we don’t have the topic nor the speaker confirmed yet – we’ll let you know through our mailing list when that happens.
Our recent meetup happened on November 28th and we had Fabio Alessandrelli (along with Adam Scott) talking about Godot – particularly their web port challenges in version 4 that has been released a few months ago.
The video along with the transcript are already available, so feel free to check it out if you missed the meetup, but still want to catch up.
We’re already planning the next meetup for Tuesday, January 16th 2024 – exact topic(s) will be confirmed soon, but we do plan to have Web Install API and/or AI in games talks.
We’re happy to report that after a short break the group is back and active again! After appointing Andrzej Mazur as co-chair in March, we had two meetups this year already:
During June’s meetup we also reviewed the goals of the group, and discussed the plans for the future. We aim to continue with the online meetups happening every two months, so expect another one around the end of August!
The Games Community Group was created end of 2011, following a W3C workshop on Web games organized in Warsaw, Poland. The group investigating game needs for a few years, the Web platform evolved to address most of these needs, and the group progressively became dormant, patiently waiting for a wake up signal…
A second W3C Workshop on Web Games, organized in 2019 in Seattle, USA, provided the wake up signal and the group is now back to life, exploring new (and remaining!) pain points for Web game developers, and reviewing Web technology proposals that could impact games.
The Games Community Group met (online) in October 2020 during W3C TPAC event (see Summary of TPAC Web Games CG email in the archives of the group’s mailing-list).
Are you willing to improve the quality of open Web standards that developers rely on to create games? Please come and join!
This is a proposal for addition of a zoom-independent version of window.devicePixelRatio to HTML5.
The issue
Before Firefox 18 and Chrome 25, to make a 3D (WebGL) game drawn in HD, we could set the scale in <meta name="viewport"> to 1 and multiply the size of 2D things (HUD elements, menus) by window.devicePixelRatio.
However, since these versions of the browsers, devicePixelRatio started to take browser zoom level into account.
While the change works perfectly for loading of high-resolution versions of <img> images and background-images, it has been impossible to draw HUD elements in HD 3D games with correct sizes since that.
Glossary of this proposal
DPR – zoom-dependent window.devicePixelRatio.
Old DPR – devicePixelRatio behavior before Firefox 18 and Chrome 25.
New DPR – devicePixelRatio behavior since Firefox 18 and Chrome 25.
Issue details
With the old DPR, when <meta name="viewport"> scale is 1, we could simply multiply the size of HUD elements by DPR to get resolution-independent size of the element (so that it doesn’t look too small too dense displays):
On screen, the cross would have the following size with the old behavior:
Display DPI
Zoom level
devicePixelRatio
Output size on screen
96 (1x)
100%
1
48×48
96 (1x)
200%
1
96×96
96 (1x)
400%
1
192×192
192 (2x)
100%
2
96×96
192 (2x)
200%
2
192×192
192 (2x)
400%
2
384×384
This is fine, on high-DPI displays 384×384 looks like 192×192 on low-DPI displays, so it’s correctly zoomed by 400% (48 * 4 = 192).
However, with the new DPI, DPR is multiplied by the zoom level too, so if we multiply the size by DPR, we get the element scaled twice (in the script by DPR and in the browser by zoom):
Display DPI
Zoom level
devicePixelRatio
Output size on screen
96 (1x)
100%
1
48×48
96 (1x)
200%
2
192×192
96 (1x)
400%
4
768×768
192 (2x)
100%
2
96×96
192 (2x)
200%
4
384×384
192 (2x)
400%
8
1536×1536
On high-DPI displays, 1536×1536 looks like 768×768 on low-DPI displays. 768×768 is 1600% larger than 48×48, while we only wanted to zoom by 400%.
So, as I said before, we get the element zoomed by zoomLevel^2 instead of zoomLevel.et the element zoomed by zoomLevel^2 instead of zoomLevel.
Use case example
If you open WebQuake on a high-DPI display, you can see that the game is rendered in HD, but the HUD and the menus appear too small.
This is because I set <meta viewport> scale to 1. If I didn’t do this, the HUD size would be correct, but the game would be blurry.
What exactly I want is to render the game in HD while having the HUD drawn at correct size.
The solution
The solution is very simple.
A constant value which behaves the same way as the old DPR – doesn’t take zoom level into account.
Let it be named window.deviceNormalPixelRatio or navigator.deviceNormalPixelRatio.
Another important thing is to make it viewport scale-independent. It would have no point then, since it is to be used when viewport scale is forced to 1 (for manual scaling of selected elements).
It must be accessible from CSS queries too so we won’t have to use JavaScript to resize every element.
For HD image loading, the old devicePixelRatio would be used, and for manual <meta name="viewport"> correction, deviceNormalPixelRatio would be.
Another possible use
Along with DPI scaling, deviceNormalPixelRatio can be used to retrieve zoom level in a cross-browser way (there’s no way to retrieve zoom level yet!):
var zoom = devicePixelRatio / deviceNormalPixelRatio;
The first Games Community Group event of 2012 will be held right before GDC (http://gdconf.com) on March 4th at the Mascone Center in San Francisco.
Like our last summit, the goal of this town hall is to track the implementation of specifications this group has already recommended and extract and document new recommendations.
If you are planning to come to the Town Hall, please take the next month to continue to review the missing features/APIs we documented at our last meeting, file bugs with the browser vendors against them, and collect new features to propose to the group.
If you cannot make it on March 4th, feel free to discuss issues you care about on the mailing list, and send your proposals to me to be presented to the group. Take a look at our last report for examples of how to propose a new feature.
This report focuses on practical notes for the operation of the group, as well as our position on the following 17 open web standards that the games group cares about:
Review the status and viability of recommendations collected at the last W3C Games Summit, collect new recommendations, and discuss strategies for communicating Open Web Game development tools to the general public.