Yesterday I figured out a new collision system using a single background image. So, maybe for the next project. In the meantime, there are 3 things that need doing.
1)The animation reduction algorithm. Since it isn’t an engine system, it can easily wait until the end to implement when I’m Gold Plating all the code and optimizing. So I’ll skip that for now.
2)The enemy Push state. Again, the system in play works and needs animation, and a system to implement the animation…but there is no animations and it isn’t an engine system, so I can skip that one too until I have more animations to work it.
3)The staggered state. This is just candy, and not having it will have almost no effect on the final game. So I’ll add it when I have more time, and an animation. But if I don’t get that I can skip it. It may affect the timing of some speed areas, but those can be tweaked to not need it at all in the end if I want to.
So for today, I’m tweaking the combat system to allow for only 2 kinds of attacks, a high attack and a low attack. This should simplify the combat system a little and facilitate dodging. After that, I’ll try to tweak that bug that makes you duck and move.
-The combat system is easier now and it is possible to beat an enemy set to 9 without getting lucky. So that’s an improvement I think. Also tweaked the speed a little bit so now the animations are a little slower so you can see WTH before you get your ass kicked. That’s good news for players, bad new for my animator, since now the combat needs more frames to make up for the different speeds. Oh well.
-Cool, easy bug fix when I had a new viewpoint. I was getting all hung up on event handling and making my variables line up. The best way was to tell the system, “Hey, jerk. When the down and left/right are pressed, ignore the down key. Sheesh.” Now if you hold down and run you just run. As soon as you let go of the running key, you duck immediately. If you duck and then run, the run overrides the duck. So all is good in the kingdom.
-With that, the bugs are squashed and the engine features implemented. So the next project is the level editor TheifEd. So the next entries will probably all be Tests that I’m running. For TheifEd I need to learn:
-Making the mouse work and recognizing where it is.
-Making variables be stuff based on the mouse position.
-How to design a GUI that is easy to work with and isn’t oogly.
-Save it when I’m done in a format I can import into the game (maybe via the Include command).
-…and a dozen more things I don’t know how to do yet.
Then again, when I started the Engine I didn’t know what I was doing either, and I learned as I went. One day, I may consider myself to be a competent programmer. Until then, I look at code and puzzle out what does what then create test systems. Eventually, I combine these Tests into the prototype that does something and then I continue to add features to the prototype until it works. This time, I’ll try to keep it all straight. The Engine is made up of dissimilar bits of code with a variety of different naming conventions and so forth because of this prototype system (iX and iY are the player coordinates, but Rect1X, Rect1Y etc are the level coordinates. If I was consistent they would be PlayerX and PlayerY or IRect1X and IRect1Y). So I’ll try to have better practices with the new system and better commenting while I’m writing the code, not after. So now, the next bit.
-Maybe. It occurs to me that I can now build a test level, not just a single screen, but a Level. I’ll consider doing that for interviews later.hmm…
No comments:
Post a Comment