hi there im making this simple game with just basic functions like if statements and 2d arrays, so i called in a lot of voids for stage 1, i want to create stage 2 with different voids however they would overlap the previous voids, is there a way to destroy/clear/stop the previous voids?

p.s. im super noob at this my teacher gave us this assignment wthout teaching us anything usefull.

Voids? As in void blah() {}?
These are called functions and no, once you have defined one, it stays and you can't reuse its name. However, you shouldn't need to. Describe what you're trying to do and we'll tell you how to do it properly.

sorry about that, the codes is too long to post so i didnt post it all at the first place, anyway here's part of the codes,

so all i want is to "stop" or "destroy" the void setupGame() so that i can call a new setup game for stage 2 or restart the previous setupgame for stage1.

If you want to 'stop' a function as you said you simply write 'return'

void stop(bool someCondition)
{
   doStuff();
   
   if(someCondition)
   return;

   doMoreDtuff();
   
}

Technically with execp you can destroy the entire call stack and replace it with a new applicatoin. All you need is stage1.exe, stage2.exe, etc.

All I said is that if he needs to do level-specific setup for each level, he needs to write a different setup function for each level and call the appropriate one. I think it's pretty clear that he doesn't need to reload the graphics that don't change.

If there ends up being twenty different levels, he can either learn file I\O and design a general map format, or write twenty different functions that do the LEVEL-SPECIFIC setup. Where does it say in my post "you should also repeat the non-level-specific code every time and under no circumstance put it in a function of its own like LennyLen said".

Don't you have anything better to do than arguing for the sake of argument?

Since the OP is referring to functions as "voids" I think it might be a little early to learn how to load levels from files.

The reason why I'm disagreeing with you is because you are advocating the case of using poor programming practices to a beginner. The only reason for ever writing specific code for each level of a game would be of the mechanics for each level were so vastly different that a universal loader would end up being larger than individual loaders, and such a case would be extremely rare. A sufficiently experienced programmer should be able to tell when this would actually be the case, but a beginner (such as the OP) should be encouraged to take the correct approach rather than the east approach until they have enough experience to determine for themselves what approach is best in a case by case need.

I actually took care with my previous posts to not discuss how such a function should be implemented as it goes beyond the scope of this thread. Should the IP want to learn how to do it correctly they can start a new thread. For now it is simply enough that they are made aware that there is a better (though admittedly more initially complicated) way of doing this.

Maybe so. However, a beginner is also not going to know the quality of the advice they have been given, which is why I wanted to make it known to them that the approach Stas B may be initially easier, but is ultimately the wrong way.

Edit: post was typed from my phone, so please forgive typos.

are allowed to a beginner and which aren't.

I haven't been arbitrary as I have said a single thing about any of his code. The only fault I have pointed out was yours.

And you're taking things far too personally.

LennyLen isn't necessarily wrong. Neither is Stas. B. Everybody chill the fuck out! I got this.

Given that the OP is a student, it's likely that he isn't supposed to properly modularize his program yet. That said, given the level of proficiency demonstrated by the OP, I find it hard to believe that he'd be given such a demanding assignment anyway. Something is rotten in Denmark...

It might be best for the class to band together and protest the assignment until they're taught enough to accomplish it. Of course, the OP could be one of those people that doesn't belong in a CS program, doesn't pay attention, doesn't read the assigned chapters from the textbook, or doesn't ask for help during class; and is now struggling to turn in an overdue assignment that he should've learned how to complete. There were many people like this in college.

Many just didn't get it and expected the instructor to wave a magic wand and make them. No matter how much extra attention the instructors gave them they just didn't get it. I don't think it's something that can really be taught (obviously the language syntax and rules can be, but how to understand the pieces and assemble them into a program is more hard-wired I think). You either have it or you will struggle to do it (and therefore do a bad job and not enjoy it). At least in my experience. You'll note that there doesn't seem to be any sense of order in the formatting of the OP's code, which is an indication to me that this may be the case (I don't think there was ever a time that I wrote poorly formatted code, but maybe that's just part of my OCPD nature; I know that you'd lose marks if you handed in poorly formatted code in college ). If the OP truly isn't trying then the only thing we can responsibly do is troll him.

Of course, sometimes instructors do jump ahead without realizing it... That can happen. It seems strange for any instructor to assign a game assignment at a beginner level so perhaps this is just a matter of the OP over-complicating his assignment. It takes quite a bit of practice and knowledge to build a game, and it would be silly to fail an assignment because you tried to far exceed the requirements. If this is the case then I would suggest doing only what is actually required first and then, with a separate copy, return to your "game" and continue trying to work it out as an extra-curricular. At least then you'll have something to hand in if you can't make the game work.

I'm getting tired of this.
Look, if you want to justify your criticism, there's two ways you can do that:

1. Prove that I did something wrong in showing him one possible way to finish his task (which I think we can agree has more to do with basic programming syntax and constructs than with proper level loading) rather than making a futile attempt to teach him proper game programming, or just giving him some ambiguous and pointless piece of advice like yours. (Let's face it - you haven't been very helpful. I'm certainly not a beginner and even I'm not quite sure what you were talking about in your post.)

2. Prove that I tried to imply that my suggestion is the proper way to load a level. (My post actually implies that it's a simple but not necessarily correct solution and that the proper way to do it depends on the details and purpose of the task)

You can prove neither, so quit it.
Your arguments are invalid.

I made no attempt to educate him as to why it may not be a good solution because for all I know, it may be a good solution. It depends entirely on the context, as I have already explained. I had no reason to believe that anything more complex was appropriate in this case, however, I did ask him to elaborate on the task so we could give more appropriate advice.

It does imply that his code is not the proper way (as it was supposed to), but first and foremost, it implies that the proper way depends on what the task is all about. (Which in turn implies that I may suggest something different when I have more details.) It should be clear that this is the primary meaning because the second post is basically a paraphrase of the first one, where I say exactly the same things before even seeing his code.

The burden of proof is on you because I'm not the one making the claim.
If I were to say that X is the proper way to do Y, then the burden of proof would be on me.
What we have instead is that I said X is an easy way to do Y and you claim I shouldn't have said that because it serves to mislead a beginner.
If you don't even realize a simple thing like this, I'm not sure there's a point to keep up this discussion.