Projects/Stargella

You take on the role of Stargella, a lonely star fighter pilot just returning home to the beautiful world of Freyja⁰ after a long patrol in deep space aboard the carrier ship Hofvarpnir¹. Sadly in your absence, the evil Viekasiekian Empire has begun laying waste to your luscious planet! Deploying all fighters, as a group of imperial Triremes² begin encircling the carrier,  the tides turn in the enemies favour. Soon you find yourself the sole survivor to reach Freyja alive, as all remaining hands go down with the Hofvarpnir.

Far from fearing a single star fighter in their midst, you must exploit that Viekasiek pride in order  to liberate your planet from the clutches of Emperor Zurick. Battling across the polar ice caps, over the sea, and into the forests of Freyja, you must push the Viekasiekian forces back into space: facing hordes of enemy fighters along the way. Among these include the heavy Ballista and Scuta, as well as lighter Velites³ and scout pods that make up the invasion force. Finally punching through the fleet in orbit, for a final show down against the emperor.

The game is meant to be played in a 2D-esque top down point of view, utilising the mouse to manoeuvre across the screen. At it’s heart, is the intention to keep the action alive, blending an array of attachable/ejectable weapons and combat styles with a large amount of adversaries. My idea for a game, you can play additively as an arcade classic but with a pace that better befits the modern style. It’s aimed at folks like myself, who can still sit down and play Centipede or Tetris all day long with a grin, but would like a bit more spice.

It is meant to be more or less, ‘traditional’, in the sense that power ups drift across screen to be collected, and fairly simple on the graphical spectrum.

Current specs call for about 11 enemy craft and 3 more usable by the player⁵. The players ship is basically given a capacitance based on its size: larger equals more guns and harder to kill. Depending on the class of ship⁵, will also limit its ability to bring that heavier ordinance to bear upon the Viekasiekian slime.

• The light fighter given at the start, being designed as a simple but agile craft, is meant to reflect an association with nature. It is obviously limited to only a few weapons because of its small size, but has a regenerative armour skin around a highly effective power plant, that makes for a long lasting craft with some serious skill. It gives extra advantage to players focused on not getting hit all the time, and favouring a few lasers backed by a heavier weapon for dispatched more powerful foes.
• Medium class, being a more conventional ship of the line gained after a a certain amount of game play. Trading the lighter vessels regenerative skin, for a deflector shield and larger weapons bays, every hit on the shields will reduce the power available to laser weapons; thus off setting the greater capability to carry heavier missile and cannon than smaller craft. It’s meant to be a middle of the line way of playing, that rewards those who can balance its abilities during furious combat and still come out on top of the scrap heap.
• Where as the heavy class, is basically the big bruiser of the bunch. It’s meant to be an unlock for scoring a good bit of points during the course of play, yet still balanced enough so that even the light fighter from the start can still stand a chance at winning the same fights as the heavy. Combing a large weapons payload with enough armour to last a while, it makes up for needing ‘armour patches’ during a long engagement, by being able to smash through anything that can’t kill it. Think about a dump truck turned into a war marchine lol.

 Weapons can be equipped when found, or jettisoned to make room for others. The hit list includes various strength of laser, that balance energy use to power consumption^<6, as well as several class of heavier particle beam and ballistic cannon style weapons. My favourite being the missile types, hehe.

Each ship can only carry X slots in weapons with so much ammo, so one has to balance out what you have collected, when it’s fired, when it’s dropped, and do it all tactically during the regular course of game play. Weapons come in several principal varieties based on the kind of ammunition they utilise, making it simpler for the player to calculate a weapons value in the present situation.

• Energy
• Drains part of your energy gauge with every shot, but other wise never runs out of ammunition.
• Types:
• Blue Laser
• Low output for short range combat, aimed to minimise energy drain whilst dealing with cannon fodder.
• Green Laser
• Typical energy weapon offering moderate damage to energy consumption. It’s a staple weapon but lacks serious punch.
• Red Laser
• Packs a hard punch but requires plenty of energy for each shot. Best suited for destroying targets that you can actually hit.
• Particle Cannon
• Fires a stream of charged paricles, consuming a large portion of energy in exchange for a solid knock down punch. It’s the plasma cannons younger brother ;).
• Plasma Cannon
• Very powerful but sucks up energy like a thirsty vampire. Ideal for quickly dispatching Viekasekian scum.
• Overcharger
• Drains all available energy and unleashes a devastating shock wave, dealing a proportionate level of damage to anything caught within the waves radius. A weapon of last resort!
• Missiles
• Uses up so much missile ammo per shot, but only a nominal amount of energy drain per firing. Some offer a form of lock, fire, and forget capability.
• Types:
• Micro Missiles
• A small cluster of homing missiles, that gives chase to any craft in their line of fire. Not very powerful but amazingly handy in a brawl.
• Heavy Missiles
• Less intelligent than micro missiles, but capable of dealing strong damage to watever it manages to hit.
• Spread Bombs
• The tactical nuke of your arsenal. It fires straight ahead and explodes, dealing massive damage to anything within its corona. Best used as a weapon of last resort or against a tight group of enemies.
• Zip Mines
• Explodes a small zero point charge whenever a craft comes within a short radius of the “Zip” mine. They gradually float off screen, making it hazardous to player and enemy alike. This is your only rear firing weapon.
• Shells
• Requires “Shells” for ammunition and packs a strong wallop with low energy drain.
• Types:
• Auto Cannon (AC)
• a
• Rotary Cannon (RC)
• A multi-barreled, large bore Gatling gun. Fires less powerful shells than the AC, but offers a more rapid rate of fire. Can quickly burn through smaller craft and shells alike, but it also jams with frequent use. Fire it in short bursts.
• Cluster Cannon (CC)
• In effect, a giant shotgun. Deals massive damage to anything up close but is practically useless for more distant targets.

Stargellas Revenge in it’s own right, is only the equal of about 6-12 months worth of coding, leaving most of the effort to graphics creation. An early prototype was built in C++, around SDL for graphics and Xerces for data serialisation tasks. Soon however, I realised that it would be worth my while to make it more general, so that much of the games insides could be redeployed for other game projects⁷.

This makes the game much more time consuming, particularly when you consider its a ‘side’ project, but the advantages are worth the delay. One reason I like it, is it allows me to flesh out the systems resource, multiplayer, AI, and various other infrastructure tasks without having to do it while coding around a much more complex game.

Most likely, it’ll be the test bed for a custom rendering system⁸ focused on stressing the API. The overall design of the games internal, is designed to be pluggable⁹ enough to allow easy access to some very professional strength rendering technologies, as well as being able to hot swap as much of the componentry as needed. Thus allowing the graphical quality to be reduced on systems where the better tools, are sadly, unavailable… without having to give up on them where so available¹⁰. The main reason for this being, I want to be able to play Stargella on my laptop¹¹, as well as the 3D games on my desktop!

Footnotes:
⁰ Freyja is a goddess in Norse mythology, associated with attributes appropriate for describing Stargellas home world.
¹ Hófvarpnir another reference to Norse mythology.
² The triremis being a type of Roman warship.
³ These are all references to Roman military weapons and armour. In particular watch out for the Celeres defending Zurick.
⁴ It’s a fairly consistent theme, that names of Viekasiekian fighters stem from the Roman military, where as those assoicated with Stargella, have roots in Norse and Germanic mythologies.

Ugh, I’m freaking tired. Started the day off computing what changes would be needed for setting up nmake based builds of Stargella, and everything has been on a snow ball since then.

I spent a considerable amount of time cursing at the MSDN Library over some very shotty docs, and realising that despite the overall quality of MSVC, the actual build tools behind it, has to amount to the stupidest ones I’ve ever seen. Although to be fair, the very first C compiler probably was worse, but this isn’t the ’70s :-P.

The depreciation of Code::Blocks for building things, and switching to appropriate make systems should mate more smoothly to my work flow. It also pisses me off that after all these years, the best tools for the job haven’t improved much. Unlike the typical morons^H^H^H^H^H^Hprogrammers I’ve had to suffer, I also know how to cook up a build set that shouldn’t be an almighty pain in the neck, just to use on another computer then my own work station. Applying basics of computer science to software construction, many hours; having to use tools that quadruple your work load, priceless!

As soon as I battle test one last makefile for MS’s nmake, all should be ready for committing to the repo. Then I can worry about the next goal, a proper merge of the common and system modules into a central core, shuffling the Windows builds to using DLLs (to match the unix builds), and integrate PCC into the unix build stack. (For ease of compiling dependencies, only MSVC is supported on Windows: MinGW users are on their own).

During the course of the day, I’ve also done plenty of the server admin loop, and have serviced more interupts today, then my processor sees in a week of abuse.

and all while carrying on several conversations, hahaa!

In being dragged across the grocery store yet again! I spent some time contemplating what I was thinking about last night, as I was finishing up part of my games net code. Wouldn’t it be practical, to just implement a simple Virtual File System? It would make adapting the code base to different uses easier, since pathes and I/O could then be defined through a set of VFS_routines, but on the downside, making it pluggable would push greater overhead on all those I/O routines at every use.

The zpkg, system input/output, and network modules present very similar interfaces. Main differences being that zpkg doesn’t have write support (an unneeded non-trivial feature), and seeking between positions in a socket, just doesn’t make the same sense as with local files. If a virtual file system layer was built on top of it, it would be rather easy to define a “Plugin” data structure providing the necessary function pointers as needed, and simply use a hash table to handle the mappings between paths. Of course that leads to the bugger of a look up operation o/.

Really, most of the places where it matters wouldn’t impact game play, since most I/O can be divided between startup phase, loading stuff, client/server communication, and shutdown phase; the chatter between client and server obviously being implemented directly on top of the networking module, and therefore a moot point. It would make it possible for the resource loading code to become more flexible at run time; i.e. being able to load game assets both out of zpkg files and local system files without a recompile or a  restrictive version of the VFS.

I think it would be worth while, as an added plus, it would even allow splitting the path argument to Zpkg_Open, and pulling out the interesting bits into the VFS adapter function, which would be replacing that feature of the zpkg module.

For today however, my primary goal is to port the networking code (almost) completed last night, from the BSD Sockets API over to the Windows Sockets API. That way I can replace the less appropriate network code in my RvS admin program with it, and save having to complicate its design to make the most of Qts networking API. All while improving my games code base ^_^.

Although WinSock was based on the old Berkeley interface, Winsock has arguably grown more over the last decade, then the Unix interface has over the last 20 years. Not that there was much need beyond adding IPv6 capability, which the common Unix interface already grew ages ago. I personally dislike both the Berkeley and Windows interfaces immensely, why? Because in my humble opinion, the proper way would have been something like:

int s;

if (s = open("/net/tcp/host:port", O_CREAT | O_RDRW | O_EXLOCK)) == -1) {
 perror("Unable to open a connection to host:port");
}

/* do usual stuff here, like read() or write() */

where /net would be an arbitrary mount point for a special file system, in which file system operations reflect their corresponding network operations. Flags for system calls like open() and fcntl() could have been suitably extended to cope, and others like accept() implemented as needed. In the light of things like FUSE, it would be even more interesting to do it that way today, then it would have been in the 1980s.

Instead of that simple form, whenever we want to create a socket: we have to setup suitable socket-specific data structures, which and how many depending on the operations to be conducted; common practice is to zero over the most important (sockaddr_in / sockaddr_in6) structures before using them, and leave it to the compilers optimizer whether it actually happens at run time; look up in the system manuals what pre processor definitions correspond to type of network connection we want (let’s say TCP over IP) for the socket() call; initialise the field structures, using the same pre pre processor flags, and even converting details like the port # into suitable formats, all by ourselves. After which we might finally get around to doing the socket I/O ourselves, pardoning any intervening system calls needed for your particular task.

/*
 * Assumes open flags in previous theoretical example corresponded to a connect
 * operation, rather then a bind() and listen() operation. Like wise for the

* sake of terseness, I'm "Skipping" support for real.host.names rather then IPs.
 */

int s;
struct sockaddr_in addr;

memset(&addr, 0, sizeof(struct sockaddr_in));
addr.sin_family = AF_INET;
addr.sin_port = htons(port);
if (inet_pton(AF_INET, "xxx.xxx.xxx.xxx", &addr.sin_addr) != 1) {
 /* handle AF_INET, address parsing, or unknown errors here.
  * error is indicated by return value.
  */
 return;
}

if ((s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
 perror("Unable to create socket");
 goto CLEANUP;
}
/* use system calls and a data structures as needed to setup things as desired */

if (connect(s, (const struct sockaddr *)&addr,
     sizeof(struct sockaddr_in)) == -1)
{
 perror("Unable to connect socket");
 goto CLEANUP;
}

/* do I/O here: send/recev, or read/write */

CLEANUP:
 shutdown(s, SHUT_RDWR);
 close(s);

I reckon the Berkeley interface was the right choice, for portability between systems (including non-unix ones; making it easy to write stuff like WinSock), and probably easier to graft onto the 4.3BSD kernel, but it’s damn inconvenient for a UNIX programmer. That ain’t changed after about 25-30 years.

Oh wells, at least it works pretty darn near every where, give or take a few kinks.

Being stuck with walking around the supermarket (baah, humbug!), I tried to devote my trains of thought to Stargella. For me, it is kind of a difficult project; much more complex then most of the things I’ve worked on.

In thinking about how to structure the rendering code, I started to think more on the issue of dealing with the data sets to be rendered, which basically means sprites (2d), models (3d), and rendering the level (2d/3d), and I want as much of the code to be shared between several game projects, which makes baking the lasagna a bit involved. Since my current focus is on the 2D oriented, Stargella, I find it wiser to concentrate on sprites then three dimensional models. At first I was thinking, it would be ideal to represent animations for sprites, as a simple image stack; but I don’t want to go through all that for unanimated sprites, which would still require a singular stack frame. The fix to that is simple, only use stacks for holding the animation details! Then I was thinking, gee, wouldn’t it be cool, if we could attach some type of script or shader program to be run, so a level of progmmability could be used in implementing special effects. For example, using program to stake out the centre of a starship, split it into segments and have them drift away from one another, while interleaving it with an explosion-like image or particle effect. Simple enough to do from C I’m sure, but I would much rather have it be apart of the game data, then the game code. I’m not sure if that would be doable from mating with GLSL files, or if it would mean binding a script with the sprite. Either way, as far as general game scripting goes, it should have some level of access to the graphic stuff as a matter of completeness.

For now, I think I’ll concentrate on resource handling. It should be easy enough, just create dynamic arrays as needed (e.g. of loaded textures), and each time a new texture is loaded, assign it an unique identifier that indexes into the array; …

Honestly, I don’t have a problem with programming in C, other then it can be time consuming at times o/. But, because I have to learn OpenGL along the way, it is, shall we say a freaking lot of docs to parse.

While I’m more familiar with Direct3D then OpenGL, even if you can still get a good bang for you buck out of a DirectX SDK without having to stoop to C++, I’m not willing to write a DirectX backend for my game. Obviously, I want to avoid using glThis and glThat all over the game code, but ahem, the issue of shaders enter the picture. Short of making a definitive choice at compile time, that would have to live for the projects entitiy, the only way to support runtime choice, would also require writing both HLSL (DirectX) and GLSL (OpenGL) code, and that’s a headache I won’t put up with!  As much as I favour the idea of nVidia’s Cg, it is not available on enough platforms, and implementing it where needed, to much trouble.

If people other then me want to play the game, they can buy a graphics card made in the 21st century and install its drivers >_>.

—- this post has been interrupted so many damn rat fucking times by family, that it is unfinished and will likely always remain so. This is one of many reasons why I fucking hate my life.

I’ve just made a forum posting, starting an open query for any artistic talents interesting in helping to contact me. My main concern at the moment is working out the games design bible while finishing off the Georgia drivers guide >_>.

Most of the code for Stargella is going to be reused for the later first person shooter and ‘mech projects (which may just get released years before the new MechWarrior lol). While the shooter is going to be a 3D affair, and the ‘mech combat game is undecided, the star fighter game (Stargella) is fairly straight forward: 2D is the only way to go. At least without getting sued for recreating Star Fox, if I dared try it in 3D lol. At its heart, Stargella is about having fun, the kind of fun that existed before the move into 3D games. I largely missed the big classics like Battlezone and Asteroids, only getting to play them in later years, but Galaga was a game I did play as a child. Its always been something I’ve found missing, no modern incarnation I’ve had access to just itches the right spot, that’s where Stargella comes in: it’s gotta be fast and furious, like an nail biting round of Centipede. Yet it’s got to something you can actually play and survive with some mastery, like Asteroids (one of my great favourites btw). Most of the games I played growing up, were side scrollers like Super Mario Brothers and Sonic the Hedgehog, so I remember the mechanics quite easily.

Graphics are my achilles heel however, because while I can code what I want, making it ‘look’ that the way I want, is limited by the models that can be created for the game to display. In fact, I’m actually thinking of drawing most of the ships for Stargella, and scanning them into the computer. Really it has been a long time since I’ve done free hand drawing, it feels more natural to me then the computer: I can work FASTER!!!

For Stargella, I very much know what kind of look I want, the question is can I get graphics that match it without the whole thing looking like the early arcade games, lol. I reckon that I could always hash things out in a modelling program and get a head start on code needed for the 3D titles, but I feel that is just over kill for a game like Stargella.