Taking on a Zelda Clone, Part 11

I was able to score a few hours today to do some more goodiness on this project, hooray!

Pretty much I spent the entire time redoing the entire movement system from scratch. It took a couple hours, but I now have the movement system in a much better form than before – not 100% what I’d like but maybe 90%. I think maybe over time I’ll get a better feel for how I like it, or maybe it’s just a case of needing to get used to it.

Even so, if you’re reading this and you want to give some input on it, the current build is downloadable below.

The main sticking issue I have right now is that the auto-sliding thing is a little too tight when trying to walk horizontally around an obstacle. I can’t really do much about that though, due to integer math. It’s either make it a little tight like it is now or make it really loose, to the point that you can’t reliably push horizontally against an obstacle or a block.

I recorded a lot of my tests in the video above, it should show the basic evolution of the system. Since I’m packing this in with the base GameEntity object, enemies should be able to use this system too. I know Zelda 1 doesn’t really do that, but I want to give it a look-see before deciding whether to make it a player-only thing or not.

XNA is nice in that it’s easy to rotate and zoom stuff without much trouble at all. I used it to try out my movement stuff in a stress test sort of way, as seen in the video above. It makes me wonder if I could use those things for some other effects though. The first thing that comes to mind is something akin to mushroomization in EarthBound. I dunno, though. I promised myself I wouldn’t go too overboard with non-NES-like effects.

I’ll probably get back to reorganizing the code tomorrow, starting with the enemies. Now that I can base a lot of their stuff off of the GameEntity class, it should simplify a lot of stuff. I still need to figure out a good way to implement enemy action scripting or something, though.


Both comments and pings are currently closed.

2 Responses to “Taking on a Zelda Clone, Part 11”

  1. Zinco says:

    It’s interesting seeing solving problems like fireball speed and block navigation in action—in part because the original Zelda programmers had to deal with the same kinds of things (not to mention with far more limited parameters), but also because I wonder how much these kinds of things have changed with modern games. I almost feel as though it’s hard to envision the problems programmers have to deal with with a more realistic game, perhaps not because the experience is more immersive, but because the problems seem like they’d be so much less a part of the greater experience owing to the complexity of the game, or because the feat of crafting a modern big-company big-name title is so far beyond the capacity of a single programmer that a layman would expect problems to resolve almost organically through the group process. But I suspect that the more things change, the more they stay the same.

    I’m very tired and hot and no longer want to think about this, because I’m having enough trouble putting my thoughts down as it is. It’s harder because I don’t know very much about programming, but I imagine that programming is the same as any other discipline in how one recognizes a problem and engineers a solution. I guess though that with game programming (as well as a few other technology-related disciplines) the rate at which the complexity of programs has increased has been more rapid than in nearly any other field imaginable. I wonder what it’s like to have programmed since the NES days (or earlier) and to still have a hand in programming now. It’s hard to conceive of game teams now being composed of the same people that made up game teams twenty or twenty-five years ago, but I’m sure that with some older companies that that’s at least somewhat true.

    • Mato says:

      That’s a good point about modern games – I bet things are so complicated now that there are a zillion things like this that have to be done, and on a less intuitive level.

      I feel like a lot of games these days are probably very similar deep down and thus use a lot of generic libraries to get things done – things like 3D model collision detection, 3D camera control, stuff like that. In fact, that’s kind of what XNA is – a generic library to simplify a lot of basic processes. But back in the NES days it was probably a case of every dev team having to create everything from scratch by themselves. That’s why my own games back in the 90s were simple and sucky, at least 😛

Subscribe to RSS Feed Follow me on Twitter!