Jump to content
  • Advertisement

Anselmo Fresquez

Member
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

85 Neutral

About Anselmo Fresquez

  • Rank
    Member
  1.   So do explain... who determines who is and is not qualified to "speak on things"?    Because I'm really, really curious here... what are all of your qualifications? Let's not just go based on presumptions and throw our weight around like pompous asses, let's talk brass tacks and actual qualifications.   Where are your games?   Because obviously as someone who is not only the only qualified person to even speak about these things, but also qualified to determine who is and isn't "allowed to speak" you must undoubtedly be a hugely successful indie developer. I only say this because I know lots of other people who are apparently not "qualified to speak" either who actually are successful indie game developers. And they don't go around touting their own self-importance on a stick. They're humble, down-to-earth people, generally interesting to have a conversation with and they for sure wouldn't sit around anonymously sandbagging other people for offering their thoughts. If they were going to disagree with somebody, it would be open because the people I hang out with have enough guts to show their faces.   So yeah, I don't really care about this place. I haven't seen anything that would make me want to join this community and post regularly. It seems like a bunch of guys with antiquated notions of game development, stuck with a laserlike focus on efficiency when efficiency stopped mattering ten years ago, when computer's started shipping with GB of ram STANDARD, today we can focus on making good games and improving our workflows and productivity and people with even a moderately good grasp of programming can (AND DO) make games that do make money, right now, in this market.    So no, I reject your premise that only certain people are "allowed to speak" on matters.   Not that I'm expecting any kind of actual response from a community where the longest post I've read so far is one explaining how your Machiavellian reputation system is actually a good thing, you know, as long as you're the one doing the down voting.   And that's what I have to say about that. If you have anything to say, I'd love to hear it.
  2.   Unnecessarily large class hierarchies are bad for sure, but not for the reasons you cite. Whether your hierarchy is 2 or 20 levels deep has no particular impact -- it makes vtables bigger, presumably, but those aren't stored per-instace so it doesn't make your game objects any bigger or less cache-friendly. In general, any kind of indirection, itself, implies a high likelihood of cache unfriendliness so there can be an impact there, and a system that relies on virtual dispatch does opt-in to that penalty, its true. Still, virtual dispatch is sometimes exactly what you need, and you're unlikely to implement a faster general-purpose solution.   The bigger problem with large (specifically deep) class hierarchies is that they're difficult to maintain, extend, refactor, and even reason about, thus they become a fairly rigid part of the whole once they get entrenched. Specifically, the troublesome anti-pattern is the propensity of people who don't really understand OOP or good practices (often people coming from a dogmatic Java-esque background) to reach for inheritance as the only solution for solving the "but something is different" problem. Inheritance should be used appropriately to model the actual relationships between objects;, to use inheritance simply because it conveniently provides for what should be an implementation detail is usually not the right approach (or at least, if it is, then it should probably be encapsulated in a separate hierarchy.that contains that single responsibility, rather than into the original class.)       Its generally good form to respond and correct someone if you feed the need to vote them down, but sometimes this has already been done. There are certain people who's attitude or way of behaving is a lightning-rod for down-votes, and sometimes they're unfairly persecuted but in general the system works remarkably well if you're trying to get along and don't try to speak on things you aren't qualified to. It costs those doing the rating a point of their own to cast a downvote, and they gain a point for casting an up-vote, so those being downvoted have usually earned it -- of course, everyone has different criteria on which they judge whether someone is (un)helpful. One clear, however, is that the quickest way to continue being downvoted is to complain about being downvoted -- if you're genuinely concerned about being unfairly persecuted regularly, speaking to a mod is probably the best course of action, rather than complaining about it, especially complaining about it in the thread where you've been downvoted.     I don't think I'm being persecuted, I just think that anonymously sandbagging somebody while offering zero reason why is pointless. Especially if you then offer absolutely nothing to further the discussion yourself. Also, your system having upvotes to vote others down is fundamentally flawed to its core. That means those who become popular can destroy anybody who they decide is wrong. You've basically engineered the world's most perfect clique system and instead of leaving it to the gray area of human nature to decide who is and isn't considered cool, you've modeled high school and encoded it into your web forum.   I actually find it disgusting, and I won't be returning.
  3. Sorry, but nope. That doesn't work. The best and most frequent solution is what was already suggested by BeerNuts and others. Add a spatial system, often a loose quadtree or BSP tree for 2D games, and query for the few neighbors. Usually this will find zero things to collide against. If there are any neighbors, often there is a broad pass and narrow pass. The first pass requires very little processing, often a bounding box, bounding cube, bounding sphere, bounding slabs, or similar. This will typically eliminate neighbors. If there is still a neighbor you can do a detailed, compute expensive pass against a model mesh or against an image or some other high detail comparison. A static list of all movable objects and testing all movement against all other movers quickly reaches O(n2) levels.     Listeners are useful to notify objects after the collision event has occurred so you can have a collision response, but they are not part of collision detection.   It seems you are conflating instances with types. Having a large class hierarchy, a large number of types, inherently has almost zero impact on the system. Following poor implementation patterns with instances, such has having a large number of free-floating objects, poor cache utilization, and poor memory management practices, these will destroy performance. When you described your large number of bullets, the issues you described can happen when you do those things poorly. A large number of persistent flighweight objects inside a cache-friendly collection can be extremely efficient. It is fairly common for games to support large pools of these; a pool of a hundred thousand particles is not unreasonable on a modern game. It is not because of inherent problems with the concept, but due to problems of the implementation details.     Yes, I am referring to instances... instances of classes. I see that semantics are very, very important here.   I was using the same class system for the bullets as all the other game objects. It's still surprisingly efficient, despite the fact that I made no efforts to optimize it whatsoever. It was sort of an experiment, to see what I could get away with being lazy. I have a nearly complete game now where the bullets have hooks for things like events, playing sound effects, they have collections of events they can trigger, etc. It's really badly planned.   But... I hate to break it to you, it does work.    So, I'm not sure what you're trying to say with: Sorry, but nope. That doesn't work.    Because it does work... and much more inefficient things also work.   Sorry to call you out, but I just don't understand your point.
  4. Anselmo Fresquez

    What game engine should I use?

      No, probably not. Iso is 2D "faking" 3D through the use of a tilted, offset-based tile grid system. 3D is actually 3D, so the majority of your troubles are already solved. You could have a working prototype in Unity in no time, you wouldn't have to deal with faking the lighting, faking the collision, faking the depth and all of the other things you're going to have to figure out that haven't really been done since the late 90's, early 2000's. I would imagine you'll be reading lots of old books and old websites to build a decent iso engine in 2015.
  5. Well if you really want to limit your number of collision checks, you would make it so that when an object moves (and only when it moves) it adds a reference to itself to a static collection and only the objects in the static collection would be checked for collisions, either that or boolean flags, then of course each frame the collection is released/flags are reset. You could also make it so that objects would be deactivated when they're not within the plausible range of a player's bullets, grenades, etc, for example they could sleep and if they're sleeping, all they really do is wait until they're in range to wake back up. This range could be just beyond the visible area so that the player is none the wiser. Objects that are supposed to maintain any level of persistence could play "catch up" just as the player re-enters the range, if you felt like it.   There's a lot of stuff you can do that is simple and effective.   Also, large class hierarchies are not necessarily the best way to go. You end up with unnecessary overhead, especially when an object only uses a tiny subset of its inherited functionality. I experienced this myself recently and won't be repeating that mistake in the future. I was able to fill the screen with hundreds of bullets, after my class hierarchies I was only able to get up to a couple dozen, max. So yes, do not underestimate the overhead of large nested object trees. You will hit the wall eventually and it will suck, the wall being the exact moment that your framerate starts to drop.   At this point, everything going forward with me will be based on a component architecture, highly minimal, utilizing events and listeners, interfaces, etc. Never again with the heavy class system and keeping track of every object every cycle.
  6. So what kind of hardware are you targeting, circa 1997 Dell PC's? Why do you even need to think about optimization with such a small game?   First off, the best way to construct your stage is to go fully modular. Everything is a module, everything has collision data separated from image data. Then you create your own tile/offset based editor (doesn't matter, your preference) and then store each object added to the stage based on its tile position or its offset from the stage origin. When the stage is created, you populate it with the objects and position them correctly and voila, you have your stage stored.    You've separated the model of your stage layout from the presentation and control.
  7. Anselmo Fresquez

    Dynamic Circle - Static Circle Collision

    So am I the only one who doesn't understand the original poster's question?
  8. Anselmo Fresquez

    Explain: Finite State Machines

    So you know what "infinite" is, right?    Infinite means "no limit". (In = not, finite = limited)    So, finite means limited.   So a limited state machine is a machine that has a limited number of states... easy right?   For example, a light switch has 2 states. "On" and "Off".  Therefore,  a light switch is a finite state machine.   How that applies to games is say in a fighting game, you have "punching", "kicking" and "throwing fireball". If you're doing one, you can't be doing the other... and that's how we arrive at our "states".   Does that make sense? Do you have any further questions?
  9. Anselmo Fresquez

    Unity Unity or C++?

    It depends on what you're trying to do.   If you are really interested in developing games, then using Unity is a no brainer, half the work is done, your scripts become reusable between games, your workflow becomes compatible with millions of other developers, etc.    If you just like programming, the more the better, then go with C/C++.   Although, most people I have met tend to value shorter dev times, higher portability and better quality in the end product.   As far as being concerned with how much work it does for you, I would love clarification on why that's an issue.
  10. Anselmo Fresquez

    Inventory management mechanics

    Weight limits are an arbitrary mechanic based on limited memory resources/limited GUI capabilities in certain kinds of games. If you have no memory or GUI issues, don't limit the character's storage capacity. Never do something because other games do it, only do what has a good reason.
  11. Anselmo Fresquez

    Why platform games now focus on unlimited lives?

    Lives were created so that coin-op arcade ports would make sense on the home console. They're a pretty arbitrary device, antiquated by today's standards. 
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!