Design Document

*The linked file at the end of this post is the current design document, detailing things like game-play mechanics, structure and story of the in-game world, character interaction, etc. It is very much liable to change.

It's amazing is how fast this much was generated, in only two hyperactive/manic meetings. Anyone who frequently attends GameDev can attest to the fact that we normally spend our time goofing off, so when we sat down and started hammering out details for the game, at the end of the day, we found ourselves fairly surprised.

Now there's barely any distinction between the Primary and Secondary Story designers, with the exception that the Primaries simply try to sort through the endless mountain of suggestions supplied by the Secondaries, and keep the game from sounding overly cliched. Everyone has contributed at least a little bit to the story, as well as to how the game should play out.

It's obvious that we as a club will not be reaching my initially proposed goal of four mini-games, nor will we finish this one game by the end of the semester, but as long as everyone has fun, and learns how to grow and organize ideas that can later be transformed into a game, then I'm happy. The purpose of the club, by the way, is not strictly the programming of games, but learning how they go from planning to implementation.


The file: game concepts.txt

DarkBASIC

This probably comes as no surprise to anyone who frequently browses the links at the right, but DarkBASIC Professional is now free for personal use (not commercial or educational though). For anyone who wants to take a more code-based approach to game design, but is too intimidated by the C-type languages and libraries that are widely available, this is a nice alternative to ease you into the methods of manipulating and managing game objects with code.


NOTE: The language used in DarkBASIC is, obviously, very similar to Basic, so if you're one of those people who firmly believe that learning Basic will inhibit your capacity to learn other programming languages, then maybe this isn't for you...

Project Roles

I'm just going to use this space to establish the official roles of the members of the group.

Lead Manager
Matthew Hydock

Lead Story/Conceptual Designers
Andrew Herring
Ben Cook

Secondary Story/Conceptual Designers
Allan Simmons
Garin Dangler
Matthew Hydock
Sean Fitzgerald
William Fisher

Lead Artist
Sean Fitzgerald

Secondary Artists
Andrew Herring

Lead Programmer
Matthew Hydock

Secondary Programmers
Garin Dangler
Matthew Miller
William Fisher

Music/SE
Ben Moser
Derek Robertson

This post will be edited as members decide what they can contribute to.

Getting to Work

Ok, it's taken a while, for various reasons (one being the diminutive size of the club at this point), but we finally have an idea for a group project. Our current goal is to create parts of a Role Playing Game (RPG), in Python, because the computers in our room are Macs and because Python is fairly easy to learn.

At first this sounds like a rather foolish idea. Many game development groups at first think "let's make an rpg" or worse "let's make an mmorpg." These are both VERY difficult tasks, due to the complexity of the underlying systems and the span of an overarching story. We recognize this, and so as not to drive ourselves mad, it was specifically stated that we are doing PARTS of an RPG, namely the battle system, and a basic overworld exploration system.

It has been decided that the battle system will be worked on first, and many of the roles have already been designated, with the art team in control of the style and themes, and the programming team ready to bring it to life. We have yet to acquire anyone devoted to music or sound effects, so both teams will contribute when they can.

Information and screen shots will be posted when available.

New Semester

The fall semester has begun, and ShipGameDev is back in business! Meetings will be held Fridays in MCT 165 again, from 2-5PM, though some members have already claimed a later time may be better. If enough agree, the time will be moved up an hour, but the day and room will remain the same.

Last fall, I attempted to steer the entire group into working on a single project. Unfortunately, we were incapable of coordinating, some of us had different ideas, and others couldn't get a hang of the software. Come spring, I decided to break us up into many groups, and work on several projects, which seemed to work a whole lot better.

And so, this year we will be working on independent projects. Those who are semi-knowledgeable with game design shall form their own groups, while those who are new will go through a couple "lessons" with me, then join whatever group piques their interest, or form their own if they are confident enough.

By the end of the semester, I hope to have 4 mini-games finished or near-complete. This isn't that hard of a task, so let's try our best!