So school hit me harder than I expected so I haven't got as much work in as I have wanted, but I assure you I have been working.
I got combat implemented! Well, by implemented, I mean it in its most basic form. I will trail with a simple diagram of whether an entity is targeted or not. Text in caps is a transition word, anything in parenthesis is an conditional and anything else is an argument.
IF (entity) IS (less than) (equipped weapon's range) distance from (player's position) THEN add (entity) to (players target array)*
FOR EACH (entity) IN (players target array)
IF (entity's DistanceToPlayer) IS (less than) (previously focused entity's DistanceToPlayer)
THEN (players target) EQUALS (entity)
*The list of possible targets for the player
I don't think that logic I shared was above anyone's head, I tried to simplify it as much as possible. I can assure you the targeting system is longer and more complex than that, but that is essentially how it works.
In addition to the targeting system, targets have health and you can damage them, and you have health, but they can't damage you. In order to damage yourself press B and to heal press N. Obviously this is only for debugging purposes and won't be present in the final game. (But I am considering going back to the classic 'cheat codes' and have something of sorts, for nostalgia's sake)
UI:
Moving to the topic of UI, I converted every thing to a frame system so instead of saying whether a button is visible at this point in the loop, you say whether a frame is visible and its children components will be visible based in its parents visibility. Once I get more stock UI components I will make an options menu, but that's not a priority.
Backend:
For the backend of the game I got pissed off with some camera problems like that I couldn't convert a screen point to a world point and vice versa because I only used a transformation point matrix to calculate the sprite batch's position, and the 3D to Screen point Projector/Unprojector requires a world matrix, view matrix, and a projection matrix, which I couldn't provide obviously. I tried simulation the required matrices but I guess that didn't work because they were created, but never accounted for. So I got rid of ALL matrices and instead of moving a camera, I move the map, which has no noticeable visual/performance affect. So no projecting matrices is required, screen points are on the same definition plane as the world points.
Near Future:
- Usable networking
- Usable combat(currently its walk up to entity, attack, wait a second, attack again. I don't consider it usable)
- Featureful GUI
- AI for entities(bit longer off than the rest)
I guess that'll be it, I'll edit any information I left out.
Stay Crazy, Monkey