Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Andrew Lauritzen, posted on November 09, 2004

Image Description, by Andrew Lauritzen

As an introduction, the description of Galactic Gladiator from the site reads: "Galactic Gladiator is a fast-paced, top-down, scrolling, space shooter inspired by several timeless classics. Beyond improved graphics, music, sound, etc., modern technology allows the inclusion of new game-play mechanics that add strategy, tactical skill, and generally more depth to the genre."

Galactic Gladiator is a game project that we (myself and Chris Iacobucci) have been working on for about 4 years, albeit very on and off. Finally we've completed version 1.0.0, and intend on submitting it to the Student Showcase of the Independent Game Festival.

While the "space shooter" genre isn't exactly leading edge technology, we feel that we've implemented quite a few new ideas that give our game more depth than your average shooter.

On to the technical features (taken from the web site):
  • Fast, pixel-perfect collision detection between all weapons and objects
  • DirectDraw graphics system capable of MMX software alpha blending (with alpha channel) in both 16bit (555 or 565) and 32bit (888) colour
  • Dynamic musical styles and transitions based on current game situation via DirectMusic Producer and AudioVBScript
  • Automated and secure (very cheat-proof) submission of high scores to the online high scores system using HTTP, XML and server-side DLLs for decryption and validation
  • Full support for DirectInput devices, arbitrary key/button mappings, analog axes and force feedback
  • Lots of testing and a relentless attention to detail has produced very optimized code that runs well even on low end machines
  • Individual behavior (AI) for every ship class
  • Solid, stable and intuitive GUI: both ingame and in the launcher
  • Smooth animation and impressive graphics rendered from 3d Studio Max models
  • Generic particle systems (both pixel-based and bitmapped) produce many effects, from shields absorbing hits, to missile trails, to massive expanding shock waves
  • (DirectDraw? Yes we'd do it in a 3D API nowadays without a second thought, but just to give a timeline: when this project was started, I had a Voodoo3... 16bit color max! That said we've expanded our graphics engine significantly to allow full alpha channel even on low-end, non-3d-accelerated machines.)

    Probably the thing that we're most proud of though is the fact that the game is solid, polished, and (for the most part) done! As fellow developers, I'm sure you all know how tempting it is to drop something and move on to some "newer" or "more interesting" project. That said, even if we don't get selected for the IGF Student Showcase, we're quite happy to have this done as a portfolio piece.

    Thanks for your time, and please feel free to submit feedback either here or on the site's forums.

    More images, music, info, online high scores, forums and free download here:

    Image of the Day Gallery


    Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
    Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

    November 10, 2004, 07:04 AM

    As had been pointed out, uridium and 99.9% of other games of the era were 100% machine code.
    "C64 was a very basic architecture"
    Mmm, your game uses sprites. You're using direct draw to draw the sprites, you didn't have to code sprite rasterisation routines in machine code. Your sound probably uses directsound (dsound->loadwav/dsound->playwav or whatever), so you didn't have to send byte codes to a sound chip. Your graphics were probably designed using some fancy pants package like photoshop, so you didn't have to hand draw them on graph paper, then convert them to byte codes and *type them in by hand*. Braybrook was about 17 years old.
    You get the picture? You have merely provided a script to a ready built game engine called directx (heck it even does your so-called pixel perfect collision detection for you).
    You people don't know you're born.
    papasmurf, you're a bell end for making such a churlish comment.


    November 10, 2004, 10:04 AM

    You know what man? There's no friggin "make game button', And as "fancy" and full featured as programs like Photoshop get (or anything else for that matter), dedicated people don't use them as a way to get out of doing work. Rather, they're used to make the graphics or game play that much better.

    I can't for the life of me understand why you have such a huge problem with people who don't write code in machine language. Are you completely against the advancement of computer science? I mean for God's sake it's not like we turned this out in a day and are trying to milk it as if it were the second coming. Both of us worked hard on this project, and I'm proud of my efforts.

    I'd appreciate it if you keep your comments to constructive criticism. And, if you do have a question, as per yours regarding the time spent on GG, phrase it as such. Refrain from calling people incompetent, deriding their efforts, and mocking their methods. Otherwise just grab your XT, go to your basement, and live a quiet life playing any "real" game you choose. No one benefits from your hostility.


    November 10, 2004, 10:52 AM

    "C64", "sprite rasterization routines", "machine code", "sound chip"
    This is far from oldschool my friend.

    Back in the day, I wrote code by punching it into a drum with a chisel and a fucking hammer.
    There was no "backspace" button. To make a code edit I had to fill the hole in the drum with molten lead.
    The game loop was timed to the time it took for the drum head to move from
    one location to another.
    There were no "pixels". The console output was a rack of christmas lights, with a
    refresh rate of 1Hz.

    Your logic really appeals to me, and I totally agree with you.
    For instance, the piece-of-shit sloppy engineering they call Doom III is simply a thin wrapper around DirectX topped with some lensflared photoshop textures.

    And even though I don't even _make_ games myself, I still feel I have the right, no,
    the _obligation_, to shit on people who do.

    Andrew Lauritzen

    November 10, 2004, 12:50 PM

    Actually you're wrong on many counts.

    First, DirectDraw does basically one thing: allocate chunks of memory. It won't even plot pixels for you... that you have to do by hand (encoding RGB values depending on user's video card pixel formats, working out memory addresses, etc). Also we stated clearly that we had to write alpha blending code in straight, 100%, unadultered MMX assembly - and this for multiple bit depths and pixel formats. What's that? We had to write "sprite rasterization routines in machine code"... and even with much more complexity introduced due to the full alpha channel and SIMD instructions? No way...

    Second, DirectSound does not have a function for loading wave files. Nope, we had to write our own loader to get all of the - wait for it - RAW sound data into the DirectSound buffer. Sounds pretty low level.

    Also DirectX does nothing of collision detection, physics or anything else like that. In fact, it's pretty much just a thin wrapper to provide a common interface to hardware. Very little of our code has anything to do with DirectX.

    I don't see how you can say that a game with literally hundreds of thousands of lines of executable code (millions in assembler ;) is "trivial". In fact there is no way anyone could write a modern game in straight assembly, but thankfully they don't have to.

    Anyways the main point here is this: you have yet to provide a reason why advancing technology via compilers and libraries is a bad thing. In fact, it is the very BASIS of why computers are powerful. If you don't believe me, look into the Theory of Computing and Turing machines a bit.

    This topic is getting a bit hostile and degrading into personal insults, so I'm going to close with a challenge instead. If you think that a game like this is simply a "script built on DirectX", then I challenge you to go write one of comparable quality. Constructive activies are generally much more useful than arguing.


    November 10, 2004, 03:05 PM

    This thread was frustrating me at first, but CoderByBirth made my freaking week. I too would love to see Knackered put his money where his mouth is and produce a game. Never have I encountered someone who's so closed minded with regards to methods of reaching a goal.


    November 10, 2004, 06:03 PM

    hey lads, cool it. I'm just reviewing your stuff in the context of what has gone before it, in this genre especially.
    I'm taking into account the resources at your disposal, the facilities available to you (the directX cushion) and the time you have invested. In the end I'm flabber-gasted that you spent 4 freaking years producing little more than the equivalent of a toddlers hand painting and are proclaiming it worthy of admiration to the world - jeez, you'll be asking money for it next.
    Andrew, if you think alpha blending is taxing code then god help you - SIMD is there to help you, dear boy...not perplex you as it obviously has. There is simply SHIT loads of documentation scattered liberally all over the internet on every single tiny element involved in producing something like this. I myself have many years experience in this field, but (understandably) wish to remain annonymous. I've had to do countless mind numbingly boring assembly language routines doing all manner of mundane tasks (basic stuff like adding two floats together)...I've had to get buses to libraries just to find out little bits of crap that 2 seconds on google would give me. You have had it easy, and concidering just how easy you've had it, I consider your product to be, at the very least, disappointing. No more disappointing than the rest of the crap that gets paraded all over the place these days, but disappointing nonetheless.
    Getting angry about it won't change my opinion. If you don't respect my opinion then simply don't reply to my's that simple.
    BTW, Farmboy, your role was to make the tea, right?


    November 10, 2004, 06:10 PM

    jesus, isn't poking a wasps nest with a stick boring after a while?

    Andrew Lauritzen

    November 10, 2004, 07:23 PM

    Alright you're not even reading what we've written now, which really signals the end of a civilized conversation.

    Still, I'll repeat myself one more time:

    1) 4 years is a time SPAN, not a time PERIOD. If you can't get the two straight then you're confusion is understandable. We've made no statements about the "time invested", only the start date of the project.

    2) SIMD (parallel) is more difficult to program in than non-SIMD (serial). The instruction set is much more limited, and you have many more issues with data sizes, alignment, saturation and other such fun. I also said nothing about perplexing - it was you who made all of the false claims about DirectX. The reason SIMD exists is for performance - it has nothing to do with easy-of-use.

    Quite frankly you give off a pretty arrogant attitude. Point one: programmers who can't adapt to new technology and still insist on using assembler (for example) for everything simply will not survive. By and large this routine work has been consumed by the computers themselves. To survive in a modern economy like ours one has to remain innovative, and thus more useful than the computers. You're never going to be able to compete with a machine when it comes to boring, low-level, repetative tasks that involve very little innovation.

    Point two: many people, including myself, have been programming for some time. Yep, I've done all that: good old DOS graphics from first principals, 100% machine code programs... it's nothing special. In fact, there was a lot less to worry about back in those "good old days": much shorter programs that much did simpler tasks. Everyone should be rejoicing that those days are over.

    Anyways I certainly don't mean to imply that programming simple games isn't easier than it was in the past: it certainly is! For a fixed game, the effort required to produce it is certainly falling. However, where you seem to be somewhat confused is that fact that even our game is orders of magnitude more complex than games of ten+ years ago. Such games would not have even been possible with machine-level code.

    I'm tired of regailing this point though: this is all clearly documented in any Theory of Computing course or probably even on the internet as you point out so often: do some reading.

    Again, there's a simple way to show that games are easy to make: produce one yourself. I'd be happy to take an honest look at something that you've created. Common, it should only take a few hours to put together the code... here let me get you started:

    TGame *Game = new TSpaceShooter(SS_TOPDOWN | SS_VERTSCROLL);
    TInternet *Inet = new TInternet;

    Good luck!


    November 11, 2004, 12:06 PM

    why are you bothering to reply? are you bored?


    November 11, 2004, 09:20 PM

    Don't start with me on this "cool it" stuff if you've abandoned all civilized debate for insults. I won't respect your opinion till you can deliver it without the attitude.

    Did I make the tea? Andrew did the coding; he has the ammunition to counter your arguments. If you'd like me to talk to him about it and do the research, I can do the same. You sound like you see no value in the graphics field at all. Good luck with that.

    I've heard enough from you and I'm through talking. You can obviously out do our "toddlers hand painting" on both the graphical and code facets. Let's see it.

    This thread contains 40 messages.
    First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
    Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.