-->
Recent Projects:
Current Project:
Exceptional Journals (in no order): [Eliwood] [Steve Healy] [Ravuya] [Mark the Artist] [Scet] [Ysaneya] [Mayan Obsidian]
My Personal Website
| Wednesday, August 30, 2006 |
  Quiet time. :( | 
Posted - 8/30/2006 11:19:42 PM | Foreseen Silence
Tomorrow is my last day here at home before I move out for my first year of University, so it'll likely be a little while before I get active again. Move-in is Friday, followed by RCC (residence computer consultant) training on Saturday, followed by Sunday+Monday where everyone else moves in and we bust our asses off helping the lamers who can't figure out how to connect to the internet, followed by a week of funfun frosh orientation goodness, followed by some time to settle into my classes. It's going to be amazing.
In short: see you guys later! 
8 Planets in Our Solar System
Pluto was fired.
| |
| What is "progress"? | |
Posted - 8/28/2006 12:52:25 AM | 3 more days!
I'm pretty pumped. In 3 more days I'll be moving over to residence at the University of Waterloo. Whoop, whoop! Frosh week is going to be nuts, and so is the free BBQ on Friday.
Oh, and "learning stuff" might be kind of neat too.
Quake 4
Bought Q4 the other day. Stinks. Same boring recycled gameplay, but with super-linear maps and eternally poor-lit areas. Worst $25 I've ever spent. 
Skirmish Online
I haven't been overly motivated to work on Skirmish as of late. Writing an autopatcher is sort of boring, and the fact that I need to tackle the GUI next doesn't do much to push me either. Still, it must be done.
I've begun the patch server, which is written in C#. I didn't really care for RakNet's autopatcher, so I opted to write my own instead. If I really actually worked on it regularly, I would likely have it done in a couple of days. Hopefully the rate of development will pick up again once I've gotten settled in at residence.
INTERWAR!
I spent some of tonight going over my old (old!) games and came across Interwar, a small -- crappy :P -- overhead vehicle-based shooter I wrote back when I was a gamedev newbie, with Delphi and the DelphiX lib (DirectDraw). What irks me is that the main-menu user interface is so awesome, but in-game it's hideous. (Date-Check: Yes, I made this approximately 3 years ago :P)
50 points to whoever can beat the game (all 3 levels).
Download InterWar (450 KB)
| |
| AAAGH! WHY AM I A MORON!? | |
Posted - 8/25/2006 1:08:27 AM | The Dumb Stuff
I am stupid. It's official. The papers are in, signed, and being sent via Purolator as we speak to the appropriate board members.
Any programmer here knows what it feels like to spend hours debugging a problem that ends up being comedically simple in the end. Right? I just pulled one, and naturally I had to share it with the world. Just.. so.. dumb. Agh. Let me set up the stage:
Movement prediction was one of the main orders of the day. Remote clients use two sets of coordinates: 'visual coordinates' and 'real coordinates'. The trick is to have the game internally keep track (and continue to simulate) the remote player's movements via the real coordinates, but visually draw the player at the visual coordinates. This is done to prevent players from suddenly skipping or jumping across the screen.
Anyways, for some reason people were jumping a LOT more than usual. The heck? Me and a few other players did a short race (horizontal line) and the remote players would appear to move somewhat slowly, then jump forward to where they 'should' be, and then slow down, and jump again. Very odd.
*3 hours later*
Oops, I forgot to make the 'visual coordinates' of the float type, not int. It was rounding down my correction-speed of 1.85 down to 1. Nice. *whacks head* I invite everyone else to share their follies to make me feel somewhat better.
(Kudos go to Cliff, who was there helping me debug for most of those 3 hours!)
(The mayhem! But.. where are the guns?)
Website!
Sephir -- also a Skirmish Alpha Tester -- has agreed to take a swing at designing a website for Skirmish Online. Which is wonderful. My last web designer took on that job in January, and in 6 months all I saw was a mockup, so I'm pleased to see results already stemming in from Sephir.
Here's a mockup of the top title bar and navigational sidebar will resemble. The plan is to have a 'floating windows' layout to represent various items (news entries, etc) in the middle, and another sidebar on the right side to show dynamic information (top scores, IotD, etc). Those will be a little trickier, but things are looking good.
(I am, of course, open to suggestions!)
Oh, and the current (temporary/ugly) Skirmish Online website now ranks #1 on Google. Take that, you UK band. :P
The World Trade Centre
Watched the movie tonight with Jason (LiquidAir in the above screenshot). Amazing. I was brought to tears several times during the film, and walked away with a much greater appreciation for the hard work, bravery, and love of life shared by those who experienced the horrific event.
After the movie ended and the credits rolled, everyone in the theatre just sort of sat there for a few minutes, collectively. In my case both deep sadness and of respect, and I'm sure it was quite mutual in there. Usually most people can get up after any movie and walk off, but this was so different it was eerie. The ending was so well-played, emotionally. I unhesitantly recommend this movie to anyone who has the time to check it out.
Next up?
I've decided to move in the direction of getting more groundwork done before heading towards features like guns, player death, game classes/modes, etc. Tomorrow I want to see if I can get an autopatcher system implemented, and after that perhaps get a GUI integrated (like CEGUI). Following that will be the master server/client, and player accounts.
EDIT: Oops. And I wrote the chat system today. I find it odd that I forgot to mention that above, since it took a good few hours. Oh well. :P
| |
| The "Online" part of "Skirmish Online" | |
Posted - 8/22/2006 12:03:21 AM | ONLINE!?
Finally the networking begins!
There's not yet a fancy interface for selecting one's alias, or some spiffy way of informing the game whether you'll be hosting a game or joining one, but for now it's just a simple no-hassle console app query. Ugly but effective. Nothing is in stone yet, but I may be checking out the nifty CEGUI library for my future GUI needs.
(Dead sexy. Well, maybe not the 'sexy' part. Just, uh, 'dead'. )
Since the IP to connect to is hardcoded at the moment (me! me!), most of you will be choosing 'C'. Based on said choice, the game will create either a GameServer or GameClient instance and get things rolling via the wonderful RakNet lib, which has been nothing but an asset thus far.
Long story (very long, gah!) short, the server and client do their jobs in listening and sending data in/out, can detect connections/disconnections, maintain a list of remote players, and such. I dislike how it sounds pretty darn simple when I do over the gist of what I've done here, but in the code it's a completely different story. I've been refactoring my head off today, removing a useless abstraction class called RemoteClient that resided between the network interface and the actual Player class. Useless!
The first step -- after boring initialization and foundation stuff -- was to get player creation/login occuring both: a) when a new player logs in, and b) when sending all existing players to a newly logged-in player. This didn't take long; Mushu, Ravuya, and DarkCampaigner assisted with the testing. (Thanks guys!)
Next up was basic movement. I know that movement prediction is a really crucial step, since its accuracy will determine the playability of the game. If I do a poor job, then bullets will appear to hit on some clients, and be clear missses for others. It's this kind of this that makes writing action games online a nightmare. I intend on keeping the server-authoratative system I had previously, since it proved not only the most accurate, but additionally prevented devious hackers from doing nefarious deeds. Anyways, basic movement consists of merely sending the player's position and rotation 4 times per second (every 250ms). The server simply bounces the message off to all other clients, and they update the remote player's sprite. Very simple, but it looks a heck of a lot better than everyone sitting on their collective arses. :P
(Click for bigger)
Fonts revisisted (and DirectX temptation!)
I don't care what anyone says: fonts/text-output in OpenGL is a huge pain in the backside. There's a smorgasboard of ways to do it, whether it be outline fonts, bitmap fonts, texture-mapped fonts, or some combination of those, but all are fairly equally a pain to implement. At least compared to the awesome D3DXFont interface that Direct3D provides.
And had I not chanced a conversation with Ravuya (GD.NET's active cross-platform (and by association OpenGL) proponent), I would have been spending part of tonight, tomorrow, a few days thereafter rewriting all of my graphic code to Direct3D. Phew.
Basically, I gave Ravuya's RavBitmapFont class another go. Apparently the constructor I used was deprecated -- it didn't like Targa images, or somesuch -- so I converted the image containing the relevant image data to a PNG, whipped in the new constructor, and BAM! It worked. Sort of. I tweaked things around a little and soon had it working exactly like it did when I was using the wgl bitmap fonts. Except now it was running several times faster. Wonderful.
In my thankfulness, I offered to beef up his class a bit. He was using plain intermediate calls (glBegin(GL_QUADS)) and such for each character, so I decided to give a shot at having it render via display lists. And so 30 minutes or so passed. I was disappointed to learn that my work resulted in a speed drop. Turns out for something as tiny as a single quad, DLs don't offer any real speed gain. All was not lost, however. I optimized several of his state-changing calls and now I'm getting fonts rendering even faster than the lightning speeds I was already getting.
If one looks at the above screenshot with me and Ravuya, it may be worth noting that when Skirmish was using Delphi+Direct3D, I was getting around 40 FPS with that much text and scenery going on. Now I'm getting upwards in the 130 FPS zone. This is a real thrill because earlier in development (with those SLOW rasterized bitmap fonts) I was really worried about performance being cruddy. Now I'm absolutely thrilled that speed shouldn't be a problem even on lower-end systems. System tests to come.
Further optimizations
The idea of having collision groups has sped up my execution speed hugely, as well. The gist of it is, there are (will be) three types of game objects capable of collisions: players, map objects, and projectiles. My old collision detection loop looked something like:
for a = 0 to big_sprite_list.length-1
for b = a+1 to big_sprite_list.length-1
CheckCollisions(a,b)
With much prettier C++ code, I assure you.
(As a cool sidenote, I find it very neat that my taking of Discrete Math/Geometry last earlier this year has had such great benefits for game development. My gained knowledge of permutations/combinations has been hugely useful in determining things like how many collision combinations can occur, and the vector math was also a huge boon. In short: stay in school!)
This code is bad, since not all sprites have a relevant collision result with other sprites. If there are 500 sprites in the game, we'd be seeing a hideous 124,750 iterations/checks. Gah.
So the new idea is that we store all sprites in one of three lists: playerList, mapobjectList, and projectileList. Map objects don't need to check collisions against any other sprite (they are purely passive), projectiles need to check against both players AND map objects (purely active), and players only need to worry about colliding with map objects (semi-active). So our total number of collision iterations falls down to:
(numPlayers * numMapObjects) + (numProjectiles * numPlayers) + (numProjectiles + numMapObjects)
// Which conveinently can't be factored :P
This has resulted in a big boost in performance -- in a sample case, 5000 versus 100,000+, gah! -- which also adds to the overall FPS at the end of the day.
Not really an optimization..
I (stupidly) found myself amazed today, when I ran Skirmish in Release mode (no Debug data generated/used) and my FPS suddenly doubled. Wow. In Delphi -- which until now has been my main gamedev medium -- never really gave a speed difference in Debug versus Release modes, so this was a whack in the forhead to me. Uh, the good kind of whack in the forhead.
| |
| It's all about the daily steps.. | |
Posted - 8/18/2006 12:15:45 AM | Revelation! (sort of) (not really)
Today I realized something very important. Although it may seem argueably obvious: daily progress is important. Making a small step in your code every single day adds up. Of course it sounds like I'm stating the obvious, but a lot more people say it rather than do it. All it takes is coding in something relatively simple every day, even if it's not a mainstream item.
An example would be today, where I merely got player names displaying beneath their respective player, and properly centered. Afterwards I added a helper function to add a black outline to any given text. Simple? Yes. A huge step? No way. But this little movement in the right direction will eventually add to the finished product down the line. The realization is: if you make zero progress, you aren't any closer to completion. At all. If you sit on your arse all day and code NOTHING, then you will never finish. Even if you just write a small feature or addition every darn day, you will get closer and closer -- albeit slowly -- to that elusive finish line.
Again, this likely sounds exceedingly obvious to many of you. This is a revelation to me however, since I'm the sort of fellow who sits down, writes a massive chunk of code (usually for several consecutive days) and then sits back and takes a breather for anywhere from a few days to a few weeks. I didn't like the big breather time where I made zero progress. I'd much rather make a small push forward every single day -- still allowing for those coding bursts -- than do massive blitzes and end up being unable to code for a week or so. This isn't a license to be lazy, but rather a way of looking at it all in a long-term way. Skirmish Online is going to take a long time to complete, so I need to move steadily, not recklessly, or else it will never see completion!
IDE Migration
Insofar I've been using Visual C++ 2005 Express. That changed today. I've got to say that the IDE has only one thing going for it: it looks pretty. I migrated all of my code/project/solution/etc over to Visual C++ 2003 Professional (supplied kindly a while back by my school :P), and things are wonderful. Not only does Intellisense actually work properly in all/most cases, but my code seems to compile a lot faster, too.
The only caveat is that the compiler is a lot pickier, it seems. It spews out a lot of warnings about my habit to not use explicit typecasting (I'm an implicit sort of guy  ), which is very annoying. Anyone know how I can block these warnings out?
Networking ahead!
I know that I've been saying that I'll be tackling networking the next day, and I think I can finally say that again today with much more confidence. Maps are loading, the game is displaying, the player is moving, and text/fonts are working. It's time to get online!
Forum Fun
In a (vain?) attempt to get some activity going around the Skirmish Online forum I've added an Off-Topic section. It's been rather bare around there since development has gotten back into gear, and this is likely because there's nothing to really 'play' just yet. The plan is to get people blabbing on there about whatever, which will generally keep them checking out the forum more often. This will allow people to already be nice and active by the time Skirmish is far enough long to warrant discussions. Feel free to help the cause. :P
(Oh sorry, no pictures today. )
| |
| Wednesday, August 16, 2006 |
| Fonts! Fonts! Fonts! | |
Posted - 8/16/2006 11:41:23 PM | You font me, and I'll font you..
Today was generally a waste of time. The original plan this morning was to 'quickly' get fonts/text-drawing implemented, and then code in a simple GUI system to allow the future players to set some simple options (like Host or Client mode, or their alias) and generally look pretty.
Unfortunately, only the first part happened. The 'quick' font implementation took the majority of today. Being the spoiled little coder I am, I was under the impression that adding text drawing would be rather trivial, like it is in Direct3D via the ID3DXFont interface. Wrong!
First I went along with NeHe Lesson #13 to try to get bitmap fonts working. I really liked the idea of being able to create new font sets/styles on-the-go, rather than being bound to a premade image, like texture-mapped fonts. Rasterized fonts like bitmap fonts aren't as fast, but they sure as heck take less time to implement (when you know what you're doing). In summarization, the bitmap fonts didn't work. Odd. I was using SDL rather than the evil Win32 API like the NeHe tutorials use, so I figured that a simple call to wglGetCurrentDC() would get the device context and make life simple. Nope. Nothing rendering on the screen. The heck?
After an hour or two I caved and decided I'd try some other method to get that elusive glyph-y paradise on my screen. A few 3rd-party libraries were attempted, but they simply didn't play nice with Windows; strange makefile lingo and QT references left me feeling dumbfounded. Nuts; off to something else.
Next I went after Ravuya's RavBitmapFont class that was conveinently close to his Propane Injector files. It sounded relatively nice and easy, since it could read in AngelCode-format texture-mapped font files. Doh. Again I was struck by non-Windows fervor. Or something like that. In either case, it didn't work out. No offense to Ravuya of course. It was likely something silly on my behalf that led to my failure.
By this time I was furious. I grunted in frusteration and played Infantry, Restricted Area, and some other PC games for most of the few hours before Draffurd came over, where we drank Alexander Keith's (a flavourful beer!) and played Doom 2 on his XBox. Good times. I'm actually still semi-drunk, so excuse any illogical sentences or typos -- although I'm pretty good at preventing the latter.
Long story short:
I got it working. Turns out if you don't glDisable GL_TEXTURE_2D, rasterized bitmap fonts will never appear. Funny stuff, huh? I didn't laugh.
Anyways, this clears the path so that I can encapsulate font drawing into a class system (so multiple fonts/styles can exist), and then writing that GUI system. And then, my friend: networking!
| |
| And Newton thought HE had it hard! | |
Posted - 8/16/2006 12:26:40 AM | Player Physics
That's right, kiddies. Gather around old grandpa Steve and listen to his recounted tales of the implementation of player physics.
Today was another marvellous day for productivity and progress. Note that I've had this whole week off of work so far (until Thursday), so the majority of my free time is going into Skirmish Online's development.
Each game instance now has a Player associated with it, which the main camera is fondly centered on. This player can be controlled by the user (via customizable keys (lacking a customization interface :P)), and features the standard fare player physics: velocity, friction, 360-degree rotation, and all of that fun stuff. The movement animation cycles relative to the magnitude of the player's velocity, so it's neat to give him a high TopSpeed and have him zip around like he's Bicycle Repair Man or something.
Whack! Watch out for that crate!
After the player was politely waltzing around my screen, it was then time to tackle collisions. Skirmish requires two flavours: map collisions (with wall tiles), and sprite collisions (with map objects, bullets, cheese-burgers, etc).
This required a rewrite of how I was previously handling the sprite lists (full list, and a list of collidable sprites). I was using std::vector originally, which was as slow as beans in terms of sequential access. std::list was a bit faster, but my framerate was still plummetting. Now I beefed it up to a quasi-dynamic array which zips along with sufficient speed, all contained within a SpriteArray class that manages addition, removal, sequential access, and data-clearing.
Map collisions were a cinch. Since tiles are arranged evenly in 32x32 blocks, it's just a matter of dividing the points on the player's hitbox by 32, and checking the hit-type of that tile. I devised both CanWalkOver() and CanShootOver() helper functions to ease the (likely) future pains of managing the collision possibilities between the various sprite types and tiles.
Pixels, my friend?
Sprite->Sprite collisions are a huge pain. Mainly because I insist upon having pixel-perfect collision detection. Stubborn me. For those of you just tuning in, I'm using OpenGL, which means that direct pixel access -- in terms of speed -- is a lot like cutting the front lawn with a frog. Not very fast. So how am I to get this working without killing my performance?
At first the plan was to render just the sprite in question, and then read just one pixel (at the player's centre) to determine if it's a hit or not (!black). I couldn't get any logical results from glReadPixels(), so a few tutorials off Google later, some milling around on GD.NET, and I canned it. That approach would just plain take too long.
The other resort was to bite the bullet and do it how I did in the previous writing of Skirmish: access the surface pixel data and check from there. That's as easy as locking a surface to a texture and reading it in Direct3D, but I'm in OpenGL-land now, and it doesn't seem that simple. So I had to settle for storing the pixel data into each created Texture object when I loaded the data in initially at startup-time. This means a bit of a bigger memory footprint, but the tradeoff is that I get direct pixel-reading access (virtually) for free. Woot.
So I implemented this, and got the player bouncing off of non-rotated objects. Those crates and chairs didn't even know what hit them. Next up was to get rotated map objects colliding properly too. This sounds simple, but you must remember that the pixel data is stored in a manner equivalent to Rotation=0. Luckily I had faced this exact problem with the previous Skirmish, and solved it by instead inversely rotating the point on the bitmap I was checking. I doubt I'm sounding too clear, but a long story short: it worked. There was a big bug that took me about 2 hours to figure out, but this is getting pretty nitty-gritty. I don't think most readers really care about that.
After that, I finished by checking the X and Y directions seperately, allowing the player to 'slide' across the edges of most objects, rather than bumping off or getting stuck. It'll need some tweaking down the line, but the game -- yes, I called it a game now :P -- is starting to feel stable and closer to being playable!
Oh, and I tossed in a few more little things, like a gfx_utils.cpp/h file-set to handle quickly drawing rectangles, lines, and that sort of jargon. Mainly so I could enable/disable drawing sprite hitboxes for easier debugging. Also implemented sprite layering via the ever-handy z-buffer. Now you can officially hide under trees again!
(Er, how do I show a screenshot of collision detection?)
Tomorrow will hopefully see the final tweaking of the player physics, and then the beginnings of networking. And I've got to say that I'm thrilled at how fast things are coming together. I can only hope that this time it sees success!
| |
| More steady steps forward! | |
Posted - 8/15/2006 12:09:22 AM | In Soviet Russia, game code YOU!
Skirmish Online makes more steps today through its tender infancy on the fast-track to becoming something that can be considered a game.
Today I fixed up a few remaining (minor) map bugs, which finished off the map milestone I had set. I quickly followed that with the creation of the "LID Generator", which creates one big lump of data from a large number of individual bitmaps. This not only prevents the vast majority of art-theft, but it also looks infinitely cleaner in the directory than seeing 200+ bitmap files strewn about. It's just bad housekeeping. (LID stands for "Lump of Image Data", BTW)
The sprite engine now uses std::list rather than std::vector, since I'm under the impression that std::list traversal is quicker than the vector equivalent. Time will tell. Resources -- at least the key ones -- now are neatly deallocated when they aren't needed anymore. At the moment this primarily texture data, since they're easily the biggest memory-eater in the game.
The 'Player' class is now underway! Players can now be fully drawn, based on their weapon type (unarmed, rifle, single pistol, dual pistols, or cannon), if they are in a running state or a firing state, and what colour their external armour is. All of which fully animating.
So why not make a silly demo out of it, and toss in 100 randomized soldiers on a map?
(Arrow keys to scroll!)
Download Skirmish Online v0.1 Sprite Demo
If you do give it a try, be sure to let me know what sort of framerate you're getting (displayed in the outputted Log.html file), and of course any abnormal occurances that may occur. I realize the file size of ~1.9mb might be a little daunting at such an early stage, but once the planned autopatcher is in place, updating your version will be a snap!
Additionally added today was game-update-regulation, which is a fancy compound word for ensuring that the game moves forward at the same speed irregardless of how fast the game is drawing. This is accomplished by getting the ratio of how long the frame took to render, to how long an ideal render should take (1000 / 60 = ideal 60FPS rate). With this I can run twice as many game logic updates if the player is running at 30FPS to compensate for their inferior video card ( ), or at half the updates if they are flying along at 120FPS. Not a vastly complex thing, but it was a huge problem before I implemented it in the last Skirmish for low-framerate players.
Up for tomorrow is player movement/control/physics, and collisions with both the map and map objects. Pixel-based detection should be a fun challenge. Afterwards I can get onto figuring out how on Earth I'll pull off movement prediction.
(And give Ravuya's latest Glow demo a go, too! )
(EDIT: And Sir Sapo's!)
| |
| Revival! | |
Posted - 8/14/2006 12:10:33 AM | Ah, yes. It's been a few days, hasn't it? I'll try to cover all of the main bases.
Radeon X1300 PRO
Bought one. Both my Radeon 9600 PRO and my GeForce 6000 GT decided to break ($200 CAN apiece, #!$*@%), so I got this one. I also (wisely) got a warranty at the store I bought it at that's good for 2 years. Basically, if it breaks in any manner, they hand me a new one. Woot.
My power supply came in, too. Turns out it doesn't fit in my motherboard or case. @#&$@*. There's $50 down the drain, too. Agh. My monies!
Skirmish Online
..is proudly coming back. Legacy was looking like a nice start, but my heart simply wasn't there for it. Skirmish Online was the most promising game I've ever worked on, and I think that I'd be wisest to stick to it until its completion. I'm sure there's a few of you around here that feel the same. ;)
However, Skirmish will be going the way of the mighty phoenix. It sort of died, but now rises from the ashes again. What I mean by that poor metaphor is: I'll be rewriting Skirmish from the ground up, again.
Delphi has been a really great language, but RAD and game programming just don't like to mix that well. There are so many areas of my code that are horribly inefficient, ugly, or plain broken beyond repair. I made so many hack-jobs that I'm surprised the whole thing still sticks together. The end-result is awesome, but it's pretty unstable and I know it can't live up to the potential I envision.
That's why I'll be retaking the battle in C++. I used the basecode from Legacy that I had already written, so I had an SDL/OpenGL setup, logging system, map engine and basic sprite engine already in-place. Uber.
And the progress?
Over the last few days I've been working on retooling my editors to work with the new source. The TOG Editor (Tile/Object/Ground) and SME (Skirmish Map Editor) are now changed over to the new data format, and Skirmish is capable of fully loading game maps and TOG data, and displaying them. Of course this doesn't sound like much, but fully implementing what took me the eventual course of a few months in just a few days feels sort of neat.
I guess I owe an obligatory screenshot, don't I? This shot is from DarkCampaigner's "Forest Fortress" map, which will eventually be a CTF map:
(Scet wasn't the only one with a glorified map viewer! )
As you can see, it's nothing fancy, but it's something else that's very important. Something that is crucial: a start. Small daily steps will eventually add up, and Skirmish will see itself reborn as something even more kick-arse than it was before. And in less time, too!
What'll be different?
Skirmish Online won't resemble quite the same game that you played before, if you had the opportunity to test in the past. Here's the general rundown of things that will see significant changes (off the top of my head):
- Faster movement. Movement prediction will get a total overhaul, and will hopefully result in much faster and more fluid movement and actions.
- New weapon/inventory system. Weapons will become part of a universal set. Grenades, rifles, rocket launchers, mines, and all manners of destruction will work from a base stat-set. This will allow for less rigidness in weapon distinction, and more flexibility for cool weapons.
- Way better networking. I'm going to be taking advantage of the super-cool RakNet library, which is a fairly high-level lib that manages most of the stuff I had major issues with in the original. Things like managing 'connections', reliable packets, and a master server system will be a huge boon. It even comes with an autopatcher system! Woo! This lib will ideally save tons of implementation AND debugging time.
- Classes and The Shop(tm). Player classes will be implemented as early as possible, as well as the shop system, will will enable players to customize their character. No details of these are set in stone, yet.
..And probably plenty more. Hopefully there are still some folks around that are up for some exciting testing sometime soon (a week or two?)! (If you're game, add me on your MSN (hopedagger (at) gmail.com))
I apologize for the seemingly whimsical project changing, but this one is in for keeps. It's a shame to start from scratch again after working on the last source for 5 long months, but sometimes you need to take a few steps backwards to make many more strides forward.
EDIT: Ah, the domain seems to have updated finally. SkirmishOnline.com lives again!
| |
| Thursday, August 10, 2006 |
| Gah. Just gah. | |
Posted - 8/10/2006 12:06:04 PM | Well, for those of you who read the news in my previous post, you probably won't be shocked that I got very little sleep last night, and spent all of this morning with my stomach knotted and my heart clentched.
And then I got an e-mail from the Office of the Registrar:
Quote:| It has come to our attention that you have been contacted in regards to having a final average below 75% in one or more of your required courses. I wish to apologize as your grades are ok and your offer to the Faculty of Mathematics is not in jeopardy. There was a problem calculating your special average, which is an average of your English, Advanced Functions and Introductory Calculus, Geometry and Discrete Mathematics and your next highest 4U or ICS4M course. We believe our system pulled the a mix of final and midterm grades while we were checking conditions. I have just finished calculating by hand your special averages and they have in fact met the required average. Again, I apologize for any anxiety this has caused you and we look forward to seeing you in the Fall. |
Jesus. Christ.
I literally wept with joy. I can't believe how close I was to being stuck waiting another year (or so) until I'd have another shot at University. Gads, I'm still awestruck by this.
A huge thanks to everyone to replied and offered their advice, support, and sympathy. You folks are wonderful, and I hope you all progress far in your endeavors.
Guess I've got to start packing my bags for this Fall!
| |
| Wednesday, August 9, 2006 |
| ... | |
Posted - 8/9/2006 8:04:07 PM | Guess what arrived in my inbox today?
Quote:
The Admissions Committee for the Faculty of Mathematics has received and reviewed your final secondary school grades.
The conditional Offer of Admission to the Honours Computer Science Coop program at the University of Waterloo, you received earlier, included conditions that have not been met. Specifically, you have not submitted a grade for University-level Grade 12 Geometry and Discrete Mathematics that meets the minimum required grade of 75%.This is a required course for the program you have been admitted to at the University of Waterloo. Please let me know if you have improved this course in summer school. If you have new final grades available for this course or any other course, please fax this to my attention at 519-746-2882.
Please reply by noon on Friday August 11 so that your admission to the University of Waterloo can be finalized. Your eligibility to begin studies at UW in the Fall 2006 term depends on your response. |
In a nutshell, it looks like Waterloo is revoking my admission because I got a 71% in Geometry/Discrete instead of a 75%. And my academic future may have just been crushed. 5 months of planning for this Fall borked. Not to mention the years of anticipation.
My feelings are beyond words. This journal may not be the proper place, but I needed to vent it out. I'm going to call them tomorrow and see if I can arrange something -- anything -- to still somehow get in. If I don't, then.. gads. I honestly don't know what I'm going to do.
| |
| Untitled | |
Posted - 8/6/2006 10:49:00 PM | Video Card Woes
Well, I think I may have solved the issues that I've been having with my 'defective' video card. Turns out it needs a 350W power supply in its host computer. Oops. Mine is only.. 185W. The tech support guy says running it at that wattage could damage my computer. Eeek.
So I flew over to tigerdirect.ca and picked a relatively cheap (came to $50CAN with shipping/etc) power supply that is now en route to Chèz HopeDagger (as of tomorrow). This should mean that things will ideally work properly after I get it installed, and maybe even some performance uppage. Splendifirous.
Legac---er..
No major Legacy progress at the moment. I did implement entity-locking on the Camera class, so that cameras can now focus on an entity -- usually the player. Also the beginnings of a customizable key system are in the works; should be finished up sometime tomorrow.
I've been playing a reasonable amount of a PC game called Restricted Area. The title is quite lame, but it plays sort of like a cyberpunk Diablo 2 sort of game. It's pretty fun, the graphics are absolutely lovely, and it's been giving me tons of inspiration and good ideas for Legacy. So I'll toss some of those in instead of Legacy screenshots. :P
 
Legacy certainly won't look as amazingly sleek at Restricted Area, but it definitely has a cooler name, and will surely have groovier gameplay. Stay tuned!
| |
| (No applicable title) | |
Posted - 8/4/2006 11:40:15 PM | Keep the Progress Alive!
More movement forward made today. Not massive strides, but taking one step at a time on a daily basis definitely adds up quickly. Being used to RAD development with languages like Delphi and C#, C++ development feels much slower, but simultaneously has a more gratifying feeling associated with it. Weird. I'll have to get used to it.
Collisions
The basic collision system is in, supporting two levels of precision. The first checks the Manhattan distance between the sprites, skipping any further levels if the check yields a distance greater than the combined sizes of the sprites. The next level is a bounding box check, which is currently as deep/precise as it goes. I intend to add pixel-based detection later on if it's needed, but it may not be needed.
Right now the detection-checking algorithm is VERY inefficient. It simply checks each sprite against all others, so for 250 sprites that's C(250,2), which is something like 31,000 collision checks. Eee! Someone -- sooner rather than later -- I'll develop a sector/segment system that will allow sprites to only check for collisions against other potentially relevant sprites, instead of the whole batch.
Sprite Types (or Templates)
I've always wanted a nice flexible system for all of the various entities, sprites, and actors in my games. I loathe all of the hardcoding I've had to do for Skirmish Online when defining the various types of sprites (Players, Bullets, Particles, etc). Now I scribble up a text file like so:
[Mr. Rogers]
Image=Template
FrameWidth=32
FrameHeight=32
Rows=4
Columns=8
Type=PLAYER
Bam. This INI-èsque format lets me define fields relatively on-the-go, so I can throw in cool stuff like particle types for the particle engine, with fields like R/G/B, alpha, blend-mode, velocity, and other goodies. All without recompiling!
(Oh, and I threw in an FPS counter for fun. Don't mind the unoptimized framerate!)
| |
| Do you have me on your RSS feed? | |
Posted - 8/3/2006 11:38:16 PM | Month of Progress Shattered?
Looks like my plan to post daily about my development progress has been dissolved already, doh. Last night the power went out here for most of the night. Then when it finally returned, my Radeon 9600 PRO died. Yes, died. Arg. That meant no journal entry last night. Forgive me.
So now I put in my GeForce 6600 GT OC card, which is actually 'better' than the previous, but is quasi-defective. It likes to sometimes (~40%) freeze/hang if I run a Direct3D or OpenGL app. Today it's been pretty good, so I've been able to get a fair bit done on my project, which happens to be using OpenGL. I've sent an email to their tech support (BFG Tech) to inquire about this issue, so hopefully it won't crap out on me anytime soon. The last thing I need right before university is my computer to break, hehe.
Captain's Log..
One of the things I've always really wanted for my game projects is a (semi-)comprehensive logging system, to help catch bugs, to look spiffy, and to help me identify the logical flow of processes in the game. Writing logger classes seem to be all the craze these days (plug Samsonite), and I suppose I'm no exception.
Currently the logger can write any combination of 3 locations: to disk (via an HTML file), to memory (via a stringstream for future in-game representation), or just simple output to the console window. Here's what the first two look like:
I personally really like idea of using HTML for the log file's format -- which I think I stole from Programmer16 -- since it allows one to make certain parts easily identifiable, like DEBUG data from ERROR data, and the ilk. Hopefully sometime soon I'll get the date/time prepending these log messages so I can determine when these glorious events have occurred.
Sprites 'n Tiles
The last few days have been focused around getting the foundations of the game done. Visually speaking, those key components are the map system (tile-based) and the sprite system. Although relatively simple in concept, these took a while to implement, since: a) I'm not a masterful C++'er, so I'm a little slow, and b) I wanted to focus on a flexible design that would NOT involve me needing to refactor/revamp either system in the future. Revamping is just plain not fun. Ask anyone (sane).
Draffurd sent me a few tiles to be used in this initial cave-èsque map theme, so I plopped them in, as well as his template character which vaguely resembles Mr. Rogers. Coincidence? I think not.
(Each sprite is of a random frame from the 8x4 frame spritesheet he is composed of (=32 frames!))
It's a shame these guys have to be seen in such a tableau manner, but the animation is wonderful. Draffurd put a lot of hard work into making this red-sweater-wearing menace look/feel very smooth. I particularly like the way he has a Zelda-like resemblence, but at the same time has a unique feel. Very pleased with the turn-out.
Thanks for reading, everyone. Naturally initial tests aren't that visually stimulating, but like my previous projects, it'll get much nicer once more graphical goodies start to make their way in.
| |
| Month of Progress | |
Posted - 8/1/2006 9:55:36 PM | The Goal
Hello, folks. July has been a month of emptiness, as far as game development goes. I've been occupied with moving to my house, finalizing details from the previous contest, and organizing my move to University this Fall. Not to mention a bit of a programming slump that I'm now passed.
The goal is to make August my Month of Progress(tm). With a new medium-sized project starting up over here, I think it's a great opportunity to get some coding done and push forward. The aim is to make a journal entry daily, if possible. If that day simply barred me from getting any work done, naturally I won't bother posting. Hopefully this voluntary obligation will help badger me into getting work done on a daily basis. Wish me luck!
Plug
If you want to see coolness, read Sir Sapo's Journal. Seriously. He's been making more progress -- shiny progress, too! -- lately than I was pumping out at the peak of Skirmish Online's development. I'm extremely impressed with his work, motivation, and dedication. Kudos, Sapo!
The Next Project
My next project -- yes, Skirmish retains its 'frozen' status! -- will be a healthy blending of the genres. To the untrained eye, it might be considered something like "Zelda + Diablo + DooM", but there will be more under the surface than just that. The game will take on a 3/4ths 2D perspective with a 'Zelda-like' feel to the character sprites and combat style (realtime battle; assigning an item for each action key), while taking the random level generation methods of Diablo, as well as its simple-but-effective inventory system, and the dark atmosphere and cannon-fodder-foes elements of DooM. That's a pretty rough synopsis, but hopefully it'll draw a rather nice picture in your head. More updates (hopefully) on a daily basis.
The Challenge
The other day I was going through my Completed Projects folder, and happened to play Gundown for a while. Previously I had only been able to get to Level 34 at the peak of my 'skill', but I managed to top it -- by far! -- and reach Level 51. Not a big accomplishment in the eyes of the passerby, but I thought that was mighty cool. Ego++ and all of that. And as such, I thought it might be neat if all of my journal readers would play a quick game and see how far they can get; posting a screenshot if it's anything over 30. Of course you don't have to, but it'd be neat for me to see how far the rest of you can get. :P
(Maybe a sequel will be brewing in the coming months? )
| |
"Good night, Monster Land."
"Good night, brave warrior."
|
| S | M | T | W | T | F | S | | | | 2 | | | 5 | | 7 | 8 | | | 11 | 12 | | | | | | 18 | 19 | 20 | | 22 | 23 | 24 | | 26 | | 28 | 29 | | 31 | | |
OPTIONS
Track this Journal
ARCHIVES
August, 2009
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
December, 2008
November, 2008
October, 2008
September, 2008
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
October, 2005
September, 2005
July, 2005
June, 2005
|
