PSvils

Member
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

184 Neutral

About PSvils

  • Rank
    Member

Personal Information

  • Interests
    Art
    Audio
    Design
    Programming
  1. It's the exact same, so you'd have to give more details as to your specific case. If you work with pathfinding, using nodes is always the general case, a grid is a possible optimization / specific case which can improve parts of the algorithm using assumptions about the structure. Try to outline which parts you're having trouble with, all concepts should have a 1 : 1 mapping between grids and nodes.
  2. Especially since you were using Flash, I think Haxe will be above and beyond what you could find anywhere else: http://haxe.org/ http://www.openfl.org/ http://kha.tech/ http://armory3d.org/ The first link is the actual Haxe language website. It can natively target Flash .swf's, otherwise it can target many languages. The next 3 links are development frameworks based on the Haxe tech stack. OpenFL emulates much of the ActionScript 3 API, but important to note, it compiles native applications for desktops, mobiles, consoles, etc. Kha is similar to OpenFL functionality-wise - it's a framework that also allows exporting projects to WebGL, desktops, mobiles, consoles etc., but with its own API, which in my opinion is more intuitive and closer to libraries people coming from C++ gamedev would be used to. Armory3d is a 3d engine based on Kha for rendering. It has full Blender3d integration, so you can build your world and visually script from Blender3d, and immediately export to all the platforms that Kha supports. All in all, I've been using Haxe for years, only recently switching to raw C++, originally for Flash development, but later on for native desktop and mobile apps, and from my experience, for game dev, it really Just Works™. By now many issues have been smoothed out, and the same game can be easily exported to all targets. (Literally by selecting the platform from a dropdown menu - mind you, there is no VM, these are truly native applications)
  3. Boids, a way not to check flock every update?

    I'm simply talking about optimizing array comparison between elements, outside of any context. Think about it, if you have an array with length N, you only need to do !N comparisons, instead of N^N. [1, 2, 3] You have 2 loops, the first goes through each element, and an inner loop, which will compare this element with the other ones. If you start the inner loop at index 0 every time (as you are currently doing), you are comparing every single element twice instead of once. By visiting the first element in the outer loop, you will have compared that element to all other elements, which means when visiting the second element, the inner loop only needs to start with the third element, because comparing elements 1 and 2 already happened when visiting the first element. I just thought I should explain this because either you're not understanding it, or I don't understand the current code / logic you have happening. The example function I wrote WILL visit and compare all elements, except only once instead of many times.
  4. Boids, a way not to check flock every update?

    Not sure what you mean by loop unrolling. You're currently unnecessarily processing boid interactions twice, when you could visit each pair only once: void Seperation (float MaxDistance){ int TempInt = 0; //HiveMind is the parent of all the zombies while (TempInt < HiveMind.transform.childCount) {//So this will run once each child int SubCount = TempInt + 1; while (SubCount < HiveMind.transform.childCount){//The problem is now I need to run every zombie again to check there distance float Distance = GetDistanceOf(HiveMind.transform.getChild(TempInt),HiveMind.transform.getChild(SubCount)); if (Distance < MaxDistance){ AvoidFlockMember(HiveMind.transform.getChild(SubCount));//This moves away from the flock member. AvoidFlockMember(HiveMind.transform.getChild(TempInt));//This moves away from the flock member. } SubCount +=1; } TempInt +=1; } } But maybe I'm assuming incorrectly about how your code works outside of this function (for example how the AvoidFlockMember function works)
  5. Boids, a way not to check flock every update?

    FYI, you're inner while loop is infinite, I assume it should be: while (SubCount < HiveMind.transform.childCount){ And you should be reseting SubCount to 0 every loop. This will get you N^2 loops and distance calculations. An easy optimization is don't reset SubCount to 0, but set it to TempInt + 1, and then process 2 boids at the same time: AvoidFlockMember(HiveMind.transform.getChild(SubCount));//This moves away from the flock member. AvoidFlockMember(HiveMind.transform.getChild(TempInt));//This moves away from the flock member.
  6. BTW - Why is ObstacleManager a pointer in the PlayState? Make it a member variable and you don't have to worry about memory leaking.
  7. I think the main advantage of legs is also obstacle traversal, except with even better results. Flat or rough terrain don't make a difference / no penalties. Also with "gripped" legs you could have full-on climbing capabilities. Otherwise yes, they're fragile. Depends if you're thinking heavy mech type of legs, or more agile spider type of legs. Another possible advantage is that the load it can carry shouldn't affect it too much. Think of a robot with 8 legs, moving 2 at a time, while the load rests on the other 6. Only part of movement that would be affected by the load would be moving the body over to the 2 legs that just advanced, which could probably be less than wheeled vehicles, that constantly need to move under the weight.
  8. I like your last idea, by giving hints or pointers to real world objects instead of a direct path to the treasure. This makes it much more rewarding, and like a real task, otherwise traveling to the treasure and picking it up might just feel like an unnecessary hassle. But I suggest watching this video for a good analysis of a similar topic:
  9. These names do nothing to express the mechanics of each gun, or say anything about the attributes that actually make them awesome. With this question - what kind of feedback are you expecting / looking for? It would be more useful to ask a specific question, outlining more details on what it is you have, and need feedback on.
  10. Here are some real time audio frameworks that might be of interest to you: https://github.com/thestk/rtaudio http://www.portaudio.com/ And a synthesis library I just found: http://maximilian.strangeloop.co.uk/ I've given RTAudio a test run, and they have an example that sets up a audio stream callback, and generates a saw wave. This sounds like something you're looking for, and it's very straight forward to setup. Also is crossplatform.
  11. Game Engine Questions (ECS)

    "The system_manager object gets passed to onInitialize, onActivate, onDeactivate, and onDispose"   :) So yes, systems get references to the system manager.
  12. Game Engine Questions (ECS)

    By what is needed, I meant it passes a list of class references to its super constructor.   The system manager uses this list when you add the system to the manager, and checks to see if all systems in the list already exist in the system manager. If yes, it activates the system, if not, it doesn't. It rescans this every time you add/remove a system to the manager.   The system itself can only access the other systems through the system manager.   Systems being dependent on each other can happen for different reasons. A bad reason (one which I use though) is performance. Sometimes direct access to system specific data is faster, and easier. An example would be a PhysicsSystem and a BulletSystem. The BulletSystem would require the PhysicsSystem, and get a reference to it when activated. That way, it can directly do raycasts on the physics space within the PhysicsSystem, as opposed to somehow raycasting through creating entities and components etc.   It's both faster, and probably more understandable / debuggable.
  13. Unity Help Deciding On New Language

    Not sure if this topic is still relevant, but I'll just toss this here:   http://haxe.org/ using the framework http://kha.tech/   In short - Haxe is a language very similar to Flash's Actionscript and Java in syntax. It compiles to other languages though, including C++, Javascript, C#, Java, Python, PHP etc.   For game development, this is handy. The Kha framework (and other ones in the language's ecosystem) compiles the source code to Javascript for HTML5/WebGL, or C++ for all desktop and mobile platforms. Currently, this means 1 codebase gives you all these targets, and they run in a native way - the only overhead is an implemented garbage collector for the C++ target, but this is less than a VM.   It also does some cool stuff that transforms your shaders written in GLSL, to target specific shaders. Basically, for many parts of the development process, you truly write once, deploy everywhere.   I think it's definitely worth a look, I use it for my own projects!   P.
  14. Game Engine Questions (ECS)

    I've explored the ECS route for a while now, but haven't yet completed anything substantial - just a tip, my main bottleneck was trying to structure really low-level concepts within the ECS, I even tried to have VertexBufferComponents at one point, that was a dark period in my life. I now aim to have an engine running without the ECS, and the ECS is a high level layer over the concepts in the game engine. Now I have a SpriteComponent and either ImageComponent/ColorComponent, which is still relatively low-level, but works for now, trying to minimize that further.   1. I think the most important concept to understand in ECS, is that an Entity isn't an object itself, conceptually. It's main purpose is to just be an ID that ties groups of components together. How this expresses itself in my design, is that much like the systems/entities concept, which is the main/popular attraction of ECS for most people, the same inversion of control applies to entities and components. I have a ComponentManager that has arrays of all component types (I use the class name itself, via reflection (not C++, but this still applies)), and each of those arrays are sparse arrays, where the component for an entity can be accessed via the entity id. The result is a 2d arrays, though I have a specific manager for each component type as well. In the simplest form, component access is: `var componentA = types[componentA_ID][entity_ID];` where componentA_ID is the id assigned to the ComponentA type, and entity_ID is self explanatory.   At this point, entities are purely integers, which is the case in my engine. They aren't objects. I have a helper class that wraps an entity id, and gives convenient component setters, but this is just an optional utility. I don't think "an entity OWNS components", but "there are components, and they are assigned to the same ID". Maybe that can be phrased better.   This way you have more control over component storage, rather than them being tossed around in Entity instances. Also, this gives you a centralized entry point into your components. In my system, View objects "attach" to the component containers directly, which ever ones they need: `var view = new View<ComponentA, ComponentB>();` That view would go to the component manager, and get references to the containers responsible for the ComponentA and ComponentB types. Whenever a ComponentA or ComponentB is set on an entity, the view is notified of the change, and it checks the entity if it's valid (in this case, if it has both ComponentA and B assigned to it). This way, setting ComponentC on an entity has no effect on the view, it doesn't care.This combined with keeping a bitflag for each entity of what components it has, means any changes to entities get propogated immediately to views, and only ones that care, for minimal cost.   To sum up my gibberish, component access is direct, no looping or anything, via the component_type_ID and entity_ID. (entity == entity_ID in my case). Views selectively subscribe only to relevant component change events to keep a list of valid entities. (so, also no looping through entities at runtime to get the relevant ones)   2. Sort of relevant to the above, the concept of ECS for me is really just EC, and the S is an optional helper for structuring functionality. Technically, systems don't need to be actual objects, they just refer to pieces of logic that process entities (you could have an ECS-based game written totally in your main function, but that would be messy).   Anywho, I do have a system API to keep track of things. They extend a base class, and have 5 callbacks: onInitialize, onActivate, onUpdate, onDeactivate, onDispose The system_manager object gets passed to onInitialize, onActivate, onDeactivate, and onDispose, and the delta_time gets passed to onUpdate. The initialize/activate things are sort of specific, but initialize gets called when the system is added to the system_manager, and activate gets called when the system will actually start running. This is important, because my system_manager handles system dependencies - when declaring your system, you call the super constructor, passing in a list of system classes it requires. When the system_manager has all required systems added to it, then it will call the activate callback, at which point your system can get references to the required systems through the system_manager...did that make sense?   Generally my systems have a bunch of the above View objects, and they get initialized in the onInitialize callback, so I don't need direct references to the entity_manager (which is accessible through the system_manager). (BTW - the entity_manager holds a reference to the component_manager, so essentially: system_manager->entity_manager->component_manager)   This way, the system purely cares about itself, codewise/internally, but gets the references to the outside world and other systems through the system_manager, passed to the init/activate callbacks. If a system doesn't need the references during its update callback, then it doesn't even store a reference.   Not sure about your 3rd question, I haven't personally used octtrees in-depth.   I hope my splurge helps you...it's basically a raw braindump. I am by no means an expert, but I've gotten to this structure over several iterations of trying to make something with an ECS - the direct system to system communication was a big one, earlier I tried to do a pure hardcore approach where ALL inter-system communication should happen via components.   P.
  15. If you really want to have a dynamic system where you could cook up a few basic behaviours, but have the player combine them etc., I'd suggest using some sort of a component system. You could attach the RainComponent to the spell, and a FireComponent, and the RainSystem would create more entities with a copy of the FireComponent, and then you process that onwards.   That would be in the case of you using an Entity System all throughout, but simply maintaining a list of Components for each spell, and having the behaviour defined in components should be an easy and natural way to stack different behaviours. (They seem to split nicely, you have components affecting the way the spell is generated (ball/rain/etc.), then you have components affecting how the generated thing moves (could have a VelocityComponent with x/y/rotation and accelerations for each), and then the type or some other sort of modifiers (PoisonComponent/FireComponent etc.)) Graphics and particle effects can also be generated from the set of components.   P.