Advertisement

I need help with having multiple player objects please!

Started by April 02, 2016 03:33 PM
16 comments, last by null; 8 years, 8 months ago

I'm looking back at my fundamentals, so there's no need to tell me to do that XD (not trying to sound harsh though! any criticism is welcome!)

Anyways, I have a question. So, I have a player object (which is basically a rectangle) with these parameters: x, y, Color, width, length, and health.

My draw method is filling in a rectangle with that color and the x and y coordinates along with the width, etc. In my main class, I create a player object and draw it from the main class (a paint method I have in the main class to be specific). Everything works fine, but when I try making TWO player objects, it just uses the second one I initialized and pretty much ignores the first. Is my method of painting it wrong?

Again, I completely understand that I have to re-learn fundamentals or just learn MORE, I guess.

How would we know your drawing call is wrong if you don't show us the code? What you could also be doing is accidentally changing both players' parameters (like position) to the same value. By any chance, are those parameters shared between multiple instances of the same class?
Advertisement

How would we know your drawing call is wrong if you don't show us the code? What you could also be doing is accidentally changing both players' parameters (like position) to the same value. By any chance, are those parameters shared between multiple instances of the same class?

No, the parameters are completely different for every instance of the player object. In the paint method in my main class, I would call the draw method from the instance of that player object rather than the class, so I don't think that's the problem either. Are there any other possible problems you could list though?

I really can't tell you what's going on without seeing code. But what happens if you make both players, and only draw the first one? Does it draw in the same spot as when you don't make player 2? Or does it draw player 1 at player 2's position? Or maybe it doesn't draw player 1 at all?

I really can't tell you what's going on without seeing code. But what happens if you make both players, and only draw the first one? Does it draw in the same spot as when you don't make player 2? Or does it draw player 1 at player 2's position? Or maybe it doesn't draw player 1 at all?

Yeah, it draws player 1 at the same spot as when I don't make player 2. Anyway, it doesn't matter since I screwed stuff up and now my project is just kind of - well, broken I guess. I had an AI path-finding system and health bar and everything :(

That brings me to a follow-up question:

Is failure in a project like this normal?

Programming can be difficult, and failure can be a part of that. Part of being a good programmer, though, means being able to fix the problem without starting from scratch. It sounds like you put some work into this project (pathfinding, health-bar, etc.), so it might be more worth your time to get the project to a working state instead of starting over. A lot of first-projects don't make it very far, as that is a time when we're learning the most (first time implementing features, making a complex game, etc.) and that's ok. But, you're going to be a lot better off if you can figure out what your problem is (because, chances are, you're going to run into something similar again, and having it not be a first-time-dealing-with-that-situation situation will be really valuable) than if you give up and start over with the idea that you'll do it right next time (which, because you didn't solve your problem the first time, you probably won't do).

This also seems like a good time to mention source-control: do you use it? Something like SVC or Git would make it much easier to go back to a point when things were working (even if not exactly how you wanted them to) to try to solve your known problems in a different manner.

Good luck!

Inspiration from my tea:

"Never wish life were easier. Wish that you were better" -Jim Rohn

soundcloud.com/herwrathmustbedragons

Advertisement

Alright, I'll look into what you said. I have a question, though. Is failure like THIS normal, though? Or does it mean I have to go over the fundamentals ALL over again? I really don't feel I should, yet me screwing up this project makes me feel as if I'm not at the level I should be at. I honestly don't want to have to relearn the stuff I'm already PRETTY sure I know... I have mixed feelings, I guess.

And yes, I got TortoiseHg today and I'm figuring out how to use it.

Yes, bugs in your code are absolutely normal. You will find and fix hundreds and many fixes will introduce new ones :) Just get used to it and learn how to debug and find them. Your particular problem is likely something simple that will make you scratch your head in disbelief when you find it, but as NoAdmiral said starting over won't help.

Also Mercurial is in my opinion good starting point to source control.

You still may want to show us some code like your initialization routine or the player class before anyone here can suggest anything.

Oh, sure it's normal, you can make the weirdest mistakes no matter how long you have been programming. All it takes is one typo.

Just yesterday, I tested (unintentionally) whether a computer has finite stack memory. And indeed, it's still finite, so infinite recursion does fail. \o/

And I have been programming for only 30 years :P

The skill to debug problems like this is a valuable skill too, and it's different from programming

Everybody runs experiments to see if what they have a handle on the concept they want to try out. Sometimes they're successful first time but usually they're not. Even then, there's usually room for improvement.

This topic is closed to new replies.

Advertisement