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.

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.

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.

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.

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".

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.

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.

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/3^rd 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).

This is a post for SE Studio Team C.

Let me know if you guys have problems posting.