Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Posts posted by Ungunbu

  1. You should address the two concerns separately. First you should learn how to draw sprites and text (I assume you'll want text in your game). If you want to use OpenGL then go for it. There are many tutorials online that will help you with that. Creating a game of any kind is a different thing though. My suggestion is you keep your rendering engine abstracted away from the game logic. You can design your RPG without even knowing which library will you end up using to render sprites on screen. You can imagine having a basic IRenderer interface with methods like DrawTexture() or DrawText(). How you implement that interface won't change the design of the rest of the project in any way.

  2. You can put your sprites into an atlas with a fixed frame size. You would need to align the sprites to make the animation look correct. Once you have your atlas ready you can create a tool that crops the sprites (to shrink the atlas) but also generates a data file. The info you need to store for each sprite are the source rectangle and the anchor offset relative to one corner of the rect. When loading the atlas you will have to parse the data file to reconstruct the original positioning of each sprite. That should do it.

  3. What you say about Unity isn't true. The whole rendering process is optimized for 2D when using the relevant component (SpriteRenderer). An engine supporting 2D games doesn't just "lock" the 3D dimension, it also performs a lot of optimizations when rendering 2D objects. It certainly doesn't submit 1 draw call per sprite/quad. You could do everything with a pure 3D engine but you would need to do all the batching work by yourself.

    TL;DR; a modern 2D engine can be considered a 3D engine that performs heavy optimizations under the hood intended to improve rendering performance of 2D objects.

    Whether or not you want to have that feature in your engine is entirely up to you.

    Since you mention Unity also consider that they have a few more 2D features like sprite packing (automatic creation of sprite atlases), 2D animation support and even an upcoming integrated tile editor (which looks quite powerful)

  4. Just wanted to add:


    #3: Your pipeline can merge all the LEGO® bricks with the same material into a single mesh (and thus a single draw call).


    AFAIK Unity can do that automagically but I'm still learning the tool.


    #5: When merging meshes (#3), you can also take that chance to reduce the geometry (eliminate unnecessary triangles) which will not only improve your rendering times but also your physics. You will have better control over collision detection if you make your own little pipeline.


    Anyway this point makes #3 valid once again.

  5. Thanks @Ungunbu,
    here is the model: https://drive.google.com/file/d/0B7KJPW84c6c_cjFoRWlfOEZSTlE/view?usp=sharing
    it was initially an ldraw file and we exported to 3ds using LeoCAD
    PS: I am also working on this project 


    As expected it was a normals issue.


    To fix the model:


    1) Import the .3ds file in blender

    2) Hit 'A' to select all objects

    3) Join them by hitting 'Ctrl+J'

    4) Go to edit mode hitting 'Tab'

    5) Make sure to select all faces hitting 'A'

    6) Mesh > Normals > Recalculate Outside or 'Ctrl+N'

    7) Export it in .fbx format


    8) Normals computed this way aren't very smooth. I'm sure it can be fixed from inside Blender but I don't know how. My (very easy) solution is: when you import the .fbx in Unity search the inspector for the 'Normals' property. Change it from 'Import' to 'Calculate' and all rounded things will look smooth as in your Blender render. Don't forget to click 'Apply'.


    Here's the fixed .fbx file: download link


    Now you can import it in Unity and it will display correctly. If you are using Unity 4 remember to activate shadows on your directional light. Once again, I strongly recommend you start using Unity 5.




    I must tell you that this model is practically useless for real time applications since it has an absurdly huge number of polys.




    The above render shows some imperfections in the normals, I'm sorry but I couldn't get a better result than this one...

  6. From the look of your screenshots:


    1) You are missing shadows. From Unity you need to add a Directional Light (but you probably already have it in your scene) and then enable shadows on it from the  inspector (select the light in your scene hierarchy and look at the panel on the right for that setting). In Unity 5 new scenes starts with a Directional Light with shadows enabled.


    2) The shader looks different. It seems you are missing specular highlights (but I'm not sure about this). Investigate "materials" in Unity manual.


    3) Some parts of your geometry are messed up. As already mentioned in other posts it appears to be a culling issue. I think 3d modelling tools can fix this automatically but I'm not very experienced in 3d authoring.


    Generally speaking I strongly recommend you use Unity 5 (if you aren't already doing that) since it unlocked ALL graphics engine features for free.


    Good luck with your project!


    - ung



    If you are willing to share your model I may take a look at it.

  7. Hi to everyone,




    say I have a pre-rendered background image and I want to display 3d characters on top of it. I also have a depth map; to create it the same background is rendered again but this time the resulting texture stores depth values instead of colors. We then have 2 textures ready to use: color and depth.

    Now what I ideally need is a way to copy the visible portion of the depth map into the depth buffer prior to rendering 3d objects. I say visible because the backgrounds will most likely be very big. I'll probably need to create sub-images from them like a tile map with very big tiles. The same applies to the depth map of course.


    I'm a bit new to Unity but I think I could render a quad using a custom shader that samples the depth map (the visible part of it) and outputs the read values to the depth buffer. Sadly, I have no idea how to implement this (in Unity) so I'd be very grateful if you could:


    - Comment on my approach

    - Suggest a way to implement it or point me to relevant info


    I'm sorry if my post is a bit confusing, please don't hesitate to ask more details.



    Thank you very much,



    EDIT: there's a typo in the title but I can't edit it, if you know how to do it please tell me. Thank you.

  8. A more generalized approach may be more like travelers using a map, along with what the travelers actually see. I.e., the NavMesh (the map) provides information on possible routes under "normal" (static) conditions, based on some criteria - shortest distance, shortest time, etc. At run-time, each traveler makes decisions whether to follow the possible route(s) - traveler A doesn't like boxes in the way, so asks for another route. Traveler B can break boxes and proceeds ahead. Just possibilities you might want to consider in your design.


    A possible solution is to make the entity that asks for a path specify the kind of objects that can block it (e.g., the crates). The NavMesh will take that into account.

  9. @Buckeye Thank you for the lenghty reply, it's very inspiring. Also, I think that a NavMesh is the natural evolution of WayPoint systems.


    The AI shouldn't have physics collisions or actuation turned off. Use the physics engine to push the characters in the right direction


    Clearly this approach makes things easier in case the AI is thrown away by, say, an explosion: collisions are handled automatically as part of the physics simulation.


    AI pathfinding would be more how an npc moves around and reacts to things in its way, my thought would be that it uses the nav mesh for navigation, to decide where to go and the path to take to get there but the code must be prepared to deal with deviations that may occur in the path


    This is exactly what I was talking about. As you say the NavMesh system must take into account paths that are blocked by other actors or props.

  10. I haven't used the equivalent of a navmesh for ages


    Ok so now you want to code an FPS and you have a big level mesh filled with other objects like furniture, crates, barrels or anything like that. You want to move an AI controlled character from point A to point B. How do you do that?

  11. Re: taking props into consideration when you create your paths: assuming by "prop" you mean objects not part of the static level: you could enhance your navmesh to take them into account  ("At this node, check if the door is open" or "Is that wall still standing?") Though, run-time collision detection pretty much takes care of the problem, doesn't it? If you do that for the player, why not other objects?


    NavMesh would be computed from static geometry only. What if I put a crate in the middle of a room? The NavMesh doesn't know about it so a path computed at runtime may potentially cross the crate. How to adjust the path? Collision avoidance?

  12. Likely I'm misunderstanding how your collision engine vs. navmesh works. I.e., if your navmesh defines fixed paths (assuming it's 3D), it's not clear what roll "collision detection" has.


    I intended to use collision detection for player movement. Are you suggesting I could simply ensure the player is always inside the NavMesh instead? Seems a viable solution.


    another approach is to build (e.g.) a quad-tree


    A quad-tree for props seems a must-have. How would one combine the NavMesh from the static level geometry with the props when computing AI paths? Maybe some collision avoidance algo?


    if anything can move AI in a physical fashion, then this will break.  For example, explosions from a rocket launcher, a grenade, or a car that pushes an AI off the navmesh.


    This is indeed something to be considered. In this situation one could let the AI go to the nearest point in the NavMesh and then create a new path. Is this a realistic possibility?

  13. ** if, rather than "static," you want doors to open/close, holes to appear in the floor, etc.


    I plan to make props inside a scene (like doors) handled with bounding boxes (or other volume types). I would have the collision engine first handle collisions with the static level mesh and then with the props. I think this is enough to handle common FPS scenarios but maybe I'm missing something.


    I also think that rebuilding the NavMesh everytime the level changes (won't happen at runtime) is common. What other approaches do you suggest? Not using a NavMesh at all? I tought the NavMesh solution was the standard one.

  14. Let me tell you how I would like to handle movement inside a 3D environment:


    1) A Collision Mesh (a simplified version of the level mesh) is used to check player collision against walls and the floor. If we have stairs we use a flat poly (like a ramp). The collision engine is tailored to handle such a mesh (we have no real physics).


    2) A NavMesh is used for AI movement. AI agents only move along paths computed from this mesh so collision detection is not even taken into consideration.


    I think this is enough to handle static scenes.


    Is this the common approach? Do you have any suggestions?




    3) Collisions with props (doors, crates etc.) are handled using bounding volumes

  15. Actually I'm going to add another feature to the game framework: I want to have systems that mantain a local list of GameObject's they want to handle during Game.Udate()/Draw(). It's very similar to an Entity-Component-System without the Component bit. Having a local collection in each system solves the problem completely but introduces another issue: keeping the local collections updated whenever a GO is added or removed. Imagine a System is updating itself and it creates a new GO. The newly created object goes into the master list which is ok since we are not enumerating that but the local one. Anyway, the new GO must be cached somewhere so that after the enumeration of the local list it can be added to it. An add/remove (as suggested by SmkViper) request would work as well. Another (simpler) solution would be to rebuild all the local lists at the beginning of each frame (but only if at least one GO was added or removed).

  16. Actually RPGMaker is a very good tool for developing classic JRPGs (IMHO).


    GameMaker can be used effectively if you can handle it. Your project can easily become a huge mess if you don't pay attention to how you structure it. You need consistent naming conventions especially inside your GML scripts. Don't forget to document your code whenever possible. GM sucks as a level editor but probably you can live with it. All in all it comes with a lot of useful features but you need to be careful if you want to create a mid to large game. Consider that successful (== that sell) indie games made with GM exists, Hotline Miami and Risk of Rain (not 100% sure on this one) come to mind.


    EDIT: I noticed you already mentioned Hotline Miami and other games. As you can see GM is perfectly capable of shipping high quality games, it really depends on your skills.

  17. In a simple architecture where a single collection holds all GameObjects of a game we have to enumerate such collection to perform some operations on every GameObject each frame, for example:

    // Each frame we need to Update() every GameObject.
    foreach (var go in GameObjects)

    Very simple indeed and for small games very effective too.


    The problem is: we want to be able to change the GameObjects collection at any time, even inside the foreach loop. A GameObject.Update() can spawn new GameObjects or destroy existing ones. In c# this will throw an Exception.


    My alternatives:


    1) Copy the collection to an array and use that inside the foreach loop. New GameObjects won't be visible till next frame and removed ones will still be enumerated if they come after the GameObject that is currently Update()'d.

    // Reuse an already existing array to avoid memory allocation each frame.
    GameObjects.CopyTo(array, 0);
    foreach (var go in array)
        // GameObjects.Add()/Remove() won't throw an Exception.

    This is probably the simplest.


    2) Use a for loop instead:

    for (var i = GameObjects.Count - 1; i >= 0; --i)
        var go = GameObjects[i];

    Once again new GameObjects will only show on next frame but removed ones will immediately disappear from the game. Of course you are updating everything in reverse order which may not be acceptable.


    3) Use temporary collections to store new/old items.

    // Sample AddGameObject() implementation:
    void AddGameObject(GameObject go)
        // Use a temp collection to store all new GameObject's.
    // Main loop
    foreach (var go in GameObjects)
        // AddGameObject() doesn't modify the GameObjects collection directly so it's safe
        // to invoke it inside GameObject.Update().
    // At the end of the frame commit changes.
    foreach (var go in _toAdd)

    Like in 1) changes are not visible in the game till next frame bu this solution has the advantage of not copying the whole GameObjects collection to the temporary array. I'd say this optimization (premature, but let's discuss it anyway) is not very significant for small games.


    Please share your thoughts.


    But how would you address having multiple components of the same type representing different things?



    Ideally, don't. Generally, I find that such a need suggests that one is modelling components at too granular a resolution, resulting in a system where you have basically replaced member variables with components, introducing rather significant complexity and overhead for no particularly good reason.


    If you must, however, there are two points to consider:


    • Having multiple instances of components with the same type doesn't always mean you have to be able to individually query for each one. Typically, a well-performing component-based entity-system will use an outboard approach where so-called "systems" are the authoritative containers for all component instances and process/update them all in bulk (rather than the more naive, cache-inefficient 'for each entity, for each component therein, update' approach). In this system it doesn't necessarily matter if an entity has two components of the same type since they are all still processed.
    • If you really, really have to have multiple instances and refer to them directly (for example, you have to call GetComponent(...) to read a bunch of data from it inside some script somewhere) you have no real choice but to support discriminators of some form. A name is the typical way to do this (but ideally you'll hash this name or somethign to avoid constant string-based searches for components, which can have a noticeable impact on your performance).


    The thing is, if you're at the point where you need to have named discriminators for components, what do you have? What, precisely, is the different between having two Point components (one called Position, the other called TargetPosition) and having a single structure (perhaps called TrackingComponent) with Position and TargetPosition members? When you get to this level of granularity you have usually started to replace member variables with components, which is not super efficient. It would almost certainly(*) be better to make the component a broader package of data and/or behavior (depending on what your components model). 


    (*) I will concede that there are scenarios where this can be acceptable, but they are reliant on specifics that you have not provided in your discussion thus far.


    I do agree, I'm using components as if they were object properties replacement which is clearly too granularized.

    I suppose that every case needs specific design where one has to decide at which level of detail components have to be broken down.

  19. I would go with the second option. The first option is fine although if you find yourself repeating yourself often, in terms of the declaration of the members or the functions operating on them, that's a classic scenario for when you may want to move to a more encapsulated representation (the Point structure).


    The third option seems downright ridiculous and reeks of the over-granularized, over-zealous "make everything a component zomg!" attitude that often comes with trendy overthought designs like the "component-based entity system."

    But how would you address having multiple components of the same type representing different things?



    class Position
        public Point Coords;
    class TargetPosition
        public Point Coords;
  • 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!