Ever get the feeling that, even though your game works almost perfectly, you feel like you've screwed up somewhere, but you don't know exactly where?
Like you feel that you organized the code in a sloppy way that is eventually going to cause problems? Or you skipped an important step which you might have difficulty going back and fixing?
Yes, I get these feelings, and yes, there are best practices to handle each.
If you feel your code is sloppy, think of a better structure and refactor.
If you feel like you've missed something, make a test for it and see if it passes.
You feel that way because it's true.
There's always something you missed. All software has bugs.
The important thing is
how long you can keep your users from finding them.
(Exactly was I was about to say).
Yup. I can count on one hand the number of times I've written code where it's literally "just worked" the first time without any bugs/issues. Incredibly rare, and when it happens my sysadmin intuition kicks in ("nah, it can't just work, there HAS to be something wrong") and I'll end up spending another hour essentially questioning or reverse-engineering my own work. Sad but true.
I get that feeling all the time, especially when programming in assembly. And the feeling often turns out to be true in bugs/problems that only manifest themselves sometime later. I try not to go overboard with testing though because that can be a huge time sink, and rather deal with the problems as they come.
I know the feeling. It's usually the case where a project I'm working on really isn't as "mature" as I'd want it to be. If I get the feeling I'm using the C++ equivalent of hot-glue and rubber bands, there's probably a reason for that. It's good to acknowledge this. Nothing starts off perfectly as soon as you begin typing code. Think of refactoring, code cleanup, and other improvements as a perpetual TODO and you end up fine in most cases.
Just don't go overboard. I knew people that would scrap their entire work every 6 months or so and go from scratch. Needless to say, they never actually finished much.
When something just works for me when coding, either luck finally found me or things are about to go horribly wrong. Probably the second one.
I usually get caught up into organizing my code for stylistic reasons so much that all I ever change is how things look and maybe the order of how the game does things. It's never "something code-wise must be changed", when sometimes it really should be that way; usually I can't ever finish something because of obsession with making the existing stuff look good.
That happens to me too. Every time I get something working, which is hardly on the first try, I spend some time trying to break it (specifically if it did work on the first try!), to make sure the solution is robust.
There are also times when I'm absolute sure I found a brilliant solution for a problem, but as time goes by it starts to look less and less brilliant, to the point where I have to use hacks around the solution so I can keep using it. I fixed a bunch of these "brilliant" solutions recently. I guess this is normal... there's no way a person can think of all the implications a specific piece of logic will have until other parts of the program that depend on it are coded.
BG Collision is one thing I'm skeptical about. When I get home, I'll try to reorganize the code with macros replacing any redundant code, so it is more readable.
I have kind of the other problem: once I'm out of syntax errors the compiler points out to me (or a second-look-over), it just works 95% of the time. This leaves me without paddling experience for the creek I'm stuck up the other 5%.
I remember when I was writing ASM code and was completely spooked when it worked perfectly on the first try.
For some people, a strong static type system helps them make programs run correctly on the first try once all the errors are cleared out. It certainly writes a lot of your unit tests for you. I vaguely remember reading some computer scientist's claim that in a sufficiently rich type system, errors that make it past compilation would be nearly nonexistent, but I can't dig it up at the moment.
Strong typing and
static typing are different things. In static typing, a variable can hold values with only a subset of the available types, while in dynamic typing, it's essentially a tagged union of every class ever conceived. In strong typing, the compiler or interpreter allows only a small number of conversions of a value from one type to another, while in weak typing, a lot of built-in automatic conversions are valid, even ones that make little sense, leading to a potential for poorly defined behavior.
Java is strong and static. Python is strong and dynamic. PHP and JavaScript are weak and dynamic. C is weak and static.
There doesn't seem to be a consensus on the exact definition of weak vs strong typing. Personally I don't really accept Python's typing as "strong" given how easy it is to make typing-related mistakes. Example:
Code:
def foo( x ):
return ",".join( x )
foo( ["a", "b", "c"] ) # cool, works
foo( range(3) ) # doh
But as I said, they are not well-defined terms, unlike static/dynamic typing, so YMMV. (It's also not black and white, some languages are more strongly typed than others, while still not necessarily
strong.)
I think "static" is a category that's fairly well defined, but "strong" and "weak" typing are relative terms at best. C is "weaker" than some particular others, but characterizing it as "weakly typed" was always weird to me; it's realtively strong compared to many languages, I think? I don't think it's a very useful characterization.
I figured out the reason (or what I think is the reason) I sometimes have collision glitches. My collision routine expects a characters hit box to be less that 32 pixels wide, and my character's hit box was 36 pixels wide.
I feel like I should've made Alisha's Adventure a run 'n' gun instead of a "run 'n' kick" game. It seems weird running up to enemies and doing nothing but kicks.
psycopathicteen wrote:
I feel like I should've made Alisha's Adventure a run 'n' gun instead of a "run 'n' kick" game. It seems weird running up to enemies and doing nothing but kicks.
The forthcoming game
The Curse of Possum Hollow will likewise feel weird to you then, as its character is also a girl who kicks.
It could be that I'm playing on a keyboard too.
psycopathicteen wrote:
I feel like I should've made Alisha's Adventure a run 'n' gun instead of a "run 'n' kick" game. It seems weird running up to enemies and doing nothing but kicks.
How about a short-range weapon then? After all, a gun totally changes the way the game is played. If your original intention was kicks, then the replacement should be something where you have to get close to the opponents as well. (But don't use a taser. That's already the weapon in my soon-to-be-released game.)
Swords are good short-range weapons for games, or even daggers or something if you want shorter range.
I don't think there's anything wrong with the primary attack method being kicks though.
Kick Master (NES) exists and has a whooole lot of ways to kick.
Maybe I should start adding more special effects to my game. Maybe, I'll do some sprite scaling, using the LUT trick.
psycopathicteen wrote:
Maybe I should start adding more special effects to my game.
I'm not sure how this addresses the problem at hand...
I'd really try to implement more moves. I haven't tried it in a while, but I don't remember the kicks being too diverse. You could do something like Super Smash Bros in terms of kicks, where the direction you are pressing the D-Pad while you are pressing the attack button determines what move you pull off. You could even have it to where you don't change direction in the air so that kicks pressing the D-Pad are different there, but that might be too awkward, considering it is kind of a platformer? You could also increase your arsenal of kicks by using different buttons, like for fast but weak or slow but strong, and you don't need to limit yourself to kicks anyway. I don't know how well this would work, I'm just trying to come up with ideas that would help diversify the gameplay more.
I'm trying to improve the physics on the dash. When she hits an enemy using the dash, she pops up too much. I'm thinking about having her dash through enemies, but give a slight angle increase each enemy she hits.
Too bad my "attack physics" routine is a sloppy mess. Every time I add a new feature, I end up doing a lot of code refactoring. Will it get easier eventually, or is it just going to get harder?
Asm tends to be like that. Sadly C is not (yet) an option for SNES really.
I found out some of the physics routine is dead code anyway, so maybe it's not as scary as I thought.
I decided that I am going to use the PEI-loading trick with DMA registers, because then I'll have at least some headroom for other kinds of graphics effects.