Tuesday, December 21, 2010

updates

Well my semester is finally over, and my hair is just starting to de-gray itself. This was one crazy semester, and I'm not kidding when I say that I am still having nightmares about due dates and things.

But now it is all over and I have all sorts of time to muck about with my code! Kind of.

First I need to detox for a few days. Nothing but a steady diet of my favorite games and sleep. I've been playing coop Dawn of War II with my bro, coop Halo: Reach with a buddy of mine, the incredibly simple and charming Killing Floor (one of my favorite mindless shooters of all time), and a little Battle For Middle Earth (1) for nostalgia.

I got the urge to write a bit after playing the latter again. Battle for Middle Earth (BFME) is such a bold and unique RTS, I am amazed it came out of EA (by the team that used to be Westwood). There are so many cool design decisions, I don't know where to start.

I guess I'll start with this: To be fair, the game is flawed. The balance is pretty wonky, with archers, for some reason, being the end-all-be-all unit of warfare perfection. It is jarring, even maddening, to see your incredibly expensive yet deliciously menacing and massive Mummakil get put down in 5 seconds flat by two units of upgraded archers. Eww.

But I don't want to talk about that. I want to praise this game, after all. So I'll talk about how this game is so different from any RTS you've played. Mainly, this game is a siege centric RTS, like Stronghold but without any of the medieval simulation bits and instead focusing exclusively on fighting. The siege theme really makes sense when you think of it. I mean, think of the coolest, most video game worthy moments from the films. What were they? The sieges of Helms Deep and Minas Tirith, naturally. And the game does a pretty decent job of bring those epic film quality sieges to the player.

The game also does something else that I've never seen, before or since, in an RTS. It gave the AI natural emotions and behaviors. This impacts the game on both a cosmetic and gameplay level.

Cosmetically, these AI behaviors mean that your little army dudes will never just be standing around looking stiff and silly like in any other RTS. For example, if you leave your orks alone for a while they will form a ring and two of them will start sparring at the center of it. Your trolls will push and shove eachother around. If your men see a regular sized enemy from across the battlefield they will start clanging their weapons together and cheering, psyching up for the coming battle. It does a lot to make the game feel more alive.

On the gameplay side of things, units having realistic behavior can have quite an impact. Put your soldiers up against a rampaging troll and they will act afraid, and won't fight very well. Your men always do end up following your orders, but if your order is a clear suicide march then they will be a little sluggish in following your command. Set an ent on fire and he will freak out and run around to find water to put himself out in. Set a Mummakil on fire and he will go on a rampage, trying to shake off the flaming archer tent on his back.

All in all, the game is really something unique, and the design would have been worth exploring. Unfortunately, they decided that the design wasn't worth exploring at all when they made the sequel. In BFME II gone are the sieges, the behavioral AI, the everything that made BFME I fun except for the Lord of the Rings theme. BFME only got decent but not great reviews, maybe that is what prompted the developers to make BFME II a more conventional RTS in every way. Whatever the reason, if you are looking to buy the better game of the series then buy the first.

By the bye, on the code side of things: I will have an update on my Dating Sim very soon. I'm also not done with Quake - I just can't quit it.

Friday, November 26, 2010

The Quake News

Quake project: Dead.

Well, here I am. Again.

After getting to a mostly playable state, I found that my game just wasn't all that different or fun. I blame a lack of vision, and too much focus on Quakey details like fucking around with Blender to get models in, fucking around with Worldcraft, and AI wankery. My original plan of having a running-away focused game ala Penumbra got muddied somewhere along the way, and instead I came out with a very run-of-the-mill shooter with baddies that can climb walls and stuff. Correction, an extremely fugly run-of-the-mill shooter with baddies that can climb walls and stuff.

When it became clear that I really needed to refocus on a new gameplay point, and shift the game into a more doable direction artistically, once again Blender stood in my way and kicked me in the balls.

I can't express my hate for Blender quite enough. I explored changing model formats from Quake's native and throughly awful and archaic mdls to something more like Half-Life's skeletal animation driven mdls. This requires exporting into an .smd format from Blender. My pain started here.

After much searching I found a user-made smd exporter for Blender. My only problem? It didn't work for my version of Blender. "Easy solution!" I thought, "I'll just upgrade to the newer, and therefore better version of Blender!"... WRONG! The newest version of Blender completely changes the bloody interface into something new and remarkably unintuitive, rendering most of what I learned about getting around old Blender's remarkably unintuitive interface completely moot. Still, I fought on.

I then struggled with the fan made smd exporter, which struggled back at me even more. Still, I fought through the pain for several hours and exported a nice little test model.

The next part? Getting the thing into the game. Now, the format is fully supported, keep that in mind. Anywho, hours of googling and looking for a way to get my new format into the game reveal... Nothing. It appears that nobody has any light to shed on the matter. It has been done before, so I know that it is at least theoretically possible, but I sure as hell can't figure it out. Not that I gave all that much effort into trying. The Blender-to-dpm pipeline sucks shit, I have to run my model through two different exporters to get my dpm, so by then I have no idea where the problem lies.

Bottom line, I'm done. I'm pretty sure that if I bashed my head against the wall a bit more I really could figure it out and get it in game, but I'm just not up for it anymore. I'm tuckered out, and when the fun little project that I could add little bits onto here and there turned into a monster of a project that required serious effort to tackle, I knew it was time to call it quits.

I've learned a lot, but now it is about time to shoot this baby in the crib.

*bang*

Friday, November 12, 2010

Tuesday, November 2, 2010

SDL Game Ahoy!

It is time to talk about the new SDL game I've been working on it. I'll break it down with just the facts, Dragnet style.

Name: Charmquest.
Genre: Fantasy RPG Dating Sim
Crimes: Being insufferably cute and nerdy as hell.

That's right, folks! My next SDL game is going to be of the dating sim variety. And this isn't just going to be an engine for dating sims, like Verily was for top down RPGs. No, this is going to be a fully loaded, fully playable game.

Its (planned) features are going to be including but not necessarily limited to:
*: Many different locations!
*: Three different gals to hit on and harass, each with a different personality!
*: Three different difficulty levels!
*: RPG style stats and character progression!
*: A combat system (type of which is undetermined, but likely turn based and Japanese)!
*: Items!
*: Witty dialogue!
*: NPCS with schedules!

I've chosen to do a dating sim because I wanted to make something that I figured wouldn't take too long to develope, and frankly/somewhat shamefully, I just plain enjoy the genre.

For those of you who aren't still virgins and have never played a dating sim or know how they really work, it goes like this:

Basically, you have a character with a couple of different stats that correspond to specific things. Intelligence governs how much money you can make on a job, strength determines your hitpoints and maybe your damage output, etc...

Every in-game day you have a set number of turns to do stuff (work for money, train, whatever), and you only have so many days before it is game over. To win you have to woo one of the ladies enough before you run out of days.

How does the wooing work? There are a number of ways of going about doing this, but the core idea is more or less the same. That is, by talking to the chicks you learn a little something about their personality (likes/dislikes, that sort of stuff), and later on down the line you will have to make decisions using a little deductive reasoning based on what you learned from talking to them, and your success during these little puzzles will determine how much more they like you.

So basically, the game is a turn based RPG with some puzzle elements thrown in when it comes to engaging with the gals and managing your time.

More fun than it sounds, I promise.

So anyways, I'm really coming along with the game.

Some technical talk that may or may not bore you:

I've broken the game down into different Zones. Each Zone has a sort of inventory of things I'm calling Entities. Entities are things that get drawn into the scene and can be anything from an item, to an NPC, to a sign that says "click here to go to the kitchen". The zones themselves are loaded into a Zone Manager that figures out which Zone I want to be in and loads it dynamically. I feel this solution is efficient and elegant, and I'm quite proud.

Anyway, the assets for this game are going to be a real bitch. A dating sim isn't necessarily art asset heavy (as almost everything is just a still picture), but one requirement is that you pretty much have to have hot chicks to hit on. I can't draw anything resembling any kind of chick, let alone a hot chick. I don't exactly have a solution for this, but I'm thinking that maybe I can get a bunch of anime hot chick reference images, and sort of trace out my own leggy-ladies from those. Maybe. I'll cross that bridge when I come to it, though.

As for Quake Thursday: It is on this week for sure. Blame last week on Fable 3. Also, expect updates for this SDL game every Tuesday from now on.

Wednesday, October 27, 2010

UPDATE: Changes are a-comin'.

Yeah, yeah. It has been awhile and all that. I won't bother throwing any excuses your way, I've mostly just been lazy. I've also been incredibly busy with school, sick, and working on a new SDL game that I haven't told you about.

So I guess I will bother throwing excuses your way. Whatevs.

Work on the Quake game has been nonexistant. There is a reason for this: I'm so bored with it! One of the little truths you discovier about game development is that the hardest part (and there are plenty of hard parts) is the very end, when all major development is done.

All of the major coding is done, the asset work is all done, and the map is finished. What remains is testing and tweaking, and MAN is it a drag. This last stage of development consists of tweaking some little value in the code or piece of the map, and then testing it out. Rinse and repeat a billion times. The only challenge is to your patience, and I guess lately I've been losing that battle.

That said, I really do want to get this game out and soon. With that in mind, I'm instituting something called "Quake Thursdays" around here.

Yes, every Thursday is now "Quake Thursday". I promise to work on the Quake game for at least a couple hours, at the end of which I'll post a bunch of screenshots here on the blog to show you what I'm doing. Hopefully this will see the game to a fairly quick release.

In other news, as I stated earlier I have started work on a new SDL game. I'll give more details soon, but for now I can say that it will be a little game that should be quick and easy to produce (coding wise, the assets are scaring me a bit), and will hopefully pretty fun. I'm toying with the idea of actually selling this one, so I'm pretty excited about it.

Hmm, what else? A gaming news site called Ultima Aiera has made its way into my list of daily must-visit sites. Specifically, it has news about the Ultima series of games and about the creators who had a hand in bringing the games to life.

'How much news could there be about a series that has been dead for a decade?', I hear you ask. Well as it turns out, a pretty good amount of news can be generated about a series that has been dead for a decade. Dick. There are tons of remakes and updates to the series to be reported on, as well as hopeful (though ultimately futile) rumors of the series being continued or restarted again. But more important and interesting are the articles that showcase the old design documents and artwork from the venerable games. It makes for some good game design reading, if you are into that sort of thing.

Other cool things: In Por Ylem 2 has gone into beta, marking yet another experiment with unrestricted PVP in an MMO environment. These experiments always prove interesting. You get to see just how much crap regular players, who make up the bulk of the playerbase, can take from unabashed a-hole players, who exist for no other reason than to ruin the game experience of those regular players, before the regular players give up and leave. Once the normal players leave, the a-holes, having nobody else to torment other than eachother, themselves leave and the game collapses.

We've seen this countless times (the original UO, the original In Por Ylem, Shadowbane, Darkfall) before. Yet there is always some designer who wants to try the experiment again, I guess thinking that this time it will be different. Who can blame him? On paper the concept of near-completely unrestricted PVP is brilliant. Sadly, it just never works, mostly because there are too many players who will take advantage of the loose ruleset and use it to ruin the game for the other players.

Anywho, I don't want to get into that. So many other, better and more experienced than me, designers have gone into it before.

All I want to say is that Azaroth is taking another crack at In Por Ylem. He has brought some interesting design decisions with him, and hopefully some lessons learned from the original In Por Ylem. If anybody can get open pvp right, it's Azaroth with IPY2.

Oh, and I beat Ultima 8: Pagan. I've been playing this thing for over 15 years! Everybody will tell you about much much crap Ultima 8 was, and it does have its annoyances and plot holes. Still, it was always be my favorite (and first) Ultima, and one of the games that originally made me want to make games myself. Cheers, Pagan.

Tuesday, September 28, 2010

Warning: Game Design Philosphy Screed Imminent!

I'm getting close to finishing my Quake mod (the alpha version, anyway), and I'm really excited about returning to formal C++ game development. I've been spending a lot of time thinking about what my first new game is going to be, and about what statements I want to make about game design in general through my games. Well, since I'm not here to talk about what my next game is going to be that means I must be about to unload some heavy game design philosophy crap on you. I apologize in advance.

To understand what I have to say about the state of game design, first I have to walk you through a hypothetical game experiment.

Let's say that you have a game. It is a 2D Metroidvania sidescroller: You attack baddies along the way, do some platforming, and when you reach the right hand side of the screen you go on to the next level. Next, let's say that at the very beginning of each level there is a switch on the wall that you have to hit by pressing the 'up' button. There is no obstacle to the switch, and it is in the same spot in every level just two steps forward from where you spawn, but you can't beat a level without first having activated the switch. Thus, at the start of every level the first thing you have to do is ALWAYS to take two steps forward and press 'up' to flick the switch.

Ah hah! I hear you all cry out that this is bad game design! And it is! Why? Well, the switch doesn't add anything to the game, it is just something you do at the start of every single level. You could cut it right out of the game without losing anything. The lesson here is clear: Any time a game has you doing something robotically just for the sake of doing it, it is bad game design. It is essentially putting a non-game obstacle in your way that you have to get past in order to actually play the game portion of the game.

Now let's take a look at a popular playing guide to the critically and commercially uber-successful Blizzard game Starcraft 2 (this is from a Terran build order):

(1)Start out with 9 SCVs, then build a (2)Supply Depot. (3)Make two more SCVs and (4) another Supply Depot when the resources become available. After the second Supply Depot is done, have the (5)SCV start building a Barracks. (6)Build the Barracks in such a way that it helps block the entrance ramp into your base. Once another (7) SCV gets built, have them build another (8) Supply Depot to further block your ramp. After your 14th SCV (9) you should start work on your (10)Refinery and save to upgrade your base to an Orbital Command Center (11).

*(Thanks to http://www.articlesbase.com/computer-games-articles/starcraft-2-terran-build-order-the-best-terran-build-orders-to-dominate-your-enemies-with-ease-3071016.html for the build order example)*


As you can see, without even counting every single SCV build you have at least 11 different things to do. You do these things at the very start of every single level you play, without variation, and that is only in the first third or so of the guide! In terms of our hypothetical sidescroller, that is 11 different switches you have to turn on before you can start playing the game. So why is it so obviously bad in our nonexistant sidescroller situation, but totally accepted when Blizzard does it in their AAA rts?

Partly because of shitty game reviewers who are too blinded by hype trains to even begin to think objectively about the games they are critiquing, sure, but I think there is more to it. I think that something that happens far too often in modern game design is a misunderstanding of what makes a game genre.

16 years ago Warcraft: Orcs & Humans came out and defined the rts genre. Sure, it was mostly a ripoff of Dune, but Warcraft really refined the core mechanics of Dune and made a hugely successful game out of them. From then on if any game designer thought rts, he was really thinking Warcraft. Nearly every rts after Warcraft took Warcraft as a base and went from there.

The base was something like "Base building > Peasant resource management > Army Building", and a new game would come and do something like "Base building > Peasant resource management > Army Building > Hero units", or "Base building > Peasant resource management > Army Building > Rock Paper Scissors combat system". Everybody just takes it for granted that rts means "Base building > Peasant resource management > Army Building". But I demonstrated earlier that this design structure breeds build orders, which is awful game design.

Furthermore, this design de-emphasizes the combat, because there is an inherent focus on the rapid continual building of your base/pumping out of units. You almost never watch a fight in these games because you are too busy jamming the hotkeys on your keyboard to keep base expansion and unit production going. Instead you just grab a mess of your units and lob them at your enemy's general direction. This is a staple of the rts genre because of Warcraft, but why?

Think about it: The reason the rts genre seemed appealing to us in the first place was because we wanted to be generals leading big armies to crushing, violent victories on our screen. We don't play because we want to facilitate a bunch of peasants and organize the most efficient building plans while our troops do something cool and fun off screen.

Now, I don't want to make an rts game, that isn't my point. The genre is largely dead to me now, and it doesn't excite any passion or imagination in me at all. I just bring up that example because what I want to do is to really examine genres in my games. I want to boil genres down to their TRUE essential attributes and then build from there. Only when a genre is deconstructed to its primal ingredients can the genre then be moved forward in a meaningful way.

That is why I want to take a sort of minimalist approach to my games. I want to take the games back to the late 1980's, the golden age of PC gaming, and then go from there.

DISCLAIMER: This doesn't mean that every single one of my games is going to be a minimalist and completely original idea. As a matter of fact, my next SDL game is likely going to be extremely conventional. Besides, boiling games down to their essentials is tough work! Still, this is what I want to do, and it definitely will be a theme of mine going into the future when I get more comfortable taking on somewhat ambitious projects.

Here is a *link* to the article that really got me fired up enough to write this today. Once again it is Ultima that gets me feeling motivated about game design.

Saturday, September 25, 2010

Stay on target...

Content is locked in and ready to move.

Time for some testing, where I can tweak the code (especially the AI stuff) to where it does everything I want it to. I also have to figure out and finalize entity placement in the level, which will also be sorted out during the test runs.

This shouldn't be heavy lifting, but you know how that goes. At any rate, a release shouldn't be very far off now. A week or two tops. I'll do a little advertising on the QuakeDB group before I release so that somebody - anybody - gives a shit and plays it a bit. Screenshots will come pouring in very soon, I promise.

Friday, September 17, 2010

Checking in.

I'm looking to be 100% on all content by the end of the weekend. From there it is just a matter of testing and finalizing. The home stretch is finally here. Screens soon.

I'm still looking for a way to ditch Blender 3D, and really the entire Quake .mdl format. The thing about Quake .mdl models is that they don't use any bone information, they purely save vertex coordinates from frame to frame. This is... Unfortunate. It inherently means wonky animation, and eliminates the possibility for decent hitbox support and sockets on the model (for muzzle flashes, storing weapons, and other cool shit like that).

Worse, getting your .mdl animations into the game is a painstaking process. As I said, the .mdl saves vertex coordinate information, which means to get it in game I have to write a script to tell the game what animation is going on frame by effing frame. For example, when I want to code my death animation I have to look at the model itself and find out what frame the death animation I want starts at, say 46. From there I tell the game that frame 46 is death animation A's frame 1. Then I tell it that frame 47 is death animation A's frame 2. This goes on until the animation is finished. What. A. Nightmare. It gets really confusing when you are 120 frames in and have to remember that you are really on frame 13 of shoot animation c. And of course Blender is kicking you in the ass the whole time.

I miss the good old days of Half-Life's .mdl format modeling. Half-Life .mdls were a compilation of vertex info, texture info, and bone info. This made animating and getting a model in game an absolute dream. Any animations you did were self contained pieces of information, meaning you didn't have to get down and dirty and worry about frame numbers. You just made an animation called "shoot", and told the game to do "shoot" at the appropriate time and voila. And the tool of choice was Milkshape 3D. Ahh, Milkshape, how I loved you and miss you. Unlike Blender, Milkshape is incredibly easy to use, never crashes, and has beautiful pipelines to all of the major low poly model formats that used to be relevant at the time.

I think a good analogy for what Blender is to Milkshape is to think about what GIMP is to Paint.Net. GIMP tries to do all of the things that the big expensive retail product Photoshop does while Paint.Net just tries to keep the usability of Paint while adding some professional type features. GIMP ends up being an unintuitive, barely functional mess while trying to do all those fancy things. Meanwhile, Paint.Net does everything a shitty programmer-artist like me needs, and it does it painlessly and easily. In the same way, Blender 3D tries to do everything that Maya, 3D Studio Max, and Softimage XSI do, but does it all shitty while maintaining an obtuse user interface. Milkshape 3D just tries to be a super usable low poly modeling program for games like Quake and Half-Life, and it absolutely succeeds.

So, since Blender 3D has been making me weep so much in the last couple months, I've recently really been trying to find a solution in a new model format, preferably Half-Life's .mdls. So far the best I've been able to come up with it the Darkplaces engine's .DPM format. It uses .smds to separate vertex and bone information, like Half-Life, but is specific to Darkplaces. The only real problem is that few people use it, and even fewer know exactly how to use it. Still, I'm going to experiment with it in the future and see if it is a possible solution for me.

At any rate, for the time being I am going to grit my teeth and fight through the unbearable darkness that is Blender 3D to push out the last model or two I need. I'm too close to being ready now. Perhaps in the future I'll use the .DPM model format which will enable me to bring back my toon shading, as well as generally make my life much easier on the 3D modeling side of things.

Tuesday, September 7, 2010

quickie update...

I'm in the process of touching up/redoing a lot of the modeling bits. For the time being I'm going to drop the fake toon shading. In the vertex grouping process Blender was being a real bastard about all the flipped faces, so I have decided to sacrifice the shading for more control over my animations. Oh well, such is life when you have to work with shitty open source tools. The toon shading will have to be something that I'll hard code in on the engine side at a later date, in an update.

Speaking of Blender, it continues to be a gigantic thorn in my side. I can't for the life of me find a decent way of rigging a model. Weight painting is SUCH a pain in the ass and is so damn inaccurate. I always end up painting vertices that I didn't intend, or missing some that I did intend. Why can't I just go vertex by vertex and assign them to the bones that I want? I was doing that in Milkshape 3D ten years ago for gosh sakes. But as far as I can tell, my only options for rigging in Blender are weight painting and the easy but wildly inaccurate enveloping. Aarrgh. I'll try googling around/forum diving to help me not hate weight painting.

In the mean time, here is a revised list of things that are going to be in the first release:
  • One semi-long level.
  • A pistol, smg, and screwdriver for weapons.
  • One baddy type with custom AI that can climb/jump around the environment.
  • A respawning baddy system that keeps the action flowing.
All of that will absolutely be in at release, and most of it is working already. As i said earlier, I am still finalizing some of the models for the weapons, but the coding for them is done already. The map is mostly done, but I may add on to it/change it around once I start really testing this thing.

Things that I'd love to have in the release but may or may not make it in time (they may still make it, but generally I'm not finished with them):
  • Buddy AI.
  • Two other baddy types; a shotty badguy and a pistol baddy.
Obviously, the Buddy AI was a big part of the game that I wanted from the beginning, and to probably not have it ready for the demo is pretty painful. The thing is though, this whole project has taken a lot longer than I ever wanted it, which is my own fault through a deadly combination of trying to do too much, having real life badness crop up in the middle of the summer and halt all development, and sheer laziness on my part. I am at the point now where I really need to just get this thing out of the door in one form or another. Rest assured, this is still my baby and with just a little bit of positive attention toward the demo from the community I will continue development and absolutely get those features in.

Things to think about for a future release:
  • More levels, obviously.
  • A shotty weapon for the player.
  • A stamina system for the running and jumping.
  • Reloading for the weapons.
  • Scripted sequences.
Later days.

Monday, August 2, 2010

That Starcraft 2 post...

Work continues...

For now. But Starcraft 2 has come out, and while I hate Blizzard and all they stand for when it comes to the RTS genre (and game design in general), EVERYBODY and their brother just won't shut up about how epic and great it is. I don't have a lot of will power when it comes to games, and the Starcraft 2 hype train is really doing a number on me. It may only be a matter of time before my shields break and I buy the game. And then hate myself for it two days later.

Thursday, July 29, 2010

Level 1 is in the can!

And it only took ~8 hours!

Everything works more or less how I want it to. Obviously, I don't know how to do a lot of the cool things I had in mind, so I had to tinker/find alternative ways of doing them, duct tape and bailing wire style.

At one point I had to duplicate a significant portion of the map. Worldcraft didn't like it at all and, while the map loads up and plays just fine, a big list of warnings fills the console before hand. I've looked it up and the answer seems to be "yeah, old versions of Worldcraft will do that. F##k you", so whatevs.

I'm going to look for a texture pack to use. Right now I am using Quake's stuff as a placeholder. I was intending to just go with it, but now looking back on the finished product it is just too ugly. Muddy dark browns don't translate well to modern office motifs. I could also stand to find some prefabs. Prefabs, for those who haven't dabbled in this sort of thing before, are self contained little models/textures for use in maps. Think computers, office chairs, desks, cars, that sort of thing.

Also, the scale in Quake is wonky. For the weird and wacky world that Quake is actually set in, this is fine and really barely noticeable. But when I try to bring things into the modern realistic realm everything either looks like it is made for giants, or midgets. I can't really find the sweet spot. Oh well. Better textures should hopefully help.

Wednesday, July 28, 2010

Worldcrafting

I'm starting to really get into a groove with Worldcraft. My maps still look assy, but they are coming along.

I'd really love to add in my own textures at some point. My maps are set in an office/industrial theme, and Quake's default texture set doesn't really lend itself to that. Still, I am going to put off those kind of additions until after I have a basic release, and if people still care.

Slowly but surely this thing is coming together.

Also, I have come up with a name for the game. I am leaning towards calling it "The Mondays", because it is set in an office with tons of cubicles and really sterile fluorescent lighting.

Friday, July 23, 2010

Sometimes...

I wish I had a team. I like the total control that comes with working on my own, but it would be nice if I could delegate all the tasks that I hate/suck at to team members who are more competent than me in those areas. Like mapping.

I found a workaround for my Worldcraft woes. It is ugly, but it works. Still, now that I can actually churn the maps out I am coming to a new realization: I suck at mapping. Fair enough, I knew that going in, but what I didn't know was just how much it is going to impact my game. It is bad enough that the game is going to be full of programmer art, but programmer level design? Yuck.

Oh well. Hopefully I can still hit the ugly but passably fun sweet spot.

expletives

Worldcraft was working just fine. And then it wasn't. Just like that.

A compile a map two seconds later and none of the geometry is lighting up properly. And I can't FUCKING fix it! Literally NOTHING has changed from one compile to the next. The piece of shit throws no errors. All I know is that I can't produce a map with working lights, and it has singlehandedly killed my damn game.

Once again, you'd think a program this stupid old would be documented like a motherfucker, but it isn't. All the googling in the world can't find me an answer. I'm going to try and enlist the help of some current Quake modders and see if they can't set me straight. Maybe there is a better program out there than this piece of shit old version of Worldcraft.

But until then, the game can never get released.

I am unbelievably pissed off right now. I put the mapping off to the end because I hate it and suck so bad at it anyway. But now to have mapping be the thing that I am forced to pay so much attention to and grind all my development to a halt... Infuriating.

Sunday, July 18, 2010

Oops

Did I say this weekend? What I really meant was "when it's done".

Which will probably be either next weekend or the week after that.

Sorry. I thought that maybe being able to plow through my work on the game all week would help me take my mind off of things (family emergency), but instead I just couldn't get motivated to start.

Sunday, July 11, 2010

The Feature List

Key:
  • Items in black indicate something that is already in the game and working acceptably.
  • Items in green indicate something that I've already started working on and is definitely going to be in the game at release.
  • Items in yellow indicate something that I haven't started working on but will hopefully be in the release.
  • Items in red indicate something that I would love to be in the game, but probably won't make it.

Here we go.

Mapping:
  • An intro map, with a tutorial for getting around. Characters get introduced, and the story started off.
  • The level where shat first starts to go down.
  • A middle level where the main button-hunt gameplay most comes into effect.
  • A finale level.
  • Custom cartoony textures for everything.
Modeling:
  • A main type of generic bad guy with an SMG.
  • A pistol, smg, and shotty for the player.
  • Another type of baddy with a shotgun.
  • A pistol baddy.
  • A boss.
  • An AI buddy.
  • Some friendly AI scientists.
Code:
  • AI that is generally enhanced for getting around and not getting stuck on the geometry.
  • A "dynamic" spawn system for pumping in enemies at least somewhat intelligently.
  • Buddy AI.
  • Some non-threatening scientist AI.
  • Some sort of system for allowing scripted dialogue/sequences.

Sounds:
  • My own sounds for the weapons.
  • Sounds for pain, death, jumping, etc... For the player, the baddy, and the AI buddy.
  • Some scripted Left-4-Dead-esq dialogue.
General:
  • Come up with a name for this thing.
I am aiming for a release day of the 17th of July. Testing? I don't need no stinking testing. Now, I realize that I put the custom sounds and textures in red, which means that they probably won't make the release. This means that my initial release will be as a mod and not a standalone game. I really want to see this as a standalone game, but digging out all of the original textures, sounds, and other game content is a load of work, and I'm only going to do it if I think it is worth the pay off. That is why I am going to release as a mod first, and then go standalone on a people-seem-to-give-a-shit-enough-basis. If nobody touches the mod then I won't bother going standalone, it is as simple as that.

What you will need to play the mod: You will need the two .PAK files from the original Quake game. If you don't have Quake you are out of luck. You can always buy the game, I think it is $10 on Steam or you can get it brand new and in a box from Amazon.com for less than $10. It is a classic as hell oldschool shooter and you owe it to yourself to own the thing anyways. I'll put all the relevant information on how to install the mod in a README file when I release the game.

Monday, June 28, 2010

AI woes...

So I'm finding the base AI in Quake to be totally inadequate for my needs. The inadequacy comes from the fact that a major part of the Quake AI, the part where the monster decides where exactly on the map he wants to move (IE: his goal), is HARD CODED into the engine. That means I can't do any QC magic to change it. Why they decided to do this when the rest of the game relies so heavily on the QC scripts is beyond me.

This means that I have to gut the AI code and put in my own. My only problem? I don't know jack about AI! Sure, I've done the same basic tutorials on how to get an entity to intelligently (and efficiently) move towards a goal using a couple of different methods as everybody else... But now doing it in practice, as well as in 3D space... This is scary!

Luckily, the Quake modding community is there to rescue me. There is some super old code for simple, beautiful bots hanging around. The TutorBot, made by a (former?) community member named Coffee (I'd be hyperlinking the shit out of this, but it is all so old that Coffee's Quake site doesn't exist anymore except in Internet archives and the memories of appreciative Quake modders). It is exactly what I need as a nice base reference from which to build my new AI on top of.

What do I need my AI to do? Well, the base AI can find an enemy (usually the player) and intelligently(ish) move to it and attack it. This means pathing out a bunch of waypoints based on the level geometry so that the monster moves around walls, avoids falling off of cliffs, ect... My monsters, however, will not path around walls. I want my monsters to climb the damn walls.

Imagine having a Quake level in an office full of cubicles, desks, and chairs. Normally, the player would be bounding all over the environment while the monsters would have to awkwardly weave through the obstacles in a maze like fashion. I want my monsters to be able to climb just as well as the player can jump. Maybe even better.

We'll see.

Thursday, June 24, 2010

Baddy!


*cough*

Get ready to shoot lots of these. For reference, that is a terrorist looking guy and not an S&M enthusiast in a gimp suit. Although now that I am thinking of it, that would make a far cooler bad guy.

Wednesday, June 23, 2010

Quicky

So I know what you are all saying. "Handshakes, you devilishly handsome, cunning, and all around sexy man, where is your progress on those bad guy models?"

Well, if I were to be completely honest with you, and I rarely am, I would have to admit that things like Ultima Online and internet porn have been eating into my time lately. But I would also add that this content stuff isn't a cake walk for me, and I'm trying my best to achieve an acceptable level of programmer-art suckery that I wouldn't mind showing off in the end product.

I've been spending a tremendous amount of time studying Blender3D, pouring through huge and oddly written English-as-second-language tutorials, and watching hours of low poly character modeling while taking notes. I want to get this right.

There is also a bit of extra pride on the line for me. I got my start in amateur game development on the 3D modeling side of things, doing low poly weapons and the occasional character in Milkshape 3D for various Half-Life mods that would never see the light of day. - In point of fact, I was only involved in two mods that ever saw the light of release day. One, I did some quicky and ugly-as-sin animations for some guy's proof-of-concept Counter-Strike zombie mod. For the other mod I just rigged a couple models as a favor to the mod leader, a coding child prodigy known as General Dodo, who got me started in 3D modeling for Half-Life working on his Predator themed HL mod which was a first mod for both of us. That mod (not Predator, but the one that saw release), known as General Dodo Coop was, despite the name, pretty special. It never really caught on, and it was accused of having stolen ideas from Sven Coop like the advanced physics and, well, the coop. But the fact is that, while it was a lot like Sven Coop, it was actually better in a number of ways, like the physics being better implemented (which was pretty special for the time), having more complex AI, and having drivable vehicles including airplanes (which made for an endlessly good time). - But, I digress. 3D modeling is dear to my heart, even if the skills have severely atrophied, and I want to make something I can be kind of proud of.

That said, hopefully I will have something to show pretty soon. Until then, more studying.

Thursday, June 17, 2010

Quicky Update!

Just a little update on my progress so far. Some shots of my patented fake cell-shading technique.
My Pistol
The SMG

I'm really just trying to get all the content nailed down at this point. Why? Because I suck at doing content (which is made obvious from the above screenshots), and I want to get that crap out of the way first so that I don't have to worry about it. The biggest monster I am going to have to tackle is when I try to get my, well, monsters into the game. Quake's animation system is archaic with a capital thissucks. It also doesn't help that Blender 3D is kicking me in the shins every step of the way.

Next thing to tackle: Getting baddies into the game.
Difficulty level: Oh crap!
In over my headedness: Drowning.

Stay tuned!


Thanks to the invaluable Tara for getting me to get off my ass and make this update.

EDIT: It might be hard to tell in the screens, but they weapons are indeed toon shaded with an outline around them. I made the screens quicky-like in the intro level of Quake, which is really dark and that unfortunately makes it hard to see the toonyness of the guns. Rest assured, my levels will be much more simply colored and brightly lit (and assily made).

Sunday, May 30, 2010

Getting my dark on

Did I just abandon a project before it began? The quick answer: Sorta.

See, since my home machine's hard drive got virus'd last year (and I've had to use this less than official version of Windows XP), my school laptop became my only Visual Studio coding machine. Well, I had to turn in my school laptop at the end of the semester and now I am without a machine with VS. Fair enough, I'm all of an hour's worth of work away from getting access to the MSDN and getting all the Windows 7 and Visual Studio I want for free - but the thought of going through a format and all that junk... Yuck.

For a while there I had been hard at work scoping out an engine to do a quick side project on. Not coding anything was making me crazy, I had to find something to do.

And then my old copy of Quake fell out of my dresser Wednesday of last week. Quake, I think to myself, is old enough that it must be documented like crazy, and be chalk full of sweet tools just ready for me to pick up and use. Genius!

It turns out I was mostly right.

Modifying the game logic in Quake is all about messing around with John Carmack's QuakeC script, a beautiful little C like language that is clean and easy to dive right into. I can modify a script, compile it, and be in game and testing it all in about 30 seconds time. As for the guts of the engine, I can let someone else do all the heavy lifting. The Darkplaces engine is a gussied up Quake engine with plenty of modern graphical additions like reflections, shadowing, and bump mapping.

Documentation? We have documentation. The Quake dev community is still alive and well after all this time. Inside3D is my main reference site so far.

But the best part about using the open source Quake-based Darkplaces engine is that it allows me to release the game not as a mod but as a stand alone game!

That sounds all well and good, but the downside to going stand alone is, of course, that I have to generate 100% of my own content to use with the thing. This is a pretty good knee cap to my progress, but I went on to see just how viable it would all be.

I already know that I'm solid on the coding/scripting front. What about mapping? Well, my logic that an old game must have some solid tools turned out to be right in this instance. A slightly old and modified version of Valve's ancient-but-effective Worldcraft editor (now Hammer) is an elegant solution. After downloading the thing it only took a bit of fiddling to get it in working order and I was compiling my own test map in five minutes. Perfect. And the package included a .wad packager, so I can make my own texture packs (which I'm going to have to do).

How about the models? Ah hah! My logic worked for mapping, so surely it would be pie to export MDL files from any modeling program I want, right? WRONG! The pipelines for modeling for Quake are kaaaarazy. I knew I was in trouble when I came across a tutorial that wanted me to export into Quake3's MD3 format, then run some converter to turn it into MDL, and then hope and pray it comes out the other side looking anything like the model I started with. Luckily, after many hours of searching, I came across a decent (if still buggy as hell) straight MDL exporter for Blender3d. It messes up the textures like crazy, but my textures are going to suck anyway, so who am I to complain?

So now I've got my own models into the game. That leaves sound, and I'm pretty sure I can find some public domain .wavs to use.

It has been an odd experience for me. When I normally enter this feeling out period of the project I very quickly find out the ceiling of my capabilities and pair back what I want to do as necessary. But this time, whenever I sent a feeler out to check out my limitations I actually found the ceiling to be much higher than what I need. For once it would seem that my own creativity will be my limit. Hooray for Quake and Id.

Now, before I get too excited, it is worth realizing that I still have a crap load of content to create, and I am nothing even close to resembling an artist. To combat this I am picking a simple boxy art style and, taking a cue from major crappy developers everywhere, adding in toon shading to cover up my shitty programmer art.

Anywho, more details on the actual game to come soon, as well as screens (which I can already show because the game is coming along so fast and furious).

Tuesday, March 23, 2010

The wheels in my head have been turning...

A dangerous pastime, I know.

First of all, go play this: Digital: A Love Story from some amateur writer Christine Love. I've never heard of her or her stuff, but I saw Digital up on Fileplanet and I decided to give it a whirl.

Game changing.

Basically, D:ALS is just a short story. The gameplay consists of you putting together little clues in order to further progress the story. It is simple. It is kinda fun. But most importantly, it is damn effective at doing what it is trying to do.

As I finished my play through of the game it suddenly dawned on me: I want to make a game like this! Not that I want to make a game about posting to a BBS on an Amiga, but I want to make a game that is simple, fairly easy to knock together, at least kind of fun, and tells a story.

I haven't had much progress with my Gladiator remake, because I just can't muster the will power required to get my ass to the grindstone and make the thing. Now, my Gladiator game design is, I think, pretty unique. And it should be pretty fun. But it is going to be HELL putting the whole thing together. So, since I'm in the middle of a busy ass semester anyway, and since I'm still coming off of Verily, I think I'm going to go the D:ALS way and make something easy and fun.

I'm sick of making prototypes. This time I'm going to make a game.

A sappy, romantic comedy game.

Blame Ms. L.

Saturday, February 13, 2010

Not too much to report

I'm still not 100% on where I want to go with my next game. In the interest of getting something done I have started coding the generic stuff anyway. So far I've got a neat game state manager in and ready to go. I'm also going to start writing the base class for my animated sprites. Regardless of what game I am going to pick, I will have animated sprites.

I will definitely have a direction picked and a meatier update next week. Soz mates.

Thursday, February 4, 2010

New Game!

The time has come to pick a new game to start developing. The question is, what game?

As I see it I have three choices based on a combination of factors, mostly what I want to make and what I think that I actually can make. I can go with:
  1. A humorous Point 'N Click Adventure ala Monkey Island.

  2. An RPG cutesy Dating Sim (Don't laugh).

  3. A simple but fun remake of arcade classic Gladiator.
The Point 'N Click Adventure is something that I've been wanting to do for a long time. If I did it, it would star Jack from Our Boy Jack and have a supporting cast of naive Victorian Londoners that I think would lend themselves easily to humorous situations. The pros would be that the game logic seems pretty straight forward and easy. The big con is that these types of games are asset heavy, and I could be in a bind if I went that route.

As for the Date Sim, well... What can I say? I've always been a fan of the simple, yet addictive puzzle gameplay that they offer. The best part of doing this would be that at its heart it would be an RPG, which I've done before with Verily. The negatives would be a whole lot of new game dynamics that I don't have a lot of experience in. Stuff like finite state machines for somewhat complex schedule and task oriented AI. Sounds scary.

For the Gladiator remake, my biggest draw to it is that it seems to be a nice middle ground between going all out and making a unique fun game, and making another prototype. If I choose to go this route I will have the benefit of learning quite a bit more about developing, as well as being able to be fairly confident of a release within the semester. I'd still have to learn a bit about AI, sounds, game state managers, and so on. But none of seems too far out of my depth at the moment.



Can you tell what I am leaning towards? Yes, although it isn't official I do believe that the Gladiator remake is going to win the day. My apologies if you were rooting for something else. On top of all the other things going for the Gladiator remake, I've also been on an Errol Flynn kick lately so I've been watching a lot of rapier sword fighting, which kind of lends itself well to a Gladiator type game. Plus, who doesn't want to be a musketeer? I haven't decided on a proper motif yet. My dream art design would be something cartoony like Captain Claw (super great platformer that went under the radar, by the way), but that might be too hard for me to pull off.



We'll see shortly.

For those of you who have never played Gladiator and don't know what I am talking about: Basically it is a melee fighting game in which you and your opponents can strike in High, Middle, or Low. In order to not be killed you have to make sure your shield is blocking the area that your opponent is striking. It is simple, but it feels believable and satisfying.

Thursday, January 28, 2010

Verily At Last

http://www.filefront.com/15446983/Verily.zip

There it is. I didn't bother making a readme, so the instructions for running and playing are as follows:
  • Download Verily.zip from the FileFront link above.
  • Unzip it somewhere.
  • Run the Verily.exe to start the game.
  • Use the arrow keys to move around.
  • The Health symbol in the bottom right hand corner of the screen represents your hitpoints.
  • The Shield symbol, also in the lower right corner, is how much damage you do.
  • The Gold Coin symbol in the lower left corner is your money.
  • On the first map there is a Health and Shield symbol on the left wall of the level. These are shops. To use them just walk into it. If you have enough money your gold will automatically be deducted and whatever you are purchasing will be added.
  • Walk through levels by walking to the top or bottom of the screens.

There. I think that about covers it. The game is anything but complicated, but just in case something is puzzling you, there you have it.

Tuesday, January 26, 2010

Verily Tomorrow

I have finished adding a HUD to the game, which incidentally turned out to be significantly more of a hard time than I had planned on.


Behold:

The HUD is composed of those icons in the corners that represent health, power, and gold. All that remains is for me to upload the beast to FileFront, which I will do tomorrow along with a simple explanation as to how to play.

Stay classy.

Tuesday, January 19, 2010

New Game Update: Verily

No really, the game is called Verily. Verily is a totally bare bones Ultima IV-ish rpg I made as a term project last semester. To make it I used SDL (to hell with Allegro), and it turned out okay.


Verily features:

  • Easy map editing.
  • Shops for buying upgrades.
  • Monsters to fight.
  • A boss monster.
  • A goal to grab.
  • Player animations.


... And that is about it. Verily doesn't feature:

  • Inventory.

  • Text of any kind - No story.

  • Any sort of HUD.

  • Sounds.

  • AI.

Now, most of these I don't care about. The project wasn't for a game dev class, and what I did finish was more than enough to get me my grade. That said, before I release this beast to the eager grubby mits of the general public (all none of you), I want to add a little something to make this a might-bit more playable. Namely, I want to get a functioning HUD in there. I estimate this will take me a week or so, so stay tuned.