Introducing… GHOSTBALL

Time is up, and my entry is about as ready as it ever will be. Introducing… Ghostball!

Ghostball.exe is 8.66 Megs in size and can be downloaded here:

No installation is necessary, however some Vista and Windows 7 systems may need older DirectX files (9.0c)  to run it. These files can be downloaded using Microsoft’s DirectX End-User Runtime Web Installer.


Posted in Diary | Comments Off

The Toolchest Used to Build this Monster

While the program bounces around a couple of playtesters, I decided to make a post about the programs used in this project.


When Turbo C++ added the Object Windows Library (OWL), it brought programming Windows apps to a new level for me. I no longer had to code all of the tedious and redundant construction of windows and various needed components. A lot of the low level stuff was handled by OWL and the Windows API, allowing me to pretty much to concentrate on the meat of my app more and the building of its framework less.

DarkBASIC made the same leap for me. Prior to DB, the last time that I used DirectDraw or WinG (or whatever it was back then) I had to define a draw surface, create the surface, manage the blitting of the objects on the refreshing of the surface, and do many other time consuming tasks that took away from the actual writing of the program. In DarkBASIC, there are several areas where I can execute in one line of code what I previously had to write an entire function to do. It removes the unnecessary task of cutting and pasting the same functions from program to program when the only changes those functions ever see are just a handful of variables – basically the resolution and color depth.

AC3D –

Easy to learn, inexpensive, support for multiple formats. As a complete novice at 3D modeling, I really found AC3D to be a great program to work with. I wasn’t overwhelmed with menus of options and features that I would probably never use for years to come, and the tutorial gave a great overview of everything that was available to me inside of a few dozen pages.

Almost every object in Ghostball is made using primitives, so the main reason for using AC3D was basically to actually create an original 3D object and texture it for the project.

Adobe Photoshop CS2 –

Although it is complete overkill for this project, my Wife owns it so it seemed silly not to use it. All the environment and object textures were created using Photoshop. The biggest advantage of programs like Paint.NET, GIMP and Photoshop  over just using MS Paint is the ability to quickly create layers, which makes it very easy to generate walls and other textures that have minor variations.

Microsoft Music Producer - (no longer available)

By far, the most entertaining and frustrating part of the project. This program can easily and instantly create horrible music. After a few hours, my goal shifted from creating good music to creating remotely-less-than-terrible music. Since I’m not a musician, my only alternative here was Hip-Hop eJay 5, and… yeah.

So that’s the arsenal I took to war with me, and they all performed wonderfully under fire. With the exception of Photoshop, it is a suite of tools that is extremely inexpensive with a very low learning curve to it.All in all, the ease of use greatly sped up my ability to actually use the programs to get the project done.

Posted in Diary | Comments Off

Playtest Week Begins

As far as the contest rules and my own chart are concerned, the goals have been met, but I want to get input on how to improve this above and beyond that. To that end, I’ve recruited a few people to playtest the game and give some feedback on bugs, fixes, etc.

More to come, soon. :)

Posted in Diary | Comments Off

Game Testing Results: My Cool Map Sucks

Conditions for winning and losing coded.
Map of inside of a computer completed.

With the above done, I went to playtest the game that I had created and found that by removing the walls and replacing them with objects to simulate the inside of a computer, I had effectively changed the game into a set of very large rooms. The player could easily tell they were inside a computer, with readily recognizable CPU, circuit boards and memory cards but the hunt aspect of gameplay was now removed as most of the enemies were now in plain view.

Improving the atmosphere broke gameplay

A few days were spent trying to adjust heights but the look and feel I was going for became more lost with each iteration.

Solution: Scrap the computer idea and go with our enemy manifesting itself inside an environment that is more conducive to having multiple rooms and walled off sections. I decided to go with Server Farm. As a server farm is normally a rather bland room of cream colored and grey boxes, I looked for excuses to add splashes of color here and there and I readily admit that in some areas there is art that looks cool but probably makes no sense whatsoever. :)

The game world gets a new setting.

Posted in Diary | Comments Off

Collision success! … and an overview

It seems I was simply over-complicating collision detection. Since I am not checking for collision with anything but the object I have locked to the camera, there’s no need for me to create collision boxes for anything but the camera.

The first step was to save the current position of the camera


The next step was to move the camera when a key was pressed. After moving the camera, I checked to see if there was collision. If so, move back to the saved location.

POSITION OBJECT 4900, camera position x(),camera position y(),camera position z()

    IF OBJECT COLLISION (4900,0) > 0
        IF OBJECT COLLISION (4900,0) < 4900

And we’re done!

While this works, it’s extremely crude collision detection and if time permitted, I would use sliding collision, which gives a much more fluid motion as you move along walls. The way I have it written pretty much just stops the player on collision no matter what angle they hit the wall at.

With collision now working, I decided to revisit the Chart o’ Post-Its.


Basic Move and Shoot ControlsDone. Arrow keys to move, mouse to target, LMB to shoot.
ProjectileDone. The projectile was scrapped as shooting was accomplished by creating a cross-hair that you move with the mouse and adding visual and sound cues when the selected mob was shot and destroyed.
Dungeon/ZoneDone. The layout of the map is complete, as are the objects in the zone. Still working on the textures as the biggest challenge is maintaining a uniform look to it all.
Original CodeDone. Still all original code. The tiny size and the simplicity of what I am writing makes the trial and error process feasible for identifying errors. So far, I have been able to figure everything out with the manual and the IDE’s help system.


Final GoalDone. When all the mobs are zapped or when all the files are corrupted (i.e. – time runs out) the game ends… abruptly and without warning. Any type of audio/visual treat for success or failure is noticeably absent. While not needed for the challenge and not on The Chart , I’m considering adding it to the “Want to Do” column so that it is scheduled if there is free time at the end to do it.
Original ModelsDone. Almost everything is a block of some sort so there isn’t any amazing 3D model wizardry here.
Reasonable StoryDone. The story will be in the email when it is submitted, however an Intro is still in the “Want to Do” column. If you can accept being inside a computer, running around and shooting blob-like viruses, then the story is one that’s reasonable enough. :)
Original ArtDone. So far we (my Wife and I) have been able to create everything we need without resorting to scanned or web graphics.


MusicDone. Background music is complete. It’s… well… listen for yourself: Ghostball Music
UIDone. No buttons, no extras. Just a frame to hold the game name, messaging and instructions.
Gauge of ProgressDone. Both your progress and the timer are displayed on-screen.


Introduction - Not Started.
InstructionsDone. Instructions on how to play are visible on the user interface.

Posted in Diary | Comments Off

A-a-a-and I spoke too soon.

It’s been a week of interesting hurdles.

Collision - I’ve been hitting walls left and right on this one, literally and figuratively, so I’m going to take a break from it for a while and then revisit it. The I *can* get it working, but frames per second drops to about 10-15. Since it is a very simple game and the shapes aren’t much more than cubes, the most reasonable conclusion is that I’m either trying to check too much or simply doing it wrong.

Music - Trying to find music that fits the theme seems to have proven harder than I thought, although it’s been extremely fun playing around with different types of songs to see how they fit with the game. I asked a couple of friends for their input and most seemed to agree that electronica  and ‘dub step’ would be the best fits.

The enemy – a challenging enemy would have required somewhat decent pathing or AI, neither of which I was having much luck at despite several long nights of hammering away at it. I decided instead to go with time as the opponent. The player must zap all the infections before all of the files are corrupted. The file corruption counts down, and the player will lose if all files are corrupted before he zaps all the infections.

Tomorrow I will try to wrestle with collision again. For now, that’s the biggest road block.

Posted in Diary | Comments Off

Making Decent Progress

I was going to wait until later in the week to do this, but there’s enough done to make it worth writing now. Below is a breakdown of each item on my Chart o’ Post-Its and the status so far.


Basic Move and Shoot Controls
Arrow keys for movement and mouse to target and fire are in game and working. DarkBasic makes it extremely easy to assign behavior to keys and to manage camera movement.

The launcher is done and in game. I created it as a 3D object, however I could have just as well used a sprite/2D to create it. I went with 3D for two reasons. First, to actually create and texture a custom 3D object. Most of the objects in the game currently are primitives, which are basic building blocks provided by the 3D engine (cubes, plains, spheres, etc). Second to allow for animation or movement of the launcher if necessary or desired during gameplay.

I haven’t started this yet. Since targeting is done by manually selecting the target, collision detection and trajectory code is pretty much reduced to traveling between two known points. I also haven’t created the ‘bullet’ yet, which is probably something I will work on early this week.

The functionality of the game world is there and not. I can build a waorld, render a world and move in the world. Collision still has yet to be coded and both the artwork and the final layout are works in progress. On paper, half the battle is fought. In reality, there’s a good chunk still to do in coding, art and design.

Original Code
After the initial two or three days of studying everything I possible could have in that time period, I have steered cleer of any code other than that which the IDE’s help system and the manual provide. So far I can honestly say that this game is 100% original code, which meets the requirements of the challenge and is also something I am rather proud of.


Final Goal
The final goal has been established. There is a finite number of enemies and a clock ticking down. The goal is to zap all enemies before the clock runs out. I’m hoping there is time at the end to establish some reasonable fanfare for completing the goal.

Original Models
Most of the models in the game are primitives. As mentioned earlier, primitives are pre-existing shapes or ‘building blocks’ that one can use in the 3D environment. Currently the only custom model is that of the launcher.

Reasonable Story
The story in a nutshell: A virus is inside your machine. You have entered your machine and, with the aid of the Virus Zapper 2010, you zap all infections before they destroy all of your files.

Original Art
All of the textures currently in-game have been crafted by my wife and myself. One can readily tell who did which as hers rock and mine seem to fall into the -less-than-stellar category.


I have poked around with the music and I have decided that part of the audible awesome for this game will be created using Microsoft Music Producer. I’ve been looking for an excuse to use this damn program for almost 15 years now and now I have found one. Muhahahaha!

A framework for the UI has been created. Several goals were hit with this one as it contains information to gauge progress, instructions how to play and a callout or two to present the ‘story’ or in-character view of what the player is doing.

Gauge of Progress
The number of files remaining and the number of infections left to zap are displayed. As the file count drops, the number changes to yellow at one preset marker and then orange and then red  to convey urgency and graphically represent time ticking away without having to glance at the numbers too often. The number of infestions remaining is displayed in a very large font on the Virus Zapper 2010 so that the player can clearly see how many he has left to zap.


I’d like to do an introduction or at least a splash screen but I am not sure there will be time to do that as the last few days will be bug fixes, tweaks and playtesting. With everything that I *need* relayed already being shown on the UI, the intro seems less and less important to include.

I wanted to make sure that anyone could understand the goal of the game and just start playing without needing any additional resources. All instructions are now currently presented on the UI.

Posted in Diary | Comments Off

Note to self: Add Gallery Section

Spent a good 5 or 6 hours together with my Wife, creating artwork for walls and floors. We went from a computer theme to Egyptian to contemporary office and back to the original computer idea. All together we created about 40 or 50 textures, with only about 5 of them actually going into the game… for now. ;)  Later this week, I’ll probably put the art up as free textures for whoever wants them, Until then, here are a few images from the weekend.

This is your enemy! The nefarious Ghostball virus has returned and is eating your files. Blast him before all your data is gone!

Virus Zapper 2010 - a specialized PDA for people who travel inside computers to manually blast viruses. Exactly.

The walls we created that we thought looked cool but matched absolutely none of the other artwork whatsoever.

Screenshot of one of the themes we put together in the process of coming up with a theme or environment for the game. (Click to enlarge)

Posted in Diary | Comments Off

Stepping Foot Inside

So, “shortly” turned into “the next day” as I lost track of time with my discovery of DB’s debugger. The time was well spent because it will result in a lot less adding/removing of print statements throughout development just to track values and the state of object.  I’ve accomplished a decent amount the past day or so, programming-wise. Code is in place and working (YAY!) to create the objects and build the game world. Camera/player controls are in to use the arrow keys to move around inside the game world. I’ve started working on the mobs that will be in game. So far I’ve been quiet about the theme/goal of the game and, to be completely honest, it’s because I haven’t even tackled that yet. It’s a Should Do, though. ;)

So far The basic controls are half complete. Shooting still has to be implemented. Dungeon/Zone/World/Level thingy is functioning but will change in both layout and appearance over the next couple of weeks.At the end of next week I’m going to revisit the Post-it wall to see how far along we are.

The video below shows what I’ve got so far. Enjoy!

Posted in Diary | Comments Off

Constructing the Stage

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 #
.# S                       # #
.#   ############          ###
`Variables and User-Defined Type

CELLX = 30
CELLZ = 30



`Load Map into Array

    FOR X = 1 TO CELLX
        READ BYTE 1,TMP
        IF TMP > 30
            CELLS(X,Z).OBJTYPE  = CHR$(TMP)
            OBJECTID = OBJECTID + 1
            X = X - 1
    NEXT X

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. :)

Posted in Diary | Comments Off

Organizing This Mess

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!

*I have every intention of dragging my Wife into this mess for art later in the process.
Posted in Diary | Comments Off

So Many BASICs To Choose From

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*

Posted in Diary | Comments Off

In the beginning…

About this blog

This blog is going to chronicle my thoughts, progress, obstacles and solutions as I create a basic first person shooter for a game programming challenge at The challenge started at the beginning of September and ends on October 31st. I’m jumping in pretty late in the game, but the smaller window of time makes it just that much more enticing of a challenge. :)

My goal is to successfully create a very basic functioning FPS. If it ends up actually being fun, then that’ll be a welcomed bonus.

Plan of Attack

My first steps will be to create a chart of what needs to be done and to write out an initial battle plan. After that, my next step will be to pick a suitable programming language. I’ve a basic familiarity with Pascal and Basic. Very basic… and since the last graphic programming I did was with the brand new WinG library for Windows, I’d say my knowledge is both very basic and very outdated. Eh, we’ll find a way to pull this off. :)

Posted in Diary | Comments Off