The World of Goo has a tentative release date of February 14 or Valentine’s Day, whichever comes first. This game looks interesting, although there aren’t very many details. The video kind of fills in some of the void, but I certainly like what I’ve seen so far! Indie (independent developers) developers have been having a great time these last couple of years. Due largely to the sales channels created by companies like Microsoft for their Xbox 360 Marketplace, or even Nintendo’s Wii – although they haven’t seemed to really use it to its full potential yet. As a company of two, Ron and Kyle seem to be creating something unique and interesting. I can’t wait to try it! Maybe I’ll put my money where my mouth is and pre-pay for an indie game which hasn’t been released yet…

Categories: Games, Indie Games, Nintendo Wii, PC
No Comments »

There is a game in development right now which can take objects drawn with “Crayons” on screen and apply physical properties to that object. Influences like gravity, collision with other objects, friction are all applied once the object is drawn. You can even draw a a small hole on the object which can represent axial mobility. For example, draw a circle with a small hole in the center and it can act as a wheel, connect two wheels together with the frame of a car and it becomes a car. The object of the game seems to be about collecting stars by drawing objects and getting them to interact together so that the stars can be collected. Pretty neat idea!

Categories: Games, Indie Games, Nintendo Wii
No Comments »

I first discovered this little gem while poking around on my Tandy 1000 RL computer back in 1991. Because I was familiar with various versions of BASIC already, I was able to fire it up and immediately begin writing fairly simple applications. However, there were differences to Atari’s version of BASIC, and no discernable way to figure that out without a book or some other documentation. I poked around on a few of my favourite Bulletin Board Systems (BBS) and found a small cache of programs written in GW-BASIC. I downloaded each of them, spending all of my download credits in the process. I poured over them line by line and found myself having more questions than answers.

Many new programmers today expect there to be some sort of documentation available when they learn a new technology. It’s an expectation that has evolved over the years. Today, it would be practically unheard of if you couldn’t find some resource describing the software on the Internet, or some blurb in a book, or even bundled with the product. However, when I started looking for a book on GW-BASIC (version 3.23 to be exact), it was darn near impossible. The people I spoke with had no understanding of programming, let alone a specific language. The computer sections in the store were spartan compared to the sections you find in stores today. In fact, several years later, I still needed to special order the books I wanted through the book store; even today, I usually order my titles through Amazon since a store like Indigo usually doesn’t have them in stock.

I eventually wandered into a local computer store – I was attracted by a demo of Wing Commander II playing on one of their expensive new 486 machines, so I went in to ask them if they knew where I could get my hands on some material. I spoke with the owner and he seemed to recall seeing a book for BASIC in the back of the store. He left for a couple of minutes and returned with two books under his arm. One was for the exact version of GW-BASIC I was looking for and the other was a compatible book for MS-DOS. I was ecstatic and I nearly fainted when he gave them to me for free. I don’t remember what I said to the man that day, but I’m sure it wasn’t adequate.

I wrote so many programs in that environment. I think I still have a few of them today on floppy diskette. They were simple at first, like simple word games such as hangman. However, it wasn’t long before I discovered how to increase the resolution and colour depth and draw simple graphics. I had already written code for the Atari which made use of pixel plotting routines or simple geometric shapes. There were pre-canned routines the Atari provided for drawing shapes, along with a few parameters for style, colour, and shape. GW-BASIC was similar but provided several more commands and options. With a smaller font and a higher resolution, debugging within BASIC became more feasible. I still couldn’t scroll, but at least I could view a larger portion of the code on the screen.

Sound was also possible through the PLAY command, or if you were so inclined, through a custom routine written in assembly language which could be written to generate all sorts of sounds like noise or even speech. I had converted several songs using music sheets and converted them to their GW-BASIC equivalent. Not terribly exciting, but it did make for some creative demos which seemed to impress onlookers.

Some of the more interesting projects involved controlling external devices like printers. I must have programmed my software to use every conceivable option available through my Star NX 1000 II dot-matrix printer. I could instruct it to use standard type effects like bold and italics when printing text, but I could also program it to print graphical data like images and shapes. I even created printed graphics for the Mandel Brot set by rendering the fractal to my printer instead of the screen, one pixel at a time.

Perhaps the most interesting device was a robotic arm which was controlled through a series of commands dispatched through the parallel port. I didn’t have access to such a device at home but my school eventually purchased one, so one of the teachers decided to create a contest for students. Whoever could program the robotic arm first, would win a special prize. The task was to pick up a piece of chalk and draw a picture consisting of at least four shapes. It was a fun contest and I walked away with a pass which granted me as much lab time as I wanted.

Before I upgraded to a new machine and moved to a new version of MS-DOS, I was intimately familiar with every command in that book, even the more obscure commands like CHAIN and PCOPY. Although, the really obscure commands were still a mystery. I didn’t know you could actually write assembly language routines in GW-BASIC using DEF USR and USR commands until sometime later.

Categories: PC, Programming, Reflections, Software
No Comments »

At around the same time I discovered DeskMate, the Amiga OS made its entry into the market as the aptly named operating system for the Amiga computer. Until recently, I had never owned an Amiga machine. I spent a fair amount of time with friends mucking around with various bits of software and hardware. One of my favourite combinations was the NewTek Video Toaster which was a powerful video editing software kit. You could do all sorts of video effects and overlays due to a technology called genlock. Genlock allowed you to synchronize different signals so that their sources become coincident, which made it possible for you to place blackout bar over your sister’s face just for kicks.It also sported several hardware and software features which I had never seen before. Real hardware multi-tasking was available on the Amiga 1000, but we mostly used the Amiga 500 which wasn’t as sophisticated in the same areas but provided terrific hardware for games. A friend of mine had a massive collection of software which were all archived in a custom-built diskette storage case made of wood and decaled with the Amiga logo. When we weren’t playing games and slogging through his massive collection of software, we were programming in Amiga BASIC or the occasional dip into the Lattice C compiler. I didn’t really understand the compiler since it was my first experience with a compiler, and it’s really difficult to learn a new programming technology when you have no means to experiment in your free time and no books available to read. At the time, I really wasn’t that interested anyway because I really connected with the structured BASIC available on the Amiga. It was a technology I could more readily understand because of my experience with Atari’s BASIC and Tandy’s GW-BASIC.

The Amiga OS made a strong impression on me as to what I was missing when I used a personal computer running DOS or Windows. There really wasn’t any comparison at the time. I remember feeling a bit underwhelmed whenever I switched my machine on after returning from a night of Amiga fun. However, after a few hours I was back into full swing. I’m not sure if I came to the realization that the machine I owned presented me with all sorts of different puzzles and tantalizing delights, but I do remember feeling like there was so much more to explore and learn. I believe that is what kept me from begging my folk’s for an Amiga every time I returned home. Although, I might have asked once or twice…

Categories: Amiga, Reflections, Software
No Comments »

Despite Tandy’s DeskMate application which tried to handle a number of disk and application related functions, MS-DOS (Microsoft Disk Operating System) was the actual operating system on which Deskmate needed to operate. I had experience with an earlier version of Microsoft’s DOS which I used at school; I believe the versions were 2.0 and 1.25. Unlike today where hard drives are common place and often taken for granted, the machines in the lab could only boot by way of 5 1/4″ floppy diskettes which contained the operating system. I believe the Tandy computer came with MS-DOS 3.42 and it was pre-installed on the hard drive. This was so much better than booting from a floppy, and I quickly assimilated as many commands as I could, since the school never gave me the time I wanted on the machine or the resources. Even with the aid of a text book, there were a few commands which took me a while to grasp, like COMMAND.COM or DEBUG.COM. My understanding of these wouldn’t completely solidify until I started programming in lower level languages like C and assembly language. I was also introduced to Microsoft’s shell scripts which they called Batch files. With the addition of extra software on the system, these scripts could actually become fairly sophisticated. Before I moved on to greener pastures and more flexible user interfaces, my system had sophisticated menus and launchers which helped my family out when they wanted to use the machine (it wasn’t often, but it did happen).

Version 5 was a much more refined operating system and contained powerful commands and programs like QBasic. It also featured a memory manager which allowed software to access all of that wonderful new memory that you may have been fortunate enough to acquire. Although it was included in MS-DOS Version 4, I believe the DOSSHELL command’s popularity spiked in Version 5. This was a program which was intended as a graphical replacement to the dull COMMAND.COM shell. It introduced a feature called task swapping which allowed you to load more than one program but only run one of them at a time; unlike multitasking which appears to run more than one program at the same time. Also, DOSSHELL could not load more programs than your memory would allow since it did not have a paging mechanism. Naturally, all of these benefits conflicted with the new versions of Windows which did exactly the same thing only better, and was soon relegated to a supplemental disk in future releases before being dropped entirely.

Version 6 introduced the much feared DELTREE command. DELTREE was a command which could recursively remove directories and files; it was so feared because new or untrained users would presumably delete their entire operating system accidently. If this was indeed a problem, I think they should have modified the program to make it more difficult to accidently trash your operating system by adding extra prompts and warnings for example, since it is a very useful command in some circumstances. Despite its notoriety, it was a fairly simple command as far as software goes, and the void was soon filled by programmers who released new versions on the Internet which did exactly the same thing only better; I wrote a utility to replace it as well but mine displayed a user interface if you specified the right command option.

Categories: DOS, Reflections, Software
No Comments »

A very effective strategy when trying to dig up the treasure maps on Harrow Island is to choose a quadrant on the island for each piece of the sea chart which you have already collected. When you start digging, just start around the perimeter of the square and dig a hole every other space. You don’t need to dig your holes right next to each other; I uncovered a treasure map the first time for each quadrant using this method.

Categories: Games, Nintendo DS
No Comments »

Have you ever noticed how addicting the fishing mini-games are within games like Breath of Fire or The Legend of Zelda? I’m playing Phantom Hourglass right now and the fishing game is a lot of fun. Although, I don’t believe it will grow to be as detailed as Breath of Fire III’s mini-game with the shear number of lures and fish species. Zelda’s latest game does record your largest catch size for each fish and there are prizes for catching big or rare fish.

Categories: Games, Nintendo DS
No Comments »

While I’m waiting for OS installations or code compilations to finish, I’ve been playing this great game on Xandros called Neverball. It’s a game similar to Monkey Ball, which is one of my faviourites on the Game Cube. It’s very polished for an open source game and is complete with the exception of minor enhancements or bug fixes from time to time. Its only dependencies on Linux are the most common SDL libraries: core library, SDL_image, SDL_ttf, and SDL_mixer. It doesn’t compile so well on Intel Macs, but I should get that working pretty soon. I believe there is an Xcode project file available too for those who choose to take the quick and easy path. I may soon walk the path of the dark side, depending on how quickly I can resolve these obtuse linker errors.

Categories: Games, Programming
No Comments »

There are two sides to every coin. Game development can be hard or game development can be easy. These are relative terms, of course. Just because writing a game can be easy, doesn’t mean your grandmother could do it (although I wouldn’t hedge any bets, especially with mine). Personally, I think writing any finished application is an achievement for any programmer working alone. With the help of my colleagues, I have produced several applications which have made it onto store shelves, but I won’t take the credit since my part was just one piece to the puzzle. Of course, some applications cannot be programmed by just one person. Oh sure, one software developer could work for years or decades to achieve their goal, but who has the time and talent required to design and engineer something as complex as Metroid Prime, Photoshop, or the KDE Desktop on their own? It just doesn’t happen in the real world because life inevitably steps in and takes over.

However, all is not lost for the eager programmer setting out to create a game. It all boils down to following a few simple rules and having a few good resources available. For the next couple of weeks, we’ll look at some of the tricks of the trade and present a list of books which I have found very useful while exploring game development. So, without further procrastination, let’s dive right in to our first topic.

Game Design – The key difference between finishing a game and an unfinished hack is managing expectations. Yes, we would all love to design and build a game like Halo, but that’s not terribly likely and will almost certainly lead to failure. Instead, try and reduce the scope of the project by carefully choosing the characteristics of a game you wish to include. Care must be taken to use only those features which are absolutlely necessary. You should spell out how you want your game to work, what features need to be written, and any third party tools you plan to use which can save you time. In essence, you need to write a bit of documentation. Yes, I know, documentation is a bore and some of you may find it difficult. But you don’t need to write a best-selling novel, just outline what you want to do and how you want it to work.

By translating those exciting images and ideas you have into something concrete, you’ll be able to assess your goals and overall design much more easily. It also makes your game much easier to digest for other people. If you wanted to hire an artist, for example, you would need to describe the concept in fragmented conversations over the phone or via the Internet. It would make the job of the artist so much easier if you had the design for the game already completed. In fact, most artists (the smart ones anyway) won’t accept a contract without a working game design in place. Without this document, you would be unable to tell the artist which assets need to be produced now and what can wait until later. If you know all of the work which must be completed before the artist draws a single pixel, he/she will be able to commit to a schedule and a price.

Over the last few years, several good books have been written on designing (and managing) game development projects. However, these books tend to focus on many details which are only relevant or important to large scale projects. Naturally, there are excerpts which you will find useful, but don’t get overwhelmed by the sheer volume of information. Generally, you don’t need to concern yourself with all of those details; the object of this lesson is to finish a fun game you want to create in your spare time. If followed some of those books to the letter, it would take ages to complete a project and you may find your interest in the project begin to drift after a year or two.

Project Management – When you are creating a game by yourself and for free, I don’t recommend setting a schedule. Schedules are for people and companies who must release the game in a timely manner because their economic futures depend on it. The bottom line for you and me, however, is that schedules aren’t very accomodating for new game developers and they aren’t very much fun when you’re ten weeks behind your target date. If you don’t need to release a game in six months, then why would you care that your line drawing algorithm is taking twice as long to craft as expected?

On the other hand, you could always use the project as a way to enhance your project management skills, which is admirable but you may find the accuracy of your estimates vary considerably. This is partly due to life, who once again chooses to interfere with your project. As a programmer at work, I can count on having at least five or six hours a day for solid work. At home, my free time will vary wildly. If you only consider the cost (in time units) and forget about dates, then you may find your estimates more useful. If you really insist on reading a book to brush up, then I recommed:

• Joel Spolsky’s book entitled Joel on Software. It’s a compilation of articles for novice program and projects managers. It has a number of good practical tips which can benefit almost any software project, including projects done by the hobbyist.

Categories: Game Development, Programming, Reflections
No Comments »

I tried to use the SX-Key over the weekend to upload binaries and run or debug them via the SX-Key IDE. Unfortunately, there seems to be a timing problem when I run the programs. If I assemble and upload the binary using the XGS ME software, the program works just fine. I’m going to compare the generated files when I get home tonight. Hopefully, I will find a difference between them which could account for the difference in operation; otherwise, if the porgrams are the same, it would imply a defect in the hardware, which is a lot more troublesome to diagnose (at least for me since I am not a hardware engineer).

I posted my problem to the XGS forum and received a few pointers from the designer, André LaMothe. As per his recommendation, I have reseated the oscillators to no avail. I’ll have to keep the coffee pot hot tonight.

Update: I did not realize the SX-Key “Run” command simply assembles, uploads, and sets the clock. You must still switch the XGS into run mode and reset the system. This is different from the “Debug” command which does everything the run command does, but it uses its own clock instead of the clock found on the XGS which allows the program to run without switching the XGS into run mode.

Categories: Hardware, XGameStation
No Comments »