So one day I encountered two different glitches so I'm posting the pictures and the console logs from those two battles. ------ SparklerGladeGlitch This one is a rather common problem I've encountered in various battles where an armor activates but does not return to normal size. -------------- Quickdraw Battle A trait card was attached to opponent but didn't shrink until later when another card was attached.
The first one is fairly common, it happens when a card triggers before it finishes the animation to add it to your hand. The second is probably also an interrupted animation.
I see. It's just that as a programmer this matter makes me feel a bit like Melvin, that it is totally unacceptable and easily avoided. The animation algorithm shouldn't permanently affect any other algorithm (other then something like loading the cache), yet alone the card_in_hand rendering function. But this problem is that during the animation the picture data (such as size) used by the card_in_hand function is occasionally being permanently affected. Plus for this game, why would the animations need to be interrupted in the first place? Have one instance for when the card activates and gets bigger, and another instance for when it goes from big to normal size. The same function can be reused for both cases. All it needs is where on the screen to draw the card, what scale to use, and time interval to wait before changing the scale and position. Other graphics can run in the background, but none of the game logic mechanics need be checked until the function is finished. I hope the game developers can let me know if I'm wrong and they did something different.
I'm confused too. I've been out of programming for a long time (8-bit machine language programmer on the Atari and 16 bit on the Amiga). Why the devil would @Jon use Flash? Adobe was the epitome of evil until Oracle and Google came along. (I'm excluding Microsoft, but that was primarily the fault of IBM, which predates the origin of my argument.) [Serious]Love your game, Jon[/Serious]
If it helps any, this sort of thing drives me up the wall too It's the sort of bug you get from using a set and forget tweening framework and/or stateful render systems. Unfortunately Card Hunter uses both! I prefer stateless render systems, where you just blit everything to the framebuffer to represent the current game state every frame. The base flash renderer really doesn't like that though since it's performed entirely on CPU and therefore fillrate limited. A persistent displaylist means they can update only the parts of the screen that change, thereby saving a ton of CPU time, but making it super easy to accidentally leave something in the wrong place or at the wrong scale or rotation. As for our decision to use a tweening framework... I don't recall why we did that but I absolutely regret it. Oh, and we chose flash because we wanted to make the game freely and easily accessible to as many people as possible. 1,406,112 player accounts later I'm pretty happy with that decision
