Inspiration
The massive social craze associated with PokemonGo created large-scale forms of minor community involvement. Particularly near cities, people could be seen conversing around parks and businesses consistently as a part of the experience. While that insanity ended up calming down over time, it maintains a strong and consistent fanbase across the world.
Much earlier, an app called Foursquare introduced a relatively mainstream basis for a business check-in system. Providing an outlet for consumers to find locations to visit around them, while advertising companies directly. This system was mostly applied for use with reviews and data collection, but has a wide variety of potential applications that haven't been fully realized.
The concept for integrating these two ideas as a single general entity provides an incredible opportunity for community engagement and economic stimulation - particularly for local entities and smaller businesses.
What it's supposed to do
This system takes the precedent set by those two existing models and combines them to form an engaging way for consumers to become active within their communities. Applying a geo-location based game system to a business check-in model provides opportunities for extended benefits for consumers, businesses, and their overall neighborhoods.
Users develop accounts and traverse the world in an Augmented Reality mindset. Provided with the local options around them, they can access mini-games by interacting with the codes and information inside those locations. These games are themed based on the fundamental aspects of those companies, but are also smaller factors in the bigger picture of the game system.
On top of these mini-games, the interactions accumulate points for the users over time. One set of points is for leaderboards and customization, while the other acts as a more consistent virtual currency that can be applied toward businesses. That virtual currency is used for purchasing partnered discounts for use at those same companies within those neighborhoods. This provides additional incentive to act within the game, but also engage with the locations around the users - as it provides direct positive impact for their existing transactions.
The businesses are required to opt-in to the program and decide their representation within the game system based on a template regarding their specific needs or desires. By opting in, they are added within the game and provided advertising as well as potential foot traffic within their locations. By providing potential customer acquisition, these businesses are financially incentivized to take advantage of the opportunity.
At the same time, there is a general community-based integration. By focusing on localized business areas, cities and towns can be divided into districts. These districts can provide incentive for remaining active with the companies inside them, as well as provide a competitive system with other districts in order to bring these communities together. This can also be scaled based on the overall system of the location. While University City may act as unique district from West Philly, the entire city acts as its own community overall. The concept is designed to integrate citizens with their environments, as well as financially boost the overall standing of smaller businesses within their economy.
How we built it
Due to relatively low development experience, our team created a general proof of concept with a simplistic java-based model as opposed to a more robust application. Using a concept map of the interacting systems, the code was divided into separate and specific classes designed to work in response to each other's variables. In the current state, the program is almost exclusively run through an active Game Manager. Taking in the information from the User and Business classes, it runs the infrastructure of the point system. By extension, the User class also uses Location and Action classes for interactions inside the Manager. With the accumulation of information within this system, the Game Manager also runs the Community class - acting as a greater extension of the system.
The User class keeps track of experience points, virtual currency points, location, and name. The Business class keeps track of name, location, and the point value awarded. Location manages the latitude and longitude information, and Actions provides possible User options dependent on certain inputs. The Game Manager references the variable data from the Users and Businesses, and then connects it with information from the related correspondence between Location and Actions. In this, it awards the respective value of points for each User based on the amalgamation of the information form the system. On top of this, the Manager also collects and awards the corresponding points and activity to the Community class. This pairs Users and Businesses with teams based on their districts and pools their points and activity accordingly through the Manager. However, the entirety of Philadelphia is interpreted as a full community, with the neighborhoods existing as sub-categories.
On top of this model, we've also developed a visual representation of a more proper system to better present the concept in a closer-to-finalized format. This representation demonstrates the general UI in place for the application, as well as working models of ideas not existing within the program. These include more active actions, lists of locations corresponding to an adapting map model, presentations of established business information, and more. The design is intended to act as modern and relatively sleek, taking advantage of working UI for mapping apps as well as influences from Foursquare.
WIP
Challenges we ran into
Considering our collective lack of high-level programming knowledge, much of the advanced process came with extensive struggles. Designing and mapping the interaction of the existing systems worked quite well, but applying that information into a working code set was far more difficult. Initially, we'd hoped to put together a working but simplified phone application, but found our low expertise on that form of programming a high barrier to entry. It took a significant portion of time simply to determine the proper language to utilize, and applying our systems became more and more complex as time progressed - leading to us scaling back our demonstration dramatically.
The Game Manager system is also a fairly incorrect model of the infrastructure that would actually be in place. As of right now, it works purely on memory using RAM, but the actual application would work on too large a scale for this to be effective. The proper model would be applied through use of servers and through a slightly different means of code, but this was the best model we understood to represent our system and prove our concept. This is relatively true for the simplification of all our classes and models.
Accomplishments that we're proud of
WIP
What we learned
WIP
What's next for Business Gamification
WIP
Log in or sign up for Devpost to join the conversation.