Home

Links

Before starting this project I hadn’t developed for anything other than a PC. This resulted in a bit of a learning curve as I came to grips with how android worked and attempted to both learn the android API and give myself a bit of a refresher on working with java, after previously experimenting with both Flash and C++ on android. This has presented me with a great many challenges along the way from experience, art and coding all throwing up hurdles at different stages.

The result of working with a new platform has been the some of my work-flows haven’t been as solid and stable as I perhaps would have liked and I’ve had to adapt as problems have surfaced. The biggest of these being the performance degeneration as extra assets were added to the game, despite place holders being used during the coding phase to try and avoid that situation. The end result is a massive learning experience that has been a blast to make and is playable, albeit with the occasional bug.

One of the most important parts of developing any work which relies heavily on user interaction or participation is getting feedback from people likely to use your work. So over the past few days I’ve been harassing people to try out the prototype of my game to see what they thought and how it could be improved.

The main feedback that I got was to about providing user feedback, specifically to relay things like combat outcomes or geyser locations. Currently these feature don’t provide much feedback.
The result of combat for example is communicated by either allowing the player to build on the previously occupied space or returning them to the map screen if they lose.

When AWorld was originally pitched it was designed as a physical computing project with a slightly different play style. While there were significant changes to the approach taken to developing this project to what would of otherwise been followed a large number of the elements were bough over. One element however that has not made it into the beta game is the QR code method of resource gathering. In the project proposal players would have an alternate way of collecting waves by scanning specially placed posters displaying QR codes. In the end scope of the project meant that a lost of feature had to be cut or reduced and this was one of them. However its not completely gone the idea of having to locate a poster in a specific location bleed into the geyser locator that is currently in game and guides players to locations rich in waves, much like the QR posters would have been.

For the beta version of the game I’ve decided to re design and texture all of the buildings to try and make them match the aesthetic that’s been set out with the buttons and tiles. The number of buildings has also been reduced to help simplify game play and consolidate the number of features required for the beta.The four building that will be usable in the beta are:
The home base.

This building provides some starting resource and is the first building players must build when initially starting the game. It also provides enhanced defensive capabilities to allow new players time to gain resources and establish a base without fear of losing there starting cell.

As a little treat for study break Doug gave us the task to write a little summary about one of the works show in lecture throughout the class.
The work I chose to write about is something that was discussed during the lecture rather than being the focal point so I went a did a little more research to fully understand the project.

The project is by Natalie Jeremijenko and is part of her series of works that are all outputs for her “environmental health clinic”.
The environmental health clinic was spawned from the realisation that many of today’s most common health problems come from the environment. It focus on providing solutions that take a proactive approach and raise awareness about environmental health issues. The project consists of many installations and works that promote activities such as filtering street run off  water or encouraging more wildlife to return to cities as we increase the number of green spaces through out our urban living environments.

My favorite of these projects was a communication tool for birds. It consisted of a series of perches that birds could land on. When they did this would trigger a sound file to play requesting food for the birds using different tactics such as encouraging sharing or treating bird flu. Birds could experiment with the perches to see which sound-clip was most likely to get people to give up there lunch.

For more information on this and other projects go here.

The other projects in the health clinic series that focus on reducing co2 from the air or improving air quality in buildings through rooftop gardens are also really interesting and worthwhile projects.

One of the most important parts of developing any work which relies heavily on user interaction or participation is getting feedback from people likely to use your work. So over the past few days I’ve been harassing people to try out the prototype of my game to see what they thought and how it could be improved.

The main feedback that I got was to about providing user feedback, specifically to relay things like combat outcomes or geyser locations. Currently these feature don’t provide much feedback.
The result of combat for example is communicated by either allowing the player to build on the previously occupied space or returning them to the map screen if they lose.

One of the goals that was built into the design of this game was the multilayer aspects which, along with navigation ended up being one of the harder elements to get working correctly. This was largely due to the multitude of different aspects that had to all work together. In the case of networking the initial system worked by sending requests over http to a php script that would then query or update an online database. This simple solution worked ok but was very prone to network latency an created syncing issues.

The solution I chose to implement was to create a caching system using androids own database system SQLite. This allows for syncing of the local and online databases to remain consistent without being prone to network problems. It also allows the system to correctly sync with one-another when players reconnect after periods of network absence.

The tiles in the game provide the building blocks for establishing bases and expanding out into conflict therefore its important that they have the right look and feel to them. The previous version of the tiles had a lot more of a simple vector stile where as the new ones attempt to bring in a new level of detail.

The new terrain tiles also provide information about there ownership status through there exterior ring status. Yellow rings are cells owned by the player, Red are cells owned by other hostile players and brown are cells that have yet to be claimed.

Putting the code aside until after the alpha now so that I can focus on getting the look and feel of the game up to speed and presentable. The main focus of this will be to design most of the screen elements to a level which is consistent and cohesive across all of the assets that can then be used to pitch the game in situations there a live play might not be possible.

To that end the first thing Ive made are a selection of the buttons for the game that will be used on the majority of the screens and provide the primary form of interaction. “Yay buttons”

A key mechanic in my game is the ability to claim new tiles and expand. It is the driving mechanic that provides for the vast majority of both offensive as well as defensive interactions as well as providing some of the key goals for players.

This new feature allows the user to claim tile near by there existing base and thus expand there empire out into the great unknown .