• Advertisement
Sign in to follow this  
  • entries
    26
  • comments
    48
  • views
    23313

About this blog

Because even I don't know what I'm doing these days.

Entries in this blog


Last week I competed in Vortex '09 in Toronto. The contest was to deliver the best pitch for a game idea or prototype. I didn't give myself time to come up with a solid game pitch, so I thought of jumping on the classic-remake bandwagon and remake the IREM NES classic "Metal Storm".

There's alot of retro remakes free on the web but I didn't see one for this game, so I thought it might be an interesting project to pitch.

METALSTORM2.PDF.

When I pitched the idea, the Judges only asked if I tried to obtain a license for the trademark. Maybe they were hoping for a yes? Let me know what you think.

Vortex was fun and I learned alot. I think I'll attend the next IGDA and Hand Eye meetings in Toronto from now on, even if I'm not working on anything worthwhile these days.

EnemyBoss LE

I finally got to put a temp site on members.gamedev.net. After understanding the limitations of the web space, and FTP not appearing to work, I decided on a plain html site with the old work I did 3 years ago. http://enemyboss.com/

I hope that when I get the creative juices flowing and some income, the site will relaunch with some new games.

My first synth.

At time I should be cut spending, I decided to invest in a synth/midi keyboard. I'm pretty competent making my graphics in Gimp and Blender using my Graphire4 tablet. When it comes to sounds however, I just find existing works.

I don't know music theory or sound engineering, but I wanted something to toy with. A while back, my brother got Korg DS-10 for his DS. I played it with for hours, and I realized that making and controlling rhythmic noises is fun (and sometimes very funny!)

Instead of buying my own copy of Korg DS-10, I investigated into full-fledged synthesizers.

My investigation told me that software sequencing and synthesis is the way to go these days, but software still benefits to have a MIDI keyboard controller. I decided to go for an affordable mini synth keyboard, which could be used both as a soft-synth controller and a musical toy. Except for a toy harmonica, my household has no musical instruments.

It was a tough decision between a MicroKorg and the Xio. Both are small, battery operable synthesizers, which can be used to model wonderful stereo sounds. Both could also be used as good MIDI compatible controllers for software.

The MicroKorg seemed to have a lot of what the old school synths had to offer. I really fell in love with the Korg brand because of the DS title. The MicroKorg also looked really fun to use, especially with the voice changing Vocoder. Tom Lee Music had it for only $80 CAD more than the Xio during the boxing week.

The Xio however seemed to fit my needs better: Its USB interface can be used to power the Xio and use it as a low-latency audio interface, as well as a MIDI interface. Had I gone with the MicroKorg, I would have had to buy a MIDI-USB cable and maybe a new soundcard, if I found the onboard sound on my to PC to have poor key-to-sound latency.

I purchased the Xio online from Tom Lee Music, and I received it yesterday.

I'm having plenty of fun with the Xio's synthesizer, the presets are all very good and varying the sound is easy with the 2D joystick. Next, I'll go through the video tutorials and learn more about the basics.

Tightening Up

Well I canceled my hosting service, and so my site is down. Money is getting tight I'm just cutting down on expenses where I can. I'm still looking for a job.

My personal site http://mujtaba.hasni.ca now just points to my linked-in profile, which serves the same purpose actually. I might just keep it that way.

And as for enemyboss.com, I'm hosting it right here on members.gamedev.net. Why not use the space while I still own it? My site was PHP based, so I'm going to need time to redo a smaller DHTML version of it. I've been wanting to redo the site anyways.

I've been doing a lot of reading on game programming. I've even started re-reading Andre LaMothes' The Black Art of 3D programming. I don't know why I keep coming back to this book, especially when I have yet to read his more current book, Tricks of the 3D Game Programming Gurus.

And I'm hoping I'll soon move forward with my game project soon.

Its not bad having this much available time. Its almost worth the money.
Blame it on the economy or whatever, but I'm unemployed again. I didn't survive the cuts past my probationary period. My experience at TransGaming was still very postive though.

So its back to my favorite vaporware title until I find the next job.

I might also consider doing freelance work, but I don't trust a lot of the work thats posted on places like rentacoder.

Anyone know who's hiring in the Greater Toronto Area?

New Job.

I start my new job at Transgaming on Monday. I didn't get to finish a game like I set out to do when I left my last job, but I got at least some time to it.

Hopefully, I won't be to busy after hours to work on my new game.

I've been stuck trying to build my own simple sprite engine. For some reason, I am determined to code this in plain C only. This results however in engines that are not very flexible and I end up re-writing. I am also trying to achieve simplicity in design(which is also very difficult).


So far my sprite management looks like this:



/* Handlers initialize a sprite's data on the 1st call, then updates logic */
typedef void ( *SPRITEHANDLER )( struct sprite_t *sprite )

struct sprite_t
{
float px, py,
dx, dy;
BITMAP *sprite;

void *extra;
SPRITEHANDLER update;

struct sprite_t *next;
};

/* Creates Sprite Object and add to sprite list */
struct sprite_t *spawn_sprite( SPRITEHANDLER sprite_handler, int x, int y );

/* Removes sprite from the list and de-allocates it */
void kill_sprite( struct sprite_t *sprite );

/* Invokes the sprite handlers to update logic (at a low internal FPS ) */
void update_sprites( );

/* Moves all sprites one step based on its velocity, invoked once per frame */
void move_sprite( );

/* Draws all sprites to bitmap object, invoked once per frame */
void draw_sprites( BITMAP *video_surface );




The "sprite handler" functions as a sort of class for each sprite. I would have a handler function for each type of sprite.

I'm afraid however that this design may be too restrictive. I haven't considered how I would display multi-sprite objects, or how they would communicate with each other.

I really need to think the design through. I just need more time.
If anything reminds me how far I have to go as a game developer is my recent considerations for the game loop. I want to have absolutely smooth scrolling and moving sprites, without resorting to OpenGL or Direct3D. My initial testing of both SDL and Allegro page flipping modes indicate this can be done, depending on how I implement the game loop.

I initially went with the timed game loop, where I update the movement in the game based on the measured time between frames. I thought that this would make sprite movement as easy as following a physics text book, and run smooth at any refresh rate. This was the technique used in David Brackeen's Java game programming book.


while ( game_is_running )
{
elapsed_time = get_time() - last_time;
last_time += elapsed_time;
get_user_input()

update_game( elapsed_time )

render_game( screen )

wait_for_retrace();
}






What I got was intermittent "blibs" between smooth movements. Apparently, even the underlying performance timers for windows are not 100% reliable. At first I blamed the page-flipping implementation in SDL, because an Allegro demo showed smoother animation in page flipping mode.

I almost abandoned SDL until I realized that the SDL.DLL pre-built for Windows will not use DirectX unless the %SDL_VideoDriver% variable wasn't set to "directx". I figured this out when I noticed that SDL_VideoInfo()->hw_available returned false.

After modifying the gameloop to sync with the refresh rate made the SDL version move just as smooth in double buffered mode as with Allegro in page-flipping mode, as long as I both updated and rendered the game at retrace.

I've read that using a time-interval like above would cause physics calculations to compound on rounding errors and otherwise break gameplay. The elapsed_time could be clamped to a reasonable max/min before being passed to the update function. In any case, I could not get the smooth uninterrupted movement that I wanted.

I still didn't want the game-speed to be dependent on the frame-rate. The next thing I tried was fixing the update rate at 60Hz, while calling the rendering function at retrace, or as soon as possible.


#define FRAME_INTERVAL 1000/60

frame_time = game_time();

while ( game_is_running )
{
get_user_input();

/* Update only at 60Hz. Skip if we're running under */
while( game_time() > frame_time )
{
update_game(); /* Update one tick */
frame_time += FRAME_INTERVAL;

}
render_game( screen );
}






I could have also put a condition to allow the loop to skip a few updates if the loop is running slow (under 60 updates per second), but I wanted the game to go into slow-mo and not skip a frame.

This wasn't good enough because while it looked great on a display that could support 60Hz, the 50Hz LCD on my thinkpad (and primary development machine) made it look all jumpy. Thats because the game was updating faster than my LCD. If I slowed the updates to 50Hz, it looked fine on my laptop, but it appeard "laggy" on the CRT monitor because it was refreshing faster than the updates.

Actually, I'm exagerting the lag and jumpyness a bit but I didn't want to use this loop.

BTW: I forget where I actually learned about these game loops, If I remember the link I'll post it.

The last method I implemented was rendering partial frames or "tweening". This is achieved by locking the internal frame rate (updates) at 50Hz, measuring the time between rendered frames and passing it to the render function as a fraction out ofa 50Hz frame period. The 50Hz was chosen so that it work well under a 50Hz monitors (LCD or PAL TV).


#define FRAME_INTERVAL 1000/50

frame_time = game_time();

while ( game_is_running )
{
get_user_input();

/* Update only at 60Hz. Skip if we're running under */
while( game_time() > frame_time )
{
update_game(); /* Update one tick */
frame_time += FRAME_INTERVAL;

}

current_frame_time = ((game_time() + FRAME_INTERVAL) - frame_time);

tweening = current_frame_time / FRAME_INTERVAL;

render_game( screen, tweening );
}






Then when it comes time to render my sprite, I predict where the sprite will be based on its current velocity (dx,dy) and draw to that location on the screnn:


void render_sprite( sprite, screen, tweening )
{
x = sprite->x + sprite->dx * tweening;
y = sprite->y + sprite->dy * tweening;

blit( sprite->frames[ sprite->frame ], screen, x, y, sprite->w, sprite->h );
}






This approach is very good. Even if I set the the internal frame rate to say 30Hz or even 24Hz (feature movie display rate) movement looks quite smooth even on both my 60Hz CRT or 50Hz LCD and at the same speed. Again, the loop will not throw out frames if running behind and will opt to slow-mo.

For my requirements, I need precise collision detection because the player will be dodging many bullets as well as enemies. So I may need to run collision detection frequently as once per rendered frame.

So despite my reservations of locking the frame rate, I'm going with the simple text-book approach of waiting for the next frame period at the end of the loop. I'll separate the update() function into compute_AI() and animate(), so that I can do the AI at a lower frame-rate (maybe @20Hz?) , then animate and render the game at 60Hz. This way I can rely on the refresh rate for smooth scrolling and animation, while relying on the system clock for logic.

This also means that my game would slow by 16% on my 50Hz LCD, but it will still look smooth. I think I can live with that.

I might then go with using Allegro, since it lets me request and query the display's refresh rate and supports both page and triple buffering. None of these features as far as I know are supported in SDL 1.2 (perhaps purposely so).

I'm open to comments, because I know locking the game speed to a 60Hz display refresh rate isn't ideal for most players.
I keep scrap paper on my recycled main-board clip-board, which i use to make notes. I was writing out my thoughts on the design of the new game, and for some reason started doodling 3D boxes in the bottom right of the page. The shapes began to look like it needed details and then something magically appeared.

I think I've discovered how to sketch. I was thinking of a jumping tank with dual rockets/gun turrents. What you see here is the result much erasing and re-penciling. I then colored it in GIMP (much undo/redo). Its not much too look at , but it is my first real pencil sketch ever, and I'm damned proud of it!



Because the game is going to be rendered from the side view, I want to to employ elements of gravity into the game. So there will be arching missles, bombs and jumping rocket-pack mechs, etc. I was thinking this tank could tag the player a bit and make a surprise leap-attack.


This sprite design probably took me much longer to do on paper, than say these using Blender and GIMP, but it was a lot of fun and I can do it anywhere. I might do a few more paper sketches for fun.



About two weeks ago I found some old files and code on a disk inside my copy of
the "Black Art of 3D Game Programming". These were from my first attempt to get
into game programming in 1998 when I bought this book. This book IMO is the
best book on game programming available at the time. I remembered making my
first VGA program based on it.

But I didn't remember until now is that I tried to make a vertical scrolling
shootem'up - just like that "Gunhacker" project I previously attempted over a
year ago. I used DJGPP and Allegro back then, and graphics were going to be
pre-rendered in POV-Ray and Terragen. I guess University got in the way and
then I completely forgot about it.

So last week I decided to make a third attempt at an R-Type clone, using the
work from both projects. All the tools I used back then are stillarround, and
Allegro is even still in development. So does anyone want a new DOS game 10
years in the making?

Seriously though, my plan is to and port the work to MinGW and the Windows
version of Allegro, using the newer assets I made for the Gunhacker project. I
can then (maybe)make a DOS port the project and put a close on both these
unfinished projects.

Question: How good is Mac/Linux support under Allegro? From what I've read,
Mac and Linux support is new and not as optimized as under Window. I might
consider using SDL (I really don't care about targetting DOS). I think its
important because Mac and Linux could use more games.

High Concepts


My goal was to make an original game centered around a "high concept" that my
brother keeps talking about. E.g Portal & Narbacular Drop was built around the
portal concept. An original idea at least seemed like a good idea having done 5 arcade clones already. I gave it a few weeks, brainstorming on paper and didn't like any of my ideas:

- Flower creation game, based on genetic programming. Not my style.

- Backwards shoot-em up where you place a limited stock of enemies on the
level map to stop the cpu-controlled player. How would it end?

- Physics based tetris game. Bouncy tetriminos? Already did a tetris game.

I sometimes forget that I'm just a beginner, and I should really just keep my
goals small in scale. So my direction is still to pick and old classic I like and
re-make it in some form. Maybe then something original will come out of it.

Catchup

I've learned a lot the past couple months, but I didn't log my progress as I
should have. I don't have anything new to show, so these next few journal
entries are really for my own record.
It's been years since I posted a journal entry, and a very long time since I did any serious game development. Life got in the way you see, I got a Job and a wife and I found myself too occupied with my Job, family and my huge back-log of video games to find time to do much else anymore.

I didn't lose interest in game development, I just didn't organize my time well enough for it. I didn't want to give it up either. Now, finding time is a little easier for me -- I got permanently laid of from work today.

I'm going on vacation this March. I probably won't start a new job until I get back. So until I get back to work, I want to complete at least one project. It would be waste of my GDnet+ renewal if I didn't have something new to showcase. :-)

I haven't decided what I'll do next, but I'm thinking continuing where I left off two years ago, or resurrecting one of the projects I started back in High School (for DOS) and port it to SDL.

So I'm still alive and still trying to get back in.

I've figured out 80% of what I need to make my next game. I've been studying source code for X-Out's Prototype (winner of shmup-dev.com's contest), Chromium BSU, and others I could find.

I decided to restart my game dev efforts back in February, and I have yet to produce something. I will make another game, but there another huge thing that I also needed to get done too.

I've got a huge back-log of video games to play. Since I've graduated and started work, I haven't taken the opportunity to really play all the games I bought. I'm a whole generation behind, I've yet to play FF IX for the PSOne.

So I've been trying to accomplish both at an unremarkable pace. I still have a huge pile of un-opened games, and a non-existant game my mind won't me forget to develop. And I have only just so much free time these days.

I weighed the two, and I realize that I have way more games in my library to play than to make (duh...) Its not even a library its an archive (my brother remarks). I'm going to now concentrate on playing or selling off my games before I can seriously get back into gamedev.

LIST OF GAMES I BOUGHT BUT NOT YET PLAYED


List of games I have and yet not played (off the top of my head and ones I can see from where I'm sitting, so there's more):

Final Fantasy IX
Final Fantasy Tactics
Final Fantasy Tactics Adavance
Final Fantasy X
Final Fantasy X2
XenoSaga
XenoSaga 2
God of War
Prince Of Persia: The Two Thrones
Grownlanser Generations (*snif* RIP Working Designs *snif*)
La Pucelle Tactics
Legend of Zelda: Wind Waker
Legend of Zelda: Oracle of Time/Ages
Tales of Symphonia
Metroid Prime 2
Eternal Darkness
Ikaruga
Gradius III/IV
Gardius V
R-Type Legends
R-Type Delta
Einhander
Silpheed
Blast Chamber (when did I get this?)
Deus Ex PS2 (huh?)
Legend of Dragoon (I didn't buy this, did I?)
Gran Tursimo 3
Gran Turisom 4
Virtua Figher 4 Evolution
Tekken 4
Shenmue 2
Jade Empire
KOTOR I
KOTOR II
Doom 3 PC
Half-Life 2 PC


This is very depressing, and this is just the tip of the iceburg. I need to get caught up before the next generation is completely with us. I at least want to play Wind Waker before the next Zelda game comes.

My brother jokes I could sell all my games and make enough money to start a game studio, thus solving my dilema. Honestly though, if it was possible, it would've been the perfect solution.

I need sleep.








Changing Gears

My original plan was to prototype the game in a RAD development environment, and then re-implement it in my own custom framework, using OpenGL and DirectX (for windowing, sound, and input).

Prototyping seemed like the right way to start off. I used Blender's game engine, which was a natural choice since I've used it so much already.

I find however, that the built-in game engine is only so useful. Blender's game engine makes certain difficult things very easy to do, and some simple things way too cumbersome. Its obvious that it was designed to make certain genre of games easy to make.

Knowing that all this work could not be easily translated into the final product, I decided to stop. I'll still continue to use Blender and Gimp to make all my graphics and animations and I'm sure there are better RAD tools out there. But for now I'm rejecting RAD tools for this project.

Instead, I will prototype my game on the target platform. I've almost decided to use Allegro for this game. Allegro is old but does 2D very well, considering it trades GPU acceleration for hardware surfaces and software optimizations. Allegro is a complete easy to use SDK. Its easy enough to prototype in, and optimized enough to develop a finished product. Especially one that supposed to resemble a game from 1995.

(BTW, I'm developing on a Thinkpad T20, PIII 650 Mhz with 256MB of ram and an 8MB Savage3D IX card).

The next thing to do is make some basic demos. For all my talk, I still haven't implemented a simple 2D scrolling sprite and tile engine yet. Once I figure all this stuff out, I can make a tool to prototype with.

TODO: (or to learn rather)

- Write a tile/sprite/font ripper. I'd rather use a little extra code, than keep each tile and sprite frame in seperate image files.

- Sprite demos w/ velocity, scaling, rotation and pixel perfect collision detection.

- parallax tile scrolling demo w/ map editor. Ideally, the editor will be built-in to the game engine. I think I'll just make the editor GUI in Tcl/Tk however.

- Sprite spline paths, and added to map editor. (Or can I animate sprites using linear interpolation and way-points by hand-in-mouse?)

- Bullet engine: A general module for generating and managing a barrage of bullets sprites and bullet effects. Swarming, homing etc.

- Lighting & Particle simulator: fire, smoke and plasma. I'll need this for the laser effects and explosion.

Gunhacker?

Here's a first crack at a design for my idea. Now I'll need a prototype the concept. But I'm thinking now that it may a bit too much for this genre. It isn't the straight-forward shoot'em up I intended to do make. I think I got carried away trying to make something semi-original.

Gunhacker (working title)

Overview

In One Sentance

Pilot your spacecraft and neutralize the fleet of rogue machines by shootingthem down with your array of lasers or by accessing the enemy units' AI to shut them down or join you in the fight.

Introduction

Gunhacker is a an arcade shoot'em up reminecent of Irem's R-Type. This game will appeal arcade fans and soft-core shoot'em up fans who don't play this genre too seriously. This game is really a one level demo, with few enemy types including a mid and end level boss.

The game will try to recreate the experience of a classic horizontal scrolling shooter as played on an SNES system in its early years. It will feature typical SNES effects such as parallax scrolling backgrounds real-time sprite scaling and rotation.

Genre

This game is classified as Action / Arcade.

Minimum System Requirements

  • Windows 98/2K/XP
  • Pentium 133MHz, 32 RAM
  • DirectX 8.1

Target Demographic

Just myself. So only I need to like it. Actually, the target audience include anyone in game development community who would appreciate having the source code.

Gameplay

The game plays like classic R-Type, with the action taking place in closed side-scrolling environments. Unlike R-Type there is no Force unit. Instead, the player will need to take control of enemy units by making them into drones and use their weapons and abilites.

Controls and Techniques

Gameplay is controlled by a 4-way directional pad and two action buttons, the Fire button and the Lock button. The player's main arsenal of weapons consist of the pulse laser, the high power laser, laser missles with lock-on capability and the EMP Disruptor.

Extra sources of weapons and defensive measures can be acquired by hacking enemy units into drones. There are no power-ups in the game. When the player succesfully turns an enemy into a drone, it follows the player around and fires when the player does. The player can attach to a drone, assign it a target, or take advantage of its special abilty by performing a power transfer.

Using the Pulse Laser.

Tapping the fire button fires a round from the main weapon, the pulse laser. The pulse laser fires a round of discrete light packets like a machine gun. This is the conventional way to attack enemies. The fire button will also make drones fire their main weapons.

Using the High Power Laser

Holding the fire button down will make the POW gauge in the bottom centre of the screen grow. Releasing the fire button will make the player emit a piercing beam of light forward until the gauge is depleted. The longer the POW gauge is allowed to grow, the longer the duration of the laser beam. This is the most damage inflicting weapon in the game.

Using the EMP Disruptor

Just after the POW gauge becomes full, it will switch to EMP and begin to flash. If released this moment, it sends a powerful blast that drains energy from all enemies around the player. If the player takes too long to release the fire button, the player will overheat and the guage will switch to HOT and the gauge will begin to deplete (cool down).

The player cannot fire or control drones while cooling down. The EMP causes enemies to temporarily weaken their shields, slow down, or shut down completely. Enemies closest to the blast will lose the most energy. While the EMP can severely weaken an enemy momentarily, the EMP disruptor cannot destroy enemies. The EMP also affects drones as well, so drones that shut down will need to be re-activated.

Using the High Power Laser with Target Lock-On

Holding down the lock button will open a cursor some distance in front of the player. While charging the laser, the player can hold down the lock button to make the POW gauge switch to LOC. The player can then lock on to enemies by moving the cursor over them. The longer the charge, the more target lock-ons can be made.

Up to 4 targets can be locked. When released, the player will fire a laser missile to each locked-on target. Using target lock-on will weaken the strength of the laser, even when all lock-ons target the same point. Releasing the lock button will cancel all current lock-ons, and continue to charge the normal high power laser.

Suppressing EMP

Holding down the lock button while charging the high power laser will prevent the EMP disruptor from becoming active. This will allow the player to sustain a full charge without the risk of overheating. This is useful for situations where use of the laser or EMP needs to be timed percisely.

Hacking Enemies

At any time, the player may attempt to take control of an enemy unit. The player then must use the lock button to open the cursor and lock on to the enemy long enough to re-write its programming. How long it takes to hack an enemy depends on its strength and power level. Enemies that are weak or deactivated can be reprogrammed instantly. Using the EMP disruptor on active enemies make hacking into them easier. Strong enemies may require repeated hacking attempts.

Hacking enemies is the primary means to upgrading the player's fire power and capabilites. Drones themselves are susceptible to enemy damage, collisions and EMP. While useful as shields and weapons, drones are not invincible (like in R-Type).

Any enemy unit, even level traps, defence systems etc can be hacked -- all except the enemy boss. The mid-boss however can be, with some difficulty be hacked as well. A mid-boss drone drone is invincible and is usually very useful against the enemy boss. The player cannot attach a mid boss however, even if it has flying capablities.

Attaching to Drones

Flying drones can be attached, the player needs only to touch it. A drone can be attached to either 4 sides of the player. If a drone is attached to the rear, it will fire its weapons towards the left of the screen. The player can also eject attached drones by pressing the lock button.

Assigning targets to Drones with target-lock on

Drones that are not attached to the player can be assigned targets to attack directly using the lock button. This is done by opening the lock cursor and selecting a drone, then a corresponding enemy target.

Peforming a power transfer with target lock-on

When a drone is targeted while holding down the fire and lock button, it will recieve a power transfer when the fire button is released. This will cause the drone to charge and peform its special ability such as attacking with its own high power weapon.

If drone's special ability has a lock-on feature, it will use it against the next number of enemies that are locked-on. When transfering power to drones with lock-on abilites, the cursor will change color and the next number of targets the player make will become targets for the drone. When the cursor changes back to its original color, it will continue selecting the player's own lock-on targets. This effectively increases the number of targets the player can lock-on to.

Scoring

The scoring will broken down this way. Bonus points are awarded disabling enemies, without destroying them and for the number of drones the player has when finishing the level.

Gameplay Elements

Stages

TBD

Enemies

TBD

Power-Ups

TBD

Media

TBD
No code, no art, no free time. Nada.

Work follows me home
Again, I'm having trouble dedicating the time I need for game development. So much for making resolutions. I come home earlier now, but work just manages to follow me home (damn VPN!).

Anyways, I have the basic design and gameplay down in scribbled notes. I'll put them together and post it up here later this week.

There is Help
I searched for resources on shoot'em up related development, and as I expected I found a dedicated community at http://www.shmup-dev.net. What is interesting is that they're holding a competition for doing exactly what I'm trying to do now -- a one level side scroller demo with a boss. This is good because this means there will be a number of other developers trying the same thing. I'll probably get a lot of help here.

The competition ends in 15 days, so I will likely not enter. But I am considering using Blender Publisher or GameMaker to prototype the gameplay. So it is a possibility. I just need the time. *sigh*

The Tools
I want to make this a 2D game with pseudo 3D effects. I'd like it to support animated sprites, 3 scrolling layers and pixel-accurate collision detection. The one thing I want most however is absolutely smooth scrolling, without flicker, tearing or stuttering.

While I haven't begun development on the actual project, I have been trying out the toolkits I want to try for this project:

OpenGL Quads
My work is all centred around OpenGL so why not use it? Just map sprites and backgrounds to GL_QUADS and take advantage of the underlying hardware. Plus I get hardware scaling, rotation and filtering for free.

I'll only use OpenGL if the current 2D APIs can't achieve the speed and flawless smooth scrolling I want.

Allegro
Its still around! Long ago, when I picked up game development the first time, DJGPP and Allegro was there. Its so nice to know that Allegro continues to provide a fast toolkit for making games.

The toolkit itself is great for games, but I'm not sure about AllegroGL. I tried Allegro with AllegroGL, but it doesn't compile without some help and it didn't run properly on my system. It hasn't been maintained since 2004 it seems.

Maybe Allegro is good enough by itself, without OpenGL. If it is, then I'll use this library exclusively.

SDL + OpenGL
Most popular for sure and I have used it before, but I'm not convinced of its 2D capabilities. It seems to be used mainly as a host for OpenGL, providing only input and sound. Once you use OpenGL you can't use SDL drawing routines. But SDL's OpenGL integration seems better supported than Allegro's.

GLFW + OpenGL + BASS/FMOD/OpenAL
I like GLFW. Its light and easier to setup for OpenGL than SDL. Its API flows well with OpenGL's API. If I find that 2D graphics using OpenGL is the only way to go, then I'll probably use GLFW. Since there isn't a built-in support for any sound system. BASS and FMOD are great sound systems from what I've heard. OpenAL's API would go well with GLFW and OpenGL, but I may have to add libOGG to the list for music.

Haaf's Game Engine + BASS
This could be an interesting choice. Haaf's game engine is a 2D game engine, accelerated by Direct 3D. HGE seems to provide exactly what I want for my game. HGE has built-in support for BASS, so I might as well use BASS for sound/music. HGE recently went LGPL.

This week
This week, I'll put together some gamedesign, or a basic blueprint for the game. Then I'll proceed to prototype the game in Blender or Gamemaker.
I was supposed to use the rest of today to work on gameplay and some design specifications. But I got distracted by the look of that red bike. So I played around with the image, re-arranging the parts here and there, to find out why I chose this to represent my main sprite.

So here is how the past hours of the day went for me:

I wouldn't want to ride it. So why do I like it?



Maybe if it didn't need wheels, and perhaps add a canopy?



Hey, maybe if I was going for the Darius look I'd work with this. Lets change and add a few things. It needs a place to put thrusters.



Now that's cool. Nobody can tell at low-res. But how will I get it to roll on it side when Its going up or down?



Very cool. Maybe I should've just kept all this a dirty secret?

Now what was it I was supposed to be doing before this?
My first idea was to simply clone the first stage of R-Type I, Sprites, backgrounds, gameplay, everything. The first stage of R-Type is very short but manages to memorable and complete with a spectacular boss. I'm just doing this for my personal learning, so I didn't see a problem in doing that.

However, I didn't want the game to be unfairly compared in anyway to the original. So I decided quickly design a semi-original level based of R-Type and other games I played.


First thing I did before starting this was to play and study a number of side scrolling shoot'em ups like Gradius III, R-Type II & III, Einhander, Sidearms, Last Resort and Pulstar.

All I have in my head right now are incomplete images and ideas of the game I want to create. I tried to sketch them on paper, but I'm really bad and unpracticed at it. This was useless. I realize now that I need to learn how to sketch on paper, and I will someday make some time to teach myself. For now however I'll just rely on the Gimp.

These are hardly game design specifications, but I think I've struck a handy way to sketch my ideas.
The level starts out in space, with the basic star field background, and a series of small enemies that drop the first few power-ups for the ship. We move on to the next scene.



Here we have the hero ship (the red bike) entering a some large space ship/station in earth's orbit. I'm not into cars and motorcycles (I still don't have a driver's licence) but there was something about this bike I like. The look of this bike conveys the kind of look I want my hero ship to have. Thats the earth and the moon in the background, BTW.




Next we have our hero face a mid-level guardian, represented here by Robocop's ED-209. I wanted some walking tank, or mecha to be here. You will have the option of destroying it, or with more difficulty you can try to hack its AI and take control over it. If you do, you can use it to against the enemy boss.




Now we're going up some diagonal elevator. The ed-209 is now your hacked drone and follows you up the shaft on the elevator platform. I wanted this scene because just scrolling horizontally is kinda boring. This will carry you to the large area where you'll meet the enemy boss...



OMG its Unicron! Okay, I admit I don't know what the enemy boss will look like, but it will be huge. I think this pictures the scale I'm trying to achieve (Although it does look like the ed-209 has shrunk a bit since we first saw him...).

Not bad for 30 minute's work but I still wish I was better at sketching. One day, I'll be well established at game development and I will be able to enlist some talent to do the concept artwork for me. But for now, its just programmer's art for me.

I've doing some interesting things with the photo of the red bike, and I'll post it later here. I think you'll agree that I am getting better at this when you see it.

I'll also post more details on the gameplay when I figure it out for myself, but want it to be like R-Type, except there is no orange orb-like module and the charge beam disables enemies instead of destroying them. It will also involve hacking enemy AI and taking control over them.
I've been having a hard time finding free time to work on fun projects since I began my career. Before August 2005, I thought I was on a roll, producing a new game every two weeks. I was determined to catch-up with game development that I put-off until after graduation. Then after a little vacation I started work in September and it just all stopped.

Next week, I'll trying to get back in. I'm now used to holding a full time job, and I'm not so tired after work hours as I used to be. I'll try to work earlier shifts (flex time), so that I'll have more time at home for game development which may include a nap when I need it (but I first have to stop sleeping late). Watching less T.V will also free more time. Feel free to add suggestions

I've decided that my next project will be a basic (but not written in BASIC) Gradius/R-type clone. Just one stage and an enemy boss (of course) :-). This just seemes the next logical step from the previous games I made. Again, it won't be original but thats not the point. I'm giving myself 5 to 6 weeks to complete this.

5 weeks. I just hope I'll have something to add to the showcase by then...
I got my Thinkpad T43, last week which I bought from IBM.ca with a 10% discount using my Visa:

Image Hosted by ImageShack.us

I bought the bundle with 1GB of ram and the expander case.

This weekend I had time to play with it, and yesterday I noticed a single dead pixel in the lower-middle area of the 14" 1400x1050 TFT display.

This reminds me way back when I was so happy to get the TurboExpress and how heart-broken I was to find a single dead pixel on the screen. I had it exchanged, then a couple of months later two dead pixels appeared. I had to live with it.

Few years ago I bought my old T20 used. Weeks later, I found a dead pixel. It was past the exchange period. I had to live with it.

Now this brand new T43 has a defective pixel. Should I have to live with it too?

I can't send it for warranty service, Levono's site states the warranty covers TFTs with 11 or more defective pixels.

Since its only a week old, its still under the 30 day no questions asked refund period. This is an option, but it means probably I will have to pay to ship it back (expander case too). I'll then have to buy it all over gain.

But what if what happened with the TurboExpress happens again, and I end up getting an even worse display?

Is a 100% defect free TFT expecting too much on todays notebooks? I still haven't decided what I'll do.

Finally working

I finally got a job. I've been searching hard for a position since the last time I posted. I'm at ALTSoftware(.com), doing work for some weeks now for their OpenGL driver.

Unfortunately, I haven't had the energy or time to dedicate on gamedev lately, or writing tutorials for my website. My online activity has been dead (everywhere not just gamedev) for that past two months. My basement is still a mess (all the drywall still has to be removed) and I need to get a new development rig setup somewhere else soon.

I just found out that today is the last day of 4e4 registrations, and I'm contemplating whether I should register, even though I have nothing yet to submit. If I do make something, I will have only my T20 to work with (which isn't really bad, but it has a weak GPU) and just 1 week development time.

Quote:
update: It appears today was already too late to register anyways. I guess I'll move on to my next great project :-).

But hey, I'm earning money, and doing stuff with OpenGL. I'm happy.

BTW, Altsoftware had in the past ported a few games (like QBert) to Mac OS, which is cool even if they don't do that stuff anymore. I'd probably hate working for a big game development company anyways.
Since coming back from vacation, I've been busy finding a job. And now my basement is flooded (Frigg'n Tornado in Toronto?!) where my general work area is. So I wont be doing game development for a while, until I find work or at least when work area is setup again.

Good thing I still have my old T20 to work with.
I'm currently out of the country, and I wasn't able to post an entry before I left. Internet access is a little hard for me to get to at the moment, but I will make a proper update when I get back home next week.

PliGame, R.I.P

Just to further prove that I'm an unusual "newbie" to game development, I present to you PliGame. This package provides extensions to the Pliant language for the SDL game library. I wrote this. Its even listed on the SDL languages page. I did this as part of my undergraduate thesis.

Pliant uses a JIT like compiler, it compiles Pliant scripts into native code in memory at runtime. My thesis professor, Marcus Santos is one of the core developers of Pliant. I decided that Pliant could perform well as a game programming language and so created PliGame.

I implemented bindings for graphics, event and input function to SDL. This was enough to prove that Pliant, which syntax is as simple as Python ( so some think ) and performs comparibly to C. I found a few demos in C and Python, and wrote similar demos in Pliant. One example was the rotozoomer.

The rotozoomer is simply zooming and rotating a 2^n by 2^n tile bitmap image in and out. I was able to implement this in Pliant in just 92 lines, with comfortable white-spacing. And it performs at full 60FPS.

roto.pli:
Quote:


module "/pliant/language/context.pli"
module "/pliant/math/functions.pli"

module "/pliant/SDL/SDL.pli"

gvar Pointer:SDL_Surface tile
gvar Pointer:SDL_Surface screen

function rotate dest src angle scale
arg Pointer:SDL_Surface dest src
arg Float angle scale
var Int u v du dv x y sx sy mv mu
var uInt umask := src:w - 1

var uInt vmask := src:h - 1
var Address texture image
var Float temp

texture := src:pixels
image := dest:pixels

sx := 0; sy := 0

du := cast (scale * (cos angle) * 4096.0) Int
dv := cast (scale * (sin angle) * 4096.0) Int

for y 0 (dest:h - 1)
u := sx
v := sy

for x 0 (dest:w - 1)
mv := (v \ 2^12 ) .and. vmask
mu := (u \ 2^12 ) .and. umask

(image map uInt8) := (texture map uInt8 (mv * src:w + mu ))
image := (image translate uInt8 1)
u += du
v += dv

sx -= dv
sy += du

return

function init -> b
arg Bool b

b := true


if (SDL_Init SDL_INIT_VIDEO) < 0

console "Could not initialize SDL!" eol
SDL_QUIT
b := false
return

screen :> (SDL_SetVideoMode 640 480 8 SDL_SWSURFACE)

if not (exists screen)
console "Could not init video!" eol
SDL_QUIT
b := false

return

tile :> SDL_LoadBMP "astroids.bmp"
SDL_SetColors screen tile:format:palette:colors 0 tile:format:palette:ncolors


function main
var SDL_Event event
var Float angle := 0.0

if not (init)
console "Init failed..." eol
return

var CBool done := false

while not done
while SDL_PollEvent:event > 0
if event:type = SDL_QUIT
done := true

eif event:type = SDL_KEYDOWN
done := true

rotate screen tile angle (sin angle)
SDL_UpdateRect screen 0 0 0 0

angle += 0.005

SDL_FreeSurface tile

SDL_QUIT
return

main




I made an MPEG video player (w/ SMPEG) and almost wrote a first-person Asteroids game. But I stopped half-way. Had I completed it, that would have been my first game.



I got an A+ for the thesis, and quickly switched to other important business. I never continued the project, and my professor is still looking for thesis students to further develop the Pliant language. Its still complete enough for making games, just without sound.

One of the other reasons I discontinued were the difficulties in supporting both Linux and windows versions. I wanted it to be cross platform, but it appears that the developers of Pliant are more interested in running Pliant in its own operating system, Full-Pliant or Linux.

Window library support was a headache and I just couldn't keep up with all the new changes in the Pliant compiler. I decided that if they can't fully support Windows, then I'd just forget about gaming applications for Pliant. I hate MS as much as the next guy, but I can't ignore the fact that gaming is hot on Windows and not Linux, unfortunate as that is.

So yes, I do indeed know SDL. And I've never made a game with it. I'm still a newbie.

I can't blog.

Tutorial 02 Online


Tutorial 02 is now up. I'll try to complete one of these every week or so. I think I did a sufficient job commenting the source code to my games, enough at least to explain how they work. I guess then the purpose for writing these tutorials is to explain how I came up with the design of the game, and the stages of its development. When I complete all the tutorials and get some feedback, I'll make a public announcement in the beginners forum.


Things I Want To Explore In the Future


Since finishing my first five games, I've been considering my next project. I want to explore many areas in game development.


2D Tricks. I want to learn how to make those 2D demo effects that used to be popular in the old days. Like bobs, 3D bobs, flames, flags, lenses, emboss, lighting, bump-mapping, screen melts and crazy animated text demos. I'm particularly interested in psuedo 3D effects. There's a collection of demo effects that I want to study sometime.

Network Play. I already know how to program network sockets and implement the basic client-server model. I was thinking of making a space melee game in the vein of Star Control but with asteroids. So its really a two player vs derivative of Asteroids. Choose or upload a pic of your ship's sprite image and select your weapon and special ablitly. Some of these abilities could take advantage of surrounding asteroid debris. The game could dynamically zoom in and out of the action. It could also actually be fun.

Quote:
Doing a quick search revealed that Star Control 2 has been open sourced. Its really the 3DO port only, but you can download the gfx pack, containing the ship sprites. I wonder if the licence extends to fair use of these too?


Scrolling SHMUP. Why do these games look easier to make than they really are? I know in the future I will make a sci-fi shooter like R-Type and Gradius. I really, really would like one day to be acredited for producing a SHMUP as fun and cool looking as Treasure's Radiant Silver Gun and Ikaruga. I first have to catch up with FenrirWolf's work.

But I may just temporarily put all this on hold. Continue reading.

Revenge of Johnny 5: Zombie Hunter.


Maybe I should explain what this is:

Its Johnny 5 the living robot from Short Circut 2, with eye-patch and mohawk, holding the sword (and human hand apparently) from Revenge of Shinobi, impailing the decapated, bloody head of a zombie. Now you know I've gotta be thinking about 4e4 this week.

Four Elements IV


It appears I arrived in time for this long awaited Four Elements IV contest. The last Four Elements contest took place 3 years ago. The next big contest at gamedev may not happen for a long time. So what should I do? Do I let this one go by because I'm not ready? I've never designed an original game. I've never even imagined of making an original game (I mean one of my ultimate goals is to make a SHMUP like R-Type!).

As overly ambitious it may sound, with just 5 simple games behind me, I will try to make an entry for 4e4. As I said in my first ever post on gamedev.net: I waited too long for this. After all, why shouldn't my first real game not have ninjas, zombies, robots and pirates?!

To pull this off, I will need to take advantage of every little flexability the contest rules allow and overcome any defeciency in my skill or expereince with creativity (I know I have some somewhere). I will also have to be realisitc with my goals; I will not win. Instead I will aim to fully complete an entry by myself and then make it to the top 40%. Thats already too hard!

So what's my strategy? I haven't fully explored it yet, but here's a break down off the top of my head:
Quote:

Technical: Stability, Use of Technology, Speed.

I lose in technology because my knowledge is limited, so I have to make up in stablity and speed. I will have to depend on Java again, or use a rock-stable RAD tool, game library or scriptable game engine. The game should be built on proven and tested frameworks.

Creativity: Game Design, Artwork, Technical methods

If my game design is correct, it will qualify. Period. Not only will all 4 elements be equally reperesented, but they will play and feel like players expect them to. Making the ninja kill a zombie with ninja stars and steal things is a good example. Making a ninja compete against a zombie in a pizza pie making contest (although funny) is a bad example.

I think the judges here will be able to recognize a sprite from Spritelib, or a 3D model from 3D Cafe. I want to try and make my own art. I must have some artistic talent hidden somewhere, I did create that logo above and I did design my cousins website. I'll just use the most minimalistic style possible, without looking like bad cartoon sketches. I do care about how my games look.

Next week, I'm gonna try to excecise my artistic skills, and read some tutorials here on gamedev.net. I may pop into the art and design forums and ask for advice or maybe even help.

Fun: The Hook factor, Gameplay Quality.

I don't have to worry about the Judges not wanting to play the game. I just have to keep the game from getting boring too quickly. The judge isn't going to play the game from beginning to end, right? I'll try to make the first five or ten minutes of the game the least boring as possible.

Polish: Presentation, Installation.

As long as the game looks complete, and doesn't appear like a half-finished demo, I have little to worry about polish. I guess a nice and clean menu system and splash screen will make judges happy in the presentation area. I can't do much else.

Kudos Points: Obvious efforts to go above and beyond the contest requirements.

Wow, how will I earn these? Here are some ideas:

1. Make the game multiplayer. I wanted to make a multiplayer game anyways.
2. Make from scratch, no 3rd party tools/libraries. Extra testing.
3. Equally represent Robots, Pirates, Ninjas and Zombies as well as Water, Wind, Earth and Fire. Hmm.

I could also improve my odds by submitting multiple entries. In the last month I created 5 simple but fun arcade games. What if by the 4e4's deadline I created 25 similariy simple but qualifying entries? The judges will hate me thats what.

Finally, I won't keep any of my work secret. It will all be published here. Nobody's going to be tracking me down for good game ideas. I'm just a newbie. Those who care to read this journal will likely be those who want to support and help me. I shouldn't be afraid of being ripped off by these people. I should infact be afraid of ripping-off someone else's work, with all these clones I've made and intend to make. So being open in this case is a safety measure too.
Sign in to follow this  
  • Advertisement