Where to next?

So, we've got a game up and running. It's very basic (currently versioned, "alpha") and does not have any of the more advanced features that we're looking to add - it still is surprisingly fun though. We may want to tweak the speeds a little bit to make it even faster. That would be intense.

In moving forward, we've started establishing some requirements and some options. Figuring out what to work on next starts with nailing down some options.

Following are requirements and options for actual gameplay as well as the game engine.

[V] - view-related
[C] - controller-related
[M] - model-related

Requirements for the gameplay technology (the more dynamic/interactive parts):

• dynamic display of changing objects for the player (i.e. browser window). [P]
• display of basic objects (i.e. blue square) within complex presentation modes (i.e. one-up, two-up horizontal, two-up vertical, four-up square, nine-up square, etc.). [P]
• accurate timing of the display (i.e. a new object every 0.5 seconds for 30 seconds). [P]
• ability to count the number of token object occurrences. [P]
• a message board and/or blog for community members to use. [P]
  
• an easy way to generate graphs and charts for statistics presentation. [P]
  
• two-way communication with the game MODEL - examples: [C]
• getting stats to display
  
• getting the token object features (color and shape)
• getting the display timings
• getting the presentation mode on the fly (i.e. changing the presentation mode mid-game)
• getting data on how to bias the objects being displayed (i.e. there may be all squares with one lone circle)
• setting the "difficulty"
• setting the user's IP address
• setting how many token objects were displayed
• setting how many token objects the player counted
• saving/mailing community posts, comments and requests
  

Options for the gameplay technology (again, the more dynamic/interactive parts):

• JavaScript (could be used in conjunction with Ruby on Rails, PHP, etc. but not really robust enough; difficult to debug)
• AJAX (I don't know enough about this - could be used in conjunction with Ruby on Rails, PHP, etc. - but has the same drawbacks of JavaScript: may not be robust enough and is difficult to debug)
• Java Applets/Java+OpenGL (seems good enough, but users have to have the Java Runtime Environment; Java just seems very heavy-weight/clunky for web development)
• Flash (this is not an open-source technology - is there an open-source Flash being developed somewhere? If not, would this be difficult to do? Keith?)
• Ruby on Rails graphics (? - haven't seemed to have found any good way of getting graphics up - would just be using JavaScript)
• Plone (? - just started using this and it seems limiting in the sense that the web apps are developed using Zope and Zope is not really used that much)
• Any other way of getting smooth, dynamic graphics into a browser

Requirements for the game engine (the more back-end, logical/magical parts of the game - I think this listing will require more thought and time, but this is a start): [M]

• a relational database
• a database schema - how and what to store in the database (i.e. a model for collecting data)
• a model for using collected data to alter game features (this could be intense, using ideas from machine learning, artificial intelligence and neural networks)
• a model for actually changing game display features such as presentation modes and the ordering of shapes (this is highly related to the above item and could, indeed, be intense)
• a model for presenting data as statistics an i++ player may find interesting

Options for the game engine:

• Zope database/framework (this would go along with the Plone package)
• MySQL database (this would go along well with anything other than Plone)
• Any public artificial intelligence or neural networking APIs out there?
• Any of either Ruby, PHP, Python or Java for the rest. This would depend highly on what works best with the presentation of the game and supporting infrastructure like a message board/blog, maybe a wiki, a code repository, etc.

i++ for you++

Check out the i++ public website. You can play the game, learn more about the project and email the developers.

Communications Infrastructure

As work on i++ has progressed, we've been thinking about how to organize our work and our interactions and collaboration with the i++ community and the world. There have been ideas of setting up a wiki, a subversion repository, an internal blog (see ya, Blogger), a mail server and a messageboard/forum. All these are very useful tools to not only keep in touch with those external to the i++ development team, but, to better organize the i++ development team itself. In addition, the development of i++ will be informally archived through the use of these tools.

After thinking about this, we wonder which tools we can use (i.e. grab off of the Internet and run), which tools we should build ourself (i.e. building our own website to contain third-party tools and content or use third-party portal software to begin with) and which tools will work well together? For example, I'm familiar with Tomcat and Confluence and have used them running on the same server. They work well - Tomcat is a solid Servlet container and Confluence is a very powerful wiki. When we introduce a Subversion Repository, however, things get a lot more complicated.

It would be nice to learn how to install, integrate and administer all these different web tools, but that's not the goal of the project. Very broadly, the goals are simplicity, learning and community. Our main focus should be developing the game and making it as robust, fun and useful as possible.

So, we've been thinking about building our public website and communications infrastructure using a popular content management system called, Plone. More research is required, but a flexible, robust content management system seems like the way to go if we want to avoid spending too much time in integrating various tools and servers ourselves.

There are other content management systems out there that we're comparing such as Joomla!, e107 and Sakai. All of these systems are open-source, free online portals that will allow us to bring together various tools and people to interact with each other to build and manage the project.

I've been working with Sakai for some time now, and it's sweet, but it may be nice to try something else. Really leaning towards Plone.

i++ Gameplay Comments

You just played i++.

How'd it go?

i++ Project Proposal

Game summary

i++ is an open-source, interactive, single-player game that challenges visual pattern recognition and mental counting ability. Players are challenged to recognize a specific object of a set shape and color in a continuous stream of objects with varying shape and color within a set amount of time. Basic features of gameplay such as shapes, colors, format of shape presentation and time of game remain flexible and can automatically change based on analysis of groups of players’ performance and location. The game displays these statistics to players and maintains an open rapport with players to gather feature requests and feedback in general. Eventually, there may be a player and developer community that maintains, develops and releases future versions of the game.

Game Walkthrough

Start Screen

• Player is allowed to select difficulty. A harder difficulty setting increases the rate at which shapes appear on the screen. An easier difficulty setting decreases the rate at which shapes appear on the screen.


• After difficulty has been set, Player moves on to the Launch Screen.

Launch Screen

• Player is presented with an object with a specific shape and color that they must count throughout the game. This colored shape will be referred to as the Token Object.

• Example: tokenObject = yellow circle

• Once the Player is ready to start, they move on to the Game Screen.

Game Screen

• Random shapes from a shapeSet of random colors from a colorSet flash before the Player at a rate according to the difficulty set on the Start Screen for a set amount of time. The presentation (presentationMode) of the shapes does not always have to be the same. Music will be playing.

• Example:

• shapeSet {square, circle, triangle, rhombus}
• colorSet {blue, green, red, black, yellow}
• gameLength = 30 seconds
• presentationMode = single shape
• music = second 15 to second 45 of “I Might Be Wrong” by, Radiohead (subject to copyright/licensing, of course)

• Once the time is up, the Player is taken to the Count Submit Screen.

Count Submit Screen

• The Player will be asked to input how many Token Objects they counted

• Once the Player enters this information, they move on to the Game Over Screen.

Game Over Screen

• The Player is presented with how many actual Token Objects occurred on the Game Screen
• The Player is presented with options to play another game, view i++ Statistics, leave Comments, or Participate in the development of i++.

i++ Statistics

• Between the Count Submit Screen and the Game Over Screen, i++ saves the Player’s IP Address, all gameplay features and the Player’s Token Object count.

• Example Statistics:

• Top five miscounted Token Objects sorted into difficulty groups.
• Top five correctly-counted Token Objects sorted into difficulty groups.
• Top five miscounted Token Objects by region sorted into difficulty groups.
• Top five correctly-counted Token Objects by region sorted into difficulty groups.
• Average difficulty selected.
• An array of all Token Objects and their correctly-counted/miscounted ratio.

Comments

• a message board about i++ Player experiences.

Participate

• a venue to collect i++ feature requests and gather developers to collaborate on i++ feature requests and overall development.
• i++ community members will have access to a subversion repository.

Technical Summary

• i++ will be written in Ruby using the Ruby on Rails framework.
• A graphics engine/library for i++ has not been determined – any recommendations (feel free to comment)?
• i++ code will be maintained in a subversion repository with anonymous checkout permissions.

• commit privileges will be determined as interest in the i++ development community increases.