Why do you need to "rearrange" the lists? Is order significant? I wouldn't think so, as long as every entity gets updated once per cycle. That's why I was suggesting you just have a way to mark the entity as "dead" and then have a scheduled cleanup.
My Dungeon Game [work in progress]
- Thread starter Jadzia
- Start date
If unit 6 is deleted, then what becomes of entry unit[6]? Do we
(A)shuffle a unit down to fill that gap? -- this is what I mean by rearranging the list.
(B)leave unit[6] blank? -- If a player stands by a generator for several hours blasting everything it spawns, then the unit array would grow without limit, consuming more and more memory, even though there are only a few units active in the game.
A scheduled cleanup would still involve manipulating the arrays. I don't see how it makes any difference whether we do that now or later, because this isn't a performance issue where cleanup needs a bucketing algorithm. It's a question of how cleanup affects the arrangement of the lists and references to objects in those lists.
(A)shuffle a unit down to fill that gap? -- this is what I mean by rearranging the list.
(B)leave unit[6] blank? -- If a player stands by a generator for several hours blasting everything it spawns, then the unit array would grow without limit, consuming more and more memory, even though there are only a few units active in the game.
A scheduled cleanup would still involve manipulating the arrays. I don't see how it makes any difference whether we do that now or later, because this isn't a performance issue where cleanup needs a bucketing algorithm. It's a question of how cleanup affects the arrangement of the lists and references to objects in those lists.
Glad you got it figured out! Sorry I was no help. 
Glad you got it figured out! Sorry I was no help.
You helped me to think through it, and now I understand the problem better from explaining it to you.
I haven't even started graphical games yet; I intend to learn some Python before I even think about downloading the PyGame module. Currently I'm working on a text-based interactive story called Four Nights. I'm probably going to have to scrap the programming a few times as I learn to take advantage of more and more features, but mostly how it works is that there's four nights until Christmas. Each night, you can either make a good choice or an evil choice and the ending will vary based on choices you made.
The problem I'm having, though, is that I want to keep each night in it's own separate little programming chunk (in Python, called a defined function or def-block). However, variables created in a def-block are essentially forgotten and unusable as soon as the block is finished. I think there's some sort of function where a def-block can return a value, I have to look in to that.
The problem I'm having, though, is that I want to keep each night in it's own separate little programming chunk (in Python, called a defined function or def-block). However, variables created in a def-block are essentially forgotten and unusable as soon as the block is finished. I think there's some sort of function where a def-block can return a value, I have to look in to that.
Glad you got it figured out! Sorry I was no help.
You helped me to think through it, and now I understand the problem better from explaining it to you.
I have that all the time. When I'm stuck on something, I'll just talk through it with someone online, and even though they won't understand a word of it, it helps me just to type it all out. Or sometimes I type it up as a forum post, but end up solving it before I post it just because the act of typing it out forced me to think through it more thoroughly. Strange how that works.
I have that all the time. When I'm stuck on something, I'll just talk through it with someone online, and even though they won't understand a word of it, it helps me just to type it all out. Or sometimes I type it up as a forum post, but end up solving it before I post it just because the act of typing it out forced me to think through it more thoroughly. Strange how that works.
Putting ideas into words forces us to organise our thoughts and apply method. Sometimes that's all that's needed.
But sometimes, we can't apply method because we don't know what method to use, and it is here where visualization and metacognition are more useful. That is
visualisation: drawing diagrams that detail the problem so we don't have to juggle it in our minds,
metacognition: exploring why your current train of thought has not solved the problem, and creating new trains of thought.
When I have a programming problem I talk it over with someone who knows nothing about programming. Often times they ill provide the incite I need to solve the problem.
I've found that, too. Lay people have no prejudices as far as solving such problems, or they at least have different prejudices than a programmer typically does.
I believe people call that the Dr House Effect.
And by people, I mean me, because I just made that up.
And typing up my problem to someone else online who has no idea about programming at all always helps me. Usually they have nothing to say, but just the process helps.
I think that mathematical skill is one of the most important (and underrated) strengths when it comes to programming. Possibly more-so than fluency with one's language of choice.
I don't think you necessarily need to know really advanced math, but you definitely need a solid grasp of stuff like trig. In games programming especially, it's all calculating angles and distances, and general problem solving of how to derive a number from a bunch of other numbers. So I agree that math is an important of programming logic.
After all, knowing the language inside out is useless if you can't figure out what you're actually trying to make your program do!
Well I'm not a particularly strong programmer, but it's rare that I encounter a programming problem that I can't solve, which I believe comes from my mathematical skills.
I am completely self taught at programming, and it was only 3-4 years ago when I got internet access that I was able to share this pastime with others for the first time.
But I was surprised how often I was able to answer people's programming questions online... even those who I felt were stronger at programming than myself. Mathematical things is where most seem to get stuck.
My approach to mathematics has generally been shaped by thoughts like "how can I compute this on a machine", while my approach to programming tends to evoke thoughts like "what theorems relate to this bit of program, and do I really understand why it does what it does?"
My weaker areas are :
(i) managing complex programs. I can take things quite complex, but there suddenly comes a point at which I can't hold the whole thing in my mind. If a program is too big and complex for me to see in my mind as a whole, then I will struggle to relate to it, and struggle to do anymore to it. Thinking in terms of procedures and breaking code down into small standalone chunks is not a natural skill for me, which I expect comes from the imperative/non-procedural programming that I started with.
(ii) minutiae of language. With C++ especially, there are lots of examples online posing teasers like "why does this line of code output this value?" and it'll be something really counterintuitive that relates to precisely how the code is executed , or some obscure situation in which pointers don't work, or something. I have no time for that stuff.
I am completely self taught at programming, and it was only 3-4 years ago when I got internet access that I was able to share this pastime with others for the first time.
But I was surprised how often I was able to answer people's programming questions online... even those who I felt were stronger at programming than myself. Mathematical things is where most seem to get stuck.
My approach to mathematics has generally been shaped by thoughts like "how can I compute this on a machine", while my approach to programming tends to evoke thoughts like "what theorems relate to this bit of program, and do I really understand why it does what it does?"
My weaker areas are :
(i) managing complex programs. I can take things quite complex, but there suddenly comes a point at which I can't hold the whole thing in my mind. If a program is too big and complex for me to see in my mind as a whole, then I will struggle to relate to it, and struggle to do anymore to it. Thinking in terms of procedures and breaking code down into small standalone chunks is not a natural skill for me, which I expect comes from the imperative/non-procedural programming that I started with.
(ii) minutiae of language. With C++ especially, there are lots of examples online posing teasers like "why does this line of code output this value?" and it'll be something really counterintuitive that relates to precisely how the code is executed , or some obscure situation in which pointers don't work, or something. I have no time for that stuff.
Last edited:
Programming is just problem-solving. If you can take a problem, break it down into steps, and devise a process for solving it, you've already done most of the work and the code is just a formality.
I've found that people who only know how to code in one language start to approach all their problems through the lens of that language's limitations and conventions. It makes it very, very hard to solve problems the language isn't suited to, and difficult to learn other languages at all because you lack the theoretical background to reduce a problem to that level of abstraction.
To point (ii), I hate questions like that. While it pays to know the "gotchas" of any language you're working with, not knowing them doesn't make you a bad programmer. It's not the programmer's fault that a language does something non-intuitive or outright brain-damaged. Ideally, you just fix the code to work the way you want and put a comment next to it, indicating why you had to write such a workaround in the first place.
I've found that people who only know how to code in one language start to approach all their problems through the lens of that language's limitations and conventions. It makes it very, very hard to solve problems the language isn't suited to, and difficult to learn other languages at all because you lack the theoretical background to reduce a problem to that level of abstraction.
To point (ii), I hate questions like that. While it pays to know the "gotchas" of any language you're working with, not knowing them doesn't make you a bad programmer. It's not the programmer's fault that a language does something non-intuitive or outright brain-damaged. Ideally, you just fix the code to work the way you want and put a comment next to it, indicating why you had to write such a workaround in the first place.
Similar threads
