Some progress to point to here - some which is visible when I point it out, some which is not. Some which is hard to call progress.
- even shoddier art - for quite a while, I was ripping off copyrighted artwork. It's fair use, it's (right now) for my own personal, internal, not-for-profit(-yet) use. So, I didn't feel bad about borrowing screen captures from a source that I enjoy. But I did feel bad about putting them in something to show off to other people (you). So I pointed the camera away from the good guys, and showed off the advancing zombie horde. (Which is probably just as copyrighted, but since I went from one medium - scanned plastic game pieces - into a different one, I claim 'derivative work' status. Not that it's a big deal, yet, but I'm OK with the zombies, and I wasn't for the adventurers.)
So, I went and doodled up a party of adventurers. I've actually got something like 15 different stick figures, so when I get around to allowing the player to "roll up" their characters from scratch, I'll already have a fair selection of classes/portraits to choose from. Assuming I don't go through and redo the artwork again between now and then.
- orange jack, green box - hark! I see a green scaffoldbeast coming!. One of the inspirations for this game is "X-COM: UFO Defense", which was a fun squad-based combat game where you tromped around, recovering bits of alien technology from UFO crash sites. Also, shooting at any surviving aliens. I recently found a remake of the game (multiplayer only), but it reminded me of the complexity of the user interface. I haven't yet recaptured that, and I probably won't, but it did remind me of the specific things that their game allowed (required) you to do, like saving "action points" to be used later on as the enemy came around the corner - you could meaningfully "cover" your squadmates as they moved forward.
I mention all of this because I need a way to have a good 3d cursor. Failing any good inspiration on how to do that, I'm copying X-COM's approach, which is to draw a phone-booth-sized box around the chunk of the world that the user's pointing at. The first thing I do is I shoot a ray from the camera, through the mouse location, intersecting (hopefully) with the ground. That intersection location is drawn with the orange spiky thing. I then go over all the legal places where a character could stand (squares in this case, but they might be hexes one day, or something completely irregular) and see if the intersection lies within the square. If so, I draw the telephone booth in green.
- circle "overlay" beneath the rightmost guy - another couple of references for this game are "Lord of the Rings: the Third Age" and "Lord of the Rings: Tactics". I worked on the latter, so I got to see the decision-making process on how to do certain things. I may end up discarding a lot of the approaches we used on Tactics, but for now I'm working on a bunch of systems that only need to get to minimal functionality, and so I'm not going to spend time making them pretty (see also: character art, level art, green phone booth).
In both TTA and Tactics, the selected unit had a circle of elven/runic writing around his or her feet. The unit's target would have a different circle around their feet. In Tactics, we had big icons to let you know if you were using a ranged weapon, a melee weapon, or magic. I've got similar requirements to Tactics, so I'm reusing that approach for the time being.
These circles at the feet were implemented by one of my friends/co-workers, a guy named Jay Kint. He implemented them as projected textures (I think) onto the geometry of our world. He called this chunk of code the "overlay" system. So, even though I'll reuse absolutely none of his code (because A, I don't have that code, B, I don't have the rights to reuse the code, and C, that was all written in C++, and I'm working in Python), I'm still using the ideas, so I'm using the same name.
Soon, my overlay system will be rich enough to support drawing a path of arrows to indicate where the character is going to move. This is less important in my current game than it was in Tactics. Tactics had a simultaneous movement design, and my current plan is to go with a more traditional initiative order system, where you issue orders to your units, and they immediately execute them. I'm not sure if that's what I'll end up with - I do like the idea of issuing orders to your entire team all at once and seeing what happens, but it feels a little unruly - like you're advising your soldiers, rather than the characters on screen being extensions of yourself.
That ramble is all explanation of what that circle is doing on the ground at the swordsman's feet. That's saying that he's the guy who's currently moving.
- initiative display - speaking of currently moving, in the upper right hand corner, running down the right hand side of the window, you'll see (but perhaps not discern) 20 tiny portraits of different units. That's the initiative order. There's a yellow arrow indicating whose turn it is (the swordsman guy with the circle, if you recall), and you can see there's a bunch of units remaining to move this turn.
I haven't yet settled on an approach to initiative, but I think it's an important part of the game I want this to grow into. I've played many (typically pencil-and-paper RPG) games where initiative is critical, and a lot where it's a hassle. I'd like agile characters to elect to jump in and hit their target, then get away quickly. Right now, I'm figuring that a unit gets a position in the initiative list (this I'm ripping off from TTA), and then you can hold your action for a later time (a little like X-COM, or also like GURPS, and probably any number of other games). This means that the better your initiative, the wider the window of time during the turn that you can choose to act. We'll see if that ends up being fun to play.
- have I mentioned Mac support? - it's easier for me to take screenshots of the PC version, but running on the Mac is just as easy. One thing that's curious is that in PyGame, with PyOpenGL running, my mouse is flipped top to bottom. To click on stuff at the bottom of the screen, I have to move the mouse to the top of the screen, and vice versa. I could work around this, but for now it's not important to me.
I have noticed that some of the code I wrote as a quick placeholder for real overlay code wasn't working well on the Mac - I was just drawing a quad 0.02 meters (squares?) above the floor, rather than projecting anything onto the floor. I may decide that this is the way to go in the end, but if so, I'll have to figure out ways to keep z-fighting from becoming obvious. Even with this small of a world, 0.02 meters ends up projecting to less than the resolution of the z-buffer at the far end of the hall.
- zombie movement - not animated movement, just popping from location to location, but still, the enemy (computer controlled) units each choose a target to move towards and on their turn, they take a step in the right direction. It's not much, but it's that minimal implementation that gets me to playing around with stuff that's interesting - testing out design decisions for the combat system to see what's the most fun. I want to be able to have 10-20 hours of gameplay in the first release of this system, and I want those 20 hours to be fun so that when I come out with the sequel, people will be happy to play (pay) more.
That's it so far - one of my next things to tackle is a first pass at getting player character movement to work, and that's where the overlays and cursors are coming in. I'll probably have to tinker with the camera UI (I've already started) to make it feel halfway usable. I can live with stick figure characters, but user interface is important to pay attention to. Perhaps it's because it's not as visible that I think it's necessary to conscientiously iterate on UI.
After that, I may get attacking working. If I do, that would represent actual gameplay for the first time in this project. It's a wild thing, but for all the bare minimum placeholders, I'm kind of excited to begin playing this game.
ETA - as I've been looking at that screenshot, I've realized there are a couple errors that cancel eachother out. (In 3d graphics, it's not as important to have zero errors, it's important to have an even number of errors, since they tend to cancel eachother out.) I looked at the screenshot and realized that the characters were being drawn backwards - left to right flipped - from the way that I had drawn them. No big deal, my first thought, I'll adjust the code when I get around to it. But then I noticed that everybody was holding their weapons in their right hands, which is what I would have chosen, had I given it any thought. My stick figure doodles were all backwards.
That's not a big problem - I'll go through and edit (use a script to edit) the pictures so that the images are correct, and then I'll make the reversal in code so that everybody's back to using their right hands again.
There's also a problem you might not notice - most of the characters have a few pixels of transparency in their textures. I'm not (yet) being clever about drawing the characters, so sometimes these transparent pixels let the wrong things show through. (e.g. a transparent pixel on the texture of the guy with the dagger in front might actually obscure a bit of the guy with the longsword, but let the wall behind everybody show through.) Nothing worth worrying about; I have solutions and the problems don't interfere with what I want to work on, but it's something to keep on the "to do" list.