The Internet is full of social web sites, offering media of various kinds and the ability to show our appreciation in some way or another; liking, hearting, starring and so on. The reason we interact with content in that way may be to show our appreciation to the content provider, bookmark it for further reference or generally serve our compulsive collecting need. But otherwise we may not do much with all those likes and hearts and stars because we’re constantly exposed to so much new content that we continue responding to, with our stars, likes and hearts.
What if we were given the opportunity to play with the content we’ve liked in the past, interacting with people who like similar things, across our usual social connections, discovering new things we may like and by the way learning more about ourselves?
Game of Likes is an idea that has been brewing for over two years. The initial idea is of a game that offers the ability to connect the various social (media) networks a player may use – Tumblr, We Heart It, Pinterest, Instagram, Flickr, YouTube, SoundCloud, Hype Machine, Spotify, 8tracks, deviantART, 9gag and so on – and play mini games based on the liked or posted media items from those networks, alone or against opponents that are friends or total strangers. The idea has then evolved into an environment where you gradually specify your interests and are assigned into groups of anonymous players that are regularly split up and reformed with progressively like-minded players, where you share your likes, with your likes(TM), as we like (!) to put it. As a new player, or when the game has only a few players, you may not find yourself among like-minded people, but as you progress through the different groups and deep-dive through the network of players, you may find yourself increasingly exposed to content that you find agreeable and along the way make connections with people sharing that content.
Later the idea has further evolved from this concept of assigning players into groups, to simply offering the ability for each player to propose a particular game to play, where others can jump into any of the proposed, open and active games, which catches their fancy.The concept of assigned groups is still appealing, so the idea evolution may take a few more rounds or shift towards something entirely different.I’m going to work on this with my wife, Edda Lára Kaaber, as a Masters Thesis project in the Games track at the IT University of Copenhagen.We have written a thesis proposal, which can be read at:
Phillip Prager has agreed to be our supervisor for this project, which we are very grateful for.He has connected well to the Game of Likes concept and has already provided us with a variety of interesting reading material.
In the coming weeks I’ll focus on the initial implementation steps towards realising this idea, along with a couple of other projects.The most basic feature to implement will be the ability to connect to the various social media networks and incorporate media items from them as objects for play in the game of likes.We envision the media items being arranged on one side of a cube each, in three dimensions.Such cubes we call like-cubes.Initial steps along that path have already been taken as a final project in a Procedural Content Generation (PCG) course at ITU, where along with Kasper Fryland Appeldorff, I implemented a prototype that collects media items from a given Tumblr account and presents four of them at a time. The mechanics of the interaction is supposed to resemble that of slot machines or so called bandits. The user can freeze any of the items and choose to roll the free, non-frozen items, where they are either replaced with random selection from the items associated with the specified accounts, or replaced with a selection influenced by the tags (if any) of the items that have been held / frozen.More details can be read in the report we wrote on this project:
This process of collecting media items into sets, that will be used to decorate sides of cubes, can be viewed as playful in itself.Beyond that, we have brainstormed various games to play with such cubes.One of the most simple games, and possibly the most relatable, is a quiz where two participants are presented with three like-cubes, one of which has been created by their opponent and the aim is to guess which of the three it is.Points are given for correct guesses and as the quiz progresses, the participants could gain a better idea of their opponents’ likes; they could increasingly become experts in each others likes.
Another idea is to have the players arrange the cubes into narratives by connecting them with text fragments.When presented with this idea, some have received it with skepticism, but while shopping in Copenhagen before last Christmas, I came across the the game Rory’s Story Cubes, in the bookstore Bog & idé, which is based on pretty much the same idea; the main difference being that the story cubes offer a predefined set of images, or icons, while our like-cubes will have dynamically generated sets of images drawn from each user’s social media accounts.In the same bookstore I also found a series of games that involve the discovery and expression of the players personality, which will also be a goal with the Game of Likes, as discussed in more detail in the thesis proposal linked above.Those findings I think further validate that we are on to something with this Game of Likes concept.
Initially the idea has been to have these games playable online, with the players usually in different locations, interacting over the internet.After seeing the possibilities of developing console-like games for the Chromecast device, where players are located at the same place at the same time, in front of a television set and using their smartphones as game controllers, I’ve also become interested in exploring the possibilities of using that technology for some playful activities within the Game of Likes.
In an Artificial Intelligence course at ITU – Modern AI for Games – the Interactive evolutionary computation (IEC) project Picbreeder, and its predecessors, inspired me to explore the feasibility of utilising the powerful properties of Compositional pattern-producing networks, evolved through NeuroEvolution of Augmenting Topologies (CPPN-NEAT), in the formation of unique waveforms to construct oscillators producing interesting timbres. Those oscillators could then be used as novel building blocks in complex synthesizers. Furthermore, I pondered the possibility of using the evolved CPPNs to construct those synthesizers.
To facilitate the beginning of this exploration, I developed a prototype called Breedesizer, for evolving populations of waveforms with the CPPN-NEAT technique, which is accessible at:
It showed to be an interesting and enjoyable process to guide the evolution of waveforms with this technique, and it is an exciting prospect to see how the variety of generated waveforms can be used with different sound synthesis techniques, as can be read more about in the Discussion section of the report.
Here are two quick screen recordings of the Breedesizer prototype in use:
It was great fun playing with this and occasionally during the past years I’ve thought about doing something interactive based on procedurally generated mountains like this. One idea was to port this implementation to WebGL, when that standard was introduced. A few years ago, when looking again at this project, I changed the code so it would compile on Ubuntu Linux, but originally this was compiled for a then current Windows version (’95 or ’98 I guess).
Today I read that the visual artist who created a fake game for Her, a movie I highly recommend, has revealed a game created with Unity called Mountain, with „questions designed to be far more psychologically invasive than anything Facebook wants to know about you“ where you play as a mountain and answer the questions „by creating a drawing, which is then used to help create a procedurally-generated mountain“. This resonates a bit with ideas Edda Lára and I have been kicking around, that we might use for our masters thesis project, though they have nothing to do with mountains.
That game will definitely go on my to-play list. The past years I really haven’t actively played games but there are now on that list a few titles that I find very interesting; the not-so-much-of-a-game Dear Esther and Flower (on PS4 – I do seem to like exploratory games), and the platformer 140 are the only ones I’ve recently given a proper try so far, and I really enjoy those, but then are The Stanley Parable, Portal (2), FEZ and Flow (on PS4), and Antichamber (that I just bought on the current Steam sale – the thesis ideas mentioned have currently something to do with chambers), and I might go for the platformer Super Meat Boy – yes, we were just watching Indie Game: The Movie and I just purchased a copy of Us and the game industry, which is still on the to-watch list… I really hope Journey will make it to the PS4; everything thatgamecompanydoesseems to be veryinteresting.
During a Data Mining course at ITU I participated in a group project that aimed at identifying places of interest by clustering photographs from Flickr by their location and discovering frequent patterns in the places individual photographers visit.
Initially the idea was to cluster the photographers themselves by their common tags of interest, but later on in the process we moved on to this concept of automatically finding spots people flock to, by looking at where they commonly use their camera, as suggested by my wife, Edda Lára, when I was discussing this project with her. This could be useful for tourist offices in recommending places to visit or avoid, or for city planners to identify load points where special emphasis should be placed on installing public facilities, etc.
In this project I had the task of implementing the photo clustering and writing about it in the report, while teammates Julian Stengaard and Kasper Appeldorff implemented the data gathering, frequency analysis and visualization, along with writing the rest of the report, which can be read here:
- a quick presentation for an oral exam based on this project.
Before proceeding on to the group project, we were to complete an individual assignment that involved using „the data set … created during the first lecture, through … filling in a questionnaire“ and we were instructed to „formulate one or several questions to be answered based on this data, write the code and carry out the analysis necessary to answer them. … apply at least two different preprocessing methods, one frequent pattern mining method, one clustering method and one supervised learning method. (For example, normalization+missing value replacement+Apriori+k-means+ID3, though many other combinations are possible.)“ – according the project description.
In this report I will reflect upon the process of coming up with an idea for a game to be developed with the Unity game engine, as a programmer in a group of five people attending the Game Development course at the IT University of Copenhagen. Brainstorming was a large part of the process and that part alone had several phases where ideas shifted shape many times over and prototypes were created and thrown aside. A large part of this report will thus accordingly be devoted to that process along with a briefer coverage of the technical implementation, where I had a delightful immersion in a technology new to me, opening up doors to new paths to explore.
With darlings set aside rather than killed, as I would like to see them, the group settled on a concept to follow through and the development of a deliverable product proceeded without hiccups, consisting mostly of the linear completion of tasks we commonly agreed upon and prioritized. The outcome is a fairly polished game offering a rather basic gameplay, though with a few twists, that may appeal to a broad audience of casual players.
The development environment and division of roles
Even though this was an initial surprise, I was easily convinced of the benefits this requirement would give, where all team members were most likely to be familiar with the Unity game engine and so would have a level playing field, giving experience with one of the most commonly used tools and spoken languages in the field of game development. In a previous Game Design course I lead the team into developing a custom server side solution and a client app, where no game engine was used whatsoever, utilising my forte as a web developer, where admittedly other team members may have had a hard time getting up to the same speed I had with the technology. Even though the project from that course may be considered a success, the choice of technology may not have been fair to everyone.
When it came to dividing roles within the group, I was open to working on tasks other than programming. Sound design interested me for instance, as I’m an amateur iPad composer and a compulsive audio app purchaser. Also I was interested in 3D modeling, as I’ve previously done hobby projects in that area and were at the time enrolled in a 3D course at ITU. Taking on those roles would have been a welcome break from programming, even though that is still my main passion, but it turned out to be logical that I took on the role of one of two programmers, as there lie my strongest skills and experience.
The student groups were assigned a limited amount of Unity Pro licenses, valid for the duration of the semester, and we utilized them for among other things to communicate with a Unity Asset Server that we set up on a cloud computing instance. It gave the development process a more integrated feel to have source control management within the development environment, though we probably would have done just fine using for example a Git repository and an external tool. The three licenses our group was assigned went to the two programmers and our game designer and graphics artist. A fourth license for our 3D modeler would have been nice, so everyone could have communicated within Unity through the Asset Server, but we solved that with the less fancy, ad hoc manner of delivering 3D models through our private Facebook group. #firstworldproblems
Initially we discussed what kind of play we wanted to create and for what platforms. One style fancied was that of exploratory games, like Dear Esther and Flower. We discussed adhering to dogmas such as having no scoring system, no narrative or textual explanations but rather only visual cues, and we even considered exhibiting permadeath as a game characteristic.
Though we are interested in mobile touch devices as platforms for games, we did not want to exclude other platforms either and so kept the choice open until rather late in the process. Even though we have now settled on the Android and iOS mobile platforms, the game actually works reasonably well also with mouse input in a desktop environment, which we indeed use for development and initial testing iterations.
The first brainstorming sessions were sparked by a photograph of a lighthouse in Iceland that has an unusual design which can resemble a space pod of some sorts. We toyed with the idea of being able to fly a lighthouse like this, exploring and discovering the environment, collecting objects that might count towards completing a goal.
One concept had the player surrounded by seven platforms, one of which is populated by a lighthouse that can be entered and flown towards flashing lights on distant shores, going through swarms of obstacles and energy units, finding that those distant lights are other lighthouses that can be brought back to one of the home bases. Each of the distant lighthouses flashed one of the seven colours of the rainbow and when all of them had been collected to their bases, their combined lights would form a white boulder or beam of light that would lead to the next level.
Several other concepts were based on that lighthouse photo, involving among other things guiding ships, rising and falling sea levels, and even going through different environments on each level, like underwater, through forests and space.
Those concepts based on the lighthouse may not have been tangible enough and too abstract to grasp, and we received the encouragement to simplify and focus our ideas. Subsequently the idea sprung up to base a game on the classical elements of fire, earth, water and air. That lead to the concept of fixing planets ruined by their inhabitants by applying the missing elements to them. And from that we got the idea of a planet trading business, where the game takes place in the context of a market where the buying and selling of renovated planets takes place, with planets habiting elements of high demand being more valuable than others, and the player has the role of a planet businessman, taking on contracts to prepare planets according to his clients’ demands, collecting revenue from successfully completed contract work, enabling her or him to sign up for grander contract work offering larger payout.
As much as I had already invested enthusiasm for the concepts based on the lighthouse, it was a rather easy transition to shift focus to a game based the classical elements, especially given the environmentalist context of ruined planets and the capitalist context of selling planets with elements in high demand. Still I was fond of those lighthouse concepts and took the position to explore them further at a later convenience, rather than to kill them on the spot, feeling well equipped by the newfound powers of Unity.
The mini games
Having settled on this concept based on the classical elements we began to define gameplay within that context. We had the business- / repairman and a vision of his home base as some sort of a garage floating in outer space. That was going to be the game’s center and a point of entry into mini games where the player would go on missions to gather elements.
Initial thought was to have four mini games, one for each of the elements, with different challenges and each even with different game mechanics. We realized soon though, that creating four mini games and the central game management in the garage would probably overshoot our capacity during the semester and halved that possible overscope by discussing the feasibility of two mini games, where one would offer the collection of the more tangible elements of earth and water, and the other would inhabit the less tangible air and fire.
As I had become fascinated by an art installation design of a constellation done for theLAGI renewable energy initiative, I volunteered to create a prototype of a mini game where the player could collect both air and fire elements in an environment inspired by that design. Another team member created a prototype for collecting the earth element and possibly also water, where boulders were rolled with game mechanics inspired by the gamesDragon, Fly! and Giant Boulder of Death.
The simplifying U-turn
In a meeting where we were presenting the two prototypes and trying them out, we had the rather insistent encouragement from our producer to simplify our concept even further, with the specific suggestion of implementing one mini game with 2D gameplay where spheres of elements would reside in each of the screen’s four corners.
Having seen that meeting as a time to flesh out a list of tasks to carry on with the already began development, I could not help being visibly irritated; an appearance supported by the lack of sleep the night before doing prototype work. Those feelings carried on into the next day and had me dazed by how emotionally invested I had become in this project. I felt done with brainstorming and ready to move on with development, having once developed enthusiasm for the lighthouse concept, set that aside and again built up steam for the classical elements concept with different mini games that implementation work had already begun on. Gameplay in 2D for this project did not initially appeal to me either, as we were working in a mandatory 3D engine and I was thinking quite literally in the dimensions offered by that.
Even though I was still rather annoyed for the second day by those repeated changes to our concepts – having personally transitioned twice from a brainstorming mode to a focus on implementation, building up steam to only extinguish it and go back to the drawing board – I could also realise the sensibility of those suggestions and also feel they were well received and easily grasped by other team members. So I wrote a comment to our team’s Facebook group, stating how I could understand the new angle as a feasible option, and other team members saw it the same way. At a later meeting our producer mentioned his concerns of having possibly intervened too much in our process, which indeed at the time I felt to be the case, but regardless we went along with the suggestions and steered the development towards that new angle.
Settled on a new course of action, it was time again to implement a prototype based on the new concept of a single 2D mini gameplay. Here our main concern was how to represent visually the reception of elements on the subject planet. To start with something simple to implement we decided to split the planet’s sphere into four segments, or wedges, where one would be receptable to one element each.
That representation indeed resembled slices of a pizza and having sharply defined quarters of the sphere, each only capable of receiving one element, was regarded as making little conceptual sense. So we discussed a representation in the form of nested rings, one for each element. How to implement those rings was not clear to me and I thought initially about stacked discs, like in the Towers of Hanoi puzzle, and later became fond of the form and mechanics of the gyroscope, which the game uses in its current form, with nested rings rotating randomly.
Development tasks and their division
Programming effort was in large part divided between the garage and the one mini game of delivering elements to the subject planet, where I devoted most of my time in the latter, focusing on the touch interaction with elements, their reception on the center planet and managing the progression of play in time and the approach of goals (rendered with progress bars). Highlights in that process include the gyroscopic rings of element reception; a module for spawning asteroids as obstacles, fully configurable in the Unity editor; configuration of obstacles for each level in the editor for a designer without any programming; handling multiple, simultaneous, touches of the elements, offering a cooperative play; and making victory and failure exit animations with mecanim, a non-programming task I jumped on to try out some of the movement through 3D space I so much desired in the game.
Later on I joined the garage, implementing a HUD in the form of a clipboard, using Unity’s mecanim system. Also I added the ability to look around the environment by touch and to buy elements from the shop before going on missions, among other tasks, like finding planet textures.
The modeling work, graphics and code from other team members flowed smoothly into the project via the Asset Server. During development it was good to have as a reference a game design document created by one team member, where among other things aspects of the economy were outlined and interactions of elements were defined, that are in fact yet to be implemented in the game.
One of the seemingly most difficult tasks of development has been choosing a name for the game. In a cycling tour around Refshaleøen I came across a barrack marked with the sign “Copenhagen Suborbitals” and that got me thinking about the word “orbital” and subsequently suggesting the name “Out of Orbit”, which is actually used by a small game currently in the Google Play store, but it has stuck as a working title, while other ideas include Elementix, Elexia, Elementum, Elemia, Elemental Architect, Elemixir, Elemade, Elemaden, Eletrade, landMiller, landMaker, landMakia, planetShop, orbitalis, orbitalia, or even just suborbitals.
Beforehand we were warned that difficult moments could arise in the process but I was not really worried about that as I consider myself pretty much open to all types of games and not tied to any specific genres of play as I’m in the first place not so much of a game player – having reached the hardest core of game playing in the early 90’s when I finished the permadeath game Prince of Persia and all episodes of Commander Keen – and so felt open to follow along to wherever the process would take us. Regardless, ideas sprung up early in the process that I quickly clung to and built up enthusiasm for, that I later on had to suppress when other ideas surfaced, that were possibly more realistic and generally acceptable. Those changes proved indeed to be sources of surprisingly difficult moments for me, though fortunately they did not last for long.
Overall I feel that the group worked very well together and no conflicts arose among the members. Only I had to make an effort to keep in line with the level of diplomacy and air of serenity within the group, having invested personal enthusiasm for what I must admit were darlings in the moment. Along with the immersion in Unity’s technical intricacies, it was a great learning experience to go through those development phases, even though I have been around the block once or twice in a previous career as a software developer. Especially it is interesting to have taken part in the evolution of ideas through all their phases and to compare that process to how other known works have changed dramatically from their initial concept to their published form.
Do I think we could have had more interesting gameplay with the multiple mini games previously prototyped? Yes. Do I think we have a more manageable project and a unified experience with the focus on the current mini game? Also, yes. And the experience the game offers in its current state is enjoyable enough to have me and other team members interested in continuing work on the game, to have it presentable for the Google Play and Apple App Stores.
IT University of Copenhagen
Game Development course – instructors:
Henrike Lode and Mark J. Nelson
spring 2014 Björn Þór Jónsson (email@example.com)
 We used a nano compute instance at Greenqloud to host the Unity Asset Server, where I currently host other projects and web sites. The Asset Server is doubly backed up, once to another disk partition and then to CrashPlan Central, and I purchased more storage for the compute instance as our project has reached a size of ~700MB. http://greenqloud.com/
 I had become fascinated by the idea of swarms of obstacles in a game after seeing this video of flocking birds: http://vimeo.com/31158841 And actually found implementation examples for Unity of the Boids flocking algorithim; see footnotes in the document Towards the Lighthouse linked below.
Project done in the Introductory 3D course at ITU.dk in spring 2014
The concept behind the project discussed in this report has taken many shapes, as ideas have brewed during the course of this spring semester. Being a Games Technology student, it could have been a good fit to focus on creating some sort of game assets, but I was delighted to learn about the freedom offered in the Introductory 3D course. If the outcome of the project leaves the viewer wondering about what just happened, then it is a success.
Though the first idea was inspired by a game concept that I had just started working on, then my initial aim was only to create a visual experience, rather than a real asset usable in a game. Then the concept changed as new inspiration struck but the aim was still to create visuals only. Later in the brainstorming process, that new concept lead to ideas of a possible gameplay, so the intended pure visual was inspiring the creation of an interactive experience and the process had come full circle; starting with an idea based on game development, aiming for an art piece and evolving it into something that inspires further game development.
Concept evolution through constant inspiration
The evolution of ideas for this project, from a focus on shapes, to the components of light, was fueled by objects encountered in the everyday life.
These days I’m constantly exposed to children’s toys, and one toy in particular, offering the matching of differently shaped objects to correspondingly shaped holes, has provoked thoughts about basic forms and how they can be the basis of more complex shapes. Everything in the universe has evolved into it’s current shape from simpler building blocks, which themselves are composed of smaller, more primitive elements. An individual’s ability also develops from simple tasks to more accomplished movements and thoughts.
This evolution and constant change inspired an idea for a visualisation where we would follow a primitive shape, travelling from the core of a sphere through a pipe to the surface, and during the travel the shape would morph into a more complex shape resembling the outlines of a country, which we would then see as a patch on the sphere’s surface.
Alongside this visualisation idea I had taken small steps towards creating a game where the player would have the task of matching increasingly complex shapes to their corresponding slots, where the most complex shapes would resemble the outlines of continents. That concept was placed outside a sphere rather than inside it, like floating in orbit around the Earth. When the continental shapes would be matched, they could be seen falling onto the sphere’s surface, forming a collection of the Earth’s continents.
All the ideas connected to this project were based on shapes and their morphing into others, until I noticed a globe model when walking past an office window at ITU one evening. I became fascinated by this kind of objects, which I had in my bedroom as a child, and started thinking about the source of that globe’s light. In the case of the model, it is obviously a regular light bulb on the inside that lights up its surface. A few years ago I saw glowing lava light up the night sky in Iceland, during the notorious “Eyjafjallajökull” eruptions, and there thelight source was molten rock, lava, flowing from the Earth’s core. Here was born the possibly surrealistic concept of light traveling from the core of the Earth, through lava tubes to the surface.
This concept of light inside and out of the Earth lead to ideas for a possible gameplay, with a connection between the seven components of light, that can be seen in the rainbow, and the seven continents of the Earth. There each continent would have seven openings / portals into tubes leading to the Earth’s core, each having one of the seven rainbow colours. The player would pick a portal, that would lead her through a tube to the core, where light particles could be seen floating around, each emitting light in one colour of the rainbow. There the player would have the task of picking one light particle with the same colour as of the portal that was entered and then pick a tube opening leading back to a portal with that same colour. The indication of what type of tube to pick would be its shape, which could be known after traveling through one tube of that shape to the core. If the player picked a correct type of tube, the light particle would travel through it and shine at the portal on the surface, and the player could proceed onto another portal; if not, the light particle would travel to the surface and back to the core, leaving the player to have another go at completing a portal.
During a presentation of these concepts for students in the Introductory 3D course, the connection between the fitting of shapes and matching of lights with colours was pointed out to me; both are puzzles that require the player to find the correct fit, and I was glad to hear that others would see some coherence in these concepts, where I could have as well expected them to be perceived as a confusing soupof ideas.
As an extension to this coloured light chase, there could be set up an array of globe models, each textured with paleogeographic maps showing how the Earth may have appeared at various increments of time. In this setting, a game could revolve around fitting a light particle to each portal on one globe, before proceeding to the next level in the form of a another globe with a map showing the continents layout in another time slice, and in the process the player would gain some idea of Earth’s tectonic evolution. Though the game would not be branded as educational, it might have some educational value as a by-product.
Realising the concept discussed above involved modeling, texturing, lighting and animation, detailed below.
The first task in the modeling process was to create the framing for the globe model. To solve that task I was given the advice to create a circular arc, with Maya’s Arc Tools and extrude a box along it. The base and stand were created from cylinder primitives, shaped with soft selections on their vertices.
It was fairly simple to model the globe itself from a sphere primitive, but the twist was that its surface had to be visible on both the inside and outside. To achieve that, all faces of the sphere were extruded inwards and the normals of that inner layer were reversed, to face towards the globe’s core. The sphere was created with an extremely high polygon count (198394 faces for both layers) only to have flexibility of where to cut holes for the tubes that were to pass through it.
Modeling the tubes started with creating CV Curves to define the path along which to extrude their profile. Four CV Curves were created by adding their control vertices in spiral shapes, in one of Maya’s orthographic views (top). In a perpendicular view, soft selections on the CVs (with falloff mode set to surface) were used to shape the curve path in 3D.
Two options were considered to create the tube models along the curve paths; polygon extrude and surface extrude. The latter was chosen as UVs are already created with that method, so texturing requires no further effort. Two concentric circle paths were created with the Arc Tools to define the inner and outer layers of the tube profiles. Each of them were surface-extruded along the curve paths and the resulting meshes combined by bridging their edges at the ends. Normals of the inner tube layer were reversed, to face inside the tube, as was done for the sphere.
All textures of the scene lie on the two sides of the main globe and on the inside of another encompassing globe. The faces of the main globe’s inner layer were selected and a texture applied to them, different from the one on the outside layer. A color map and a bump map for the Earth were used on the inside, and the texture happens to be flipped there, which could have been easily fixed by flipping the texture in an image manipulation program, but this was considered a good surrealistic effect. The outside faces of the globe were textured with a bathymetry map of the Earth, for it’s nice visual effect of black continents and light blue sea. A cloud map composed of satellite images of the Earth was applied on a sphere encompassing the whole scene, with normals facing inwards.
Different kinds of textures were considered for the tubes, ranging from a custom gradient resembling the layers of the inner Earth or the inside of a hala fruit, to a bump map imitating the ribs of plastic tubing, or even a tree bark texture that could give the illusion of enormous trees growing from the Earth’s surface. Brushed steel and chrome Mental Ray material presets were tried. Even the gray default material was considered, as it was visually pleasing in this context. But the final decision was to have the tubes without textures, even though they were easy to apply due to the surface extrusion, but tinted with the seven colours of the rainbow, using a Mental Ray material (mia_material_x) with a rubber preset. Though this decision would not make sense in the context of a game where tubes would have to be selected for the correct colour, making it too easy, it makes sense for this project which is focused on the visual experience and those coloured tubes look delectable.
The lighting for the inside of the main sphere consists of one point light located at the center (core) and another pointlight attached as a child of the camera (in the Outliner), so it lights up the inside of the tube as the camera travels through it. As the project uses the Final Gathering technique offered by Mental Ray, a considerable glow saturated the whole scene when rendering inside the globe, and that was found to be due to light bouncing off the inside faces of the globe. This glow was mostly removed by disabling the Final Gather Cast Mental Ray option for all the faces of the inside globe layer.
For light emitting from the portals on the Earth’s surface, spotlights were created with a Light Fog effect, to simulate the beams coming from a disco light. To ease the creation of the required 29 spotlights, duplicates were created from the initial spotlight created and adjusted, where each duplicate was rotated to it’s position with the pivot located at the world / Earth’s center. Only when all spotlight duplicates had been configured in their position was it discovered, by rendering a one frame sample, that it is not possible to duplicate spotlights with the fog effect and have good results; all spotlights rendered with a yellowish tint, even though they had been configured with the seven rainbow colours, and further research on the web confirmed that this was to be expected. So they only way to go was to manually create from scratch each spotlight and configure it with the right colour and fog effect and transform to an appropriate position. This was one of the most time consuming tasks of the project.
The most interesting lighting technique used in the project is that of Object Based Lighting with the MIA Light Surface Shader, where the material applied to the outside layer of the globe emits light according to the bathymetry texture used with the material – a feature offered by the Final Gathering technique – simulating the glow of a typical globe model with a light bulb inside. The result is a bit grainy glow on the surfaces around the globe, probably due to the low resolution of the texture used, but a less grainy result was obtained by increasing the Accuracy value (from 100 to 600 in one case) for Final Gathering in the Render Settings. Higher accuracy values resultedin much longer rendering times and so the default of 100 was used for the animation batch render.
The animation was to take the viewer from the inside of the globe, through one of the tubes, to a view of the globe’s exterior. One of the first decisions was to animate the camera along the same curve as was used to create the tube it would travel through. Manual keyframe animation was initially used to move the camera in thefirst part, before entering the tube. Then there was the question of how to transition smoothly from the keyframe animation to the guided animation along the tube path. One option was to have two cameras and switch them at the transition point, but I preferred to have one path for the whole path and tweak it visually to my requirements. To that end, two other paths were created for the animationsegments before and after the tube travel. The Bezier Curve Tool was used to create the paths, as it is more familiar to work with those kinds of curves.
When the curves had been attached, the camera movement along the newly created parts was shaky. Applying smoothing to the vertices where movement was rough made the situation a little better, but when vertices were moved they got sharp corners again with shakiness appearing again in the animation. Part of the problem may have been that the tube curve was initially a CV Curve and the new curves were Beziers. Converting the combined curved to a NURBS curve and choosing to smooth the whole curve didn’t completely solve the problem; movement was still hard to control around the points of attachment and sharp corners prevailed. It wasn’t until I found the Rebuild Curve option on the Edit Curves menu that the problem was solved with a resulting smooth curve that was easier to control.
Timing along the motion path curve was controlled with position markers. Orientation of the camera along the path was controlled with orientation markers on the curve with keyed values of Up Twist, Side Twist and Front Twist. The possibility of blending keyframe and motion path animation in Maya was considered, but controlling those twist values was sufficient.
Camera movement is wobbly during the first seconds of the animation along the rebuilt curve, but instead of ironing that out, that now could have been easily done, it was kept for it’s nice effect of chaotic introduction to this surrealistic world.
Several music pieces were considered for the animation soundtrack, including Wave Dub by Dope on Plastic, Halcyon (On and On) by Orbital, Down Down by Nils Frahm, Justice One by Drokk, and S.A.D. by Mind in Motion. The last minute of the S.A.D. was finally chosen as the change in mood midway through that part is a perfect fit for the transition from the inside of the globe to its exterior, and the rave music of the first part goes somehow well with the colorful, psychedelic pipes. Importing the audio file into Maya helped synchronizing the animation to the soundtrack.
Only little over two days before handing in this project, rendering commenced. As I have a five year old desktop computer at home, running Ubuntu Linux, and I discovered that Maya is offered for the Linux operating system, I decided to try and use it for the batch rendering of the animation. As only a 64 bit version of Maya for Linux is offered, and that home computer was running a 32 bit version of the operating system, I decided it was time to re-install a 64 bit version of Ubuntu on the machine. Having done that, I had to jump through a few hoops to be able to run Maya in that environment.
After initiating the batch render process, it became apparent after the first few frames rendered that this one machine wouldn’t finish rendering the animation in time at a HD 720 resolution. So it was clear that I would have to utilise more machines for the task, and the lab computers at ITU were certainly an option. After rendering 500 frames in around 18 hours, Maya became corrupt on the Ubuntu machine for some unknown reason (logging into another account, resulting in a login prompt freeze and subsequent reboot of the computer, was the start of the trouble).
So the ITU lab computers were now the only option to finish the rendering. A few hours later I had manually created a rendering cluster by starting batch rendering processes on seven computers at ITU, each set to render a range of 200 frames. The morning after I saw the lab machines had successfully finished the rendering and I was able to fetch the files from my file space at ITU via the Internet (SSH).
To assemble the rendered sequence frames, in the TIFF image format, into a movie file with the audio track, I used the avconv command line tool (ffmpeg fork). To add opening and ending titles, I imported the assembled file into iMovie, from where the final result is exported.
It’s been delightful to be introduced to the many facets of 3D rendering and get to know some of the many parts of Maya. Back in 1996 I did some 3D graphics in 3D Studio for DOS and have fond memories from that period, so it is especially interesting to become acquainted with a mature, modern tool like Maya.
Having a basic knowledge of 3D modeling, texturing, lighting, animation and even character rigging, will be a valuable tool for realising ideas for games or other interactive experiences. This project turned out to be a visual experience with the possibility of becoming a basis for something interactive: Being able to take ideas and concepts in whatever direction feasible gives a great sense of freedom.
Vefurinn alaska.is veitir aðgang að teikningasafni Jóns H. Björnssonar ásamt ævisögulegu efni. Jón – fæddur 19. desember 1922, dáinn 15. júlí 2009 – stofnaði Alaska gróðrarstöðvarnar og blómaverslanirnar, og hann var fyrsti landslagsarkitekt Íslendinga. Í dag, þegar hann hefði orðið 91 árs, er tilefni til að segja hér frá þessum vef.
Í gegnum árin hefur verið þó nokkur sókn í teikningasafn Jóns, sem hefur undanfarin ár verið hýst í geymslum Listasafns Reykjavíkur og nú í Þjóðskjalasafninu, þar á meðal frá nemendum við LBHÍ og LHÍ. Þennan áhuga þótti Jóni vænt um en hafði jafnframt áhyggjur af ástandi teikninganna, þar sem þær eru flestar unnar á stökkan smjöpappír sem verður brothættari með árunum. Til að veita fullan aðgang að teikningasafninu og jafnframt vernda frumritin lagði Jón til að afrit væru tekin af teikningunum sem áhugasamir gætu nálgast. Ljósrit voru augljósasti kosturinn en ég, sonur hans og áhugamaður um Internetið, lagði til að teikningarnar yrðu skannaðar og gerðar aðgengilegar á vefnum.
Skráning og varðveisla
Skönnun teikninganna og útfærsla vefjarins má segja að sé búin að vera tíu ár í vinnslu, með hléum þó. Verkefnið byrjaði þegar var ákveðið að flytja teikningasafnið af teiknistofunni hans pabba niður í Hafnarhúsið að frumkvæði Einars E. Sæmundsen og Samsonar B. Harðarsonar landslagsarkitekta, í samstarfi við Gunnlaug Björn Jónsson og Pétur Ármannsson arkitekta, árið 2004. Þá útbjó ég einfalt skráningarkerfi og pabbi færði inn í það upplýsingar um hvert og eitt verk sem hann lét af hendi. Á þeim gagnagrunni, sem var lengi vel aðgengilegur á jhb.bthj.is, byggir alaska.is .
Vorið 2009 útfærði ég nýtt kerfi fyrir sama gagnagrunn sem heldur utan um skannaðar teikningar og venslar við upphaflegu textaskráninguna. Haustið 2009 sýndi ég kerfið á fundi hjá Félagi íslenskra landslagsarkitekta þar sem við Gingi bróðir vorum með kynningu, en þá var ég kominn áleiðis með umsýsluhlutann, þar sem skráning efnis er unnin, og átti eftir að útfæra vefviðmót kerfisins sem snýr að almennum vefgestum. Síðan þá hefur vinna við þetta að mestu legið niðri fyrir utan skönnun, þangað til nú í lok sumars 2013 að ég tók upp þráðinn aftur og endurforritaði skráningarviðmótið til að halda utan um staðsetningu verkanna og útfærði vefviðmótið sem má núna sjá á http://alaska.is/
Útlitið er með naumhyggjulegasta móti og gengur út frá ALASKA kennimerkinu. Persónulega finnst mér það nokkurnveginn sleppa en mætti kannski slípa eitthvað til. Undir http://alaska.is/Jon-Hallgrimur-Bjornsson
er handahófskennt efni sem ég hef fundið um pabba sem mætti skipuleggja betur og bæta við. Nýlega barst þangað kærkomin viðbót en í grein eftir Ástu Camillu Gylfadóttur sá ég minnst á ritgerð um Jón eftir Arnar Birgi Ólafsson og sendi því fyrirspurn til hans um rafrænt eintak. Arnar sagðist því miður ekki lengur eiga eintak af ritgerðinni á stafrænu formi en sagðist myndu vera í sambandi ef hann gæti skannað hana eða slegið inn upp á nýtt. Nokkrum vikum síðar, nú í haust, hafði Arnar aftur samband og sagðist hafa skannað inn eintak sem kom í leitirnar og nú er ritgerðin aðgengileg á vefnum.
Af 597 skráðum verkum vantar enn skönn fyrir 102 í kerfið. Á landakortinu má þekkja þau á ,,hálf-strikuðum“ lurkum. Þó eru skönnin orðin 807 og ég þykist vera búinn að fara í gegnum allar möppurnar sem fengust afhentar frá Listasafni Reykjavíkur á sínum tíma, sem eru núna í Þjóðskjalasafninu – ég skilaði síðustu möppunni þangað föstudaginn fyrir búferlaflutninga til Danmerkur síðastliðinn júlí 2013. Nýlega komu í leitirnar fleiri teikningar sem væri gott að skanna og koma á vefinn sem fyrst þar sem meðal þeirra eru líklega nokkrar af þeim helstu, eins og t.d. af Hallargarðinum en á alaska.is er núna bara ljósrit og riss af honum.
Upphaflegt skráningarkerfi, sem gagnagrunnurinn byggir á, var útfært í forritunarmálinu TCL fyrir vefþjóninn AOLserver, þar sem gögnin voru vistuð í PostgreSQL gagnagrunnskerfið.
Þegar kom að því að vensla skannaðar teikningar við teikningaskráninguna var nýtt kerfi útfært sem byggir á Django veframmanum. Einn af kostum Django er að umsýsluviðmót verður til sjálfkrafa út frá skilgreindum gagnagrunni og það er hægt að sníða viðmótið að þeim sérþörfum sem hver og einn vefur kann að hafa. Möguleikinn að sérsníða sjálfgerða umsýsluviðmótið var nýttur til að útfæra valglugga fyrir skannaðar teikningar, þar sem kemur fram hvort hver og ein hafi þegar verið vensluð við teikningarskrá. Upphaflega voru teikningaskönnin hýst á sömu vél og vefkerfið (í heimahýsingu) og upplýsingar fyrir valgluggann sóttar með beinum skráakerfisaðgangi. Þessari útfærslu bakendans var lokið árið 2009, eins og fyrr segir, og framendaviðmót fyrir vefinn átti eftir að útfæra.
Þegar þráðurinn var tekinn upp aftur nú í sumar var tekin ákvörðun um að hýsa teikningarnar í skýjageymslu og knýja vefkerfið á sýndarvél í skýjavinnslu hjá GreenQloud, sem býður upp á forritunarviðmót samhæfð vinsælu Amazon vefþjónustunum. Þetta kallaði á nýja leið fyrir skráningarviðmótið til að sækja upplýsingar um teikningaskrárnar og forritasafnið boto var notað til þess ásamt stuðningi við biðminni í Django.
Til að sýna staðsetningu hvers teikniverkefnis á korti var högun gagnagrunnsins breytt til að taka við þeim upplýsingum. Sérstakur stuðningur við landfræðiupplýsingar í Django var skoðaður en niðurstaðan var að nota einfaldlega heiltölusvæði fyrir lengdar- og breiddargráðu og styðjast að öðru leyti við Google Maps forritunarviðmótið. Teikningaskráin inniheldur heimilisföng við flest verk og nú þurfti að finna hnit út frá þeim upplýsingum.
Ein leið til þess er að nota forritunarviðmót frá Google til að breyta heimilisföngum í hnit en nákvæmni þeirrar þjónustu takmarkast við heilar götur frekar en einstök hús. Borgarvefsjá finnur hús nákvæmlega út frá heimilsfangi og bak við tjöldin má finna vefþjónustu sem veitir þessar upplýsingar. En sú þjónusta skilar hnitum í ISN93kerfinu svo fyrir notkun með Google Maps þarf að breyta þeim yfir í hnattræna WGS84 kerfið. Fyrir fjórum árum sendi ég fyrirspurn til Landmælinga Íslands um leið til að varpa hnitum á milli þessara kerfa og var bent á Cocodati vörpunartólið. Svo í uppfærðum umsýsluhluta útfærði ég skráningarviðmót sem sendir heimilisfang í vefþjónustu Borgarvefsjár og með ISN93 hnitunum sem fást þaðan er í framhaldinu framkvæmd fyrirspurn í Cocodati viðmótið til að varpa þeim í GPS hnit. Leiðin sem hér var farin til að fá nákvæm hnit fyrir teikningarnar byggir því á óopinberri vefþjónustu Borgarvefsjár og skröpun á vefniðurstöðum úr vörpunartóli Landmælinga; semsagt fjallabaksleið að þessum upplýsingum.
Sjá skjáupptökur af notkun skráningarviðmótsins:
Upplýsingum um staðsetningu teikninganna er skilað til viðmótsins á KML sniði, sem vefkerfið útbýr með kvikum hætti út frá gagnagrunninum (einnig með stuðningi biðminnis), og viðmótið vinnur úr því með aðstoð geoxml3 forritasafnsins.
Teikningarnar eru skannaðar í hárri upplausn, 600dpi, því vistaðar í stórum myndskrám sem eru þungar í meðförum. Á vefnum eru þær birtar á Deep Zoom sniði sem gerir birtingu stórra mynda lipra og þjált að kafa í smáatriði, með svipuðum hætti og kortaviðmót eins og Google Maps byggja á. Upphaflega var teikningunum breytt á þetta snið með Python skriftu og var ætlunin að hýsa Deep Zoom gögnin sem fást með henni á sama stað og frum-skönnin með vefkerfinu. Síðar var ákveðið að nota zoom.it þjónustuna og forritunarviðmótið sem hún býður upp á, með tilheyrandi aðlögun á vefkerfinu sem alaska.is byggir á.
Þegar vefkerfið var komið út á alaska.is varð ljóst að svartíminn var engan veginn ásættanlegaur, þar sem tók að meðaltali þrjár sekúndur að birta hverja síðu. Uppsetningin á vefþjóninum byggði á Apache og mod_wsgi viðbótinni en hún reyndist of frek á tilföng fyrir þá litlu nano sýndarvél sem knýr vefinn, þar sem hún hlóð í raun vefkerfið inn í nýtt ferli fyrir hverja vefbeiðni. Þessa uppsetningu hefði verið hægt að stilla betur til en í staðinn var prófað að setja upp vefþjóninn nginx ásamt fastcgi fyrir þetta vefkerfi (og reyndar önnur sem keyra á sömu vél, til dæmis vefinn sem hýsir þessa færslu). Þessi breyting skilaði stórkostlegum hraðamun þar sem hver síða birtist á broti úr sekúndu.
Fyrir aðstoð við þetta verkefni fá þakkir Björn Axelsson landslagsarkitekt hjá Umhverfis- og skipulagssviði Reykjavíkurborgar, fyrir veittan aðgang að skanna; Samskipti og Pixel fyrir skönnun á hluta teikningasafnsins; Einar E. Sæmundsen, Samson B. Harðarson, Pétur Ámannsson og Gunnlaugur Björn Jónsson (Gingi bróðir) fyrir frumkvæði að því að koma teikningasafninu fyrir á Listasafni Reykjavíkur; Elín S. Kristinsdóttir skjalavörður hjá Þjóðskjalasafni Íslands fyrir að taka vel á móti mér þegar ég skilaði hluta teikningasafnsins á síðustu stundu fyrir brottflutning til Kaupmannahafnar; Guja Dögg Hauksdóttir fyrir veittan aðgang að teikningasafninu þegar það var geymt hjá Listasafni Reykjavíkur; og Arnar Birgir Ólafson fyrir að útvega stafrænt eintak af ritgerð sinni.
Hér má sjá nokkrar myndir úr fórum Einars E. Sæmundsen:
Phosom is a game, or a toy, based on image similarity, where players receive challenges in the form of a photograph, to which they respond to by either taking a picture or finding a picture from the web, and receive a score based on how visually similar the images are. Creativity and visual memory are good skills to possess while coming up with an imitation of the given original, that may not have to represent the same motive as the original but rather be visually similar overall. This kind of play offers the opportunity to perform the popular activities of creating or finding photographs, with a defined goal of similarity and rewards given according to performance within the frame defined by that goal. Also it leads to thoughts about the originality of visual creations; is the original image the player is to imitate really original, or is it itself an imitation of something else, and can the imitation created by the player be considered as an original for imitation in some other context?
Today people commonly carry a camera in their pocket at all times, embedded in their smartphone. Photography in general is a very popular hobby. Playing digital games on mobile devices is a fast growing form of entertainment that often is interweaved in everyday life, where people pick up a casual game during short and maybe random moments they have during the course of the day. Combining those elements – readily available cameras, interest in photography and casual gaming – in a software toy-game, is a goal with Phosom.
The game allows players to connect with others, people they know or other random (anonymous) players, and challenge them with photographs and receive challenges back. How to respond to those challenges offers much creativity when searching your everyday environment for motives that may give a good score when compared to the given challenge. Play with this toy-game can then be “…viewed as…[a] potentially artistic [enterprise] capable of stimulating and releasing the creative components of the participant … that gives satisfaction to [her] creative imagination, nurtures the emotions, excites the soul, and satisfies the senses.”Phosom may thus give social value and develop personal skills. Also it encourages people to explore their environment in a new and exciting manner where they may learn more about their surroundings in the process.
The design of Phosom as a toy to play with or even as a game, has gone through a few iterations and here is an account of what I consider to be the highlights of that process.
When taking a nap with my nine months old son last September (2013) the unrequested idea sprung up to create a mobile application that would allow a group of people, all present at the same (possibly large) location and each holding mobile devices running that app, to create an Internet connected game where the group would be divided into two teams in which each member would be assigned an opponent from the other team. Everyone would be given the task to photograph a motive from their own choosing. Having taken a picture, a team member sends it to his or her opponent, and then waits for a picture to be delivered from him in the same manner. Having received a picture, a team member has to create a photograph, with his mobile device camera, that resembles the received picture as closely as possible, either by finding the motive his opponent photographed or by taking a visually similar picture in some creative way. Each team member’s effort towards image similarity in this way is graded and the total grade earned within each team determines whether it won the game.
Although I was not actively seeking ideas while taking that nap, I did know that a game would have to be implemented as a final project in the Game Design course. During the first days of the semester, we students were guided into group games like Ninja, to mingle, break ice and start us thinking about games. That probably influenced the game setting described in the previous paragraph. The required Internet connectivity of the game is also probably influenced by my fondness of the Internet as a technology and how it enables communication.
What about playful communication with photographs? The act of comparing images within a game is an obvious result of the frequent use of image search engines and an app like Google Goggles. Indeed there already exist mobile photo toys like Instagram and Snapchat, but competing at finding the most similar motive to the one given may be considered as something novel.
Taking that nap probably tuned the brain into an open mode where it could be aflood with ideas sourced from those influences and inspirations.
Initial user interface sketches. Name ideas other than Phosom include PhotoKO and Phosimi.
All team members were enthusiastic about the basic idea of creating play involving photography, visual memory and interpretation. Everyone also saw from their own angle what could be done with that core game mechanic of playing with image comparison, and so in our discussions about what kinds of gameplay could be conceived based on that foundation, several different ideas were collected, into a Google Drive document and our Trello board.
The most discussed gameplay scenarios were one-on-one challenges and turn based group challenges, where players can either get automatically assigned photos, or create their own challenges by taking a picture or uploading one. Other possible types of gameplay we discussed include a memory drawing game, where a drawing is shown for a limited time and the player is to draw it from memory and take a picture of it; art quiz where the player is shown a well known image and has to track it down on the net to submit as a response; a tourist guide in the form of photos from sites of interest, which players find and photograph to have the next location revealed (which could be offered as a white label product). Also we discussed the offering of different categories to play within, where challenge pictures could come from the chosen category, and bribery was even considered, where players could in some way bribe the system to get a better result, which lead to some discussion about ethics.
One of the more fascinating elements within the gameplay scenarios we discussed is the possibility of wordless communication between geographically distant players, as they go about their everyday lives and may at random moments spot interesting visual motives to respond to a challenge with, or create a new one. That element of remote challenges is not present in the initial idea, which is basically about a toy (or a tool enabling play), for a group of people present at the same place at the same moment, to play with. So here the idea was already on its way to evolve into something different.
From that collection of ideas, we settled on a bare minimum of features to implement initially, to get a first hands on feel for how it is playing with the act of coming up with an image that is supposed to be the most similar to another image that is given as a challenge. This minimum consisted of enabling the player to ask for a challenge, that would be delivered as a random photograph from the Flickr image hosting service and the player would then perform a web search, within the game, to find the most similar picture.
As the initial idea is about taking pictures, to create something similar to a given image, the ability to search the web for images instead was only considered as a quick means to have something working, that would then be thrown away at later stages of development when a camera would be accessible from the game running on a mobile device. Much to our surprise, casual playtesting with people we met in passing, indicated that the option to search the web to find images similar to the one given, was regarded as a pleasing game mechanic in itself, and the game could be based on that alone in a desktop environment, where a mobile camera is not an option. More formal playtesting later on confirmed this, where players liked the option to either search for images on the web or to find a motive from their environment with the camera.
Even though this initial prototype was well received, with its limited offering of automatic challenges and web searches, we were still eager to try playing with the mechanic of taking pictures with a camera when given a photo to imitate. When that ability was available in a further iterated prototype, it mostly added a new dimension to the gameplay that had been available until then, rather than changing it completely. Indeed, it was more interesting to explore the environment for a similar motive and asking someone to pose in this or that way, that should be similar to what the picture being imitated showed. This allowed for more social interaction within the present environment, than would been had by doing endless web searches, and that local interaction could be a good addition to the remote interaction discussed previously.
Technical limitations masked by narrative
What became apparent in the first prototype with web searches and in later versions offering photography interaction, is the inferiority of the applied method of image comparison and the perceived uncertainty of how it works. Players were confused about how their results were being evaluated and as a result they were not sure what they were looking for. At least this was often the case the first few times a player took a challenge, but then he or she got a better feel for what worked and not.
Was this something to worry about or was this a part of learning how the game works? This is a question we discussed quite a lot. It was a concern regarding the playability of the game when players found the results they were given to be unfair. A player might find the same object as in the given challenge photograph, but still get an aggravatingly low score because the overall tone and brightness of the image she produced was different. In those cases she would be likely to throw the game away immediately and never play it again.
Before we commenced with formal playtests we decided to use those technical limitations to our advantage and conceived a narrative that introduced a fictional character whose opinions would represent the evaluation of similarity. Any possible peculiarity of the underlying image comparison method could be attributed to this character’s quirkiness. We were quite happy with this solution, but still, playtesters who had in some cases not taken the time to familiarize themselves with our fictional character and her role in the mechanics of the game, were confused nonetheless. From playtests we learned that the participants would have appreciated some kind of an introduction on how the images were being evaluated, so they would have a better idea of what they were about to do exactly.
Apart from getting the highest score when comparing your image with another, what is your goal while playing with this toy-game? This question lead to discussion about the possible metagaming players could be involved in while interacting with the basic play offered by Phosom. Given the positive feedback we received from the prototypes, where playtesters said that they would like to play this kind of a game, there seemed to be little doubt regarding the potential of the idea for a playable game. But the question remained about how engaging the game could be, what would keep players coming back to it?
With that in mind, we thought about possible in-game values that players would compete to win the most of. Typical representations of such values are coins or points, but I was most fond of using photo prints to represent those values, that players would collect to be able to take pictures. Those prints I liked to call pholoroids, which players could win by coming up with an image that is more similar to a challenge than their competitors could produce. To be able to take a picture, a player would have to possess a pholoroid, and each day he would be given a handful of them for a good start, that could lead him to win a whole pile of pholoroids, which could then enable him to send a picture as a challenge to a group of other players, where, in a sense, he would be putting them all at stake, possibly winning pholoroids from all the players in that group after all rounds had been taken, or possibly losing them all to another player within that group that performed better – in a high risk, high reward scenario.
After reflecting on the previously discussed design process and the collection of ideas, I have become to believe that all this is overly complex, adding layers of narrative and virtual game values, while the values gained directly from the core mechanic could be interesting enough and how the game works could be self-explanatory without words. It could be more interesting to steer the development towards a minimalist game design, where “…self-imposed, deliberate constraints on both the design process and game are an important component to exploring new types of game and play” and “…these point to choosing a few powerful, evocative elements, and then exploring the design space they constitute” where “the goal is not just to strip away the unnecessary parts but to highlight and perfect the necessary elements”.
~ vs ~
Collection of core game values as a metagame
Instead of virtual in-game values in the form of pholoroids, players could see to how many photos they have the most similar imitation, and they could decide whether this count of similarities is something they care about and if they want to compare it with what others playing the game have gained. All images put into the game would be open to imitation by any player.
At one point in time you could have the most similar imitation of one photo, and thus in some sense own it, but then later on, someone else could do a better imitation of that photo and in the same sense win it from you. Notifications could be delivered about those events, that might ignite competitive fires in a player who may decide to try and do a better imitation of that photo, to win it back, or he may decide to look at what other photos that competing player “owns” and try to win some of them from him. And so on, back and forth.
As a player, you could care about collecting increasing numbers of best imitations, comparing your gain with that of all other players within the game, rising and falling through the ranks, or you could care more about narrowing the view of whom to compare with, seeing how your performance stacks up against that of in-game friends, who could be defined manually, by adding them in a “traditional” manner, or they could manifest organically as they decide to compete against you and vice versa. Spontaneous social connections could be forming as everyone can compete against anyone, possibly imitating a photograph that was created to imitate another photograph, in an endless recursive spiral, forming a snowball of imitations that rolled out of the very first photograph initially added to the game; in a postmodern world of endless imitation to explore, where players create the games they like with the mechanics offered by this photo toy-game. Here we would have metagaming directly based on the core game loop and the values it creates.
The interface would be minimalistic, initially only showing the basic element around which the play turns; a photo, one at a time. The photos could be navigated in a sequential order of popularity or by some other metric, such as location. The photos with the most imitations would be considered the most popular – imitations as likes. In the same way, players who have gotten the most imitations of their pictures would be considered the most popular. Would the game then be about collecting the highest count of the best imitations, or to become the most imitated photographer? Players decide, since “being playful is an activity of people, not of rules”.
No introduction would be provided, just that basic element covering the whole screen, and possibly not obvious interactions for the player to discover, as he taps, touches and swipes. This type of interface is inspired by recent mobile apps such as Snapchat,Vine, Mindie and Rando. The player will see images with given scores, attached to the images they are imitating, and see the ability to take a picture. Within that context a player should soon realise what she is looking for when taking a picture; the attached images with the highest score should make it instantly visible what works within the game.
Graphic design can make a game or a toy look beautiful, but it can be argued that it is not the reason why anyone likes to play with it, but rather the affordance of play it offers, and maybe that should then be the most, or the only visible element. That is at least one way to approach the design, that suits well a graphically challenged developer and seems now to be fashionable as the example apps mentioned here show.
Should the development of Phosom proceed in the spirit described here, I would then be taking it closer to that of a non-game mobile app, ignoring the elements that define games, or at least leaving their implementation up to the players, within the facilities provided. This may be a natural progression, as it aligns well with my background as a traditional software and mobile app developer, with little gaming experience (I did finish Prince of Persia and all episodes of Commander Keen back in the days of DOS! -and I was the proud owner of an Atari 2600 Video Computer System). That background of skimpy gaming experience can indeed be considered as an asset and that is a perspective I will try to embrace.
Image comparison methods
When first contemplating the feasibility of the idea of creating a game based on image similarity analysis, I searched for readily available libraries to handle the function of image comparison and settled on two libraries to try out: LIRE and OpenIMAJ. Preliminary tests with those libraries indicated that some kind of play could be facilitated with the image comparison features they offer, computing distance vectors between images based on their histograms.
As a quick solution, a simple servlet using the OpenIMAJ library was created and run in the lightweight Winestone servlet container on a nano compute instance at GreenQloud. The resources of that inexpensive instance are very low and so the image comparison took a long time to run. After receiving a $2000 starter pack for the Google Cloud Platform, the image analysis servlet was moved to a more powerful and expensive Compute Engine instance, with a better response time as a result. This starter pack, with its six month expiration time, is one motivation to continue the development of Phosom and see where it goes.
Programming the backend I used a traditional object oriented approach, with object relationships in hierarchies, probably due to my software development background. With that approach, the relatively simple model behind the game quickly became confusing and now I have learned that the Entity component system (ECS) design pattern is often regarded as a better fit when programming computer games.
For the future development of Phosom outlined above I would like to refactor the underlying data model, from being centered around a game entity to being focused on a photo entity instead, and in that process a move to ECS could be in order. In that same process I would like to consider using hammer.js instead of the jQuery Mobile UI framework currently in use, for the simplified, minimalistic user interactions I have in mind.
Given the widespread use of mobile devices and interest in photography, across all demographics, an opportunity to play with a combination of those may be welcomed. Phosom would not be the first opportunity to play with photography on mobile devices, but could provide a novel angle to approach that play from. Also it can ignite philosophical thoughts about originality and authenticity, while players use their visual memory to scout their surroundings for reminiscent images.
 “In multiplayer games, other players are typically the primary source of conflict.” “We like to see how we compare to others, whether it is in terms of skill, intelligence, strength, or just dumb luck.” – Tracy Fullerton: Game design workshop, 2nd ed., p. 77 & 313.
 “What does the player need to know?: Where am I? What are the challenges? What can I do/what am I doing? Am I winning or losing? What can I do next/where can I go next? – Miguel Sicart: “User Interface and Player Experience”, lecture slide in Game Design-E2013, ITU, Copenhagen, October 21: http://itu.dk/people/miguel/Design_Lectures/UI.pdf#page=30
 “Metagaming is a broad term usually used to define any strategy, action or method used in a game which transcends a prescribed ruleset, uses external factors to affect the game, or goes beyond the supposed limits or environment set by the game. Another definition refers to the game universe outside of the game itself.” – http://en.wikipedia.org/wiki/Metagaming
 Andy Nealen et al.: Towards Minimalist Game Design, p. 1 & 2.
 “Affordances provide strong clues to the operations of things” – Donald A. Norman: The design of everyday things.
 “…we…identify seven elements in games: 1. Purpose or raison d’être 2. Procedures for action. 3. Rules governing action. 4. Number of required players. 5. Roles of participant. 6. Participant interaction patterns. 7. Results or pay-off.” – E. M. Avedon: The Structural Elements of Games.
 ““Students who know every game often have preconceptions about what games are … I have to find ways to make them see that games are an aesthetic form that hasn’t been exhausted. …[it] is sometimes more difficult than starting from scratch with someone who’s maybe a casual gamer or just curious“ – Faye” – José P. Zagal, Amy Bruckman: Novices, Gamers, and Scholars: Exploring the Challenges of Teaching About Games. http://gamestudies.org/0802/articles/zagal_bruckman
Project report done in a Game Engines class at ITU.
This site’s template is a bit outdated and a PDF version
may look better, which can be downloaded from the Google Drive source document,
but there the embedded videos are missing.
Young children often spin around as a form of play, which they perform for the sheer joy of it and maybe the resulting dizzying effect as well. Many forms of dance involve spinning around to various degrees (!) at different moments in time, and people usually dance for their enjoyment. Spinning around can also be a part of religious acts, whether they be Tibetan or Islamic. The act of spinning in circles has even been promoted as a means towards weight loss.
So the impulse to spin around, for different reasons and in various contexts, seems to be quite fundamental in us humans. Usually the act is related to fun and play, and rotatengine.js is based on the idea of encouraging, and maybe structuring, object play that requires or offers spinning around.
Many types of games can be conceived, based on this frame of play and implemented with this kind of a game engine. One kind can include textual elements that are arranged in a circle and the player must tap them in the correct order to organize them into a coherent goal. Another could present the player with images that she must tap on when certain conditions are met, like when the image aligns with another fixed image or text or sound.
Here are outlined more specifically a few game ideas:
Rotabet: The player is presented with the letters of the alphabet in a random order, spread out in a circle around him, as if he is standing within a cylinder where the letters are painted on the wall and his view into that world is through the mobile device screen. By rotating the device in different directions and angles, the player sees different portions of the cylinder wall and has the goal of tapping the letters in the correct alphabetical order. As the player taps the letters they are arranged sequentially in a fixed position on the screen, so he sees the progression towards the goal: The letters of the alphabet being arranged in correct order.A game like this utilizing rotatengine.js can then offer various gameplay mechanics, such as penalizing incorrect choices (taps) by cropping off the already accomplished result, rewarding for so and so many correct choices in a row by then allowing an incorrect choice without penalty, and giving an overall score based on how quickly the goal was reached. Levels can be made increasingly difficult, for example by varying the required player response time; at first removing the choices (letters) as they are chosen, to make the level easier as it progresses, and then at later levels, leave all choices in to make the level constantly difficult. Fonts could change with level progression, with at first a large and readable sans-serif font, then later on, less (quickly) readable script fonts.This could be considered as an educational game, where the player gets practice and fluency with the alphabet. Rotabet is actually the initial idea that inspired the creation of rotatengine.js
Rotaquote, a quotes game: The player sees the name of a known person fixed on the screen and then a few words scattered around him or her in random order. Here the goal would be to tap the words in an order that would arrange them into a (famous) quote that is attributed to the named person.
Similar to Quotabet, a game could be created that is based on poetry instead of quotes. Here the player would have to assemble (known) poems, line by line. Each part of the poem (paragraph) could form one level of the game. If the player gets so and so many errors, she will for example have to start at the previous level. The goal is to assemble the whole poem.
Form grammatically correct sentences: Similar to the quotes and poetry games, the player is presented with a soup of words she has to arrange into any of possibly several grammatically correct sentences.
Anagram: Player is given the task of assembling a given number of anagrams from a set of letters she can spin around, for example: emit, item, mite, time.
Palindrome: Given a random sequence of letters, the player has to arrange them into a palindrome, for example: abba, radar, kayak.
Rotatag – match pictures with tags: Various photo hosting services, like Flickr or Instagram, offers users to (#) tag pictures with descriptive words. Those services also offer public programming interfaces (APIs) and a game could use them to pick a few random pictures each time to spread around the player, then pick a tag from one of the pictures to place in a fixed position on the screen. The player is then to guess from which picture the tag came from by tapping on it.
Match a picture to a written word: Around the player, on the walls of the cylinder, are visual representations of various objects and beings, such as a chair or a duck. A word appears on the screen in a fixed position and the player is to tap on the visual that matches that word. So if the word “horse” appears, then a player must spin around until he sees a picture of a horse and tap it, with a resulting encouragement in the form of a cheering sound or some in game value, such as a trophy.This type of a game could be suitable for young children learning to read or those learning a new language.
Tap a graphic matching with the sound you just heard: Five visuals are spread around the player and at regular intervals, one of five matching sounds is played and the player must in time rotate to the matching graphic and tap it. So for example, if the player hears a goat screaming, she must rotate to the position where the drawing of a goat is located and tap it in time. Progressing levels decrease the required response time and the goal is to stay playing as long as possible without an error or too long a response time.This type of game is inspired by the audio game Bop It, originally implemented in specialized hardware (which this author has tried) and is now apparently available in an iOS version and a clone is available for Android. But those touch-device implementations don’t require full body movement, like the game proposed here does, though from their description they do seem to require some device movement by recognising hand gestures (possibly using Dynamic Time Warping (DTW) and Hidden Markov Models, which were considered for the implementation for rotatengine.js but deemed not a good fit, as they seem best for sensing spontaneous, short lived movements but the engine discussed here requires continuous monitoring of movement and position – more on that below).
Visual rendering and interaction
At the current stage of implementation, focus has been on the part that handles rendering of elements in the desired manner and the interaction with those rendered elements by the player’s circular movements.
Choice of technology
The game world provided by rotatengine.js must in some ways give a three dimensional illusion, where the player is to sense that he is the pivot around which game elements rotate as he spins in circles. Modern desktop browsers provide the WebGL 3D graphics programming interface (API), which uses the HTML5 canvas element and provides code execution on a computer’s Graphics Processing Unit (GPU). That could be an obvious choice for an engine that manages content in 3D. Mobile devices have lacked support for WebGL, though the most recent versions of web views on some platforms are now supporting it, with iOS being a notable exception. So to reach the widest range of mobile devices, it is worthwhile to consider other options for 3D content rendition.
The CSS3 specification includes a module that defines 3D transforms that “allows elements styled with CSS to be transformed in two-dimensional or three-dimensional space” and CSS3 3D Transforms are supported on most of the recent mobile platforms. Given that wide support and the simplicity of arranging various types of HTML elements – letters and images, as in the game ideas listed above – with the same set of CSS rules, it seems to be a good choice to base the visual implementation of rotatengine.js on CSS3 3D transforms.
Interactive animation mechanics
A couple of approaches have been considered to manage the objects in the game world as the player interacts with it.
The first one considered is inspired by the Cover Flow graphical user interface, where off-screen game objects would wait in line, decoupled from the animation mechanism, until next on screen Then they would be coupled with the animation and flow across the screen, until decoupled again at the other end. The objects would be incrementally skewed to either side and translated in distance from the viewer, as they flow across the screen to simulate a cylindrical / circular 3D effect. This approach could have the benefit of allowing virtually infinitely many game objects, that would wait in the off screen queues for the player to pass by them while he rotates, and then more than one full circle could be required to display all objects.
Another approach is to arrange the elements on a circle using the trigonometric functions sine and cosine. This is the method currently implemented, where each item is assigned an amount of radians by dividing the amount of radians in a full circle (2 * π) by the number of game elements. Then the x and - z coordinates are calculated for each element by applying cosine and - sine , respectively, to it’s radian value multiplied by the integer value of it’s sequential order. The coordinates are multiplied by a radius which itself is a scaling of the view’s width. So now the elements are spread evenly around a circle that is roughly double the width of the scene. Each item is rotated individually by it’s radian value minus π / 2 to have it facing inside the circle. The radius value is added to each z coordinate to have the viewer inside the circle, close to it’s perimeter. A simplified version of the relevant code is as follows:
var perspective = viewWidth / 2;
var radius = viewWidth * 1.2;
// let's go clockwise, thus fullCircleRadins - ...
var thisItemRadians =
fullCircleRadians - (self.radiansPerItem * i) + viewRotation;
var x = Math.cos(thisItemRadians) * radius;
var z = - Math.sin(thisItemRadians) * radius;
var transform =
"perspective("+ (perspective) +") " +
"translateZ("+(z + radius)+"px) " +
"translateX("+(x)+"px) " +
"rotateY("+(thisItemRadians - (Math.PI/2))+"rad)";
Initial testing of this game element rendition was performed in a desktop browser, where interaction input was read from mouse movement and keyboard button presses. One animation anomaly that became apparent during this testing was that if CSS3 transition-duration was set to high and fast movements were made, the elements would spin around themselves and take a shorter path to their new destination, over the circle’s area, instead of animating smoothly along its perimeter. Setting the duration speed to 0.1 seconds solved this for most animation speeds, and zero seconds also but then sacrificing a little in animation smoothness.
When most flaws had been ironed out and the elements were animating in the intended manner in a desktop browser with mouse interaction, it was time to proceed to testing on mobile devices with input from their sensors.
Differences between sensors and platforms
Mobile devices commonly offer three types of sensors that provide information on their orientation – magnetometer (compass), accelerometer and gyroscope – and together those sensors can be referred to as an Inertial Measurement Unit (IMU). Of these, the compass is a straightforward choice for input to the rotatengine.js game world, as it provides information on the device’s heading in degrees.
Magnetometers on mobile devices can be inaccurate when used indoors, due to interference from the building. That would not be problematic for rotatengine.js as it does not need an accurate measurement of heading, but rather a responsive and mostly stable and consistent reading of where the device is pointed.
Apache Cordova, the open source engine behind PhoneGap, was used to package rotatengine.js into applications to be run on the Android and iOS mobile platforms. NetBeans with it’s recent Cordova support was used to manage that process.
A sample application of rotatengine.js running on Android and iOS, receiving periodic heading input via the Cordova API, performed correctly but not with the desired responsiveness; when moving around in circles holding the device with hands stretched out, the updates of the game world objects were quite slow and somewhat jittery and equally so on both Android (Nexus 4) and iOS (iPad 2) devices. See video recordings of tests:
Though Cordova’s API offers the option to specify the update frequency from the compass, further debugging showed that updates were in fact being delivered around every 200 milliseconds, even though a 50 ms update interval was requested. This seems to be a hardware limitation on both platforms tested and a 200 ms interval is unacceptably long for a smooth animation and responsive updates.
A simple attempt was made to extrapolate future changes in rotation with shorter intervals, from the previous update interval, until the next update would be received from the compass. Those future changes are calculated by dividing the delta of the previous two compass updates by four, and the scene is rotated by that fraction every 50 milliseconds. Those intermediate updates from extrapolated values did not result in much improvement when run on a device, and as expected, an initial halt of animation is visible when rotation is started or direction is changed and two compass readings are being collected (with their 200 ms interval) for further extrapolation. See video recording of test:
Gyroscopes have recently become available as sensors in mobile phones, first in the iPhone4 and then in various Android devices. That kind of a sensor gives information on orientation changes, so it was the next option as input to rotatengine.js. Here, Cordova’s API was bypassed as HTML5 provides direct access to updates from the gyroscope (via callback function attached to window.ondeviceorientation). The device’s heading is read from one of three values returned from the sensor (alpha) to which the scene is rotated.
The gyroscope on the iOS devices tested, iPhone 4s and iPad 2, proved to be quite stable and it’s raw data readings provided smooth updates of the game objects, even without any CSS3 transition-duration and it’s smoothing effect of animation easing. See test video recording:
The same can not be said about the results from the Android device tested (Nexus 4), where orientation updates were very jittery and unstable, even when the device was being held still, the game objects would jump around constantly. See test video recording:
Using the gyroscope with the current implementation would be adequate for targeting iOS devices, but if the aim is for a more cross platform solution, then the raw data from the sensors needs to be handled in some manner that both provides stability and responsiveness. One approach considered was to implement a basic low pass filter on the data returned from the sensors, but having something to filter requires first the accumulation of sensor data to then apply the filter on, and that results in an initial delay and a lack of responsiveness.
A viable approach for the use of sensors to update game object positions in a responsive and stable manner, on multiple platforms, could be to fuse the information from multiple sensors and apply advanced filtering on the data with statistical estimates of the real heading. The gyroscope and accelerometer can be combined to form a 6-axis inertial sensor (roll, pitch, yaw and vertical, lateral, longitudinal acceleration). Two prominent methods for integrating gyro and accelerometer readings are the Kalman filter and the Complementary filter, the latter is easier to understand and implement and is said to give similar results. Also, the lighter implementation of the Complementary filter would require less processing power, and that is an important consideration for the battery consumption on mobile devices.
The next step in developing the rotational interaction with game elements in rotatengine.js would be to apply this fusion of the gyroscope and accelerometer with either the Kalman or Complementary filter. The Complementary filter’s simplicity makes it a tempting first choice.
Further development of rotatengine.js includes reacting to interaction with game elements by touch, where events would be fired that a game implementation can register for and different element behaviours could be defined for those events, like animating to a different place or disappearing.
Also, the game world could be rendered in a spherical fashion, in addition to the cylindrical one, where navigation of game elements would be done by tilting the device up- and downwards, along with the basic circular motion. Options for this kind of spherical world could include the definition of how many layers of spheres surround the player and whether the spheres are shrinking towards the player, to allow for a more dynamic and engaging environment.
In the first phase of the implementation discussed here, attention to code structure for the project has been minimal and has at most consisted of encapsulating functionality in object literals and function closures. For further development, the module pattern has been considered as a way to organise the code. For inter-module communication the mediator pattern is a choice.
The module pattern fits well into the Entity component system (ECS) design pattern, which favors composition over inheritance. When designing a game engine that may handle entities that have many different variations, an object-oriented approach may lead to “deep unnatural object hierarchies with lots of overridden methods”. A game engine based on the ECS pattern, however, “provides the ultimate flexibility in game design” where you “mix and match the pre-built functionality (components) to suit your needs”.
With rotatengine.js based on the ECS pattern, a game using it can define behaviour and functionality by referencing different modules, for example specifying how game objects respond when a player taps on them. Work on the filtered sensor fusion described above should continue within a separate module that can, when implemented, be swapped with the direct, unfiltered single-sensor reading implementation currently in use.
Data schema and automatic content generation interfaces
Each level instance in rotatengine.js contains game objects created from data defined in a JSON configuration file. For now, the definition of how the data is structured is arbitrary, to have something running as quickly as possible. But when the engine should be ready for use by a party not involved in it’s development, some means is needed to communicate the required structure of the configuration files.
To define the structure of configuration files for rotatengine.js, the JSON Schema specification has been considered. To ease the creation of a schema definition, there can be found tools based on that specification, to generate a definition from an example data file.
Declaring data files, based on the schema, could be done manually by reading the schema and carefully adhering to it in a text editor. A specialised user interface for entering the level data according to the schema could help a level designer get up to speed. User interfaces can be automatically generated from a schema definition and the Metawidget object/user interface mapping tool could be a helpful choice in that regard, with it’s JSON Schema UI Generator. With that tool, the engine could include simple webpages, that allow data entry resulting in a JSON string conforming to the given JSON Schema, which could then be saved to a configuration file ready for use.
rotatengine.js is a specialised engine designed for limited game mechanics, where the player is to spin around in circles and interact with game objects as they rotate around him. But within that limitation, it is possible to conceive diverse types of games, as the examples above show. The engine will hopefully lead to a unique variety of play and games.
As of this writing, the runnable code can be initiated by opening the index.html file in the project’s root, or by compiling it into a mobile application with Apache Cordova or Adobe PhoneGap. As mentioned previously, work has started on modularizing that same code in the js/rotatengine directory, but it is currently not in a runnable state.
The project can be found on the attached optical disk and online at:
 „The Kalman filter, also known as linear quadratic estimation (LQE), is an algorithm that uses a series of measurements observed over time, containing noise (random variations) and other inaccuracies, and produces estimates of unknown variables that tend to be more precise than those based on a single measurement alone.“ http://en.wikipedia.org/wiki/Kalman_filter
„In my opinion the complementary filter can substitue the Kalaman filter. It is more easy, more fast. The Kalman filter is the best filter, also from the theorical point of view, but the its complexity is too much….“ – http://letsmakerobots.com/node/29121
 An interesting practical application of the Kalman filter is the Android app Steady compass, which has the description that “sensor data is treated by a Kalman filter in order to obtain superior stability in readings”:
At the top of plafgine.js are a few configuration variables to define the level, which could be factored into another file:
defaultPlayerPosition: Defines the size of the main player and where it is positioned initially.
enemyPositions: Positions for the enemies and their sizes.
platformDefinitions: Placement of the platforms.
There are no real physics in this platformer and it rather implements pseudo-physics by starting a jump at a fixed speed and then decreasing it on each game loop, until the jump speed reaches zero, then a fall speed is incremented until collision with a platform or the ground happens. Those are the jump, checkJump, checkFall, fallStop functions within the player object.
Different instances of the same implementation of the Player object are used for both the main player and the enemies (NPC), with their configurations differing in setting whether they are automated and then with the added behaviour-function mentioned above. Some sort of class inheritance could have been a good idea here.
The collision detection is as inefficient as can be where player collisions are checked against all platforms and all other players on each game loop. Spatial segmentation of what to check against would of course be better for any reasonably sized level.
Control of the main character is handled by registering pressed keys into a state variable and then reading those states on each game loop (in the player implementation) and moving the character accordingly.
Camera movement is implemented by keeping the main character still and moving all other game world objects in the opposite direction when the character has reached a certain threshold on the screen. That threshold is in fact centered on the screen so the character is pretty much always in the horizontal center. There are glitches in the implementation of this camera movement that can almost always be reproduced when jumping from the highest platform; then the player doesn’t fall completely to the ground, but that can be fixed by jumping again! – the cause of this should be investigated in another iteration.
Timing is used to determine when to update player sprites based on their activity; when a predefined amount of time has elapsed the portion of the sprite to render is updated.
Same goes for the lives bookkeeping, only when a set interval has elapsed can the count of lives be decreased, so all lives don’t disappear instantly when multiple characters collisions are fired. So if the main character hits an enemy he loses one life and loses one again if he keeps hitting an enemy when the set interval has elapsed. Unless the main player hits the enemy from the top – jumps on top of him – then the enemy gets killed.
Then the GameLoop function / class calls itself repeatedly via setTimeout until all lives have been lost – then GameOver is called – and in each round it updates player positions, either from input or automation, checks collisions, checks if to update any pseudo-physics and then draws all players and platforms.
The game seems to run smoother in WebKit based browsers like Chrome or Safari, rather than Firefox for example.
Implementing the 3d wireframe renderer was pretty much straightforward after reading through the given overview of the 3d transform process for the second time and realizing that what’s needed is basically computing three matrixes, multiplying them together and using the resulting matrix to multiply with each vertex as a column vector, as shown in the given pseudocode.
The implementation consists of a HTML5 file, index.html, that includes jQuery Mobile for easy inclusion of a few UI widgets and then there is the wire frame rendering code in 3dWireframeRenderer.js
The function getCameraLoacationTransformMatrix implements what’s described in section 3.1.1 of the overview, Setting the camera location,
function getCameraLookTransformMatrix returns the matrix described in section 3.1.2, Pointing and orienting the camera,
and the projection matrix from section 3.2 comes from the function getPerspectiveTransformMatrix
The test meshes are in meshdata.js and I got them from http://threejs.org/editor/ and it’s export function. One of the biggest difficulties was deciphering the faces array in the JSON export from there but then I found some documentation on where the vertex indexes are located and the function getTriangleFaces does the job of extracting the vertices for each face.
When I had the function renderWireframe (basically like the given pseudocode) drawing vertices (I have them cover four pixels for clarity) and connecting them with lines, I had some difficulty finding a good combination of near and far values and camera Z position. Adding sliders for those values in the UI helped, but, near clipping happens quite far away from the camera as it seems – I haven’t found a combination of near, far and camera Z position that allow the object to come near the camera without clipping, except, if I reverse the near and far values, for example set near to -300 and far to -10, and the camera Z position to 150, then the object (cube) renders happily close to the camera; is that a feature of the transformation matrixes or a bug in my implementation? I don’t know…
The camera movement could be connected to the arrow / wasd keys and mouse but to see clearly the interplay between camera XYZ and the near and far planes is of most interest here so I’ll let those sliders do.
I tried getting the width and height from given FoV, near plane position and aspect ratio, as discussed in the overview and that didn’t play well with my UI so I abandoned that, but what I tried can be seen in the function getWidthAndHeightFromFOV.
For this project I started by reading an article on the web titled A* Pathfinding for Beginners for a text on how the algorithm proceeds but then I based the implementation pretty much verbosely on the pseudocode in the Wikipedia entry for the A* algorithm, along with supporting functions.
The implementation can be run by opening the index.html file in a recent browser (I’ve tried Chrome and Firefox) and pressing the Start button. The chasing agent is represented by the letter C and the goal or target is represented by T.
When the target is moving the run can end without the target being reached when the open set becomes empty (line 145 in pathfinding.js), but the run can also end where the target has been reached. It could be worth looking at the D* algorithm for this case.
The target moves randomly one step at a time horizontally, vertically or diagonally, except when it’s the next neighbor to the chasing agent (C), then it tries to choose a move that results in it not being the chaser’s next neighbor, which is not always possible (when the target is on the grid’s perimeter – see the last condition in the do…while loop at line 198). It’s possible to have the target fixed in it’s starting position by unchecking the checkbox (Target (T) wanders and tries to avoid) in the interface.