NEXUSKill

Member
  • Content count

    216
  • Joined

  • Last visited

Community Reputation

475 Neutral

About NEXUSKill

  • Rank
    Member

Personal Information

  • Interests
    Design
    Education
    Production
    Programming
    QA
  1. There is common misconception in the relationship between object orientation (OO) and entity component model (EC / ECS), the first is a language paradigm, its embedded in the programming language used and provides a thinking frame and a set of tools to work with, the latter is a design patter built WITH object orientation, EC IS object oriented. The problem EC tries to solve, problematic deep inheritance hierarchies is a misuse of object orientation, most people are taught quite emphatically that object orientation means structuring your implementation around concrete objects and using inheritance to specialize more and more those objects and mold how they behave. This is a gross misrepresentation of what object orientation is, Inheritance is far from being the only tool in the shed of OO, Composition being another very important piece of the puzzle, and there are more, EC enforces heavy use of composition to discourage and reduce Inheritance abuse, truth is in most cases you should be using both quite a lot. Deep inheritance is only the problem EC solves for the user of the engine, for the developer of the engine its solving an entirely different problem which is unforeseeable requirements, while there are parts of an engine that are extensively and thoroughly studied and "solved" like resource management, rendering, collision detection and so on, the more versatile you want your engine to be the more wild the possible requirements get, these requirements, what we call the Game Specific Logic, must be implemented by the user of the engine, one way of doing this is by giving the user a scripting language, which is a very powerful tool, but without an enforced structure script code bases tend to get unwieldy quite fast, enter -> EC, its a way to give the user a structure in which to organize his game logic that implicitly forces the user to do his scripting better, if you think an EC project got unwieldy, try to imagine how it would be with plain scripting. In my experience these misconceptions come from two sources, one is language, the very name of the paradigm, Object orientation, perhaps a better name would be Concept Orientation? I'm not sure, but by language we are instinctively driven to associate Object with concrete entity like things. Another part of the problem is the way this is taught, the first thing most programmers are told is the cat hierarchy example (or some variant of it), i.e. the cat is an animal, has four legs and does both cat specific things and animal generic things. On the surface examples like this, or the car, are good ways of illustrating the concepts of specialization, composition, aggregation, and so on, the problem is most people stick to that example like a rosetta stone and take it quite literally, missing the point completely. The example goes to the approach of implementing a cat, when the cat is your whole problem, but you are NEVER implementing a cat, you are implementing a game, the cat is (if the game has one) only a character within the game, more often than not he is functionally indistinguishable from other characters like dogs, a crocodile or depending on the complexity of the game even a car, before you start putting names to the "objects" in your game you need to understand the level of complexity (and therefore the abstraction) your game requires. If all these characters are so simply simulated that they all move around identically and are basically just animated sprites roaming the screen, you don't have a cat object, the cat is content, you have a free roaming agent, and it can implement all your characters with the same code. The most important point of object orientation is abstraction, the ability of dividing and stratifying an extremely complex logic implementation of varying kinds into different levels and modules of abstraction to reduce the complexity of the problem to make it easier for people to understand and solve it. Failing to grasp this important concept is exactly how both inheritance and composition both get wildly out of control.
  2. The template paradox

    Yes, this is the case, this class is meant to be inherited by other classes that need to be serialized and they must set themselves as the template parameter. Though it is true that this class declaration by itself does not force its data to inherit from it, it could be the same class with the same type, but that would be pretty pointless in my project. It goes just as unbird said.
  3. The template paradox

    Oh god I laughed so hard when I read the pattern name! xD
  4. The template paradox

    each class implements its own specialized serialization, they inherit many common methods from this class and any loaded resources are held in a static hash implemented in the base serialization class.
  5. The template paradox

    I just wrote this, it works perfectly, but I don't know what to make of it in terms of what the concept means...   public class SerializedData<DataType> where DataType: SerializedData<DataType>   This is a template class in which its template type must be derivate of the same clase with the same template type.... sounds terribly weird
  6. spriteBatch.Draw slow?

    Then I'd go with phil_t's explaination, spritebatch is not meant for point sprite particle systems, there are samples in xna's resources webpage that implement point sprites, particle sistems both in 2d and 3d, look it up.
  7. spriteBatch.Draw slow?

    Could you post your test update and draw methods? I've seen severe errors in implementation born out of bad examples, first clue would be if you are executing the End method for every particle, that would be VERY bad, there are other common errors though. EDIT: Also no, SpriteBatch is not a shader, it does HAVE a shader, which you can have access to through the XNA resources, you'll find it under sprite batch default shader or something like that, what srpite batch is, is a batchnig and sorting abstaction algorithm, so you don't have to deal with those things yourself, which works wonderfully until you WANT to deal with those things yourself.   It takes away the tedious task of figuring out what is in front of what and if used correctly it optimizes instructions to the graphics card.
  8. Auto update systems - yes or no

    Well there are a few factors to take into account, mainly the nature of the software and the target audience/consummer. If the consumer is likely to be tech savy, they'll want to be given a certain degree of control, if not, they'll likely expect you to do everything for them.   Personally I hate resident processes, such as the google updater or the adobe auto updater, I hate a program being there running consuming my computer's resources while I'm not even thinking about their software, adobe reader is probably the worst example of this, you open it what, once every coule of months? meanwhile adobe has a resident software active on your computer full time, why? why does that need to be there? Steam on the other hand, can be set so it doesn't start at bootup and will only update when you start the program.   Thats another issue for me, unless the update is absolutely required for the software to function, when I open the program I want to use it, making me wait for an update is an inconvenience, if the update is optional, I would prefer to delay it to when I close the application and no longer care about it. Thats the way I handle windows updates, I apply them once I decide to shutdown the computer, not when I want to use it. Taking the user to a website is pretty old school and annoying, its not even necessary, you can trigger the update download and instalation without going anywhere, do that.
  9. Against most of wat was said above (probably, for what I can gather since I didn't read it all), none at all. In my experience, in order to do things right, you must first do them wrong, at least one time. The first thing a GAME programmer should do (this most likely does not apply to other more structured programming tasks) is to make a working prototype. On one hand the designers need to have a working prototype to test their ideas as soon as possible, they may not want it, they may not ask for it, they may even refuse to use it after you made it, but you should do it just the same. Why? because before you can design anything thoroughly, you must understand its deepest inner workings, and you can't just sit and think for hours until you got it all in your head, make drawings and write and re-write designs until its just perfect. You are gonna forget something. And even if you do get a clear design that looks good on paper, you still don't have any empirical evidence to support your theories and most likely at some point someone is going to want you to change it, maybe even yourself.   So make prototypes, the best way to understand everything involved in the inner workings of a system is to implement said system. Once you got it working, make note of its flaws, its dependancies, profile it, and then go to the design process with all that knowledge that no amount of thinking can magically conjure up.   If you are asked to implement an input reading system and you have done so before, design might come easy to you, but then they tell you "it has to work on touch screens", and you never done that before, go do it, understand its needs before trying to apply your known designs to it, once its working you'll know if it fits your designs or you need to adapt them and how. If you've implemented Character control many times before, but you are asked to do so in Unity, which you never used, go make it work first. Go for quick and dirty and just get it working, you'll have something to show for and you'll be able to make better estimations when asked to. I've banged my head against the wall trying to come up with designs that foresee any need of a system many times before, I've always understood it much better after making it work.
  10. Levels are not game states, levels are content of a game state, specifically, gameplay, Game states are used to sepparate contexts of your application that have radically different logics, a menu is very different than gameplay, and maybe you have other states, like a world map and a battle stage, the logic in each of them is very different to the others and there is a connection between them, look up state machines. Between different levels, the logic of the gameplay itself is likely to be more or less the same.   As for levels, if your game is linear you could have a simple array, if the array is too big it might be more clear and efficient to hold a link to the next level within the current level itself, maybe in the exit, so if you have multiple exits you can use a different link in each one. As for the transition from one level to the next, you just initialize the Gameplay state with a new level as content, maybe put in a loading screen if it takes a while.
  11. A* is as fast as it comes, but huge maps are huge maps and simply exploring them with A* will inevitably at some point become too expensive. If the map is enclosed, like a city or the inside of a building, there is a lot you can do to simplyfy A*'s workload, the map is not likely to change and going from A to B will always require the same path. When you edit and save the map, you can precalculate paths between key points and store it along with the map data, so when someone wants to go from A to B it simply loads the saved path.   On an open map, there should always be choke points, natural barriers that split the map in zones, like a bridge over a river, a slope that climbs a cliff sided mountain, stuff like that, the path to cross an entire area from one chokepoint to another will always be more or less the same, and can be precalculated, you then use A* for more short range adaptations.
  12. Calculating arrival with soft turn (help!)

    I'm thinking of putting together an article for flocking and steering behaviors, the working code I have now I cannot share due to contractual obligations but I can make something on the outside and get a working demo of the technique.
  13. Calculating arrival with soft turn (help!)

    The target ghost worked quite well, its not perfect and its subject to a fine tuning of the kinematic parameters of the mobiles, but gives out a nice effect for what I wanted, A more precise method would probably exist but I don't need to dig deeper at this moment. For reference, the idea is to create a ghost mobile starting on the target position and orientation and having it move backwards based on the same logic used to move forwad with some reversed signs and considerations, the positive and negative boids are aligned you can move on to follow the target directly and arrival should do the rest quite nicely.
  14. Calculating arrival with soft turn (help!)

    I already have arrive implemented, and the mobiles do arrive and slow down at target, the problem is when you want them to end up looking with a specific direction and you don't want them to reorientate after arriving, but rather come softly from behind the desired heading.   I'm already using steering behaviors for this.   The target ghost boid as I've come to call it seems a promising approach, though it still needs tweaking.