Wed, 14th Jul 2010 by Alfie.

Visual Basic 6 and DirectX 8 are looking very long in the tooth now, pretty much dead, but where to go?

I dabbled briefly with an early version of XNA (Game Studio 2.0 I seem to recall) when I was looking at alternatives for game programming languages/libraries, but wasn’t particularly impressed with it. Yes, it allowed rapid development, and most of the basics were done for you, but it seemed slow, and required doing things in a particular way, and seemed more aimed at the casual 2D game market on the Xbox 360 (although it supports Windows development as well).

With the advent of XNA 4 (due later this year) I thought I’d have another look at it and so installed the latest iteration XNA Game Studio 3.1.

Install Microsoft Visual C# 2008 Express Edition

Install Microsoft XNA Game Studio 3.1

Visit the XNA Creators Club Online, in particular their Getting Started section (based upon XNA Game Studio 3.0)

The video tutorials walk you through all aspects of getting started with C#/XNA;  setting up a Creators Club account, creating your first simple 2D and then 3D game, and there are ‘Starter Kits’ that help springboard you into different projects.

Bear in mind that you don’t need to purchase the full membership to develop games for both Windows and the Xbox 360, but you will only be able to deploy your games on Windows PCs without the full membership.

Its slicker than I remember, and much more streamlined, I’m actually going to give this another go

Posted in XNA, PC, Xbox, Programming, Video Games | Print | No Comments »

Tue, 17th Nov 2009 by Alfie.

I’ve been a bit busy lately undertaking a self-enforced C++ refresher course comprising two ‘Learning C++’ books, and some on-line tutorials as well as looking through two ‘C++ for Game programming’-type books (one on DirectX).

I now feel ready to tackle the pretty much required reading of Scott Meyer’s Effective C++ and More Effective C++.

So, if you see me around looking a bit dazed and confused you’ll know why

Posted in PC, Programming, Personal | Print | No Comments »

Fri, 30th Oct 2009 by Alfie.

So far, my design has revolved around the overall concept of the ‘game’. Although I have talked about the core, one thing not directly apparent from this design is that we will be building an ‘engine’ to form the core and handle all the main aspects. The game will sit on top of this core and provide all of the game-specific code, resources, flow, etc.

I decided to run an additional design stage on the engine to lay out the basics required separately to the game (although bearing in mind the requirements that the game will impose).

Essentially, we end up with several key criteria for our engine;

• The engine will encapsulate all of it’s functionality into a single interface
• It will provide 3D 3rd and 1st person graphics rendering
• It will provide sound effects and background music playback
• It will support, at minimum, keyboard and mouse for input
• If a multi-player component is decided upon, it will support network interfaces
• A scripting system will be used to provide control (and allow expandability)
• A resource system will manage loading and releasing memory with game assets such as meshes, textures, sounds, etc

I have already specified Microsoft Visual Basic 6 and DirectX 8 as requirements for this proof of concept, but I am going to structure it in such a way that I will be able to migrate it to C++/DX9 should I move on to a full product in the future as my experience of C++ grows.

In this vein I have decided to make the engine class-based. This sacrifices a small amount of speed to provide better encapsulation and readability/maintainability.

I will also be experimenting with constructs normally considered in C++ such as creating windows directly (instead of using VB forms), the message pump, sub-classing, etc. At this stage the design is still fairly fluid and I will need to evaluate these decisions to ensure that they do not compromise the ultimate goal.

Posted in Rain City, PC, Programming, Video Games | Print | No Comments »

Thu, 29th Oct 2009 by Alfie.

Alongside naming conventions it’s also a good idea to have some coding standards, such as layout, declaration standards, commenting, etc. This will aid readability, and understanding of purpose, and avoid issues due to default data/object typing.

Option Explicit
Option Explicit is used to ensure that all variables must be specifically defined to avoid issues of typos, unintentional data types, etc.

Scope Declarations
Private, Public and Friend will be used for all declarations and ByRef and ByVal will be used for all function/sub parameters as this avoids confusion over default assumed declarations that differ between programming languages.

Object Declaration/Destruction
Where possible, objects will be declared using the early binding construct, ex;
Private m_objMyObject as ObjectType
Set m_objMyObject = New ObjectType

Objects will be explicitly cleared with;
Set m_objMyObject = Nothing

This avoids issues with default object references, and hanging references.

White Space
White space shall be used to differentiate sections, prior to comments (so that comments are always associated with the code directly below them), and to separate distinct steps in multi-line functions.

Indenting
Tab indents (3 characters) should be used to differentiate elements contained within another element such as a sub/function, loop, if…then condition, etc.

Form/Class Instantiation/Destruction
All modules (excluding BAS) shall include a public Initialise() and Terminate() function to allow explicit set-up and clean up rather than relying upon inherent methods such as Form_Load(), Class_Initialize(), etc. This allows us to control the exact point at which modules are made available/unavailable (allowing us to perform setup and clear down at particular times), allows us to pass parameters (which VB does not allow in most intrinsic methods), and enforces a common structure of creation, set up, use, clean up, destruction.

BAS Modules
A BAS module (modMain) is used for the main start up ‘Sub Main()’ and clear down ‘CleanUp()’ procedures of the project, but otherwise their use should be restricted to global declarations and code common to many other modules such as common API functions.

Posted in Rain City, PC, Programming, Video Games | Print | No Comments »

Wed, 28th Oct 2009 by Alfie.

It is important with large projects, and even more so amongst teams, to have a common naming convention for your code. Having conformity of code layout aids readability, avoids confusion over scope and usage, and should improve productivity.

There are many naming conventions, each coder probably has their own. I had my own convention that I had used for many years, subsequently influenced by the MS Naming convention for VB.

I originally laid that convention out here but have since made some major changes to dramatically simplify it.

Some objects/variables use special prefixes to denote usage or scope;

• BAS Module  = M
• Form = F
• Class (standard) = C
• Class (Interface) = I
• Class (Singleton) = S
• User Defined Type = T
• Enum = E
• Member Variable = m_

Variable names should be descriptive, with the first letter of each word capitalised, no spaces, and where required a suffix qualifier can be used, for example;

• WindowHandle_Prev = variable holding a handle to a Window with the Previous suffix
• WindowHandle_Curr = variable holding a handle to a Window with the Current suffix

Suffixes include _First, _Last, _Next, _Prev, _Curr, _Min, _Max, _Cnt (count), _Src (source), _Dest (destination), etc.

Constant use names that are all capitals, qualifier suffixes can be applied.

• BACKGROUNDCOLOUR_BLACK

Values used within calculations shall use the optional suffix character (& for long int, # for double float, etc) to avoid accidental type coercion. For example (RotationAngle is defined as a double float);

• RotationAngle = RotationAngle + 0.1#

This is vastly simplified from my original convention, and is mostly influenced by looking through other peoples code, particularly C++ code, and seeing how complex to read so-called full Hungarian notation can be.

Posted in Rain City, PC, Programming, Video Games | Print | No Comments »

Fri, 23rd Oct 2009 by Alfie.

In my forays around the internet looking for examples and advice I have noticed that the majority of these sorts of projects flounder, fail, or stall out for varying reasons, but one key reason appear to be common; Lack of a clear, documented design goal.

Design for the win!

Having an idea is a good start but to keep things moving in the right direction you need a design document.

If you’re working with a team the design document is a way to clearly communicate what you want to achieve, what decisions you have already made, and the motivation behind them while for a solo programmer it is a way to ensure that you stay on target for what you want to achieve.

Design documents come in many shapes and sizes, but I would suggest that the key points to address are;

1. Clearly state the ultimate goal
2. Provide an overview of the main aspects
3. Specify the key features
4. Provide detail by section of each key area

1. For Rain City my goal is; ‘Rain City will be an immersive 3D role-playing environment utilising a ‘free-play’ system that does not constrain players to a set role or storyline. You will be able to develop relationships with the other inhabitants of the city and pursue your chosen role and any of the diverse sub-plots…or just roam freely.’

2. From this I can identify several aspects that form the goal; ‘immersive’, ‘role-playing’, ‘free-play’, ‘relationships’, etc and provide a bit more detail, including why these are important to our goal.

I also include in this section a set of common questions and answers, such as; ‘What is Rain City?’, ‘What is the setting?’, ‘What is the main focus?’, etc.

3. This section details the technical features; ‘3D engine’, ‘1st/3rd person view’, ‘interpersonal interaction model’, ‘character design system’, ‘storylines influenced by player actions’, etc. This allows me to build upon and demonstrate decisions that have been made about what to include, why, and further strengthen the design to meet the goal.

4. I then take each section in turn; ‘game world’, ‘characters’, ‘scenarios’, etc, and flesh out what decisions have been made and why, and what each section needs to achieve.

At this point I have made few technical statements, beyond the feature set, but have focused on look and feel, where necessary providing the background to that focus.

Because this is going to be based in part on a pen’n’paper roleplay system I also have a separate Rules document that details the underlying game system mechanics, and a Background document that details the game world background.

The combination of these documents provides the basis for all future decision that will be made during development. Where you would normally be quite strict in constraining the computer game within the bounds of the RPG game system and background, I have the flexibility to adjust those if it simplifies or enhances the computer game.

A design document doesn’t have to be complete when you begin coding, and will evolve during actual implementation, but it should be as complete as it can be by that point. This avoids going off target, or exploring other avenues already rejected, which both wastes time and can be divisive in a team environment.

Posted in Rain City, PC, Programming, Video Games | Print | No Comments »

Wed, 21st Oct 2009 by Alfie.

I’ve been tooling around with this game idea for what seems like forever (12 years) from originally wanting to write stories in the fictional world of Rain City, to turning it into a pen’n'paper roleplaying game (RPG), to wanting to translate that into a computer roleplay game (CRPG). But somehow, I never seem to get a finished product at the end of my dreaming.

In the early days of development I could blame it on 2 things; 1) Ridley liked to constantly re-invent the rules system to incorporate new ideas from other sources and 2) my programming skills sucked (I’m a self taught programmer).

Sometime in 2000 I took over sole development of Rain City (as Ridley was developing other settings) and separated it off from the current iteration of the RPG system that we were working on at the time. I had moved on from the original GFA Basic Atari ST and Windows drafts to Visual Basic (VB) and started experimenting with DirectX (DX), with the help of the DirectX4VB site. VB6 was a ‘mature’ language reaching the end of its projected lifecycle and I hoped to be able to build up a core engine that I could then migrate to Visual Basic.NET which was due out the following year. VB.NET proved to be a major step change from VB ‘Classic’ so after a year of learning .NET I felt I like I was learning a whole new language and got no nearer to realising my core engine.

In 2002 I decided to go back to VB6 and DX8 (as Microsoft chose not to support DirectX interfaces for VB6 above DX8) and started on the core from scratch. I bought books on VB/DX, I collected links to various tutorials and many code snippets (some 480 articles on game programming, techniques, and tips relating to VB and VB/DX). I experimented with several ‘development’ engines such as Genesis3D, Revolution3D, TrueSpace, etc as a short-cut to getting the core done so that I could concentrate on the actual game play.

In late 2005 I realised that I had half finished bits of a core engine in various hacked-about tutorials using various ‘development’ engines but still nothing that was in a state that could be completed to get me to that first stage. I had been working on it on and off with sometimes many months between programming sessions. I had started exploring C++ as an alternative programming language (the language most used for ‘real’ games development) and that had distracted me even further from my goal as I had to unlearn some bad VB habits.

Rain City went back on the back burner (again), and whilst I continued to collect articles about game design and add to my own game design document I was getting no closer to a core engine, and technology was advancing away from my development environment (DirectX10 and Vista were around the corner and PC hardware had advanced dramatically).

Now nearing the end of 2009 I feel that it is time to do this properly, as I should have planned for so many moons ago

I am building a class-based core engine to handle graphics, music, sound effects, scripting and minimal AI (pathfinding, environmental effects, etc). I will chart development through the course of these diaries…

Posted in Rain City, PC, Programming, Video Games | Print | No Comments »

Thu, 15th May 2008 by Alfie.

My ultimate aim is to do something that I have wanted to do ever since I read my friend, Ridley’s, first novella…re-create Rain City as a computer game. Rain City is the setting that he used for a series of futuristic short stories, and something that we worked together on to try to bring to a role-playing environment. I think that it’s different enough from most other games, be they computer or human mediated, to be interesting to people, fun, and potentially limitless.

Rain City could be categorised within the ‘cyberpunk’ genre, but in a far future rather than near future setting. This allows for ‘alien’ races, and a non-Earth environment, while keeping some of the feel of the film, ‘Blade Runner’, with its sprawling over-crowded cityscape, a thriving black market, and a familiarity with modern human issues.

Most of Ridley’s Rain City stories were based around corporate investigators tracking down a criminal who turned out to be more than they expected, and I intend to continue the ‘detective story’ style, emphasising role-play over hack’n’slash, and with progressive story-lines, yet where possible, free reign to play the game you want.

Character creation and development will be important, which both gets you into character to play the game and gives you a goal outside ‘kill as many baddies as possible’. Interpersonal relationships will also be important within the game, so conversation rather than combat, although combat will sometimes be necessary.

The initial project will concern itself with gradually building up West Sector from it’s 10 component districts, laying out the buildings; residential, business, public, and Corporation, populating it with ‘living’ residents, vehicles, and both core and non-core, linear and non-linear, scenarios to suit the variety of character types that you will be able to play within the game.

The emphasis will be on creating a role-playing environment that allows for character interaction, relationships, and inter-personal influence. Alongside this is creating a ‘living world’, a world that reacts to the impact that the character has on it through their actions and those of the people that they interact with.

Additionally, the game will need to be expandable through the addition of linked map spaces, scenarios, characters, objects, etc, and possibly modification of the physics system to support new objects. If required, editing tools will need to be created to facilitate user modification of the game so that other users can create ‘expansion packs’ for the game.

The ‘Proof Of Concept’ game will be developed using Microsoft’s Visual Basic 6 and DirectX 8.1 and should be playable on most PC systems running Windows and DirectX 8 or higher. Where possible the game will be designed to take advantage of high-end DirectX API functions, while scaling down for low-end PC systems.

Visual Basic and DirectX are copyright © Microsoft Corp.
The logo images used here are representative of the relevant products and no copyright infringement is intended.

Posted in Rain City, PC, Programming, Video Games | Print | No Comments »