Skip to content
Peter Schwede edited this page Aug 8, 2013 · 40 revisions

In general, we decided to make a web-based application.

We decided to use jQuery for DOM manipulations and jQueryUI for regular widgets of our interface like tabs and selectable table rows. Our interface is written in CoffeeScript instead of native JS to make future development easier. We also appreciate the advantages of Less for compilation of regular cascade style sheets.

The interface is basically an event-based Model-View-Controller implementation. Using web-based technology, we suppose it's easy to port our software to mobile platforms (e.g. Android) in future.

The interface visually concentrates around the playing field displaying the current position of each player and the ball on a field. On top of it below the headline displaying current goals and time, are tabs for the user to choose from perspectives and other features concerning the field such as heat maps.

On each side, the players of the teams (A on the left, B on the right) are listed in selectable tables. That way, the user has a quick overview of the players and can easily select multiple players for more detail. When the user selects a player, it's highlighted on the field and the current data of the selection's top most player will be displayed in a short table situated at the bottom of the player's side. It is updated each time, more data is received.

The field itself is a simple plane of 120x90 in size displayed on a WebGL canvas. Each players are symbolized by a colored t-shirt icon with the correct player number on it. All coordinates are relative to said field size. The height is transformed as well, but less accurately approximated:

result.x = (position.y) * @field.width / @reality.width
result.y = (position.x - @reality.height/2) * @field.height / @reality.height
result.z = position.z * (@field.width / @reality.width + @field.height / @reality.height) / 2

All players and the ball cast emulated shadows onto the field to visualize their height when seen from the top. In our final version, the user can choose from a series of camera positions:

  1. BIRD - view from the top
  2. SWING - view from the side, camera moves to enforce 3d impression
  3. A - view from the left goal
  4. B - view from the right goal

To establish smooth motions rather than "jumpy" animations, each object sets their current position by reusing the current position and the currently set target position via a transition function on each frame:

transition: (factor, current, target) -> (current * factor + target) / (factor + 1)

That way, the actual display may never show the real data, but it's more natural and thus easier for the eye to trace than positioning to the raw data. Please note, that factor defines how many frames it will take until current adapts target. Therefore the aesthetically chosen factor has to be graduated by the time between the frames before put into transition, which we do.

The interface receives the data from Mobilis via XMPP that is immediately translated into JavaScript objects which then are handled like events. To assign the data to the right places, we make sure that each objects has a constructor.name that can be compared to strings. Obviously direct communication via UTP without XML decoding would raise the general performance, but this is an academic experimental piece of software about using XMPP for transmission of high amounts of events. We hereby can demonstrate how fast this can happen between server broadcaster and a web client.

Last but not least, there's a prophecy feature below the field display. Every second the interface receives a prediction about the current team attack and the current pass. Each is displayed by a commenting text and up to three bars that display the statistical distribution of the possibilities.