Another Fork in the Road

To build the little world that players will be plinking at things in, my two main choices are either importing a BSP  that I can create with one of the many utilities currently available for existing FPS’s or creating the game world manually. The makers of DarkBASIC also sell a 3D World Studio program that would probably be the best route to go, but that option comes with a price tag of about $50. Using a Quake level builder would probably speed things up, and the 3D World Studio’s price tag isn’t bad at all, however I think I’m going to go with manually building the game world. I’d benefit more from focusing my efforts on learning DarkBASIC rather than spreading the learning love in multiple directions.

The Great Little Tutorial that Kinda Sorta Could

The Huge Dungeons tutorial on the official site gave me all the information I needed to build my game world. It demonstrated how to convert a 2D ASCII map into a 3D world. If I keep the design completely simple, I can avoid needing any third party tools of any kind to create the world environment. I think what helped most about the tutorial code is that it doesn’t work right and only barely does what it’s supposed to. Figuring out where and why it’s broken helped me better understand how it worked.

So now the game within a game begins. I made my notes and shelved the tutorial in order to begin coding. Once the FPS is finished, I plan to go back and compare the tutorial code with how I coded mine to see where the similarities and differences are.

The building blocks of my dungeon…

I’ve decided on a small map, 30×30, in order to both keep resources down and keep the project from getting unwieldy. Creating the map was a fun little exercise in Notepad, and to read it I defined an array to store the type and number for each cell of the map.

..................#####.......
..................#   #.......
............########D####.....
....#########           #.....
....# D     #           #.....
....# #     D           #.....
....###     #           ######
......#     #           #    #
......####D##           D    #
........#   #           #    #
........#   #######D##D##    #
........##D##.....# #   ######
.........# #......# #        #
.........# #......# #        #
.........# #.....## ##       #
.#########D#######   #       #
.#  #           ###D######## #
.#  D           #          # #
.#  #           #          #D#
.####           #     #    #  #
....#                 #    D #
....#           #     #    # #
....#           ##### # #### #
....#           #     #    ###
.####           #     #    # #
.#   ############     #    D #
.# S                       # #
.#   ############          ###
.####...........############..
..............................

`Variables and User-Defined Type
`================================

CELLX = 30
CELLZ = 30
STARTMAP$ = "MEDIA/MAP01.TXT"
OBJECTID = 1000

TYPE CELLINFO
   OBJTYPE AS STRING
   OBJNUM AS WORD
ENDTYPE

DIM CELLS(CELLX,CELLZ) as CELLINFO

`Load Map into Array
`================================

OPEN TO READ 1, STARTMAP$
FOR Z = 1 TO CELLZ
    FOR X = 1 TO CELLX
        READ BYTE 1,TMP
        IF TMP > 30
            CELLS(X,Z).OBJTYPE  = CHR$(TMP)
            CELLS(X,Z).OBJNUM = OBJECTID
            OBJECTID = OBJECTID + 1
        ELSE
            X = X - 1
        ENDIF
    NEXT X
NEXT Z
CLOSE FILE 1

…
The next step is going to be creation of the objects from the data we have. I’ll post an update with that shortly as I am in the process of writing that now. These blogs actually serve as a nice diversion when I want to take a break from the project itself. The other alternative is Civ 5, but I know if I dare fire that up I’ll get nothing done for the rest of the night.

So, about that GDD…

I’m skipping creating a game design document for several reasons. The primary one is that I can already see in my initial attempts at it that I would spend more time detailing a working game than outlining what needs to be done in order to simply make a game that works. I may end up regretting this decision later, but I think I have a reasonable alternative to go with.

A design document’s main purposes are to lock down the vision of the project and provide the details of the project so that all parties involved have one, central, evolving resource to refer to. Since I’m flying this plane solo for now*, I need to just assess what the vision is and what features to commit to.

The vision is the easy part.

Create a functioning game that meets the requirements of the challenge:

• Gameplay must revolve around shooting things.
• The game must be represented from the eyes of the player character

The features and commitment were the challenge.

I decided to make a list of what I want/need in the game and then spent a good amount of time prioritizing it. The list completely lacks detail because the depth of what we are doing here is, well.. actually, it’s an insult to the word ‘depth’ to use it in any shape, form or manner related to this project.

• original code, no copypasta served here!
• a dungeon or zone to play in
• a projectile
• a launcher
• an intro
• in-game instructions
• a user interface (UI)
• a final goal or endgame condition
• a plausible story as to why the player is doing this
• a visual gauge of progress
• basic controls to move and shoot
• music
• original models/art

To organize the list, I set up a board with four columns and labeled them – Must Do, Should Do, Could Do and Want to Do.  I then wrote each item on a Post-it and started putting them on the board, arranging them in the appropriate columns.Below is the breakdown that I came up with.

MoSCoW Chart

MUST DO:Basic move and shoot controls, launcher, projectile, dungeon/zone, all original code

SHOULD DO:final goal, original models/art, plausible story, original art

COULD DO:music, UI, gauge of progress

WANT TO DO: intro, in-game instructions

The process is my very simplified and time-pressed adaptation of what is known as “MoSCoW Prioritization.” The next step would be to assess the time it would take to accomplish each task on the board. That’s really an important step and if I had the slightest clue how long half of these steps would take, I would at least make some wild guesses here. Unfortunately, I won’t know how long each step will take until DarkBASIC and I spend some quality time together and get to know each other.

I know there’s a few items there that may cause one to quirk a brow, but there actually is a method to my madness.One of the glaring ones is UI. The User Interface is normally extremely important. Having a friendly user interface is even better. In this case, considering the email to the judges/reviewers can simply have “Arrows move, Mouse targets and fires,” the user interface can fall into the Could Do category.

Atari 2600 - Adventure

Plausible Story could probably have a much lower priority but this is just a ‘button’ of mine. Actions without context are meaningless and boring. Making a ball move to the cursor location to hit the square leaves the user asking “Why?” Firing your cannons at crates to destroy the enemy’s supplies before they get to them is more enjoyable because there is a reason for why the user is being asked to do these actions. A classic example would be Atari’s Adventure game. Moving a dot around obstacles to find keys and fight ducks doesn’t make the slightest bit of sense, but venturing out from a castle to collect treasures and fight dragons suddenly makes piloting a little square a whole lot more fun!

Anyway, tomorrow we venture out into 3D space and see what we can build. Til then… cheers!

The Pascal options were looking grim, so I went through my boxes of diskettes and CDS to see what I had down the line of BASIC choices. LibertyBASIC, PowerBASIC, MS Visual Basic, DarkBasic, BlitzMax… I had purchased or downloaded each of these at one point or another and they, like many other programs I had purchased on a lark, sat around collecting dust in the dark recesses of the computer room closet. But wait… what’s this? Such wonderful words were written across the top of the DarkBASIC Professional box:

“Write incredible 3D games, applications and presentations with ease”

DarkBASIC Professional

I flipped through the reference manual and peeked at the 3D sections. It seemed like it had everything I needed but, then again, I really am not sure what I’m going to need yet. It was however designed for game programming so that put it leaps and bounds ahead of the others for the task I’m looking to accomplish. Googling ‘DarkBASIC’ I found that the makers were not only still around (I bought this in 2002 or so) but that the program was going strong and still being updated.

After an hour or so, DarkBASIC was installed and updated, ready to aid me on my journey into the wonderful world of 3D game programming. Now, it’s off to the web to digest as much as I can in order to get started creating my FPS.

*starts a fresh pot of coffee for a long night*