Now for something a little bit different.
In our last update, we unveiled a new $50 reward and talked about the role of UFC champion Ronda Rousey in our game’s development. However, we get a lot of questions about the tech, development and design side of our game as well.
Today we unveil Part I of our Developer Diary as we get an update from our lead developer/resident genius, Dennis De Mars.
Dennis is actually a former rocket scientist. So, like, when people sarcastically say, “Boy, you’re a real rocket scientist…” Dennis will say, “Well, retired actually,” and it kind of ruins the joke.
In the first of these posts, Dennis will get into some of the more technical aspects of our game. Below is a summary of our detailed criteria.
The first section is a verbatim transcription of our original white paper stating the criteria. In our next installment, Dennis will look at the results of our study and provide a (relatively) brief summary of our findings.
Also, if you have any questions about the technology/development side of our game (or anything else pertaining to our game or our company), please let us know. We’re happy to answer any questions that would give you a better understanding of our game, our company and ourselves.
So without further delay, we virtually turn it over to Dennis.
DEVELOPER DIARY – PART I
Introduction
7 Generation Games has already been in development for about a year. It began with a high level idea of how the game would appear to the students and what kinds of gameplay would be involved, and requirements for supported platforms based on the likely platforms that would be available for the initial testing and the platforms that would likely be available to students in the future.
Starting with this, we conducted a study of the technologies that were available to support these goals. We needed to determine which combination of these technologies would be most likely to help us achieve our goals in the shortest period of time.
CriteriaÂ
The game to be supported is, in general terms, a game which will contain an exploration component and a narrative (i.e. the student/player is on an adventure and can move around in and explore a world. The student will periodically be presented with questions or puzzles, often presented as separate mini-games in themselves, in which the student will have to apply facts or skills that they have learned (in math, cultural history, etc.) in order to win or solve. The game should be sufficiently entertaining in itself that the student will be motivated to continue playing.
The guiding criteria for this investigation have been:
1. The tools must support the creation of interactive games that include both mini-games, puzzles and a connective narrative, all involving movement within a physical environment and interaction with a character who will act as a guide. A major distinction that is made among game creation tools is between 2D and 3D games.
3D games can be much more engaging than 2D games and allow more scope for impressive effects, but the development effort can be an order of magnitude greater for a 3D game than a 2D game, and the degree of hardware support required is also greater (this is currently a problem mainly for mobile platforms such as iOS/Android). We also consider a variation of 2D graphics sometimes referred to as 2.5D or isometric. This is a variation of 2D that positions the viewer at a fixed angle above a scene and therefore allows all three dimensions to be seen. The position of the observer is fixed and the projection is orthogonal (not perspective).
Also, lighting is usually not simulated realistically. Isometric games don’t provide the same degree of realism as a full-blown 3D game but the processing requirements are much more modest, along the lines of a 2D game. Games based on isometric graphics were popular in the late ’80’s and early ’90’s, when personal computer use was becoming widespread, but graphics technology had not progressed to a point where full-blown 3D graphics processing was practical on a personal computer.
Isometric games are currently enjoying a resurgence due to the popularity of mobile (smartphone) games and web-based games (e.g. the popular Facebook-based game Farmville is an isometric game); on these platforms, as was mentioned above, the available graphics processing resources are limited. In this investigation we consider both 2D and 3D game development, with the idea that 3D will be preferable if it can be accommodated within our budget and schedule restraints, but otherwise a well-done 2D or 2.5D game will be acceptable.
2. The following platforms need to be supported (in approximate order of importance).
- 1. Web browser supporting HTML5. (More to follow).
- 2. Windows (required OS version TBD, likely Vista or 7 as minimum.)
- 3. iOS (iPad/iPhone – primarily iPad, game need not be constrained to be playable on iPhone size screen)
- 4. Android
- 5. Mac OS X
- 6. Linux
3. Regarding tools licensing: if open source tools are chosen, the license restriction on the resulting game should not be too onerous. For example, tools that would require that the resulting product be distributed under a GPL (Gnu Public License) would be eschewed. Tools and libraries that carry an MIT-style license would be OK.4. If the tools are commercial, they should either be free or carry a reasonable cost. For instance, tools that require a royalty per distributed copy would be ruled out. Tools that carry a cost per seat could be acceptable if the cost is within budget; recurring licenses (requiring periodic payments) would almost certainly be ruled out.
5. It is an absolute requirement that game results and details of gameplay TBD should be automatically collected and stored for analysis. It will be important to assure that the data can be collected and retrieved easily, so the most likely scenario is for the game to transmit the data to a remote server (probably over the Internet) where it can be added to a database. In the case of a web browser-based game, the same server that hosts the game would probably store the data; in the case of a stand-alone game application, the game would have to connect to the remote server on startup.
A further word on platforms: the goal is to support platforms that will be commonly available in classrooms. Currently this means Windows primarily. Looking to the near future, it is possible that the iPad will achieve significant penetration in the educational marketplace, so it is desirable to support the iPad if possible.
The other platforms (Mac OS X, Linux, Android) are not as important. However, Windows and iOS are on the opposite ends of the spectrum with regard to commonality; any tool or library that can support those two platforms often will also support some or all of the other platforms listed.
One approach in particular that tends to assure a broad degree of platform compatibility is to implement the game to run in a web browser using a combination of HTML5 and Javascript. This requires that the platform support a web browser that complies with HTML5. This includes Internet Explorer 9 (which runs on Windows Vista and up) and the most current version of the other major browsers (Firefox, Safari, Chrome and Opera). An HTML5 web application can also be packaged to run as a normal “app” on iOS devices (iPad/iPhone/iPod Touch).