This week in EDTECH534 I completed the Map Tour tutorial using my favorite day trip location, Salem, Massachusetts. The tutorial was pretty simple this week so I took it as an opportunity to explore using multiple screens in my app. In the last few weeks I thought about adding a game-over screen a couple of times but haven’t been brave enough to really try it (plus I was thinking a tutorial would present this to me eventually). The very first part of the tutorial, using the Activity Starter, did not work for me at all. I suspected it was due to the properties entered. Since I’ve worked on Java apps before, the paths LOOKED ok to me but in this context, I had no idea. This forced me to use the Web Viewer and pray it worked. Thankfully, it did. In the process, since I still had to use Activity Starter, I found that all I really needed was the Action and URI properties.
When the user clicks on the “Choose Your Destination” ListPicker on the first screen (Screen1), they are presented with a pre-defined list of landmarks. The user then selects the landmark they want to explore. The app then opens a new screen (Screen2) with 2 Web Viewers on it, one for the landmark web site and one for the landmark Google map. Now, I have a Samsung Galaxy s6edge+ so my screen real-estate is ample and I still felt a little cramped at this point so I added “pop-out” buttons that open each option in their respective apps. I found in my testing that the device back button kicked me out of the app altogether so I also added an in-app back button (come to find out, it kicked me out because I was using the Companion app, the device back works just fine in the finished app).
This week in EDTECH534, we continued learning about AppInventor’s abilities by building the “Ladybug Chase” tutorial. In the process of extending my app, my name and theme changed to Cheesy Chase. I ended up doing all the extensions the tutorial suggested including: adding better graphics &/or theme, stopping all movement when gameplay ends (although I left the little wiggle from the cheese and cat because I though it was cute), increasing the energy bar visibility (I had done this before I realized it was an extension, it just seemed necessary) , increased difficulty by increasing the cat speed over time, added a timer label letting the user know how long they made it, and removing the mouse if he’s eaten by the cat. I also added a game over indicator since it didn’t seem immediately obvious that the game was over.
As usual, I enjoyed creating this app and am looking forward to what we create next. I must say I am getting nervous to not have tutorials to rely on soon as the final project gets closer. While I know I’m creative, I don’t always have big ideas without inspiration.
This week in EDTECH564 we started to build mobile apps using AppInventor. Since I am taking EDTECH534 at the same time and have been using the tool for a few weeks now, I completed this alternate assignment “Ball Bounce” instead of repeating Hello Purr. The original tutorial has a ball on screen that you fling with your finger to bounce off the walls. I extended the app with a colorful background, purposefully overly colorful to try and add some difficulty to the game. I also added a good guy and a bad guy. If you fling the ball into a good guy, you add to the score and the bad guy takes from your score. Additionally, in order to increase difficulty with game play, I increase the speed of the ball with every bounce off a wall. There are also buttons to stop the ball while keeping game play alive and reset the game. The “Score” and ” Speed” labels allow you to keep track of your game play on the fly.
This week in EDTECH534 we created an app that auto-responds text messages while the app is open. I got off to a quick start on the app after feeling so successful last week. I worked the tutorial as it was written. The tutorials are getting a little more difficult as it expects you to build on skills from previous weeks. After I figured out the new format, I was able to get all the parts to work. I was surprised at the functionality available to me via AppInventor. With the app open, and a text comes in, the app reads the senders phone number and the text. Then it sends a response text back letting the sender know whatever the user has programmed. Finally, the app also appends the users location to the auto-response. For my extension, I added some pre-canned responses as well as the ability for the user to turn off the location functionality. I also played around with some more layout do-dads.
This week in EDTECH 564 we took a look at mobile games and their place in the classroom. I ended up evaluating Brain It On! and I Love Hue as educational games. Both of these games provided challenging puzzles that were quickly addictive. For games on the non-educational variety, I evaluated Bejewled Blitz! and Dots. Like the educational games, these games were addictive and are the puzzle variety. One of my peers had mentioned our class discussion my tendency to see puzzle games more educational. While I obviously would agree based on this weeks assignment but upon reflection, I would say this is true mostly for mobile games. I feel like the digital divide is still wide enough to not be able to effectively and reliably use mobile apps in the classroom. Now, I understand there are places where schools have devices, or have great wifi, or perhaps have students who all have current devices, but at my school, we’re not there yet. Therefore, using any mobile app, educational or not, is very difficult. That said, if I lived in an area where using mobile apps in the classroom was realistic, I’m not sure I would use them for anything more than time filler for several reasons. Most importantly, unless the app is trackable, how would I assess how students do with the app? Assuming that wasn’t an issues, wouldn’t it be neat to be able to analyze these games as a class. I would love Brain It On! in my Video Game Design course when discussing physics in video games. I feel like the physics in the game were spot on and it really challenges the user to use physics to their advantage.
This week we created a whack-a-mole type game. The Mole Mash tutorial we completed introduced us to the ImageSprite, Canvas, Clock , and Sound components. We created Procedures to implement repeated behavior, such as moving the mole & bee and practiced using Math blocks. I really enjoyed working through this tutorial and am feeling more and more comfortable in the AppInventor environment. I’ve found myself wanting to explore just a bit farther each week and sometimes have to hold myself back. Not a bad problem to have 😉
For my customizations, I enhanced the imagery and tried to use good layout design practice by organizing data and function logically. I added a slider to control the speed of the mole and a label to let the user know what speed they were playing at. I also had to work the speed into the reset button.
This week we were tasked with evaluating the popular augmented reality game Pokemon Go using Shute & Ke’s “seven core elements of well-designed games” as the criteria. There is no doubt that Go is a great game. It captured the imagination and engagement of the masses almost instantly. While initially there were bugs and issues to resolve, there have been strides in the app since it’s initial release. I’ll admit that I wasn’t thrilled to download and test the game and I had a bit of a biased chip on my shoulder during the process. I’m just not into the game itself, I’ve never really understood the Pokemon craze. That said, I love the functionality of the game. I love how it gets people up and out. And I love the potential for other games based on the same ideas. For example, imagine a game where real live creatures are found and collected (or tagged, for the conservationists) that are native to the region the player is currently in. Shoot, why stop at creatures, why not plants and trees or types of rocks.
Shute, V. J., & Ke, F. (2012). Games, Learning, and Assessment. In D. Ifenthaler, D. Eseryel, & X. Ge (Eds.), Assessment in Game-Based Learning (pp. 43–58). New York, NY: Springer New York. Retrieved from http://link.springer.com/10.1007/978-1-4614-3546-4_4