• Content count

  • Joined

  • Last visited

  • Days Won


ApochPiQ last won the day on November 9

ApochPiQ had the most liked content!

Community Reputation

23107 Excellent


About ApochPiQ

  • Rank
    Moderator - General Programming

Personal Information


  • Twitter
  • Github
  1. Tactical Pathfinding - Unity3D

    Most implementations of tactical pathing use custom A* code and some kind of annotated navmesh. Your approach might technically "work" but it's gonna perform terribly and certainly won't scale to many pathing agents.
  2. I'm going to try and limit the snark a bit here, but believe me, it's hard. Matthias, what you're doing is basically reading us one page at a time of a mystery novel, and then asking us who the killer is. Except it isn't even consecutive pages, or even chronological pages. Just rip a sheet of paper out of the book at total random, read it aloud, and then see who gets the correct killer. And you've read us only two pages so far. We don't even know the title of the book or who the characters are. We can't help you find the killer.
  3. You don't, because that's horrid design and asking for a spaghetti mess at the end. Tell your nodes to process themselves, and they can handle any components/children as appropriate. Your main processing can be one line of code: tell the root node to process. This "process" might be Tick(), or NetworkSync(), or Render(), or any number of other operations.
  4. C++ Recursion Quick Sort

    Try walking through a visualization (like https://visualgo.net/en/sorting - click QUI on the top bar to switch to QuickSort).
  5. Every now and then I will click around on GDNet and suddenly get a full page takeover ad like this: http://d2xdw0i3rxujy9.cloudfront.net/creative/c/4/?rdm=822604&m=1510441410&l=82260415104414047471510441404749473ABAjH0jrV-ZBD07CvShQ6iz9re9Z&platform=android&clickid=15104414047471510441404749473ABAjH0jrV-ZBD07CvShQ6iz9re9Z&adx=1&pubid=1333143972&ctype=3# I'm not part of the hardcore "all ads are evil" crowd, but a full page ad that disables the back button is some seriously unpleasant stuff. Only ever happens on GDNet for what that's worth.
  6. Templates are a powerful tool but probably not the right one for this job. Accepting a buffer and size is the right thing for the API to do unless the API can stipulate the usage of std::string or whatever. But your main point is spot on - mixing the responsibility for allocation and deallocation across API boundaries is bad juju.
  7. Java How to design this game weapon?

    Clear the flag just before collision detection runs for the frame. Or do it after the flag is checked and you decide not to move the enemy for a frame. The specifics depend on your code and game design, but either way, it's literally two or three lines of code different. If it turns out to be a problem, you won't have wasted any serious time on it, so you shouldn't feel bad ripping it back out. Trying to anticipate issues is good, but you need to realize that until you make a critical mass of mistakes as a programmer, your ability to anticipate is limited. Don't get hung up on perfection.
  8. Java How to design this game weapon?

    I would simply have your collision detection logic call a special method on Enemy when someone is contacting a barrier. That method can be as simple and hard coded as "set a flag so that the Enemy stops moving." Or you can get a bit more general and set the max speed of the enemy to zero; this enables other features like tar that merely slows down enemies instead of stopping them entirely. If you want, you can even do a full blown status effect system with immobilization, damage over time, friend/foe inversion, etc. But ultimately, don't be shy about adding a special code path for certain flavors of collision. As you get more and more cases, keep an eye out for ways you could generalize the design. If your game has exactly one special collision type, though... Hell with it, just put in the single special case :-)
  9. My personal preference is to forward declare only what I need to use, and then promote to a full dependency as infrequently as possible. So if you need to use another type, forward declare when you can, but don't just throw around declarations for the fun of it.
  10. There is no architecture, code pattern, design trick, compiler setting, or any other flavor of magic that can deter a serious reverse engineering attempt. You run the risk of making it more fun for the attacker if you get overly clever; they'll just be that much happier to defeat your protections. If I were you I would think the opposite direction. Instead of trying to hamper efforts at using your code, go for broke. Publish the code (not the assets!) for free. Encourage modding and user scripting. Encourage people to break the game in entertaining ways. A popular YouTube video of your game glitching in a funny manner is worth quite a bit in terms of exposure and awareness. I know a lot of people will say this is defeatist or whatever. But it isn't. Trying to lick a bonfire to death is a bad idea; nobody says it's defeatist to reach for a different approach. Choosing your battles is a vital skill. Think of it like judo - redirect the energy of "security" into making a great game that people love. Yes, there's still a risk you will get burned. That is always true of any creative effort.
  11. I'ma just leave this here: https://godbolt.org Also, your code has a lot of improvement to be made. Your API for GetProcessorName() is bad. Please don't ever write a function like that. You should either return a string object or fill a string buffer, but not both in one function. As you are discovering this is a recipe for confusion and unhappiness. Please don't use C-strings. You have a number of issues in this code that indicate (1) you are not familiar with how C-strings work, (2) you aren't thinking carefully enough about how you manipulate C-strings, or (3) both. For example, you confuse allocation size with string length in a couple places, and your attempts to account for NULL terminators look wrong to me. The loop style invocation of __cpuid is overly complex and needlessly busy if the CPU returns a huge number of capabilities/extended IDs. You can write this simply as a single if check and 3 successive __cpuid calls with no loop.
  12. There's... Multiple things wrong with that code. Let's start with this: https://msdn.microsoft.com/en-us/library/5471dc8s.aspx And move on to this: https://en.m.wikipedia.org/wiki/Dangling_pointer Hopefully you'll see how your approach is fundamentally flawed. (As to why the optimizer scrambles your code - welcome to undefined behavior.) Design a better approach and we can get nitpicky on the rest of that snippet :-)
  13. Path Planning and Steering behaviors

    The flow should look like this, more or less: 1. Pick a place you want to go. This is higher-level AI logic and irrelevant for getting there; it could be controlled by a patrol route, a quest objective, a target you want to fight, or anything else. 2. Feed the destination into a path planning algorithm. 3. Feed the waypoints from the path plan into steering. 4. Optionally feed steering forces into physics or just apply the net resultant velocity directly (depends on the game). Note how "instructions" or "commands" flow in exactly one direction at all times, i.e. from more general to more specific. There is no cross-talk between steering and path targets, there is no mechanism by which steering can get confused with multiple objectives, and so on. Everything flows down the list and only down the list. This is a defense against convoluted designs where you need to track all kinds of redundant information about your movement so that you can reimplement the same basic goals in three different places - i.e. this is a clean and simple but extremely effective solution.
  14. Reinventing the wheel

    Nitpicking time: std::map has an ordering property by definition, which means in practice it is not a hash map but usually a red-black tree. Unordered constant-time maps are generally serviced by std::unordered_map in C++11 and up.
  15. Is Phil Fish a Jerk?

    1. This thread was ill advised from the beginning. Even the title is clearly biased and unobjective. It verges on a personal attack which is never acceptable. 2. Labelling people as "trolls" because they do not expressly agree with you is basically just as bad as offense #1. 3. Basing your opinion of someone on an edited, selective, dramatized, and utterly incomplete third party account of their words is worse than #1 and #2 put together. A number of you need to go sit quietly and think very hard about how you relate to your fellow human beings. To facilitate this: thread locked.