The DB is still being finessed because the structure is very complex however to get the general flow of the application going on the front end I am employing the use of dummy data.<\/p>\n
I will be disabling the “signup” form and only have the login link included in the main nav. Part of the DB finessing powers a lot of the user sign up such as avatar creation and story selection.<\/p>\n
Though for quick demonstration purposes the registered user path will be used. The maps will just be squares with defined spots for interaction. As stated before is that we are using “dummy” data for the application.<\/p>\n
On the flip side I am working on the twitter app that will be consuming the direct messages to trollmeastory on twitter and parse them out to actual events. There will be a limit of three events per day per user and luckily Twitter tattles on whom did the direct message. After their third event the application will ignore those subsequent requests with the corresponding date.<\/p>\n
But first thing first here is what is being coded (creative is pending):<\/p>\n
In the works–<\/strong><\/p>\n Pending—<\/strong><\/p>\n *Requires Creative and Database.<\/p>\n \u2020Placement of attributes need to be coded and recorded. DB needs to be updated to reflect the treatment such as location (up, down, out, in, left and right) and size.<\/p>\n I plan on doing small feature releases. As I get each section built then I will release it. So for the signup form the most important thing is to get the basic information recorded. The player can always update\/create their avatar from the profile screen. The same will go for the story.<\/p>\n So yeah\u00a0first sprint:<\/p>\n Second Sprint:<\/p>\n Third Sprint:<\/p>\n The DB is still being finessed because the structure is very complex however to get the general flow of the application going on the front end I am employing the use of dummy data. I will be disabling the “signup”…<\/p>\n\n
\n
\n
\n
\n