In our game, the player takes control of a farm. This farm is displayed and interacted with in an AR environment. The player can cultivate a variety of different crops and place a number of buildings to help him/her doing so.
The crops can be bought (and sold) to the in-game store for in-game currency. The buildings, on the other hand, have to be acquired from scannable cards. These cards will contain a one-use redeemable QR code that, once scanned, adds the items to the player’s inventory.
These cards can also contain a number of cosmetic items. These items don’t give off an in-game bonus but can be used to customize and stylize the player’s farm.
There is no clear goal to our game, as it can be interpreted in a few ways. For example:
- A player could choose to invest a lot of time and resources on the visual appearance of their farm without engaging much with the other progression in the game. This could be interesting for players wanting to show-off their farms to others for example.
- A player could also choose to focus solely on efficiency. This would mean cultivating the crops that give the biggest reward for the (relatively) lowest resources spent. This type of gameplay could be interesting for players that enjoy creating an efficient farming “solution”.
Designing an AR farm game for the children of supermarket consumers that encourages the players to use and collect cards that add significant value to the game.
Risk assessment matrix
|Little to no effect||Effects are felt||Serious impact||Could result|
|on event||but not critical to||to course of||in disaster|
|Risk is unlikely to||-1-||-4-||-6-||-10-|
|Risk will likely||-1-||-5-||-8-||-11-|
|Risk will occur||-3-||-7-||-9-||-11-|
|There is not enough project time to finish the requirements.||Low||Acceptable||1||Document all processes so that the next group can take over the project.|
|During the sprint there is a necessity for an extra task or user story.||Low||Acceptable||1||add the new task or user story to the backlog|
|Group members don’t follow the coding principles||Low||Acceptable||1||Refactor the codes that don’t follow the coding principles|
|The database goes offline. That causes the game to stop working correctly.||Low||Tolerable||4||Give a message in-game and disable all in-game options that use the database until fixed.|
|A mobile software update makes the game stop working||Low||Tolerable||4||Implement the new software requirements for the game to work on the newer versions.|
|The project documents are made incomplete and lack value||Low||Tolerable||4||Group members review documents made by others. These documents will then be improved with provided feedback.|
|With the current AR technology, we can’t make some requirements||Medium||Tolerable||5||Do research to AR technology. If no solution is found then discuss further with the project owner.|
|A user story takes way longer than the time that was agreed upon||Medium||Tolerable||5||The team will reevaluate what has the most priority and will adjust prioritization where this is needed|
|The database crashes and the data is lost.||Low||Intolerable||10||Replace the database with a recent back-up|
|A group member quits during the project.||Low||Undesirable||6||Lower the requirements for the project, in agreement with both the project and the product owner.|
|A group member gets sick for a long time||Low||Undesirable||6||Lower the requirements for the project in agreement with both the project and the product owner.|
|When the UX test makes it clear that the game is not fun to play for the target audience||Low||Undesirable||6||Discuss with the project owner to see if changes can be made|
|The player encounters a bug in the game whilst playing.||Medium||Undesirable||8||Have a bug report option/system in place where the player can notify the developers about the discovered the bug|
|The goal of the sprint could not be realized||Medium||Undesirable||8||This is discussed with the product owner and together is decided what the next course of action is|
|When building the game we find out the structure is wrong||Low||Intolerable||10||Change the structure if possible, otherwise change some requirements|
|Communication between team members deteriorates which results in double work or forgotten user stories||Low||Intolerable||10||Make sure that members use scrum tools accurately so that everyone has a clear overview of what is happening. Also, call for a team meeting and discuss the current situation and how to best proceed.|
|A member of the group pushes to the wrong branch which results in the project not functioning||Medium||Intolerable||11||Revert the push to a working version|
Entity Relation Diagram
The IPlaceable interface indicates whether the class that does inherent IPlaceable can be placed on a tile. In the above ERD, it can be seen that IBuilding, Field and Build make use of the IPlacable interface.
Map en Tile
The fARm game uses a map. This map is divided into several tiles where the player can put placeable objects. For example, the player has the option to place a crop field on an empty tile By subdividing the map into tiles it’s possible to indicate exactly what could be placed and where.
All the items that can be used in fARm can be found in the static ItemList class. Items that can be found in the class are buildings, crops, and cosmetics. The static class is used by: – –
- Shop: Various items are sold here that have a reference in ItemList.
- Inventory: The inventory also uses the ItemList. All items that the players have acquired can be found in the inventory.
The BaseSO has a behavior gameobject and a name. The BaseSO will be given to the Placeable which will place the gameobject stored in the SO with the information from the SO.
Analysis and advice
The research was done using the DOT framework. These documents were also reviewed by the product owner.
At the start of the project, we held multiple brainstorming sessions. These sessions helped us in coming up with the general concept. To validate this concept we will user test this with children that are part of our target audience.
The deliverables from our project are:
- Project document
- Target audience research
- AR research
- QR code scanning
- Game prototype
The research was validated by the product owner. Every week there was a meeting with the product owner where the progress of the project is discussed. Besides the scrum board, we also used communication tools like Discord and Whatsapp.
We will use user tests to validate our product. These will be held with members of our target audience. After deciding on a concept, an ERD was made to show the general structure of the game. These points have all been discussed with the product owner.