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.
6 comments:
Sweet. Something I always wanted to know when I was hauling loot/gearing up, was whether it would put the soldier over slow down the soldier, and how much.
So perhaps somewhere in the inventory screen show how much is carried and how much it is slowing the soldier down.
Be sure to post anything about terrain generation, it's something that interests me.
Collections.sort( list );
works for all lists, also LinkedList. The objects in the list must implement the Comparable interface.
Droid factorial; thanks or the idea about encumbrance. I've already got it working to the point that it calculates how much all of a unit's equipment weighs, I could easily include that in the inventory screen, and have that number turn colors or something when it's just too much. Terrain generation interests me too, a lot. It was one of the first things that I started thinking about when I decided to embark on this project. I'll keep you posted.
Tormod Haugen; I've tried using Collections.sort(list) and i get some weird errors. It's frustrating, because looking up almost any problem with java brings me to various forum posts with people telling other people they won't help them with their homework. I implemented Comparable and even wrote the comparable method, but it seemed like it wanted me to use the Collections.sort(list, new Comparable()) way, which seems like it would require an external 'comparable' object. I'll have to look through my java data structures book sometime soon. It's not holding me up, as mostly I was just hoping to allow for quick sorting of large amounts of inventory easily. As in, it could be sorted by price, size, weight, equipment type, etc. So it's not important for now.
Oh, right. Then you need to use different *Comparator* objects apart from the items in your list. You'd need a PriceComparator, a SizeComparator, etc.
class PriceComparator implements Comparator {
public int compare(Object o1, Object o2) {
//Cast to Items, throw ClasscastException if wrong;
//Compare ((Item)o1).getPrice() with o2's price.
}
}
Check out http://lkamal.blogspot.com/2008/07/java-sorting-comparator-vs-comparable.html for a quick rundown.
Great to see you getting ahead this fast. Good luck onwards :)
Oh. Wait. I just read your post, again. If you want to keep it continually sorted, you'd use something line a TreeSet instead. That is a bit expensive.
OTOH, as long as you keep a list sorted you could use Collections.binarySearch(inventoryList, item, PriceComparator); It returns the position of the item, or where it would go if it isn't in the list.
BinarySearch is expensive on LinkedLists but not on ArrayLists. ArrayLists are expensive on inserts especially at the start of the list.
THat said, it is more important to get something working; you can always worry about speed later. It will probably not be a problem anyway. :)
You could also do the sorting when displaying the lists on screen.
True, about the sorting stuff. It mostly won't be an issue until I have to deal with large inventories... which is a ways off. Thanks for the link explaining comparators and comparable. In my data structures class, we wrote our own linked list class, and the one I wrote had a built in sorting method, and/or one that would insert a new item into it's proper spot so that it would stay sorted.
Post a Comment