Showing posts with label srs. Show all posts
Showing posts with label srs. Show all posts

Tuesday, January 10, 2012

Making of an Arcade Frontend - Part 2

If you haven't read them yet check out the prolog and Part 1

I think it's been a sufficient ahem an excessive time since I've posted last...

During my Christmas vacation I managed to bash out the majority of the features I've wanted to support in my arcade frontend. I had a couple false starts before then. Frustrated, I went with the tried and true "just make the damn thing work" development methodology (aka hacking.)

Well, I didn't build it quite as haphazardly as that. The idea is to translate the project requirements into some minimal functionality that must be created for the project to be considered "working." For a small project like this it only takes about 10-30 minutes of effort. For larger projects it takes longer. Most of the time you'll find some features that are independent of each-other. To get the most bang for your buck your best bet is to start working on some feature that a lot of requirements depend on.

Huh? What?

I'll give an example. This is taken from the requirements list in Part 1 under each requirement is a number of functions that need to be implemented
  • Hide the regular Windows front-end.
    • Using pygame run in full screen mode
    • Leave full screen mode before starting a game, re-enter once the game exits
  • Allow the user to shut down the computer without exiting to Windows
    • Method for responding to user input
    • Method for confirming user action
    • Method for invoking windows shutdown
  • Allow an administrator to exit to windows
    • Method for responding to user input (key-mapped arcade controls)
    • Clean program shutdown
  • Allow rapid selection and launching of games using arcade controls (not keyboard and mouse)
    • Method for responding to user input (key-mapped arcade controls)
  • Support launching any game/program, not just MAME
    • Scan (something) to create a list of programs that are launchable
    • When prompted launch a program using information from the list
  • Display a preview of the selected game
    • Scan (something) to create a list of images associated with games
    • Method to load images as needed 
  • Display a list of games that can be played
    • Scan (something) to create the list of playable games
    • Method for distinguishing selected game from others
    • Method for displaying available games 
  • Display a marquee for the game... somewhere near the screenshot
    • Scan (something) to create a list of images associated with games
    • Method to load images as needed
  • Everything must have an animation
    • This means needing an endless update/draw loop for objects
    • Need a state machine to indicate whether some transition is occurring and what kind
  • Alter control-key mappings to support games without configurable controls 
    • Method to invoke IPAC-2 programmer with some known configuration
    • Scan (something) to create a list of control configs associated with games  
There are a couple things that pop out:
  • Method to load images as needed
  • Scan (something) to create a list of games and things associated with them
Of those scanning comes up the most and, more importantly, relates most directly to the purpose of the program which is starting games.

For my first crack at this I've decided that (something) will be a directory tree containing files called (game)-launcher.cfg which describe playable games. For the sake of organization, since there will likely be well over 100 files, the config files can be in any directory in the tree.

What do I want to put in the file:
  • The program to start
  • Extra information to pass to the program
  • Controller settings for the game
  • Where to find game's marquee, screenshot and other image files
Now, how do I format the file? I don't want to spend an undue amount of time writing a parser so I could use one of Python's built in parsers. But that still means I need code to convert that to an easily usable datastructure (let's just ignore JSON for now since it slipped my mind at the time) So... how about just making it a Python module. That reduces parsing to one line of code. The file itself simply contains a Python dict with a standardized name and standardized keys.

First the code to scan for config files:
def FindAllLaunchables( startDir ):
    outList = []
    dirList = os.listdir( startDir )
    for dir in dirList:
        checkDir = os.path.join( startDir, dir )
        try:
            if os.path.isdir( checkDir ):
                outList.extend( FindAllLaunchables( checkDir ) )
            elif os.path.isfile( checkDir ) and dir.lower().endswith("-launcher.cfg"):
                outList.append( checkDir )
        except WindowsError:
            pass
    
    return outList

That's it. The function recursively scans all directories under startDir and, if it finds a configuration file adds its location to an output list which the function returns.

This bit of code handles reading the configuration file.

def CreateLaunchers( configFiles ):
    launchers = []
    for launcherConfig in configFiles:
        moduleName = os.path.splitext( launcherConfig )[0].replace( os.path.sep, "_" ).replace( ".", "" ).replace( " ", "_" )
        
        moduleFile = open( launcherConfig )
        try:
            modulePath = os.path.split( launcherConfig )
            module = imp.load_module( moduleName, moduleFile, launcherConfig, ["cfg","rt",imp.PY_SOURCE] )
            launchers.append( config.Launcher( module.LauncherConfig ) )
        finally:
            moduleFile.close()
            del moduleFile
    return launchers

The meat here is the call to imp.load_module. The imp module exposes some of the guts of Python's import statement and is useful for importing arbitrary files as modules. Notice the config.Launcher object instantiation. The Launcher class will be used to carry out the work of starting up a game based on its configuration along with some other stuff.

And that's everything! To finish this initial step I stubbed in some code to start up fullscreen mode and to pick up keyboard input. That code is below and makes up the skeleton which the rest of the program will be built around.

pygame.init()

# load configuration
configFiles = FindAllLaunchables( search, skip )
launchers = CreateLaunchers( configFiles )

# startup sequence
screen = SetScreenMode()
pygame.key.set_repeat( 1000, 200 )
pygame.mixer.init()
things = []

# the main loop!
frameStart = time.clock()
time.sleep( 0.01 ) # XXX: don't want a frame time of 0 when starting
while True:
    frameTime = time.clock() - frameStart
    frameStart = time.clock()
        
    for event in pygame.event.get():
        if event.type == pygame.QUIT or (event.type == KEYDOWN and event.key == pygame.K_F12):
            sys.exit()
        
    for thing in things:
        thing.Update( frameTime )
        thing.Draw( screen )
    pygame.display.flip()
    screen.fill( (0,0,0) )

Whelp, that's all for part 2. I'll have more for you next time! (and since the project is working, next time should be sooner, not later) SetScreenMode isn't all that exciting so I've spared you its details. Notice that with this code we now have the following done.
  • Using pygame run in full screen mode
  • An endless loop to update/draw objects
  • Method for responding to user input (stub)
  • Scan (something) to create a list of games and things associated with them
Not bad for one blog-entry worth of work eh?

Sunday, July 31, 2011

Making of an Arcade Frontend - Part 1

Ah, time to take a break from work and dealing with ASP.NET web applications, continuous integration servers and all that fun (but boring to talk about) crap. Time, for The Making of an Arcade Frontend!

H'okay. So, like any good software project, my arcade frontend needs a plan. And any good plan starts with a set of goals. A bunch of things the frontend is required to do. In other words, software requirements. Woo! Exciting! Sounds like something out of a college software quality course eh? Well, at least a good software quality course would discuss requirements. After all, it's hard to tell whether your software is "right" or "good' if you don't even know what right or good are.

There are a few ways of going about making software requirements. You can write up a paragraph of what you want the program to do. Or you could make a checklist of features. Or you could draw a bunch of pictures. Or you could write a formal SRS document. The choice is yours.

I tend to favor brevity when coming up with goals for my software. It reduces the amount of effort I expend on the requirements stage dealing with contradictory requirements and other general issues. It also helps avoid falling into the trap of writing requirements as a set of instructions on how the program will work; instead of what the program needs to accomplish. If you do fall into the trap of writing a how-to for your program you'll regret it when you find that the design won't work with real code. Good requirements say nothing of how they get achieved. For a large project I tend to go with a short paragraph describing each requirement. A couple sentences does the trick quite nicely. Small projects only really need a set of bullet points. There's no hard and fast rules on what is or isn't descriptive enough for a given project. It really depends on the size of the projects and who is working on it. Practice makes perfect.

So, what are the requirements for my arcade frontend? Here they are.
  • Hide the regular Windows front-end. It should appear as soon as the computer becomes usable.
  • Allow the user to shut down the computer without exiting to Windows
  • Allow an administrator to exit to windows (e.g. to install more games)
  • Support launching any game/program, not just MAME
  • Allow rapid selection and launching of games using arcade controls (not keyboard and mouse)
  • Display a preview of the selected game
  • Display a list of games that can be played. Preferably in a manner that looks pretty (e.g. like how DDR displays its song list)
  • Display a marquee for the game... somewhere near the screenshot
  • Absolutely no hard transitions. Everything must have an animation to go with it
  • Alter control-key mappings to support games without configurable controls 
See, nothing all that complicated at all. So, now that I know what I want to do, I need to decide how to do it. That's for another article.