Pictures using Quorum

Want you or your school to be highlighted by the Quorum team in the next refresh of the website? If you’ve taken some photographs of yourself, or your students using Quorum or doing programming, and have permission to post the photos, we would love to hear about it. We are in the middle of a refresh of the website and would love to highlight the great work being done by our partners. If that’s you, let us know!

Breaking Stuff with the Keyboard

We are now neck deep in implementing changes for the Quorum 5.0 release. Most of the time when we make changes, we go out of our way to not break backward compatibility. When we do, depending on what kind of system it is we are adjusting, our team internally requires evidence. For example, changes to core syntax or semantics require a randomized controlled trial or other rigorous techniques. If the changes are to something less important, our standards change accordingly. Further, if we identify technical problems, sometimes just make the changes. In other words, if we find a bug, we aren’t going to run an experiment. We’re just going to fix the bug.

For Quorum 5, one change we are making that will break backward compatibility with Quorum 4 is in keyboard constants. Basically, we did a review pass of using keyboard events in the game engine. As we are porting the engine to the web, we noticed every browser and platform was even more varied than we realized (e.g., Safari is very different than Chrome). Further, our keyboard constants were pretty messy and, so far as we could tell, had problems that fell in the technical issue camp. As such, here’s a list of all of the changes to the constants in KeyboardEvent and related keyboard input classes:


The following constants were removed because they could not be detected by our backend anyway. They represented extra hooks we thought we had, but really didn’t, from way back in the Quorum 3 release.



The following constants were renamed to make them more consistent with other, similar keys, or just to more closely follow standard Quorum naming conventions:

NUM changed to NUM_LOCK


These constants were added to allow for control over a wider number of standard keys on a keyboard.


Web Compatibility

All key constants in the new version are usable on the web, with the exception of these constants:

As always with changes that can potentially break an app, if anyone has concerns or comments, they are welcome to email the mailing list. In this case, we imagine this particular change won’t impact many people, but we want to put the information out there anyway.

Quorum Web Update

We have now made significant progress in the lab on the Quorum 5.0 web updates. The following is now working internally for the web version of Quorum:

  1. 2D Graphics: We have all the normal pieces functioning now, except for image sheets
  2. 3D Graphics: Pretty much everything is finished here as well, except for loading custom 3D models.
  3. Sound: Sound works similarly to Quorum in offline mode, except that in-browser sound systems do have some limitations (e.g., HRTF support only instead of 5.1, no doppler). There are also some limitations to specific browsers.
  4. Embedding: On the Quorum site, it will not be long until these little development environments start popping up all over the site. They can now be embedded in our lessons.

We still have a few things left to do. Notably, our testing has been pretty limited so far, we have only embedded into one lesson, and we have not finished our accessibility and user input designs. We are close though and this thing is pretty fun to play with.

This image shows three components. First, there is a normal Quorum development environment, coupled with its error or console window. Finally, there is a canvas window shown, which executes any audio or visual content.

There is one last thing that is worth noting. Right now, if we want to run our games on the web, there is some extra code we have to tell Quorum about, which looks like this:

WebConfiguration config = GetWebConfiguration()
//which HTML canvas do we want to draw on?
//We need to know because there can be multiple games
//on a page
config:canvasID = "instantiateObjectIdeGameOutput"

The reason is because Quorum needs to know which part of a web page to alter for games. It is possible there is a way around this with some sensible defaults, but right now it is the one difference between online and offline modes. Either way, considering there is zero JavaScript required, a pure Quorum solution, it is a small sacrifice.

Screen Resolution Adjustment

One new feature in Quorum 4.0.6, which was requested recently on the mailing list, is an easier way to adjust screen resolutions in games. We have now finished this feature and added a tutorial online:

This should make it easier to adjust the screen in a variety of ways. With it, one can query the system for what screen sizes are available, set it to an allowable value, or make adjustments on the fly. Because screen sizes could potentially impact in-game cameras in several ways, several versions of the actions are available depending on the desired effect.

Quorum 5.0 Alpha

There are obviously more important things going on in the world today, but we have now posted for the first time the alpha version of Quorum 5.0 online. While alpha implies that not all of the features are in, the team is internally moving toward testing some of the new physics and online features. When this happens, which is about on schedule for the year, we toss up a beta server and give everyone access.

Technically, anyone can access the beta with a special access key that we’ll put below, but most of the time these betas are mostly used by the UNLV team internally. The reason is because none of the documentation is publicly available yet, as we are still inventing everything. Normally, we do not finalize the documentation until after the design is set in stone.

New features in the alpha, besides many of the steps included in the Quorum 4.0.6 release include:

  • Physics Support in 2D Games. Not all features are complete, but many are. Support for 3D is not included.
  • NetBeans 8.2 support. Last year, we kept with the NetBeans 8.0.2 release, but will be moving to 8.2 for the Sodbeans 7 release.

    To access it, we can go to plugins -> Settings and put in the following key: From there we can install the Quorum 5.0 plugin. Note that because of changes Oracle made to NetBeans, this version is not compatible with NetBeans 8.0.2. This means that, since Quorum 4 is built on NetBeans 8.0.2, you can have both Quorum 4 and Quorum 5 beta installed if you wish.

Quorum 4.0.6 Released

Version 4.0.6 has been released for Quorum. This version fixes a number of minor bugs on the system and rolls in some alpha versions of new features planned for Quorum 5.0 (e.g., compile to JavaScript). Some of those features are not fully complete yet, so buyer beware, but we are using them internally and they seem stable enough to make available for testing. Further, this version rolls in a new way of handling various screen and camera resolutions. We have built a tutorial on how to use that, which will be posted live probably next week. Finally, the command line version of the compiler has not been posted live yet, but will be in the relatively near future.

As always, the full release notes are available and the notes for 4.0.6 are posted below:

Quorum 4.0.6 January 21st, 2017

This patch includes a variety of small changes as we continue with Quorum 4. Besides the fixes below, this version includes a new version of the website, which should bring us one step closer to web support for many of Quorum’s features.

  • Fixed an but pointed out by Amanda Rodda+Tyler with the JavaScript converter causing it to not properly popup input dialogs.
  • Fixed a minor issue with the compiler causing generics to be slightly less strict than intended.
  • Added SetInput and Empty actions to the textbox class.
  • Fixed an issue with the textbox causing it to sometimes delete two keys instead of one.
  • Fixed a spelling mistake in one of the package names.
  • Continued working on the documentation for the various new systems.
  • Rewrote the the web library generator for the standard library.
  • Fixed a variety of bugs in the JavaScript converter.
  • Fixed a grammatical issue in one of the compiler errors.
  • Fixed another issue with rotation in the game engine.
  • Fixed a minor compiler bug causing an exception to be thrown on invalid input.
  • Fixed a bug pointed out by Pete Lamonica where carriage return and line feed were flipped in the JavaScript converter.
  • Made some additions to the game engine that will help toward running it on the web.
  • The website has now been rewritten from scratch. A vast majority of it is now written in Quorum.
  • Many of the web tutorials have been rewritten from scratch and are now runnable on the web. Some lessons are now runnable online as well.
  • Made a significant number of accessibility improvements on the website, including with the development environment and in general.
  • Added an option to compile Quorum to JavaScript from the options window. The feature should be considered Beta until Quorum 5.0
  • Added several options for changing the screen resolution both in windowed and full screen mode.
  • While not yet complete, finished a great deal of the new work on running games on the web.

Smart Girls

Smart Girls put up a nice little video for the outgoing administration:

Looks like I had a cameo. I’m proud to be making my small little contribution to try to make life better for those in our society. This isn’t just for the blind community, even though I care deeply about that, but for everyone!

EPIQ Applications

It’s that time of year again to apply for EPIQ. To remind the reader, here is a direct link to the application:

EPIQ 2017 Application

This year, we are making a small change to the registration process. In previous years, EPIQ has always filled up with more applications then we can accept. So the question the steering committee has struggled with is, how do we fairly filter?

The reality is, we have never had a good answer to this question. Each year until now, the committee has discussed and ultimately voted on applications and scholarships. However, it seems like there often a handful of people leftover where we want to accept and give space to all of them, but where we just do not have the space. In these cases, we feel like all of the candidates are qualified, which makes the decisions rather gut wrenching for all of us on the committee.

Because of this, the committee voted to make one small change to the registration process into account this year. The committee will still vote on applications and accept as many as we can, but once we start running out of room, we have agreed to take application date into account during the process. In other words, if we are forced to say no due to space or funding limitations, we will go with the individual that applied earlier.

Point being: Get your EPIQ applications in earlier for priority consideration!