Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

479 Neutral

About ninnghazad

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well in that case basically any collision detection would work. Testing intersection against a sphere is as easy as comparing distance vs radius, when the distance is smaller, there must be a collision. But you probably don't have only spheres in your game. And your sphere is probably a spherical model made up out of triangles. And the problem with collisions really isn't detection but resolution. And if you don't know that, you will have a hard time writing that by yourself. I'd say use a physics library to detect and resolve collisions. Don't know what language or engine you are working with, but you can find one (free ones even) for almost any language or engine. For anything but really simple cases writing it yourself is ... insane. And unnecessary.
  2. Do you use cartesian coordinates and have a spherical object as ground? Or do you use spherical coordinates over a "flat" world?
  3. I think what JoeJ refers to is that, when you add your position/node to the list of possible walkable targets, you do so by only using cardinal directions. meaning the square at step 13 wouldn't be added to the list of possible targets at all. for all other steps of A* you consider all directions,including diagonal as you did before. edit: depending on your implementation that might mean that finding walkable targets and updating their distance to parent has to be split into two steps.
  4. ninnghazad

    How to find freelancers?

    https://www.reddit.com/r/gameDevClassifieds/wiki/index https://polycount.com/categories/freelance-job-postings
  5. this kind of sounds like you mix some stuff weirdly - if the client is behind the server in time, why do you need to snap rewind->replay the client? if the client is behind the server, you interpolate/snap from known states - if the client is ahead of the server, you rewind/replay from known (past) states. it sound like you mix client-rewind with client-behind-server. also - arcade physics with lots of enemies that bump into each other is going to be messy with high latency. note how arcade shooters usually don't do enemy/enemy collisions, not even player/enemy collision-responses, just detection. you might save yourself from a world of pain by rethinking your design. collisions, especially complex ones with multiple forces, restitution, friction ... can diverge quickly even through minimal differences in starting state. does "bouncing off stuff" really add to your game? you can detect collision just fine without bothering to do realistic bouncing off/collision-responses.
  6. ninnghazad

    Did I really remake Minecraft?

    Apart from agreeing about the situation in germany, there is a public thing starting just about now to which you might apply - „De-minimis-Beihilfe zur Computerspiele-Entwicklung des Bundes“. 3rd of June or something like they start accepting applications. Haven't looked too deeply yet, but it's sure worth checking out. Also - put some more screenshots on your page, It sounds nice.
  7. you can query keys from steam. but checking if a user has a valid license is done by steam's api to which i linked. you don't use the key to check that - the api checks upon init if the logged in (in steam) user has a valid license for your software. i think it happens when you call https://partner.steamgames.com/doc/api/steam_api#SteamAPI_Init
  8. use steamworks api to do stuff like user auth: https://partner.steamgames.com/doc/sdk
  9. do you keep 2 positions for predicted entities? one true position, and one visual with an offset which is slowly reduced towards the true position? on received update you snap the true position and calculate a new offset towards the position the entity is currently seen at on the client. that should reduce erratic position changes upon updates coming in.
  10. ninnghazad

    Understanding Entity Component System?

    you might want to check out the source of https://github.com/miguelmartin75/anax it's a minimal ECS in c++, you could find some inspiration there.
  11. fully functional means you have skills in some kind of datastructure? add some display related info to those, like icon and menu-title or description. then write a function to create those buttons from the prefab using the info from the skills' data. check this: https://answers.unity.com/questions/1085263/dynamic-menu-creation.html
  12. As JoeJ said, use GPU-supported formats for production builds. Some resources: OpenGL Wiki on Texture Compression Nvidia Texture Tools
  13. the number of unique vertices per triangle per level of subdivision (not per hex) should be integer sequence https://oeis.org/A028401 btw: if all triangles are supposed to have the same depth of subdivision, don't use pointers - just use a flat array and calculate indices.
  14. Extendable prototypes are useful - Enemy->Undead->Skeleton for example. Just to not have to write so much. Using combining prototypes may be useful, but also kind of doubles the whole component thing - might well be superfluous. Creating entities from prototypes does not mandate passing parameters to whatever actually creates them. At whatever point you create an entity, you know why and what entity is to be created. You might as well just return one from the factory without passing anything other than the proto-id, and set whatever you need on the returned entity in whatever place requested it. Lets say you populate a dungeon with enemies - that generator-thing knows "right now i wanna place a skelly at X,Y" - so have it request a skeleton and have it set the proper position. If you have serialization for your entities, human readable that is (so you can manually adjust the file), you could just use that for "prototypes". create an "empty" skeleton, save it, and use that when somebody request a fresh skeleton. Another way might be to have prototypes and init-data, prototypes have an init-function that accepts init-data to set up that specific type of entity. So you can decouple specific inits away from the factory to some place more appropriate.
  15. Ye, you send a prepared sparse octree, basically an array of the tree's nodes. you can use vertex shader to do some translations and then use the fragment shader to raytrace it. or you use OpenCL/CUDA for the actual tracing, but fragment shaders would do. a sparse tree uses (in most cases) a lot less data than the raw data, on top of that you have kind of builtin multisampling for far away nodes. i advise to read this excellent paper from NVIDIA on the subject: https://www.nvidia.com/docs/IO/88889/laine2010i3d_paper.pdf also if you do not need transparency (which i would assume you don't with medical scans) you can raytrace front to back and stop at first hit. and if you only need to see the surface and not be able to dynamically slice the scan, you can store only the surface in the octree, drastically reducing its size. for a simple introduction check out this cpu-only example: https://github.com/tunabrain/sparse-voxel-octrees should you find that SVOs aren't for you, consider using multiple compressed 3d-textures. you prepare each "cube" by quantizing non-surface areas of the scan. this will let the compression achieve better ratios without reducing the visual niceness too much.
  • 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!