I have two apps in Apple's App Store, both developed with LiveCode:
Lunar Hotel Shuttle
https://itunes.apple.com/us/app/lunar-hotel-shuttle/id580954161?ls=1&mt=8
Accepted: November 28, 2012
Catch Sunny
https://itunes.apple.com/us/app/catch-sunny/id485099497?mt=8
Accepted: December 12, 2011
Both are free, so check them out. Catch Sunny is a little game that I developed to be used in an educational research project here at UGA. The strength of the app is the way it collects data "behind the scenes." (Read the project's description in the App Store to learn more about this.) I might write about that app at some point in the future, but I want to focus attention on the Lunar Hotel Shuttle app over the next several posts.
My main purpose of developing the Lunar Hotel Shuttle game was not to create a great game that would make money, but rather to test the appropriateness and functionality of LiveCode for action games on mobile devices, especially a game where the "feel" is very important. This was important to me in order to know whether I would be wasting my time learning LiveCode for projects like this and to understand where LiveCode's limits were to be found for games requiring high responsiveness. I'm pleased with the final result of the feel of controlling the rocket as it simulates the laws of motion. However, when I compare the responsiveness of the rocket in the earliest drafts to the final published version, it is clear that I was pushing the limits of LiveCode in this area.
I also wanted to test out a wide range of functionality within LiveCode. I give LiveCode very good marks here, at least a B (maybe an A-). There really was no feature or option that I wanted to include that was beyond the scope or limits of LiveCode. My biggest criticisms of LiveCode is that the interface is a little clunky, especially the way in which one must format text fields. However, I give LiveCode an A+ for giving me a very enjoyable programming experience. (I know about the third party LiveCode extension MobGUI and am considering purchasing it for my next project.)
I kept very careful notes as I developed this game (21 pages worth). It took me a total 59 hours to design and develop this game, not including the time for the following:
--testing of the various prototypes.
--finding sounds and graphics, or making graphics.
--'relearning' how to submit to the app store.
This time did include learning new things in LiveCode as I went, so I'm sure the development time of my next projects will be faster.
I've analyzed how I spent time on various development tasks. Here is the breakdown of the programming time:
Simulation engine: 7 hours (11.9%)
Interface design: 23.5 hours (39.8%)
Graphic and audio design: 28.5 hours (48.3%)
The "simulation engine" is the programming of the mathematical algorithms that simulate Newton's laws of motion within a gravitational field. This is also known as the "underlying model" in the computer simulation literature.
The interface design involves all of the strategies and options that are needed to inform the player of gaming/simulation context, the design of all strategies to communicate the goals of the game/simulation, and the design of feedback to let the player know if the goals are being reached. Examples include the story context of the moon and lunar hotel, the concept of fuel and the principles of its consumption and refueling, the timer, the concept of rank and being promoted in rank as one progresses in skill, the engine speeds, what constitutes a successful landing, and the way in which the game is scored. There are many more. The gEqual engine speed is a particularly interesting example of interface design because of its intent to convey an important physics principle. When this engine speed is used, the engine is providing thrust with exactly the same force as gravity, but in the opposite direction. This creates a situation where the rocket's velocity remains constant at the moment that this engine speed is selected. Including this engine speed provides an important opportunity for learning of physics. Of course, it also complicates the game play by having multiple engine speeds to choose from.
Another simple example of interface design, although very much related to the graphic design, is having the rocket show a flame when its engine is on. Of course, the decision as to what the rocket (and the flame) look like is a graphic design issue. But, the decision to have a flame to communicate the fact that the engine is one I characterize as an interface design issue.
Graphic design is just that -- the decisions on what graphics to include and how they are designed. This is admittedly the weakest part of the game because this is an area in which I am very weak. It's one thing to tell a story about a hotel on the moon, it's quite another to illustrate it. (I'm happy to report that a colleague of mine who is a very skilled artist and graphic designer is seriously considering helping me with a revision of all of the app's graphics. If this happens, I think it will be fascinating to compare the "before and after" versions.)
The use of sound effects also took much time and is also a rather weak part of the game. There is also much to discuss this, but suffice it to say that the few sound effects that I included were both important and time-consuming. (Important note: One difficulty I had was including a sound effect for the engine. I could never quite get that to work properly, so I scrapped the idea.)
As I pointed out, I did not include the time required to test out the various prototypes. This point needs to be emphasized because I broke a cardinal rule of game/simulation design by not field testing the prototypes with actual users. (Recall my goal was really about evaluating LiveCode as a programming to tool for games such as this.) Had even minimal field testing been done and documented, I estimate this would have doubled or tripled the time to create the game. Of course, this would have resulted in a much better game!
While I think this breakdown is consistent with much of the literature in software design, I think this little development project bears out what the RunRev company touts as an advantage of LiveCode, that is, its ability to use prototyping as the principal design methodology for development, which in turn greatly speeds up the development work. Only requiring seven hours for programming the simulation engine is a good case in point.
Lloyd
Lunar Hotel Shuttle
https://itunes.apple.com/us/app/lunar-hotel-shuttle/id580954161?ls=1&mt=8
Accepted: November 28, 2012
Catch Sunny
https://itunes.apple.com/us/app/catch-sunny/id485099497?mt=8
Accepted: December 12, 2011
Both are free, so check them out. Catch Sunny is a little game that I developed to be used in an educational research project here at UGA. The strength of the app is the way it collects data "behind the scenes." (Read the project's description in the App Store to learn more about this.) I might write about that app at some point in the future, but I want to focus attention on the Lunar Hotel Shuttle app over the next several posts.
My main purpose of developing the Lunar Hotel Shuttle game was not to create a great game that would make money, but rather to test the appropriateness and functionality of LiveCode for action games on mobile devices, especially a game where the "feel" is very important. This was important to me in order to know whether I would be wasting my time learning LiveCode for projects like this and to understand where LiveCode's limits were to be found for games requiring high responsiveness. I'm pleased with the final result of the feel of controlling the rocket as it simulates the laws of motion. However, when I compare the responsiveness of the rocket in the earliest drafts to the final published version, it is clear that I was pushing the limits of LiveCode in this area.
I also wanted to test out a wide range of functionality within LiveCode. I give LiveCode very good marks here, at least a B (maybe an A-). There really was no feature or option that I wanted to include that was beyond the scope or limits of LiveCode. My biggest criticisms of LiveCode is that the interface is a little clunky, especially the way in which one must format text fields. However, I give LiveCode an A+ for giving me a very enjoyable programming experience. (I know about the third party LiveCode extension MobGUI and am considering purchasing it for my next project.)
I kept very careful notes as I developed this game (21 pages worth). It took me a total 59 hours to design and develop this game, not including the time for the following:
--testing of the various prototypes.
--finding sounds and graphics, or making graphics.
--'relearning' how to submit to the app store.
This time did include learning new things in LiveCode as I went, so I'm sure the development time of my next projects will be faster.
I've analyzed how I spent time on various development tasks. Here is the breakdown of the programming time:
Simulation engine: 7 hours (11.9%)
Interface design: 23.5 hours (39.8%)
Graphic and audio design: 28.5 hours (48.3%)
The "simulation engine" is the programming of the mathematical algorithms that simulate Newton's laws of motion within a gravitational field. This is also known as the "underlying model" in the computer simulation literature.
The interface design involves all of the strategies and options that are needed to inform the player of gaming/simulation context, the design of all strategies to communicate the goals of the game/simulation, and the design of feedback to let the player know if the goals are being reached. Examples include the story context of the moon and lunar hotel, the concept of fuel and the principles of its consumption and refueling, the timer, the concept of rank and being promoted in rank as one progresses in skill, the engine speeds, what constitutes a successful landing, and the way in which the game is scored. There are many more. The gEqual engine speed is a particularly interesting example of interface design because of its intent to convey an important physics principle. When this engine speed is used, the engine is providing thrust with exactly the same force as gravity, but in the opposite direction. This creates a situation where the rocket's velocity remains constant at the moment that this engine speed is selected. Including this engine speed provides an important opportunity for learning of physics. Of course, it also complicates the game play by having multiple engine speeds to choose from.
Another simple example of interface design, although very much related to the graphic design, is having the rocket show a flame when its engine is on. Of course, the decision as to what the rocket (and the flame) look like is a graphic design issue. But, the decision to have a flame to communicate the fact that the engine is one I characterize as an interface design issue.
Graphic design is just that -- the decisions on what graphics to include and how they are designed. This is admittedly the weakest part of the game because this is an area in which I am very weak. It's one thing to tell a story about a hotel on the moon, it's quite another to illustrate it. (I'm happy to report that a colleague of mine who is a very skilled artist and graphic designer is seriously considering helping me with a revision of all of the app's graphics. If this happens, I think it will be fascinating to compare the "before and after" versions.)
The use of sound effects also took much time and is also a rather weak part of the game. There is also much to discuss this, but suffice it to say that the few sound effects that I included were both important and time-consuming. (Important note: One difficulty I had was including a sound effect for the engine. I could never quite get that to work properly, so I scrapped the idea.)
As I pointed out, I did not include the time required to test out the various prototypes. This point needs to be emphasized because I broke a cardinal rule of game/simulation design by not field testing the prototypes with actual users. (Recall my goal was really about evaluating LiveCode as a programming to tool for games such as this.) Had even minimal field testing been done and documented, I estimate this would have doubled or tripled the time to create the game. Of course, this would have resulted in a much better game!
While I think this breakdown is consistent with much of the literature in software design, I think this little development project bears out what the RunRev company touts as an advantage of LiveCode, that is, its ability to use prototyping as the principal design methodology for development, which in turn greatly speeds up the development work. Only requiring seven hours for programming the simulation engine is a good case in point.
Lloyd
It is in deed a work of Web Developers AND Web Designers to work on this. A great layout from the designers with responsive design and usability in mind (as David Platt comments) can help and save a lot of work-time to the developers, and create a better experience to the users. Thanks for the post!
ReplyDeleteCado Magenge
iPhone Application Development Melbourne
Responsive Web Design Company Melbourne
Web Design and Development Company
I would love to see these but they are not in the Apple Store any longer. I get a message that says: the item you requested is no longer available in the U.S. Store
ReplyDelete