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.