A lot of time is eaten by discussing and working against each other in shared code bases or tasks. With only one week to create something that ought to take a month, my goal is to reduce the amount of interaction and collision to the bare minimum. This page outlines where the interactions ideally should be.

In-Game Coding + Out-of-Game Coding

I will be doing in-game code including game interactivity, physics, and maps along with the core infrastructure. I will use more or less the same API for game scenes as I did in PyWeek 10. You guys (ikr/Falun) will be doing everything else. I have a specific list of all the tasks this includes, but unfortunately it is on my iPod which has a dead battery and I won't have access to my charger until tonight. But I will post that list there. If it is possible, you should discuss which ones can logically be separated into workloads that match the amount of time you'll be able to code that week. The large tasks here are in-game inventory/status screens and interactive dialogue/story screens. 

The API will look something like this...

Create a class that implements the following "interface":

class MyScene:

     def ProcessInput(events):

          ...

     def Update(gameCounter):

          ...

     def Render(screen, renderCounter):

          ...

Also include a field called NextScene which will be set to None. When set to another scene object, the main loop will swap out this scene with NextScene. For menus that show backgrounds of the gameplay scene, you'll want to accept a reference in your constructor of the gameplay scene itself, and call its Render method from your Render method first, and then apply any changes. 

Coding + Map Designers

For talking/interactive dialog scenes, accept a string in the constructor containing a script or a file path to a script outlining the dialog and I will instantiate the scene from in-game. Feel free to use whatever format you want and let the map designers know. There will be a place in the map editor to link to the dialog script which will likely have to be written by hand, so don't pick a format that's too crazy. Having created something similar before, I'd recommend something that looks like BASIC with line numbers, GOTOs, and a simple instruction set, but it's up to you and the map designers. 

I will create a static active game context object that can be accessed from anywhere and give you access to the player's stats and variables, such as flags, stats, and inventory.

I will also create a simple API for game entry management (I'm going to go with the Nintendo-style 3 saved game entries menu). 

Map Designers + Art

I will create a wiki page for art requests. When you are designing maps and think you need something, add it to the request list. If you think you will need something complex, (like an NPC) let her know sooner than later. 

Music

The levels will be decided during planning week. By UTC midnight Saturday you (ph1n) should have everything you need for the whole week. When you finish songs, email them to me like last time. 

Source Control / Asset Management

The repository lives at http://svn.magichappyplace.com/nppw11/ and is publicly viewable.  That means you can download what we have but will need to get an account to commit.

If you need an account or help figuring this out talk to Falun in IRC.  A reasonable Windows client is http://tortoisesvn.tigris.org/

Organization

     This is a suggested structure based on how we did it in NPPW-10.

• trunk/ - active development, we'll probably only use this
• source/ - the actual source code, python files, etc
• media/ - sounds
• music/  - specifically music
• images/ - images
• levels/ - any metadata needed for a level
• world-name/ - everything needed for a particular world
• scripts/ - any scripts we may use (cutscenes, dialog, etc)
• tags/ - static snapshots of our progress
• branches/ - if we have some random idea we want to explore it goes here