Sunday, December 2, 2012

Code Refactoring

I started noticing I was writing paths to image files a lot as I was creating scenes.  And I realized as we kept adding more and more, we were going to run into problems if we decided to change images.

As an example - a line of code may have something like this: 

local bullet = display.newImage('resources/Bullet_Black.png')
 
As you can imagine, that image gets used a lot.  If we want to change to a different bullet image, and decided to keep Bullet_Black.png we may have to edit a lot of files.
 
So I built three resource Lua files:
 
  • bgFile.lua - to hold background image paths
  • controlFile.lua - to hold button and other control image paths
  • shipFile.lua - to hold the various ship image paths
 
Those files have local variables that hold the path statements to the images, and then get functions so other modules can gain access to the resource path.
 
It dawned on me, this is a classic refactoring scheme -  what is the least amount of 'knowledge' a code module has to have to do it's work.
 
So now - the resource files 'know' where to get an image; a scene file 'knows' how to manipulate an image, and so it goes.
 
One benefit we will be able to capitalize on later - as we add higher definition images for other devices we won't have to have the scene modules 'know' how to determine what image to use.  That bit if knowledge can be transferred to yet another module - and then 'asked' by the resource modules.  If the device is a higher res one - then the resource module can serve up a HD version; or else just the regular res image if the device can't handle it.
 
One thing that caused a bit of a struggle - Lua and the way it handles arrays.
 
Lua it turns out is a fairly primitive language - in that I mean primitive in the way C is.  Arrays are very simple structures in Lua - no matter how you have defined an array it is actually a KV collection set into memory.  And of course the variable name is just a pointer to the actual location where the values are stored.
 
Using them is not a big deal - it's copying them that things get fun.  There isn't anything built into Lua that provides a way to copy an array:
 
MyArray = {a, b, c}
foo = {}
foo = MyArray
 
becomes an assignment for the pointer foo to the pointer MyArray - not the values MyArray is pointing to.
 
So - I found a deep copy function at http://www.dreamincode.net/code/snippet5401.htm, made a couple of changes to it and added it to our fileIO.lua file.  That is what gets used when we need to make a copy from one array to another.
 
So when we have this defined in the ship file:
 
local uavShip = {'resources/drone1a.png', 'resources/drone1b.png','resources/drone1c.png','resources/drone1d.png'}

Using the deep copy function the KV collection uavShip is pointing to can be copied to the memory location myDrone is pointing to:

local shipFile = require "shipFile"
local myDrone = { }
myDrone = shipFile.getDroneTbl( myDrone )

Saturday, November 24, 2012

Winter Intersession - the Game goes on...

I'm taking advantage of the period between the two sessions for now.  I've started working on the beginning/training missions/point of our intrepid player having to make his/her first in game choice.

So I've started by adding a few new ships to the mix.  Found a bunch of nice top down view graphics, and adapted them to our use.

For the here and now these are the 'canon' images I've added - these should be considered source files in that the in game images have been altered:

First is a background for our training mission:
 
This image is a cut out from the full size below:

 
I wanted something modern and very different from the rest of the game.  But I noticed the transitions were choppy - then I really looked at the image.  It's lighter at the bottom than the top, and of course the small craters or whatever they are don't match up.  So I found another desert type background that is a lot more even:
 
 
I also added a whiteboard:
 
This helps keep the intro-training text in an uncluttered environment.
 
As for ships, I've added  three - first is a training drone:
 
This gives our pilot something to test his/her new prototype GAU-6 20mm Vulcan Rail cannon against.
 
Next is the Zeppelin that may or may not make an appearance later:
 
 
And a steam punk boss of all bosses zeppelin which may make its debut later in the game:
 
From the looks of this bad boy our hero may have just met his/her match.  Kind of excited to see what happens...
 
 
Okay - now in keeping with a tech discussion with our Tom Resource writer - my original question was how do we keep a slightly future tech airframe full of gas and bullets in the time frame of 1917?
 
So I took some liberties.  Our pilot has two X type technologies on board - a Warshawski generator (okay - kudos to the Honorverse BUT Warshawskys has been a huge auto parts seller in Chicago for a very long time...) and the GAU-6 20mm Vulcan Rail cannon.  The current gen Vulcan is a GAU-4 - I added the electric Rail gun so means no cartridge case, propellant etc. to worry about. In other words we are just carrying the things that go out the barrel - nothing else.  The rail gun supplies the motive power.   In a pinch add ball bearings - heck even just washers and out they go at an astonishing speed.  Tom Swift can eat his electric rifle!
 
What's a Warshawski generator you ask?  Slyly I answer - it's the typical Sci-Fi X device that allows this discussion to move forward.  Gives us the ability to take slightly future tech and have it run in 1917 without trying to figure out how we are going to get JP8 or any other type of AvGas for our jet driver.  It's when our plane driver is asked to test full military power that things get - well, interesting shall we say?

Wednesday, November 21, 2012

Installation for Amazon Kindle Fire


General Notes


Flights of Fancy is not yet available thru Google Market or Amazon.  The file needs to be manually downloaded and then installed on your device.

Installation for Amazon Kindle Fire


Download our Amazon Fire Flightsof Fancy apk file to your PC.

If you don’t have a file manager installed, you will need one.  Select Apps, Store and look up either EasyInstaller or ESFile Explorer and install.  Both of these are free from the Amazon Apps for Android Store and are compatible for Kindle devices.

You have to turn on Allow Installation of Applications in your Kindle Fire.  Navigate to Settings, More, Device, and click the ON button next to Allow Installation of Applications from Unknown Sources.  Click OK at the warning; this will get turned off later.  Click the Home icon.

Connect your Kindle Fire to your PC using a USB cable.  Once your PC recognizes it, copy our Flights of Fancy.apk file to your Kindle Fire; then select the Disconnect button on your Kindle to safely unplug the USB cable from the PC.

I’m going to use ES File explorer for the rest of the guide.  Navigate to Apps, Device, ES File Explorer and select it.  Navigate to where you placed our Flights of Fancy apk file.  Select it and a screen is displayed asking if you want to install the application.  Choose Install. 

Once completed, our app is installed.  Now would be a very good time to turn OFF Allow Installation of Applications from Unknown Sources from Settings, More, Device.

We hope you enjoy Flights of Fancy!

Installation for Android devices


General Notes


Flights of Fancy is not yet available thru Google Market or Amazon.  The file needs to be manually downloaded and then installed on your device.

Installation for Android devices


Download our Android Flightsof Fancy apk file to your PC.

If you don’t have a file manager for your device, you will need one.  ASTROfile manager is one often mentioned for Android devices, it’s free and it is available from the Market.  You will need to install it before you can continue.

You have to allow your device to install from “Unknown Sources”; these are non-Market apps.

To do this, navigate to Menu, Settings, Applications.  Make sure the box marked Unknown Sources is checked.

Once you have a file manager installed, connect your Android device to your PC using a USB cable.

Mount the external card and copy our .apk file from your PC to your device.

Once the file has is on your Android device, navigate to it using your file manager and select it.  I’m going to use ASTRO File Manger as the example.  You should get a dialog box that allows you to install our app; select Open App manager.

On the installation pages that follow, select Install.

Once completed, our app is installed.  Now would be a very good time to uncheck Unknown Sources from Menu, Settings, Applications.

We hope you enjoy Flights of Fancy!

Sunday, November 11, 2012

This Week's Progress

One of the items I worked on this week was to fix the bug in level 3, which was showing up only on restart, where the enemy ships did not appear. This was a logic flow problem that I had not noticed before IEric pointed it out to me). While I was fixing this problem I ran into other logic issues which I ended up fixing at the same time. For example, there was also a bug in level 2 where, after restarting, you advance to level 3 after shooting the enemy boss only 1 time. I fixed it so you now need to shoot the boss 5 times to advance, as intended.

Something else I worked on this week was I added explosion effects when enemy plans are killed. Ther eare 2 separate explosion sequences: the first that appears when an enemy plane is shot down; the other, which is a bit larger,  appears when an enemy boss is shot down. These effects are not quite as cool looking as I had hoped. Therefore, I hope to find a chance to revisit these at a later time to improve them and/or add other explosion effects. I implemented the code for these functions within the displayfunction.lua script. That should make it relatively straigtforward to improve upon, since the code is modularized to within just 2 separate functions in that single .lua file.

Another item worth mentioning for this week is the problem I came across when implementing more than one method with the same name (though in different .lua files). I found out that this throws an error. It sounds like you can get around this by removing (or destroying) the functions when you exit that .lua file. I have yet to test this. This was a difficult bug to figure out because the error messages gave me no clue that the problem was that I had 2 methods with the same name. This is one of the errors that our group has discussed: some of the error messages that Corona throws are difficult to interpret.

Cross Platform Craziness

Well, this past week I spent time fighting with Facebook (yet again).  The issue was that you have to register your app with FB in order to obtain an app ID used to authenticate that the app trying to connect to FB servers has permission to do so.

This is not unheard of and is even standard in most distributed type of applications.  The first problem was that you need to be a registered FB developer before you can obtain this ID.  This wasn't a big deal; just the standard "create a new account" stuff you would expect.  It was in "verifying" the account that an issue first manifested.  FB has two options for verification; a verification code can be sent via text message to your cell phone, or you can give FB your credit card information (assuming you have one and assuming you want FB to have this information)
I chose option 1 because I'd rather not give FB my credit card information.  Option 1 never worked for me. the verification number that was sent to my phone was eight digits long and the text box on FB's verification page only allowed six.  I kept getting a "verification number incorrect or invalid" error which then strongly urged me to give up my credit card info instead (I started sensing a pattern here).

Another member of our team had mentioned that he was pretty sure he was already a FB registered developer so he is going to try and register our app under his account.

Issue two stems from the fact that when FB changes their API for connecting to FB servers, the group responsible for the Corona SDK must also change the way the SDK implements FB connections.  As any experienced developer knows, this takes time and resources.  It seems to me that since Corona SDK is still young, its resources are still limited.  Case in point - FB has changed the way iOS 6 devices connect because iOS 6 now has FB connection integrated right into the OS.  Corona SDK has not made the update yet, or at least hasn't documented it yet.

The process to connect via Android is a little different from iOS but doesn't "seem" to have changed all that much in the past few years.  In the interest of time, I may end up just implementing the Android FB connection and leaving the iOS piece for later.

-Eric

Player State

My task this week was to display the players high score.  A simple task yet it lead to several paths...

Okay, so first up was just to display a simple high score.  I built a way to keep this tidbit of information, using the json library available in the corona sdk.

It's nice, what gets created is a essentially a name/value pair list.  Nice and light, especially for this use.  So our game has two of these data constructs - one keeps the current level and score values (it gets zeroed out at the start of the game), then there is another key value pair that holds onto the highest level and score achieved by the player, as well as a simple counter that holds onto the total score number for the player.  Not sure if there is any value to that yet, but we'll see.

So next up was a task to display the high score value.  Fairly easy to do, John created a topScore library file to which I added the functionality to read from the json table, then display the high score.

Well - that was so easy I figured I might as well add the highest level the user attained.  Few more minutes of coding and done.

Okay - but my current gaming obsession is Fallout New Vegas.  Second time around in fact.  And that reminded me - there are achievements in the game based on hitting certain criteria.

So I built a quick if...elseif...else structure and then got some simple achievements displayed.

Nice, but not all that satisfying.  Besides, it just looked like it was going to get clumsy trying to keep that up and running in case the rest of the team liked the idea.

This really needs to be a table based data construct - so I found that lua/corona sdk supports SQLite tables.  Built a nice quick and dirty one using SQLite Admin - and changed the code from the ugly if...elseif...else structure to a sql call to the database.  Took a bit more time to get the correct code but it's in place.

The payoff will be later on - this is a solution a number of other developers use to not just keep player state in but also stats of the various objects in a game. 

Here is a screenshot of our topscore page from the game:

TBowers Week 9 Report

Now that we have started to flush out more behavior in the three levels that we have, we are starting to experience the pitfalls of the current approach and do not want to end up with 20 levels that have a low level of cohesion and instead of components copied amongst each level's file. The break between quarters will hopefully give us a good opportunity to refactor some of the level design into a heir achy that makes sense with common components shared across. How to implement these sorts of OO practices that we for granted in Java or C# is what I spent a good part of this week researching. I picked up a new book to help me grasp some of the best practices which I think we've all started to realize are a moving target and subject to interpretation.

I spent the second half of this week creating our final presentation for the quarter. Then on Saturday, we had our meeting and collaborated on the presentation in real time (a credit to Google Docs). It was interesting to reflect on what we've done, the processes we've adhered to (or created), as well as discuss what's gone well and what hasn't. Overall I'm really happy with the quality of interaction and output from this team, I am glad we will be together again next quarter.

Monday, November 5, 2012

Progress This Week

Some notes about what I worked on over the last week:

I spent some time this week attempting to implement some type of enemy flight pattern logic into the game. I did a lot of research and ended up finding some sample code showing how to implement a "sine wave" pattern. The sample was not specific to a game, but I was able to adapt some of the logic to implement a basic flight pattern, which I put into the code for Level 3. I'm not completely happy with the code. It's not exactly the look I was looking for and plus I was hoping to find something more readily adaptable to other patterns. I hope to find some other ways to improve this aspect of the game going forward. This type of logic seems like an important aspect of game development, so I hope to learn more about how it's done effectively.

Another thing I worked on this week was modularization of the section of the display that shows the player's score. This was mostly done as a proof of concept. I wanted to get the hang of implementing external module calls in Corona. I did some research and found some helpful tutorials on the topic in the Corona documentation. I created the 'displayfunctions.lua' module. This is a very basic module so far, which contains only a few functions so far, but could potentially be a place to put additional logic in order to keep things more logically organized.

On a separate but related topic, I have noticed that some aspects of Corona "best practices" seem to be in a state of flux. For example, I found this 7/6/11 entry on the Corona site on how to implement external modules: http://www.coronalabs.com/blog/2011/07/06/using-external-modules-in-corona/.  I later found this 9/5/11 entry on the Corona site: http://www.coronalabs.com/blog/2011/09/05/a-better-approach-to-external-modules/. The latter entry, written by the same author just 2 months after the former, explains a "better" way to implement external modules compared with corrections to the method described earlier. A comment posted on the later entry notes that a technique described in the earlier entry had been deprecated by the creators of lua.

A Social Dilemma

Getting this Facebook thing going is proving to be a pain.  As I posted earlier, Facebook needs to make doing this easier considering how vital it is to their business model.

I'm setting up an Facebook age for the FoF game and will seek to register the game with Facebook  n order to obtain a registration number.  This number is needed by the code used to log in and access Facebook  from within the game.

This week I also finished implementing the "Post It!" button on the game over screen.  The button transitions to a new screen that contains the FaceBook icon and a Twitter icon.  I'm at a standstill on Facebook  development until I get the registration code from Facebook because without it I can't even test the Facebook  ode to see whether or not it is functioning properly.

In the meantime, I made tapping the icons show a dialog that explains that this function is not fully implemented yet.

Next week I intend to investigate advanced enemy movements while I wait for the access number.

Hurricane Sandy

I'm becoming a veteran of this I guess - last year was Irene, this year Sandy.  I live in a semi-rural area - which means my water comes from a well.  No electricity no water.  However, I do live on a lake, so getting water for other use (think flushing...) is only a bucket away.

We stocked up on water - bottled and filled up a number of water jugs - got propane, positioned tools, camping gear, all the other things that need to be done before the storm hits and power goes out for several days.

We lucked out - lost power for a bit over 24 hours - Monday afternoon to Tuesday evening.

So - after the clean up, got back into coding.  I extended and refactored our scoring scheme - instead of just using a text file, I found that Lua has a fairly robust support for JSON.  It becomes almost trivially easy to have a SQL-less data table get created, read from and written to using the built in JSON library.  So I've got the following libraries:

File IO - general functions to read, write and append files; functions to write to and read from Lua tables.

User State - functions that use the File IO library that write or read user state; right now current level and current score, functionality for highest level and score started on.

Player Score - a centralized set of functions that use the User State library to write out or read from the user state tables.

Code has been added to the main.lua as well as the three user level lua files that writes out the user score.

Plan is to further extend this code so as to have the highest level achieved and total accumulated score to also be saved.

Sunday, November 4, 2012

TBowers Week 8 Report

I spent the majority of time implementing a player health bar. Before, a single collision with an enemy would decrement your lives. Now, the player health is represented by a bar along the bottom and starts at 100%. Getting hit decrements health by 10%. When the health is 2/3, the bar turns yellow and when it's below 1/3, the bar turns red. This should give the player an at-a-glance view of their health status. I also spent some fixing some bugs in how we transition scenes and allow the player to restart the game after dying. I also refactored our pause system into its own scene in the storyboard framework that is transitioned to as an overlay from gameplay. It smokes out the game scene (which is still viewable underneath) and displays "Paused" on the screen.

I think we've had some great progress this week. The social integration with Twitter and Facebook is firming up and starting to look really. Now it just has to be hooked into the actual services themselves which Eric is researching. Lee is using Corona's built in support for JSON for serialization of data out to a file which I think is going to make maintaining state and potentially hooking into game services like Game Center easy to manage. As we move forward with fully supporting more than one level, we want to prevent duplication of code as much as possible. So John and I are taking a look at inheritance in Lua and how might be able to solve some of these challenges.

Sunday, October 28, 2012

Storyboard API & Accelerometer

I finally worked out the issues I was running into this week when working with the Corona Storyboard API. I was trying to refactor our existing game code to use the Storyboard API that's built into the Corona SDK for handling scene/level management. As it turns out, the main problem I had was that I was not "removing" all the listeners before transitioning to another scene. Before I figured out what the problem was, I was getting a vague error, which did not point directly to the problem, thus making it difficult to determine what was causing the problem (and the error). This brings up another point that I would like to look into: the question of whether there is any debugger functionality either built into Corona or available as a third-party add-on. The ability to step the code through a debugger of some kind would have most like helped me to be able to narrow in on the problem quicker. Nonetheless, the code is now using the Storyboard API without throwing any errors.

Another task I completed this week was to add the Accelerometer functionality into the game. Unfortunately, the accelerometer functionality cannot be tested in the simulator. However, I ran the build of the install package and ran it on my Android phone for on-device testing and it works great. That is, rotating the phone right and left drives the movement of the player plane. One note: at first the plane's movement was quite choppy. I experimented with the "system.setAccelerometerInterval()" function in attempt to resolve this. Changing this setting from 100 measurements per second down to 50 resulted in the movement becoming much smoother and less jumpy.

Social Integration

Well, I spent a good amount of time pouring over examples of how to integrate publishing the player's high score (or publish ANYTHING for that matter) onto Facebook from within the Flights of Fancy game.

You'd think think this would be an easy task given how popular social websites have become.  On one hand it seems to way easier than back when FB started.  On the other hand It's easy to see that it has a long way to go.

I think what we're seeing here is a clear example of being caught in the middle of a software revolution.  Facebook exploded in popularity very rapidly and opened the doors to many other "social" site ideas (Twitter, Pinterest, Instagram, etc...)  The API is still IMO in it's infancy.  There really ought to be a much easier way to integrate social functionality considering how popular it is; and I think there will be someday.

It's easy to forget that Java, for example, is still at a 1.x level but is soooo much better than 1.0, 1.2, 1.3, and so forth.

So back to my past weeks work. I was able to come up with the code but can't test it yet because you have to register the app with FB and have a FB page for the app.  So until I set that up, I have put the FB and Twitter buttons on a "social" view in the app that is shown when one presses the "Post it!" button.  It's not working correctly at the moment because i've run into a bug somewhere after tour code was refactored into separate modules.

Social integration is important for any new app these days so i'll figure it out.

-E

A gotcha and a gripe

Gripe first.

Once again, need to learn a 'new' way to concatenate strings.

One would think such a common programming task would be easily done regardless of language. 

One of course would be wrong.

Lua furrowed new ground for me here - no pipes, no use of the ampersand or the plus sign.  No sir!  Instead Lua uses two dots to indicate the concatenation of two stringvalues.  Go figure.

Lua concatenation: string3 = string1..string2

Gotcha next - spent some time trying to figure this one out. Kept getting an obscure error.  I was calling a function in another file - had the proper initializing statement in the file trying to use the function:

requires ( "filename" )
 
Instead of using the name space idea common to Java or .NET, Lua has you put this line into your functions:
 
module(..., package.seeall);
 
Added that as a line to my two new files and no more errors.

TBowers Week 7 Report

This week we made good strides in continuing to enhance the feature set of our game. I think Trello is working out nicely for utilizing an agile approach to identifying and assigning tasks. John is being an excellent PM by keeping everyone on track and making sure we don't go too far off into the weeds technically or creatively and forget the charter and the architecture we agreed on.

It sounds like Eric has some cool social elements (e.g. facebook, twitter) that will coming down the pipe and Lee is working on writing out our state (level reached, high score, etc.) through a file IO class. James is continuing to remind us why he's a good choice for architect as this week he has brought us some much needed re-factoring to the code base that is going to provide us a more object-oriented approach. We are utilizing the Corona SDK's built in story boarding that is helping with scene management and creating the different levels.

I spent this week adding pause functionality to the game. I added a pause button to the top left corner of the game that when pressed will suspend the world. Pausing the physics system and the update loop of the game was pretty straight forward though I was presented with a bit of challenge when I noticed as you unpaused the game the player would fire. I eventually tracked this down to the fire listener being triggered off a tap event which is really cued off the release (not the press) of the players finger. So as you touched to unpause the game, the subsequent release would be processed as a fire. I corrected this by adding a resuming flag that is set when unpausing and causes the listeners to ignore the event if resuming and then reset the flag. Fun stuff.

Friday, October 26, 2012

Corona SDK and good architectural practices


John has created an architecture document using UML following good Agile practices.  There are factories, components and other well laid out logical blocks that should allow us to parse out tasks, and develop in an iterative way.

Now the question is, will Lua/Corona SDK support such a way of doing this kind of work.  After all, it is a scripting language, using a main.lua file that controls the code that gets run.

After doing some looking around for demos and examples of displaying text to users I found that yes, indeed Lua does allow the ability to create discreet Lua modules, which can be treated as if they were classes.

The module sits in the same directory as the main.lua file; a variable is named and pointed to the module such as:

·         local director = require("director")

·         ui = require( "ui" )

Lua variables are global by default; so ui is now used throughout the application.  The local keyword keeps the director variable scope limited to the current code module.

Now we can create code modules and use already code modules easily, without creating spaghetti bowls of code in our common main.lua file.  And keep within the spirit of John’s architectural plan to boot.

Tuesday, October 23, 2012

Adventures in Scene Management

It turns out that implementing an overall strategy for level handling/scene management in Corona is more difficult than I had expected. From what I can tell, the Storyboard API, which is the scene management functionality built into Corona, is relatively new. Presumably due in part to that reason, there seem to be some issues with its implementation. I read up on the API and created a version of our game that used the API - but I ran into a few issues. For example, when I switch scenes, I was getting errors that say the 'transition' method (which we are using to scroll the background) is getting a nil value error. It is certainly possible this is due to programmer error. So I am continuing to try to work through these issues as they come up. My goal is to have a working multi-level version of the game completed in the next couple of days. What I have found out from reading the Corona forums that one of the latest daily builds of the Corona SDK included fixes to some of the Storyboard functionality. Unfortunately, the daily builds are only available to subscribers. Since the other members of our team have not purchased a license, I have not upgraded past the latest 'public' release - which is the version the other team members have.

John has written up an excellent first draft of an architectural diagram for the game. I hope to get a chance to take another pass at a draft version of the design this week. A couple things I found interesting while investigating Corona and the lua programming language in general, which we may need to take into account:

- The lua source code examples I've seen don't often seem to use the concept of object-oriented Classes. Not that this means necessarily that we can't take this approach - in fact I wouldn't rule out the possibility that may be our preferred approach. I'm just wondering if there is a reason why the samples I haven't seen seem to stay away from this. It may simply be that the Corona sdk has been designed to be more accessible to non-developers. On further research, it appears that lua does not utilize the concept of separate Classes to implement OO, but they can be emulated (see http://www.lua.org/pil/16.html & http://www.lua.org/pil/16.1.html) as "tables".

- The books and tutorials I've seen on mobile app development emphasize the need to minimize the use of memory resources due to limitations of the platform. For example, objects are often "removed" as soon after use as possible to free up memory. I'm wondering what the impact would be on memory if we use separate classes for the Managers, etc. I've been leveraging the examples I can find in my testing/experimentation with the platform.

Sunday, October 21, 2012

More adventures in the Paleofuture


My first actual programming job was doing Visual Basic – version 3.  I was getting into the nuts and bolts of C, C++ and Visual C++, but a job is a job and there you go.
Well – except…
The job was up in Park Ridge IL.  Seems there is a colony of Russian emigres in Park Ridge – as a lot of the code I started looking at looked very familiar – it ‘felt’ like C, not Visual Basic.  Which was a good starting place – as while a lot of the bad things classic VB would allow you to do was in the code base; there were a lot of other high level styles as well. 
Well, anyway I started my library of books etc. for my job.  One of first books I got was Bruce McKinney’s Hardcore Visual Basic.  It’s out of print, but Amazon still lists it.  The first chapter in McKinney's book gave a thumbnail history of the BASIC language, and provided some thoughts on what he termed the spirit of Basic. 
From that beginning followed chapters on how to turn what is often viewed as a weak, hobbyist language into ways to create high performance enterprise level product.  Yes, a lot bad code was written, and the language allowed that to happen.  But - a craftsman could quickly turn out journeyman level code in a fairly quick time.  To bring this back to my beginning paragraphs - you could write functions in Basic/VB that were similar to the type of functions you could write in C.  Well - maybe not as tersely, but the concept could remain the same.
The reason I mention all this is Lua, the language we are using for this project, in a lot of ways reminds me of the later versions of classic Visual Basic (versions 4 thru 6).  Lua is not an object oriented language, in that does not fully implement the three pillars of object oriented programming:
·         Encapsulation

·         Specialization/Inheritances (this doesn’t exist)

·         Polymorphism
Instead, it’s a lovely object based scripting language.  And it’s written in the Spirit of Basic – make things simpler than possible.
I think Edsger W.Dijkstra would hold as much disdain for Lua as he had for BASIC – but Dijkstra must not have been running into the programming sheep versus the non-programming goats problem other, later Computer Science instructors have been.
Summing up, I’m finding Lua to be much like classic Visual Basic was – fun, easy – potential to make very messy code that will at least run, probably poorly; yet with the potential to create elegant and well written programs.

TBowers Week 6 Report

This week was mostly spent preparing our presentation and schedule moving forward. I think we have fallen into a good groove in terms of pace of work. As our comfort level increases as does our frequency of meeting, communication, and resulting progress. In the milestone presentation, I think we will need to show how we have tackled (or plan to tackle) both the gaming and non-gaming aspects of Corona. I think some of the social integration we have in mind will provide a good opportunity what Corona can provide from a non-gaming perspective.

In addition, I had some extra slack in my planned tasks so I went into Trello and looked at the items that needed to be done but weren't assigned resources yet. I saw there was a need to implement a <pause> feature in the game which I thought would provide a good opportunity to learn more about Corona, Lua, and the related physics engine and "suspending the world". I haven't completed the task just yet but it's been a good learning experience.

John Sweeny Work Done


Created first detailed pass of software architecture
Created first pass of pseudo code for implementation of software architecture
(see attached for the two)
Updated project requirements into Trello
Created presentation for Monday's class
Worked with team to re-prioritize requirements
Identified nice to have tasks 

The Joys of Development

This week was spent doing a little bit of everything from looking over docs and APIs for the Corona SDK to looking over team docs to writing code.

I suppose the main portion of my week was spent figuring out how to incorporate Facebook interaction with our app.  Corona SDK supports doing this but I figured someone out there in game development land must have done this before and hopefully posted example code.

I was proven correct in that lots of people have done this very thing because as I understand it, this "Facebook" thing is pretty popular.  The only hiccup in my plan proved to be what I had suspected deep down; nobody seems to do it the same way.  So I'm going over what FB functionality the SDK will allow and what makes sense to do with our app.  Once I have a solid list of FB functionality items gathered I'll send it out to the group so that we can decide together what want.

Ultimately (and if time allows) I would like to integrate Twitter into the app as well.  The ability to "Tweet" your high score or what level you're on (or maybe just some random thought) without having to leave the game might be nice for the user.

Monday, October 15, 2012

This Week's Progress

I started off my project work this week by writing a (rough) version of some pseudocode for the game. It will need some work, but hopefully a starting point for getting the overall plan together for how the app should function. I also put together a mockup of the different screens that will comprise the application and how they will be navigated (i.e., which button on each menu/screen leads to where).

While I was testing out the source code we have decided to use as a starting point (pulled from an online demo/tutorial), I found that the bug seemed to contain several bugs. I spent several hours over the weekend becoming familiar with the code and working on fixes: debugging the issues, researching best lua/corona practices, and implementing & testing fixes. Some notes on the issues I worked on:

One of the bugs, which was keeping the restart from working (and was throwing Runtime errors) is that after a bullet is removed the code still attempts to 1) move it upward, and 2) check whether it is offscreen. The solution I implemented was to first check whether the bullet object in the bullets displayGroup is nil, and only perform the above operations on it if it is not. 

There was another bug where bullets were disappearing before they hit the top of the screen. This had to do with the way the display objects were being removed. I made some slight changes to the way in which display objects were being removed and this bug now seems to be resolved. This same bug was affecting the enemy ships, so I made the same fix to that section of the code.

Another change I made was to comment out the function declarations/prototypes. I read somewhere that lua does not require these to be declared ahead of time (and removing did not cause errors).

Some other minor modifications/fixes I made:
- Made alertView global so it could be removed. This was causing problems because it remained on the screen upon restart and the way it was coded I was not able to remove it in the restart function.
- Changed some function names to simplify them (e.g., changed "removeCredits:tap(e)" to "removeCredits()") based on corona documentation.
- Added a variable to hold bullet speed (10 was hardcoded) and enemySpeed (4 was hardcoded)
- Changed the "alert" function to "gameover" function. I had moved some logic around to make things more straightforward. With these changes, it made more sense to call the function "gameOver".

Sunday, October 14, 2012

Back to the paleofuture

Back in the day - when Java were a wee acorn in the minds eye of Gossling - Microsoft used to ship an icon creator as a part of Visual Basic and Visual C++ (aye - these were the days of yore before even Visual Studio came about)...

The reason I mentioned that was I started to take some open source sprite/png images I found and re-purpose them for our game.

I found a top down image of a 'german' biplane - as a gif file.  Saved it as a png, opened it up in Paint.Net.  Added a solid line in front of the plane and saved it as image A, removed the solid line, kept a little bump in front of the plan and saved it as image B.  With the Corona MovieClip functionality got a 'prop' animation with very little work on my part. 




Next part - a bit more work on my part, and the flashback to the image icon builder.

Found a top down jpeg image of a Fokker tri-plane.  Did the same work - saved it as a png file - but I wanted a transparent background.

Well - found that with Paint.Net - if I stayed careful, I could use the delete tool on any white space I found and that caused it to be set to transparent.  After about a half hour or so got an image with a transparent background - saved one image again with a solid line in front of the engine, another with just a bit of a bump in the front one.

Ran the game - oops too big.

Re sized it down a bit - and now we have German bi planes as well as a bit larger German Fokker tri-plane menacing our hero.





Other things of note.  Tom Resource was flogged to provide level information.  He got the Entente (English major - can't just say the Good Guy side) levels done, posted to our Google Drive.  I'm going to add his comments:

Here is the ENTIRETY of the Entente campaign I wrote up, with attendant clarifications on the terms I used. Pretty crude and breaks multiple rules of sentence formation and basic English, I am well aware, but I know you software guys: you can write a program to move the sun over if I give you enough time, so keep it quick and simple if at all possible... 

I like his faith in software engineers!  Good kid.

Week 5 update

This week (I thought) was very productive.  As a team we added Trello as a project management tool.  SVN is in working order and everyone has successfully checked out the base code.  During our weekly meeting we solidified our direction a bit and I'm even more confident that we are all on the same page.

As for me, I spent more time getting to know not only the Lua language but the Corona framework.  I am overjoyed (but a bit overwhelmed) with the sheer amount of tutorials, free libraries and other sources available for Corona.  You really get the impression that a lot of people want Corona to succeed and that goes a long way to boosting my confidence not only in where Corona stands but in where it's going.

I found helper libs for many useful things that are common to game developement such as backgound scrolling, high score tracking (even between sessions), collision detection, etc...

most are available freely but some were commercial.  Still, even the "commercial" ones proved to inexpensive ( $0.99 - 9.99)

I also changed the players ship sprite and put in a new background image.


JSweeny Weekly Tasks

Though last week was smack dab in the middle of a large integration at work, I did manage to get a few things done. 

I've begun familiarizing myself with Corona. I've researched and begun my assigned test cases. Specifically, switching between levels.  I've also begun identifying level requirements (e.g. enemies, crafts, etc) for the first two levels.

Next week I'll continue working on creating a simple shooter with multiple levels. I'll also complete the game elements for the first two levels.

As a group, we began discussing the software architecture and I think we'll continue to flush that out next week.

TBowers Week 5 Report


This week was spent taking care of some final maintenance items that are bringing the toolchain and team together. We were able to get our subversion repo fully functional (yay) and have imported the baseline Lua source and resources we will work with. James's stuff has off to a great start and Eric has done some really cool initial changes that has it starting to look like the world Lee and his resource are painting for us. I feel like exciting changes are afoot.

This is normally the time where I fear teams get paralyzed deciding what to do next. And given how geographically spread out we are, it is especially difficult to stay in sync. To combat this, we are attempting to use Agile head on. Specifically, we have created our virtual board of cards using Trello. Everyone is starting to fill in the details on the things items we need to do, the things that are being done, as well what is complete. We are using Trello to self-assign resources to each task and I think this will prevent us from doing double work and harmonize efforts.

Overall I am quite pleased with our trajectory. In a few weeks we should have a better sense of a burn rate and being able to provide better estimates to both the professor and amongst ourselves. Tomorrow will be our first attempt at using Google hangouts as a means to share our screen and demo what we have so far with the professor. I look forward to his feedback on our progress and plan thus far.

Sunday, October 7, 2012

Initial Thoughts & Scene Management

I've been experimenting with Corona in my spare time for several weeks before the start of class this quarter. I've come across a pretty wide variety of beginner-level tutorials that demo some of the essential functionality of the sdk. I expect to utilize some of these demos to get some tips as to how Corona can be used to create our app. Expanding on some of the demos and using the Corona API for reference, I put together some relatively simple working code that includes some basic features of a 'shooter' game that we may be able to utilize in the project. We are still of course working out most of the details of the game, so I don't expect we will use most of this code. Nonetheless, we may be able to modify some of the basic functionality to create a starting point for a beginning version of our game.

One shortcoming of the basic code I have put together is that it is not very modularized. I am thinking that going forward we may want to have a base of code that is divided into separate modules in order to make it easier to expand on what we have so far, add features and levels, etc.  For example, it may help to structure our code so that each "level" or "scene" has its own separate lua script. This may simplify things by avoiding having all the code in one single, long script. Before setting about developing our own method, I started looking into whether there is a standard or commonly used method for creating this type of level framework in Corona. I've come across 2 methods so far that look like they could be good candidates for us to use for the menu-ing framework for our app:

- Director Class (http://www.coronalabs.com/blog/2011/11/14/introducing-the-storyboard-api/). This is a free lua module for Corona that has been created by a third party developer for implementation of scenes/levels into a Corona app.

- Corona Storyboard API (http://www.coronalabs.com/blog/2011/11/14/introducing-the-storyboard-api/). This is the "official solution to scene creation, management, and transitioning". As such, this may turn out to be a preferable solution.

TBowers Week 4 Report


This week was spent continuing to define our functional and non-functional requirements with the team. John brings excellent PM skills to the table and has helped us walk through identifying requirements and determining our scope. We have a basic milestones setup and a wealth of ideas in terms of game play and story. I think given this abundance, one of our challenges will be identifying what's realistic given our schedule but I think the complexity will start to flush itself out more as we each get a chance to code.

Among each other, I think we've settled nicely into using Skype for meeting, Google Groups for day to day communication, and Google Docs/Drive to hold our shared documents. Lee was kind enough to setup a Mantis instance online for use in bug tracking. There has also been an SVN server setup at DePaul for our use, though at the time of this writing I still cannot properly commit anything to it (I do not get prompted for credentials). I have reached out to the professor to ensure the server configuration is correct.

Overall I think things are progressing and the team is working well together. The idea is beginning to solidify and once the schedule and tools are fully in place, we can move from the planning phase to monitoring and control and the work.

Yay.

Taming the Cross-Platform Craziness

So, "developing for iOS is not as easy as it could be" is something i hear a lot from iOS developers that I know and have talked to in the past.  The reason always seems to stem from the fact that to develop in iOS you have to write your code in Objective-C.  I've heard Obj-C called many things in the past ( "powerful" , "well thought out", and even, "what C++ should have been") but "easy" is not one of them.

This past week I have spent a fair amount of time setting up and getting to know the Corona SDK.  Corona's claim to fame is that it allows a developer to code an app in the Lua language and it does the nasty business of converting the code to native behind the scenes.  A really nice advantage that Corona has over other attempts to do such things is that it also supports conversion to other platforms (Android, Kindle, etc...) so it allows writing once and deploying on multiple platforms.

I had anticipated a tedious and lengthy install process but was pleasantly surprised to discover that installation was super simple and went without incident.  I know others in the team had noted that Corona needed the 32 bit version of the Java JRE installed to run.  I'm running the Java 7 64 bit JDK (which includes the 64 bit JRE) and have had no issues though i'm not sure why.

Corona on Windows starts the Corona Simulator and the Corona output terminal together. Corona on Mac OS X allows starting just the simulator if one wishes, otherwise starting the Corona Terminal also starts the simulator (the terminal is used to show the developer app output and debug info).

Once installed the next step was verifying my Corona developer credentials (you need a corona account to use the SDK but it is free and is quickly becoming standard practice).

The last thing to do was to start writing code.

Corona supports you using whatever text editor or IDE you choose.  I tend to switch between Sublime Text 2 and IntelliJ IDEA 11 (free edition) with the Lua plugin.  I really like Sublime Text 2 because it never "gets in the way".  Other developers will know what I mean.  However, when I'm starting out with a new language I love having code-completion (intellisense) to help guide me in doing what i want to do instead of having to look up the API every time.  Also, I like the IDE's ability to show on the fly errors and warnings.  This is just the way I like to work, everybody is different and Corona doesn't care what you use to write the Lua code.

Speaking of Lua; so far I really like it.  From the official Lua site:


"Lua is a powerful, fast, lightweight, embeddable scripting language.
Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping."

It's still early but thus far i have found Lua to be all that it claims.

Next week I'm gonna continue to continue learning Lua and continue poking around the Corona framework.  I have the tasks of researching any social network integration capabilities that Corona might support to check on feasibility.  I may even begin implementation if it's not going to be too difficult.   I'm also going to research some open source Corona libraries that are available that are supposed to make app development even easier by packaging commonly used methods.  Some basic game sprite creation is also on my plate but I'll have to see how far I get with he other stuff.

Thursday, October 4, 2012

The Writers Appel

Yes - I'm getting into the spirit of the old style pulp/serial's of the time and subject we picked for the game.  I'm using this as a reference...

Storyboard
Level One: Introduction
Introduction to flight controls with a senior instructor’s prompts appearing as text on screen. It becomes clear the PC is a test pilot experimenting with the first deployment of a new prototype fighter equipped with laser and plasma weaponry, as well as the abilities to hover like a helicopter and achieve low and high speeds at the push of a button. The instructor explains basic flight controls and introduces the concepts of the fighter, including the Eternity Drive (the fighter essentially runs by tapping off of a micro singularity or black hole, allowing for virtually infinite fuel reserves and power for its primary weapons). The PC engages in basic target practice (live drones?), and when he initializes the higher functions of the Eternity Drive, is propelled into darkness. The PC emerges into an unfamiliar dawn as a blue biplane and black triplane are firing away at each other. The player has to make a decision here of which to assist; after shooting down their chosen target, they accompany the surviving plane home. Discovering the date to be 1915, the shocked pilot offers their assistance in the quickly expanding global conflict known as the Great War (WWI).
 
Level Two: Second Battle of Ypres
Entente Side: The PC is ordered to assist in any way possible after the mass retreat from the line due to German gas attacks. The PC destroys a few observation balloons before being jumped by a squadron of triplanes. After the destruction of the triplanes, a cutscene triggers in which the pilot lands to assess the situation, and receives orders from a ranking officer to destroy as much of the German artillery as possible to assist with the retaking of the line and prevent German exploitation of their successful gas attacks. While destroying the artillery batteries, a German Ace (the Black Knight) intrudes and begins attacking with incendiary rounds. After shooting down the Ace, the PC witnesses him retreating from the wreckage of his plane to the advancing German troops.
 
Central Side: The PC is ordered to assist German advances in the wake of successful gas attacks. He must defend the observation balloons from French and British biplanes. After shooting down the final biplane, a cutscene ensues in which the German commander order the PC to destroy and remaining British artillery behind the lines. A British Ace emerges (the White Knight) and begins a boss battle against the PC using incendiary rounds. After shooting down the Ace, the PC witnesses him retreating from the wreckage of his plane to join the retreating British troops.

An Editors Riposte

Hi Tom  (our resource),
First of all; we need to keep this simple for a couple of reasons - there are only 16 weeks left of dev time (this is counting up both class sessions); and we don't have a graphics person/team organic to the group.
So - we are going to be stuck with whatever 2D images/sprites we can find that are open source. That being said, I'd stay as close to 'real world' as possible. Later on if the team stays together and we want to go full bore development then we can get a lot more wild.
So with that caveat - I'd say stay with normal zeppelin for the times etc.
And yes - I think you have it as the player levels up there needs to be
Increase in player hit points
Increase in NPC hit points
Increase in number of NPC's
Sprinkling of tougher NPC's (on both sides - think squadron ace's fighting against and fighting with)
With maybe a boss battle against an enemy ace and their squadron
Some way for the player to add capabilities to their ship
And yes - there needs to be zeppelins...
And I like the idea of the user having to make a choice right away.
So taking your story line I've come up with a concept of the initial story -
Player takes off in airplane (now here is the where some background information is going to have to be fleshed out - how does the guy keep his bird gassed up? Load up bullets? That sort of stuff. So clearly we are going to have to have our hero come from the future, with some kind of air frame that uses X fuel that never runs dry) - some kind of event happens and player transported to the skies over WWI Europe; Axis and Ally dawn patrol squadron getting ready to duke it out and our hero is smack dab in the middle of the fight.
Here again some kind of background information on the aircraft - it needs to be slow enough to be able to fight against bi-planes. We are almost really talking about the kind of vessel that was in the Descent series - ability to hover, move slow then fast etc.
Once the player makes a decision - the enemy npc's get killed and the player lands with 'his team' at their base. That finishes the intro, gives a nice segue to some kind of cut scene and then an invite to go on another patrol or some other task.

A Perilous Junction

So 'our resource' - budding writer - does ask for some clarifications.

Got your note, couldn't read all of your handwriting but I got the gist of it.  Couple of questions for your and your team...

How pulp hero do you guys feel comfortable with me getting about  this (Ex. level 2 boss a normal zeppelin for the times, or a lightening-spewing steam punk monstrosity?)

<IDEA> Or, as a progression from level to level, normal gradually gives way to more and more insane ideas as the side the PC is fighting against throws anything it can think of against you to try to win back the skies?

Right away - does user get a choice on side they fight for/against, or does it make more sense to do a single "campaign" now; think of alternate campaign as DLC or a sequel if successful (NOTE - hint of fatherly pride here - clearly he DOES get the idea of monitization).

The Editor Strikes Back...

I gave 'our resource' some homework - nothing too complicated...
 
Tom - for Thursday we are going to need:
 
Beginning storyboard
  • Background Story
  • Characters
  • Layout
  • Level complexity - what happens when going from level 1 to 2
  • What begins a level
  • Hazards
  • Top down vs. scroller
  • Cut scenes - how does user get information
  • Missions?
Right now we need at least two levels - game start, next level for our discussion on Saturday.

Oh - we settled on idea #3.
This is going to be 2D - hence the question side scroller or top down.
Keep it simple to start - we can flesh it out more as we go.

The story so far...

I figured I would begin my posts with the story information I got from 'our resource'...

I tasked my youngest son with this - give us a few game ideas that we could use to create a multi platform game.  He responded with:

Working Title: 1938, Pastwatch
Possible genre: Platformer/3rd person
Story basics: Time travel storyline from a projected future into the past, namely mid to late 1938 in Europe. The PC is an agent of a governmental Time Security agency (the Pastwatch) sent to prevent a fellow agent (working name: Romanov) from changing the flow of events leading up to World War II. The story has the potential for multiple endings (possibly based on player’s chosen difficulty level), including ones where Romanov succeeds, succeeds but ultimately fails, the PC wins and the PC assists the antagonist in achieving his goals. The storyline depends on making the player believe Romanov intends to make the Czechoslovakian government stand up to Hitler’s ambitions for German expansion, igniting WW2 earlier and dramatically altering the perspective sides (perhaps even starting a series of smaller wars overall, with fewer overall casualties but a Nazi Germany that survives into the present day facing down a fracturing Soviet Union while the USA remains isolationist). The true story is different: he hopes to ignite the war earlier than actually occurred, of course, but intends for Germany to ally with Poland to invade the Soviet Union, allowing for the two powers to burn each other out and the building of a true European Union to result. The multiple endings can expound on the magnitude of his successes or failures, or even if his attempts to change (Intervention) rather observe (Witness) the past even work.
Possible Hooks: Leader boards for scoring purposes, time attack/trials mode, player decided difficulty levels, multiple endings
 
Working Title: Forerunner
Genre: Shooter
Story basics: As the titular Forerunner to a future alien invasion of the Earth, the PC must destroy as much infrastructure as possible to aid and abet the invasion while keeping overt resistance to a minimum. This means thinking strategically, striking at weaker nations across the planet and isolating more powerful nations before striking at them. A shooter in the purest sense, storyline would be limited to perhaps faux news reports of the PC’s actions and responses to them from across the world that the PC alien character would intercept. The true hook here, of course, is to actually be playing as the dastardly bad guy alien who, at the end of the day, is a punch clock villain whose sole goal is to suppress the elements of effective armed resistance and get his paycheck, while shooting the platitude shouting hero out of the sky.
Possible hooks: Same as above
 
Working Title: Flights of Fancy
Genre: Shooter
Story basics: A freak accident during testing of a prototype fighter equipped with laser and plasma weaponry sends it back to the spring of 1915, in the middle of the 1st World War. Upon encountering an air battle of biplanes and being fired upon by both sides, the PC’s first decision is to decide whom they will assist, the Central or Allied powers. That decision tips the balance of the war in their favor slightly, but the PC must also decide if they will intervene in other ways, such as going out of their way to kill specific individuals (a young corporal in the German Army named Adolf Hitler, for example) or use their historical knowledge to influence the course of history (help stave off the Russian Revolution, for another example).






Monday, October 1, 2012

This is a post for SE Studio Team C.

Let me know if you guys have problems posting.