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)

Minor update

Just a minor update before I forget about it. I've got 4 exams and 4 projects due in the next 8 days, so I'll likely (or shouldn't) get much done on this. I have, however, successfully figured out how to connect the gameplay loop to an event timer so that after the passage of X amount of time, the geoscape clock automatically updates. A few bugs surfaced though... in that it's possible for the forced refresh of the zoom to interfere with the forced refresh of the time update... (which makes for some interesting things as it's rendering the ascii matrix) I've got a few ideas how to fix this. Also, I've got an invisible variable properly moving the horizon, now I just need to modify the rendering methods so that they access this variable to see if it should render the element in question as day, dawn/dusk, or night. That's about it. I'm pretty sure that this project will go on hiatus for a month in November as I direct my extra time towards the NANOWRIMO. (National Novel Writing Month) I'll likely post on here about my progress with that, and at the very least, have a link to my progress bar as I slog through 50K (or more) words in 30 days.

More Geoscape

So, as you can see, I've done a bit more work with the geoscape. I've added the time/date window, which properly increments through arbitrary amounts of time and such (except it doesn't yet correct for leap year, as if that really matters) Also, I've added the 'controls' though, none of them do anything yet. However, I HAVE added zoom in and zoom out functions, though the x,y coords of the view screen don't change when you zoom in/out. (I'd like the zoom to focurs on whatever is in the center of the screen. Perhaps I'll fix that later. A few more lines of code and this will actually progress through time with the user being able to change how quickly time progresses. I currently have the capability for the world map to include differing colors, textures (IE, desert, arctic, etc) I just haven't gone in and changed any of the #s to something else. Once I get the time progressing, I'll add in the night/day progression when you can actually see where night and day are on the world map, then I'll add the layer(s) which will let me see where the (if any) bases are, and cities perhaps. (though I doubt I'll put in any cities right now, at least, not more than 2 or three, just enough to make sure it works. I think I'll have the cities be asterixes or something on the world map, and the ASCII characters will be followed by a sequence of city names, in the order that the asterixes were found in the map file. I could do the same the countries, except that I don't know how I would define country borders, through the map. I could make it a bit more simple, and just have a country's capital/center of mass or something be labeled and connected to it's starting pay amount... and anytime there is any activity that would cause a country to increase/decease its payout, the location where said thing happened will be calculated for its distance from the nearby countries. Or something... but I might not do that.

Just a bit.

I fiddled around with my code and fixed the color output for the geoscape window. I also changed it so that scrolling makes it jump 5 sqaures at a time and shift-scrolling takes it to ten. I fixed a weird bug that caused the bounds-checking when moving to get borked. The fix is just a hack though, until I figure out where I got X and Y values crossed. But, out of this, I have the basic framework for all of the file-parsing (I assume that I'll have rooms and components of levels saved as editable text files) functionality. Next, I'll implement a zoom (which will basically print every other unit in the array (though, will arbitrarily place 'important' units nearest where they actually are, IE, Bases and the like.)