Game Dev Part 3: Starting the Game Framework

February 23, 2013 · Posted in game development · 2 Comments 

In our last post on creating the game architecture for our high level classes, we discussed a number of design decisions about our game. While the details will be important, almost all games have the same basic structure, so I thought we’d get started on creating that in parallel with our creative process.

Usually, I build out the skeletal structure as I’m doing the creative process details. As a reminder, here is our structure:

 

Game Class Diagram

Main.lua in Corona SDK

In Lua, everything starts in your main.lua file. Most people will probably put a lot of logic and variables in this. We use the main.lua file strictly to launch our application and leave the rest of the logic up to the Game Controller, which we’ll create a file for called GameController.lua.

 

main-lua

This is all we have in the main.lua file. It simply declares a function, and then adds an event listener that gets system messages for when the application starts, exits, suspends and resumes. For each of these states, we either save or load the data. For example, if we were in the middle of a battle and our game gets sent to the background, we’ll need to save the current state of the application to a file so that we can resume in the same place, even if the app quits completely. These might be things like current health, time, which enemies are still active, etc. When the application resumes again, we reload this data and we’ll check it later in the code to see what our state was, so we can handle the loading of that screen, just as if we never left.

If the application starts up, and there is no data, that means it is the first time we’ve launched our application. We call a special function in GameController.lua called firstLaunch() to handle this. You could put this logic in the GameController’s main function to make main.lua even simpler if you wanted but by testing for nil, we can handle it differently if your game had different needs.

First Launch

This first launch function might include a quick tutorial overlay to introduce the player to our game. Always after that, we save the data so the next time the app starts, data will be loaded in and firstLaunch() won’t be called. First launch may do other things like setting up and writing settings files, but we’ll want to separate out the logic for overlays and other things into other functions so that we can reuse them later, if the user wishes to go back through the beginning tutorial. In other words, if the user wants to revisit the tutorial via a menu item, we don’t want to run through all the first launch logic like creating settings files, user names, etc. We’ll simply want to call something like showTutorial() in order to bring that feature up. It’s important we separate out these steps for later use in the app. You never know what you’ll end up reusing or accessing from another execution path.

System Events

Finally, we print out the event.type variable if it is not nil, in case you’re interested in handling additional system events that Corona sends your way. In our case, I’ve simply commented out the print statement but keeping the handling of system events in one place is a good idea. In our case, we’re forwarding the handlers to our GameController since that’s acting as our master controller.

Game Stats

You may have also noticed we made a call to getGameStats() to serialize and deserialize our data. This returns the Game Stats controller that holds all the information about our game including character stats, level stats, scores, and everything else we want to keep. This will talk to our storage controller to read the file information and then put it into a format. We’ll also have a level loader, so we can load things such as those one at a time from storage.

Dive Centers, iPhone apps and More

April 17, 2011 · Posted in news, personal, projects · Comment 

For those of you who follow, you always want to know what I’m up to.

Some might think I’ve spent all this time opening a dive center here in the New River Valley. In fact, I think I’ve only spent about 10% of my time doing that.

iPhone Apps

We have two that are completed and awaiting final testing. This is usually the longest part of creating any application. We haven’t had any of our live apps crash yet, and I prefer to keep it that way. So, we do a lot of testing. And when we think we’re done, we test some more.

Lab Work

One must think I’m getting my PhD in Environmental Engineering. I do have a degree from the College of Engineering (Computer Science), but Environmental? I would never have thought. But Ana is finishing up and I’m helping out. That means preparing batch reactors, measuring gas production and writing a thesis. Luckily I’m only helping in small quantities and the lab work is completely done. Now it’s just data analysis and finishing off that thesis. I guess it’s science, and we use a computer, so it’s kind of what I went to school for.

Businesses

As I mentioned, we opened a dive center in Blacksburg. But we also created a state of the art website for it that’ll allow the company to grow into something much more than a dive center. We had the awesome team from HellowYellow design us the site, and they did an amazing job. We’re working on a ton of new features to the site like class registration, videos, etc. How hard can all that be? Well it’s part of a much larger picture, so a little harder than you think.

Part of that larger picture is this: It’s not about opening a dive center and sharing our passion for scuba. It’s about taking a business, any business, and making it the best at what it does. Most dive center websites look like theirs were created in 1996, by a dude with 10 minutes of html experience while sitting on a beach, drinking coronas.

So we started something. That something has grown to include several businesses, several partnerships, several clients and a lot of change. That change will upset a lot of people, namely those on the other side. How many, will be our measure of success.

Mobile Application Development

February 22, 2011 · Posted in iphone, work · Comment 

I’ve been doing a ton of application development for LTZ lately. Not only have I been working hard at getting iPhone and Android apps finished, but I’ve also been updating the website and making sure our apps are properly represented. Take a look at the website to see the changes that have been made!

iOS Development Code Kitchen

December 6, 2010 · Posted in advice, code, iphone, projects, work · Comment 

I’ll be putting on a workshop on iOS and iPhone development this Saturday from 9AM to 5PM on the Virginia Tech campus. The event is free so if you’re in the area feel free to sign up:

http://www.ltzllc.com/2010/11/ios-development-code-kitchen/

The event will run all day and will be hands-on programming, but all levels of experience are welcome and encouraged to come.

I Am Not an Entrepreneur

October 7, 2010 · Posted in iphone, news, personal, projects · 4 Comments 

Many people throw around the term entrepreneur. It seems most people put that in their bios. Don’t tell me you’re an entrepreneur, show me. What have you done?

When we started LTZ, our mobile and web app development company, we didn’t need any venture capital funding. We didn’t need a fancy office to rent. We didn’t need to do the whole fancy company launch. We just sat down at our computers and started coding. And when we finally had a product to ship, we did all the legal paper work and got ourselves a little LLC.

Sure there were risks. The risk of becoming single again was always there. Sure there were long days. 16 hours seemed to be the norm. And sure there were a few new technologies that we created. But when it came down to it, we just had a simple plan: work really hard and make some great products.

The business model we had, seemed like a great idea: become an authority and gateway for indie developers to develop their apps with. Sort of like a record label for mobile app developers, but without the whole ripping them off bit. We’d mentor and direct them to a finished product and take a minimal cut from the net profits. Any programmer can attest to the numerous projects that never make it to a finished, polished, tested app. But that’s exactly what separates the professionals from the amateurs: finished products.

Now, we’re looking at things differently and adjusting our model. We’ve found out a little more about what works and what doesn’t in this new space. When you’re such a small company, the saying, “If you want things done right, you gotta do it yourself,” turns into, “If you want something done, you gotta do it yourself.” It’s really hard to concentrate on writing good code when you’re the tester, the project manager and the client manager all in one.

I’ll talk more about the new direction we’re heading soon. In the meantime, we’re still working on the details and we’ll update everyone as soon as we finalize everything.

I am not an entrepreneur. I just create stuff.

Next Page »