2*2 sized units

So, I've spent some time working through my code and making it a bit more robust and less obfuscated. I have a long way to go, but out of this process emerged the possibility for larger-than-1 tile-sized units. (IE, tanks or whatever) As of right now, they are limited to a rectangular shape; there's no requirement for the dimensions to be square.

larger units are properly displayed, properly block light, properly move, and properly check for obstructions. (a 2by2 sized object won't fit through a 1by1 hole)

What you're seeing above is a 2by2 unit. it isn't necessary for a larger unit to be all the same character or color, but this one is like that for simplicity.

The only remaining issue related to this is that I need to figure out what algorithm to use in regards to placing units inside of a ship, or their initial starting positions.

Graduation

So much to do.

Theoretically, I just graduated from EMU. I say theoretically, because i only have 3/6ths of my grades. I'm not worried about two of the remaining grades, but my senior project class is scaring me a bit. Though our professor was a nice guy, he never handed any of our work back the entire semester, not even our midterm exams. My group project for that class didn't end as strongly as I would have liked, as I learned too late that both of my partners were content with mediocrity.

Anyway, that stuff aside, I've suddenly got some more free time and a LOT less stress. I plan to do some coding today, mostly related to 2*2 sized units (instead of the current 1*1 size), though eventually I'd like to support arbitrary size/shaped units, like say 2*3 or whatever. (this other shapes will make things more complicated, especially rotating, etc)

I also need to work with my equipment routine.

I also feel that soon I need to start designing my (G)UI

In general news, I've been reading and listening to some various programming books/podcasts and have some new and better ways to deal with problems that I've created for myself primarily because of my general ignorance of proper large-scale software design.

shadows

So, I've fiddled around with a few of my algorithms, and I've now got properly functioning light sources that cast shadows and are dynamically updated when things move through them. Here is an image of two agents on opposite sides of a bright light. You can see the shadows that they each cast.

LOS & lights

So, I've done a bit more work with LOS and lightsources. Here is a screen shot of everything in action as it currently is. Agent's lights follow them around, but the other lights are static for the time being. The gray shape is the ship, the darkness at the bottom is a spot that can't be seen by either agent yet. It appears that my LOS algorithm is rather permissive, or whatever.

Shared vision, memory

There. I've implemented shared vision and agent memory, both of which are things that can be turned on and off (for whatever reason). I've also been slowly de-cluttering code that I haven't touched in a while. As of right now, the only two things that determine if an agent can see a tile are the following two things.
1) is there sufficient light
2) is it within whatever the agent's sight distance limit is.

I'll actually utilize LOS for vision as soon as I can design a proper ray-casting algorithm that makes sense and can be used for other stuff, such as lights and such.

I'm trying to decide on a way to standardize the color scheme of things. As it is now, some characters can be impossible to see if the level of light (which affects the darkness of the background colors) makes the background color too close to the foreground color.

The shared vision is a simple boolean matrix, as is the individual agent's vision matrix. Currently, the memory matrix is also a boolean one, which allows the agent to see the current happenings of an index, even if it's changed since it was last seen. I'll eventually change this, but it's not a worry right now. I'll also need to start keeping track of units and equipment and other agents that the selected agent can see, for use in targeting, etc.

So, this is where I am now.

Simplification and lights

So, I've been simplifying my approach, which is something I should have been doing a long time ago. Anyway, so I'm fleshing out my light source routines. I've got some light sources now that are connected to the agents, and follow the agent around when they move. These are simple fill lights and do not cast shadows; which will be replaced with actual light ray lights when I get to it. I've already got a few different kinds of lights, but I need more. Anyway, here is a screen shot of what it looks like so far. I can tell already that I'll need to deal with the offset problem, trying to get it centered directly on the agent, instead of its top left corner.

Why did I think I'd start with 3d?

So, after being convinced of what I already knew to be true, I've decided that 3d is much to difficult (at least, to start with) my XCom roguelike will be 2D for the time being. This will make everything much, much easier to code. An as was previously stated by a wise person, even Dwarf Fortress started out as a 2D game.

I'm back.

I've been gone for far too long. I'm in my final semester as an undergraduate, and I must say that I've been feeling a little down. Living in Michigan (United States) means that I'll soon be out in state with over 15% unemployment. At least we're the best at something... being the worst. Luckily though, I live in Ann Arbor, which is likely my best hope at getting a job in the state.
Though, Michigan does have a lot of nice things, especially when you look at our countryside and natural aspects. I believe we have the most/largest fresh water lakes in the world.


Anyway, I'm back; I've fixed my installation of Eclipse on my laptop; and I've actually started thinking about this project again. I've got about two months of archived rec.games.roguelike posts to sort through. I'd also like to separate my class that deals with the display and make it a little more robust. I can see it being the starting points for many of my other projects; such as artificial life simulations. Another long-term goal is to have some sort of framework, a skeleton, so that I could quickly make a roguelike game for a 7dlr competition without having to start from scratch. I've never been that into using other people's libraries, mostly because I feel that any problems I have to solve will help be get better footing as far as coding goes. I don't mind reinventing the wheel, at least, when I don't have a deadline.

refactoring is done

For now, that is. I think I've worked out all of the new bugs I introduced and everything seems to be working fine. I feel so compelled to work on things more related to the engine than creating more 'x-com' content, but this is probably a good thing. If you open/close a door that's adjacent to another door, it automatically opens/closes all adjacent doors. Yay for double-wide doors. Units now have a dimension variable, which will later be used for 2*2 sized units... and possibly larger ones.

the LOS algorithm is still only looking at a single dimension and I need to work on this, but I also need how to abstract objects into a sort of 3d shape. Things have a height, but nothing else really. I really need to figure out how I want to do this. Goal: windows that you can see out of.

Also, I'm going to start working on light sources, which will be switchable and vary in different ways. The simplest type of light source would be a diffused light which wouldn't cast shadows, but would diminish as its distance from the source increased. This would only need to be updated if it was switched on/off. Another type of light would be very similar to the LOS that agents use to see, except it would add light to the lighting matrix array. Each time some object in the world were to move, it would have to check with all of these light sources:
am I within your range?: no = done
yes = am I within your field of view: no = done
yes = subtract your light from my current position and the position I'll be moving to,
I move
add light aimed at my old and my new position.

This could still take time if there were a lot of these lights within range, even with only needing to redraw a small portion of their beams, but I think it would open up an interesting level ambiance that isn't normally seen in roguelikes. Also, many light-sources will likely be a combintaion of diffused light that doesn't cast shadows, with another LOS light that does, but the raytracing one will have a shorter range than than the diffused/soft light. The sun would be directional also, but would come from an entire horizontal direction, not a single point. (so, each ray would move directly across the y axis, for example.)

Refactoring is almost done

I'm nearly complete with my refactoring. I've also pulled all of the hard-coded human stats and all of the changeable information out of the classes, so that they can be kept outside (and later) will be contained in text files. I've also chosen to separate most of the standard 'costs' for things and contain all of this as a 'rule set' or something.

One of the most annoying reasons that I chose to refactor, besides realizing just how much in common many of my classes were, I found that the original way I'd been labeling my methods became horribly unworkable the larger my code got. I'd been naming things like, 'getThisThingy' and 'calculateThisThingy' (where these to both are in reference to 'ThisThingy.' when ordering the methods by alphabetical (or any other order) it was hard to keep track of which things were in refrence to what. All of my methods now are of the sort, 'thisThingyGet' 'thisThingyCalculate'

I continue to be amazed at how much I've learned so far in this process. Once I finish my external functions to actually set up the agents and I make sure that I haven't introduced any new bugs during my refactor, I'll likely 'fix' my messy equipping-related code. Seriously, it's incredibly horrid. You don't want to know. (it's not 'hacked' in or anything, it mostly is the way it is because I was OVERLY worried about somehow using it to cheat and dupe items, etc.)

Rehash

Just a quick update; in working with my code, I realized that it was time to clean up some of its mess. I've been splitting some of the classes up and taking advantage of inheritance, etc. This may take a few days to finish (and to make sure that I've not introduced any new bugs), but this single (large) act, will expand functionality between objects, agents, and environment tiles. It's a bit frustrating, but also rewarding.

We truly, really have color

So, I buckled down and hashed out a simple java class to display my color. each character on the screen is made up of three parts:

*A Color object that will be applied to the background (a solid rectangle)

*A color object that will be applied to the foreground (whatever character is there)
*And of course, a char.

One thing that I just realized, while I intended to make the 'ground' beneath an agent transparent, so that the background color of whatever he/she is standing on will show through, I can actually show two kinds of information at a glance. One of the standard optional views will be to represent all of your characters by the direction they're facing, which could be the foreground (just a simple arrow) and the background color could be toggled from transparent to represent whatever stat you'd need. (It would likely be used most for TUs left/Health, whatever. Also, the color of the foreground character could be temporarily altered to show other information.

I'm not sure how complex this will get, it might me something as simple as having a small number of presets and then having another key that can cycle through the rest. (in case you need to find an agent quickly that is a good thrower. You could also toggle through the detailed information for each agent, as you could in X-Com, but that method was tiresome because you had to exit the detailed info screen to see where your agent was on the map.

In the picture I have included, the X is the agent, the darker brown areas are hard-packed earth that are being recalled from memory, while the lighter cone is the area currently being viewed. The solid black squares are unviewed, while the black squares with the % signs are the front landing gear of the skyranger.

It works.

I think that my next goal will be to make a new file with just the absolute basic structure of this project so far, mostly the display part, so that it can be a sort of framework for me to use in the future for perhaps a 7DRL. :-)

Color!

So, I've been putzing around with 3d LOS. I knew that before I could implement this, I'd need to figure out how the objects are actually represented in the 3d environment. I'm thinking about doing it this way:
Any object that blocks light will have a linked list of 'obstacles.' Obstacles will be put into the list such that those at the front of the list will have the highest priority, and this will create a sort of boolean shape. If the first list object is a smallish obstacle that allows for light to pass through its dimensions (an empty list would default to allowing light to pass), and if the next obstacle in the list blocked all the rest of the light (it would actually overalap the whole plane) rays now passing through the first object would hit the second and be blocked. This would be a window. I started to make things too complicated, so I'm going to have to really plan how detailed I want these obstacles to be. That's a job for a few days from now.

BUT!!! I've also really been feeling that I need to get it over with and impliment color. So I did. Well, I made a 'Hello World' proof of concept. I've yet to import it into my program and change modify my things so that they include color values and clever ways to modify them; but here it is. I knew this day would come, so I developed my place-holder output methods to allow for quick swapping of new ones. Hopefully it won't be too much of a burden to get this working. I've just populated it with @s with random shades of blue.

3d LOS

My current LOS implementation has one very HUGE limitation... it's completely 2D. I'm working on an idea that will allow for half-height objects and such to partially block sight... but this would only handle LOS in the same Z level. Most of the LOS algorithms that I saw seemed to be geared towards 2d games. I know I can get a model that works wellish, but it will likely be fairly processor intensive.

I forgot to mention, that while you'll only be able to view one Z level at a time directly, important information will show up regardless of which Z-level your viewscreen is currently focused on (and to go up and down between Z-levels will be but a key-stroke away) Anyone who's played Dwarf Fortess knows that you get some information about the z level that's directly below the one you're looking at, such as if there's an object there. (this basically shows up as 'top of an object') Well, I'll do something similar, that if your agent can spot any other agents/friendlies/corpses/items/aliens that AREN'T on the current z-level that you're viewing, those items will still show in their proper x-y coordinates, but as a different color, perhaps indicating if that object is up/down.

I hope to overcome that possible cumbersomeness of this by making different kinds of data easily accessible/toggle-able. for example, a quick-key to show which of your agents has the highest (fill in the blank) stat/ability/level/health, whatever, by substituting a single digit number for their '@.' No more will you have to rename your units to "thrower" "sniper" "heavy weaponer" "MC agent" or, the super-annoying "55ST70TU60H..."

little stuff

So, I've decided to scrap my car today... which means I won't have one during my last semester at college.

Anyway, I don't think I'll work on anything large tonight, but I've got enough //TODO things that I can just go through and fix/add little things. I just adapted the ship importing algorithm so that agents don't necessarily have to start facing north. You can specify a different facing direction for each starting square. (and it works, I just tested it) this isn't a big deal for the original X-COM ships, but I want for there to be more options.

Things I'll eventually include... driveable vehicles, parachuting into a mission, etc.

LOS and Memory

So, I've got properly working LOS and a rudimentary implementation of memory. My LOS uses variable fields of vision, which adjust depending on what species you are and what you're doing. (if your unit is set to sprint, you'll get tunnel vision, if you're standing motionless, you've got the whole round to look around so you'll get an FOV bonus. In the image I've provided, the unit is facing south, after first facing east. You can see the void that the '%' creates in the 'X' unit's vision. The unit's memory is separate from the other unit's memory, but I'm going to impliment a static variable that they can all share, such that assuming they aren't radio-silent, they'll be able to know what the other units are seeing. (radiosilence would likely improve one's stealth ability/ make them quieter, but cut them off from their other comrades... but that is something to do in the future)

I'm really thinking that I need to swap my output methods soon, as i'm in desparate need for color/variation in darkness. You wouldn't know, but I'm currently differentiation between what the unit sees 'now' and what they 'remember', which would be done justice if I could render the current vision brighter, as is commonly done with roguelikes. One thing that might be problematic, though it's the same as I remember from X-Com, is that if something changes to the map (IE, a door opens/closes) in a portion where the unit visited but can no longer see, this change will show up in their memory... which doesn't seem altogether fair.

We have LOS!

So, after sifting through my code for a bit, I figured out why my LOS was so buggy. When using the Java's Math.tan() function, it inputs the angle in radians. I was using degrees, so I had to convert the angle from degrees to radians. I then (most unfortunately) had two very-similarly name variables, one which held the degree in radians and the other which held it in degrees. Everything about what I wrote WOULD have worked, except that some of my if/then/else statements which I used to filter out a few cases were designed to work with degrees... Except I had plugged in the radian version into them all!

But, now it's fixed. I love how making horrid mistakes like this helps me become a better programmer, because it's just one more thing in the back of my head that nags me while I'm writing code. (and yes, this is the main reason I'm working on this project; to become a better programmer)

So, the LOS works fine. It's directional and your agent can only see in a variable field of vision centered on whatever direction he/she is facing. Tomorrow I'll add a screenshot, as I'm on my laptop and I can't figure out where my printscreen key is. next I've just got to impletement an 'explored' array, so that things that the agent has seen in the past will show up also;

My LOS effectively casts 'rays' of sight from the agent in the directions needed. I'm aware that this isn't the best way to do this, and I'm sure I'll change it in the future.

A bit more LOS

So I've implemented a very buggy LOS algorithm... but the main thing is that it's properly updating the vieport as the guy is moving around. Bugs: he's always facing south, also, It seems that light gets around single post objects much too easy. I'll work on this more tomorrow, but I've got to get some rest. In the picture above the X is actually the character. To differentiate the multiple @, I'm currently displaying the currently selected unit as an X. When I impliment color, this will be much easier. The << up stairs are actually the ramp up to the skyranger, so these should/are blocking the LOS-- more or less.

LOS and other stuff

Well, I haven't quite gotten to LOS yet, but I've written methods that allow for it. Previously, the screen was being generated via the environment class without any regards as to what the selected unit could see. I've added a few unit variables and methods so that (unless you've enabled omniscience) the player only can see what the unit can see. I don't have a LOS algorithm yet, but I've got it set up so that I can drop one it. I randomly set the boolean array 'player can see this tile' to T/F and it works.

I've been reading through a few LOS explainations and such, but I think to start that I'll just do something simple.

Also, I've implement directional facing, both automatically when you move a certain direction, and also for TU cost if you change which direction you are moving while you are motionless.

Another thing, I've started writing methods to allow for sounds and smells to be left in the environment by agent's (and alien's ) actions. Sounds will only be stored for the current and previos turn in the form of a linkedList. Selecting a unit will show which sounds they heard (and where they may have originated) I'm trying to add in more tactical elements. :-)

floors and falling

Well, I've successfully coded some routines so that every time a unit moves forward, a check is made to see if the ground it's standing on is strong enough to support it. If they step onto a weak tile, (for example, say something has been damaged by an explosion, or the unit is a 4-ton tank and it's driving inside of a house) it will break through the floor and fall down. It will keep falling until it hits something that can support it, (or until it reaches the bottom z-level) No damage is currently done, but it does keep track of the distance that the unit fell. I'll likely institute falling damage, based on some preset 'free' bit of cushion based on whatever a unit's species/training may be, how much weight they're carrying, how far they've fallen, and perhaps how many spare TUs they have when they've hit the ground.

Next I'll need to write some sort of recursive function, perhaps, to check if every floor tile is being supported by something strong enough. I'd like to incorporate the aspects of X-Com Apocalypse that I found nice; and one of those was a destructible city. I want a high-explosive round to be able to topple a 3 story house. (though, the residents wouldn't like it that much and would likely demand compensation)

I'd like to make this game a bit more dynamic than X-Com was. Things I plan to include:

being able to jump various distances.
being able to climb over various things.

I've returned

I'm back! I'd hoped to have remained active during the last semester, but I turned out to be more busy that I expected.

Anyway, I've been coding a bit over the last few days and I've now got working stairs. It took me a while to write the framework for ascending/descending stairs, because I wanted it to be robust. How it is now, I can later add ladders, ropes, fences, and even tree climbing; with little extra code.

The skyranger now has two levels and you have to go down the stairs to exit. Next I need to make it so that if your agent walks into 'air', he/she will fall until hitting something solid.

summer class

I promise that I'm still around. I'm taking two classes right now during a condensed 7 week session, and I've currently been working on some ML 97 homework for almost the last 24 hours straight. I haven't abandoned my rogue-like at all, I've just been busy.

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.

Good news! I've finished my throw/target/look routine, which means that now I can move forward with any of my methods that need to have a target. This means that I'll be able to throw objects, shoot weapons and walk more than 1 tile at a time.

Well, I've started over from scratch, mostly. I'm not worrying about the interface right now, though I'll soon embed everything inside of some swing panels so I can use the key listener. Anyway, I've got the tactical world working fine, a super-random level-generator, I can cycle between units, move them around, the inventory works, time units work, you can equip things and look at inventory, etc. I really need to spend a day going through my code to make sure it's commented well. for the time being, I scrapped the color capability in the display, as this is what led to my frustration last time. I'll worry about the display later, as it won't take very much changing for my objects to return colors in addition to their represented character. I'm in the middle of writing methods that actually allow for the unit to use/throw euipment that it's holding in it's hands.

I took the liberty of adding in extra 'stances', (standing/kneeling) so that now you can low-crawl, crouch (move while doing these things) run, and sprint... all of which affect how much TU/Energy is expended, while either increasing or decreasing your accuracy (and other things)