Charlie Fleed
Member
Updated the first post with version 1.2.
Main changes: Unplayable Reaction.
Basically I have reviewed the code, also on the base of your advices (Trickster's mainly).
Besides I have implemented a FFX-like reaction feature, which I called UNPLAYABLE REACTION. In version 1.1 a player that reacted had a regular turn just after being hit. Now the player attacks the enemy (physically) automatically, and the queue of actions is unchanged (i.e. this is not a regular turn). TODO: the player loses the guard position after the reaction. That is not desired (I guess).
Fixed some bugs regarding reaction and player's states.
Fixed the "enemies behind actors" bug.
Added a few more faces to complete the set.
Used only complete enemy spritesets.
The hunt for the bugs is open.
@Trickster: I had started to compact the code as you suggested, but don't you agree that a single method accepting more parameters and having some conditional branches may slow down the execution? Especially when a method is expected to be executed a lot of times, I would trade synthesis with speed.
About what you said in point 14) of your comment: this code is written in this way for modularity, I can easily change it and try different window layouts. It will be optimized when I decide the definitive layout.
On 16) how would you load an array of images? Editing the string representing the filename?
Thanks.
Enjoy.
Main changes: Unplayable Reaction.
Basically I have reviewed the code, also on the base of your advices (Trickster's mainly).
Besides I have implemented a FFX-like reaction feature, which I called UNPLAYABLE REACTION. In version 1.1 a player that reacted had a regular turn just after being hit. Now the player attacks the enemy (physically) automatically, and the queue of actions is unchanged (i.e. this is not a regular turn). TODO: the player loses the guard position after the reaction. That is not desired (I guess).
Fixed some bugs regarding reaction and player's states.
Fixed the "enemies behind actors" bug.
Added a few more faces to complete the set.
Used only complete enemy spritesets.
The hunt for the bugs is open.
@Trickster: I had started to compact the code as you suggested, but don't you agree that a single method accepting more parameters and having some conditional branches may slow down the execution? Especially when a method is expected to be executed a lot of times, I would trade synthesis with speed.
About what you said in point 14) of your comment: this code is written in this way for modularity, I can easily change it and try different window layouts. It will be optimized when I decide the definitive layout.
On 16) how would you load an array of images? Editing the string representing the filename?
Thanks.
Enjoy.