Musings about wounds/health/damage

So, after reading a thread on r.g.r.d in which people were talking about hit points, regeneration and healing spells, I've made a tentative decision. in X-Com, before you get the best armor, the game tends to be very brutal in that many agents will be killed with a single shot. I want the game to be gritty and brutal, but this is relatively unacceptable.
I think what I'll do is make weapons do less direct-to-HP damage, while doing more 'fatal wound' damage. Also, units will have a certain amount of regeneration, something relatively small, like 2 or 3 HP per turn (not move, but 'end-of-turn,' which would be counteracted by their fatal wounds... so, 10 fatal wounds would be -10 hp each turn, while the regen would be +3, so they would lose 7 HP each round. Healing via medi-kits would take 'longer', costing more TUs; though I'll allow for agents to (if they are reasonably conscious) use medi-kits on themselves. Basically, in X-com, early in the game, you either have to play it incredibly cautious, get lucky, save-scum, or just buy new agents to replace the dead.
I really want the game to remain dangerous, but at a level that fits better in the rogue-like world. I want for units to get injured, have it be scary, have to be dragged out of the line-of-fire, and I want for other units to haver to come to their rescue. I don't want them to be expendable. But, this is just me.

Also, before I go to be tonight, I hope to have the bugs ironed out of loading weapons; then I'll be able to move on to non-inventory stuff.

UPDATE: It looks like I have a working 'load', which is just an extension of 'move', where if you're moving ammo and it matches a wielded weapon that isn't already loaded, it gives you that option (in addition to others) as a place to put it. I'm sure that as I progress, I'll find more glitches as I just found and eliminated a few move glitches that I previously overlooked. For example, a particularly nasty one that only happened if you were moving things from certain compartments to others; an errant 'break' command was causing a for loop to remove everything in the linked list. Not very fun. I'm not even sure why I used break. I guess that's what happens when I code at 6am. Now, I might eventually combing move, drop, and get into one command, but for now I won't worry about it.

End of the semester inventory

Well, my semester is over and I've got about a week and a half until I start my next one. I've been coding a bit today and managed to iron out the bugs associated with unloading a weapon. The only other inventory bit that I need to tackle right now, other than some various visual things, is loading weapons. But, it's 6am and I should go to sleep, so I'll have to fuss with this later today.

Inventory!

Well, my semester is almost over. I've turned in all of my projects and all that's left is exams. As far as this project goes, I've been fussing with inventory commands and such. Agents can now properly move items from one spot on their person to another, which properly costs TUs and such.They can pick things up off of the ground, drop them to the ground. The only thing missing is the ability to load/unload ammo from a weapon. It won't take me long to include this, just saying where I'm at.
The inventory screen functions are kind of neat, because depending on which command you're using, and which item you've selected, it actually shows you where you can and can't put the item, related to how much space is free and how many TUs you have. You can still try to put it in invalid spots, but it will just say that it can't. I'm doing this, partly, because it's not graphical, so you can't see at-a-glance where things will fit. It's also very modular, with the names of the compartments and ordering of the compartments being defined by the species.
This means that an alien soldier could have the same amount of personal spots to carry things as an X-Com soldier, while an alien engineer might only have its hands and pockets, or an 8-armed alien could theoretically weild 8 weapons. I think the only bit I need to change for loading/unloading, is to have something that defines which 'compartments' are effectively hands. Because it doesn't make sense to unload a weapon that's in a backpack, when your hands are full.
As I was doing this stuff, I realized that I've been lax about having functions declare what is happening, such as, "Unable to move: Not enough TUs" So I'll try to do as much of that as I can. I also had an idea, such that opening and closing doors would open every '+' that is adjacent to the one you opened, which would allow for those double-doors and even wider ones, like what you'd find on a garage/carport. (perhaps doors wider than 2 '+' would take longer to open/cost more TU)
I've started poking around with recursive ways to generate levels. One I'm working with right now should break it down into smaller and smaller rectangles of various sizes, which will be expanded to allow for non-rectangular shapes. I've also got a few articles about recursive level generation to read.

Quick question to anyone that deals with Java. Is there any sort of built-in way to sort a linked list? I know that you can sort a 'plain' List object, but I can't seem to figure out how to do it with a LL. I might just do a manual sort that runs every time something is added to the LL, but I was hoping for there to already be a framework for it. Oh well.

We have Doors; we also have scrolling!

Ahh, so I slogged through some more code last night. The first thing I did was, using enumerators, allowed for the methods that get game objects' symbols to vary. For example, in this screen shot, the X symbol is the currently selected unit. (The 'R' is a stack of weapons with R (rifle) being the largest in the stack. The X is being returned in this way because I've chosen "getRepChar(AnAgent.RepEnum.SELECTED) or something. This might not seem all fancy and stuff, but it will only take a few lines of code to implement different toggles. For example, a toggle that would switch the terrain display from its normal symbols to perhaps, # or . , depending on whether it blocks walking, etc. Or perhaps, I want to toggle so that each unit is represented by a single digit number corresponding to their health. Basically, this should make it easier to take in large amounts of important data all at once.

Also, we have doors. They open. They close. They cost TUs!!!

And, I was dreading it, but I knew it had to be done. I finally wrote the code that allows for a view-port to scroll around the environment. In the demo picture, the view-port is maybe 10 rows by 20 columns; where the world is 50 *50. The scrolling works perfectly and without bugs, at least as far as I can tell. Also, I wrote a nice little method that attempts to center the view-port on any location, and if you give it a location that would cause it to run off the screen, it fixes that location. This means that when you cycle through your agents now, the screen tries to center on them; and when your guy walks around, the screen follows.

I'll do some more coding today, but I won't be able to code any more until I finish an assembly project that's due on monday for my operating systems class. We're modifying the boot sector of a floppy disk to (at the very least) write a "hello world." bootable OS. Though, most things beyond 'Hello world' will actually score us some extra credit.

Here is a list of things I would like to accomplish before I release my first super-shitty alpha version.

*Stairs!! We need them!
*reformat the HUD so it's actually usable
*allow for easy adjustment of the font size
*Finish implementing the equipment screen
*we need to be able to shoot at things!
*example soldiers should probably (for now) be created already-equipped
*finish random ship placement (basically, I just need to write a method that randomly checks for an arbitrary size/shape of empty tiles to place a ship/house/sidewalk, whatever
*make sure that '?' shows which commands can be used.
*Something to shoot at!! (and something that shoots back?)

Ships!!!

I finally took a few hours to actually create my ship class... I only hard-coded the Skyranger, as I just wanted something that units could sit inside of... and I only did one level because I haven't handled stairs yet... But, it's all modular, so adding extra ships won't take extra lines of code.

the ships are visible in my code as ASCII (and will enventually be in external text files)

they have arbitray dimensions and the ship itself is defined by various symbols. Right now, all I have are % (bulkhead) ! (a square that an agent can 'ride' or 'safely exit' the mission from) and a closed door; (of which I have no means to open) but, here's the kicker... I wrote all the methods for the ship class that allow for agents to board it, and for it to be equipped with equipment... and all of these things get addded dynamically where they shold be. Equipment gets placed at the first ! closest to the top left of the ship, and the agents themselves fill in these ! marks sequentually. when there is no more room for equipment or agents, this things are returned to their calling classes.

And then, when you send a loaded ship to the tactical mission handler class, it (crudely) finds a place for it to 'land' and then transfers its structure to the game environment and it's equipment and it's soldiers, and it all works more-or-less perfectly.

I'm satisfied for tonight...

things to do soon: open and close doors (so they can exit the ship!)
figure out why it doesn't cost any TU to move directly south
re-implement the inventory and equipping methods so that agents can pick up stuff in the field. (as it is now, I can hard-code a driver method to force-equip them, but I want to be able to move them around and pick up a pistol from the ground)

As for the picture, Yes, all of those @ are mobile... I can cycle through them :-)

Sorry for the low-res picture

More work

It's getting close to the end of my current semester, but I've been stealing little bits of time to work on this project. I've plugged my current version into a window with keylisteners and such. Once again I let my code get messy, so I've been transferring it into my new project, while trying to be better about encapsulation and such. This is all a huge learning experience for me, and I've told myself that I need to spend more time on this project so I can use it as something to showcase (ideally) in my resume. Not that I'm planning to design games, but rogue-likes have a LOT of different kinds of programming inside of their interior bits.

One thing that I've succesfully managed to do today is to switch inventory and such from a fixed array system to linkedLists... the way I have it set now, different species/types of units can have different numbers of types of places to put inventory and/or varying sizes for each of these slots. Imagine an 8-armed creature with 8 weapons, or an alien pack-mule that can lug around 30 items, etc.

my linked list implementation is much more useful and loads nicer to look at, as far as the code goes.

My goal is to release a super alpha version in the next few weeks as a JAR file, as basically a POC. Right now, units are randomly added to a random landscape with a random number of randomly generated objects. I won't add 'enemies' until I get back to adding in weapons-fire, which probably won't be for a month or so.