• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

187 Neutral

About Tset_Tsyung

  • Rank
  1. @Scouting Ninja (or anyone else who reads this post) Okay, so I've tried a few different methods of overcoming this, including what Scouting Ninja said (although need help with one of his methods, see below). I've tried shitfing the new meshes away from each other (using the normal of the plane that sliced to work out direction) and even shrinking the objects a little by adjusting their scale.  However I'm still getting some exploding meshes, although less... So I was thinking about Scouting Ninja's idea of 'waiting for space before turning the colliders back on', however if I do this with a non-kinematic rigidbody that uses gravity it'll fall through the world.  Turn it to kinematic with no gravity and it'll hang there in the game ruining the immersion. PLUS, and this is the bit that I'm struggling with, I can't seem to find a utility in the UNITY physics API that allows me to get a list of all objects intersecting with a collider AT THE POINT OF CREATION.  OnTriggerEnter/Exit method of listing everything won't work because if there's an object already within the collider I don't believe that OnTriggerEnter will call.  I could try using OnTriggerStay, but I believe that requires at least 1 frame before checking what's "staying", and even though that's only 1 frame I'm concerned that it'll cause more issues as other moving objects may go in and out of the collider during this time. Thoughts?!?! P.S. I wasn't too sure what you meant by using 'precise collision bounds.  Is that not what happens already when using mesh colliders?  I'm already using "Continuous Dynamic" in the rigidbodies... is there something else I can set to increase accuracy.
  2. Scouting Ninja, You're a star, many thanks. I though it was something like that.  It semed to lesson when I adjusted the width of the 'foundation' (think it was too thin and read that can throw off the physics). So now I just have to find a way to implement what you suggested... may as well repair the triangle code AND try using a hald-edge mesh system as was suggested. This isn't going to make it into one of my "Game-A-Week" games for a while, lol.   Again, many thanks ;)   Er, how do I adjust the title to read that there has been a solution provided?
  3. Hey all, I have put a post about this in the UNITY forums... but then remember that this get more through put - I apologise for the duplicate post. Basically, I have a catapult-smash-stuff game that I was trying to hack together for a "Game-A-Week" challenge.  However I'm having a random effect. Please see this video (especially the end) to get a visual feel for what I'm on about.     https://www.youtube.com/watch?v=-nSodGTsxHc&feature=youtu.be Basically this is the idea: 1) Boulder hits an object. 2) If boulder had enough velocity 'Split' the mesh once (random way). 2b) If other things are hitting each other with enough force (initial force is only provided by physics engine when boulder hits something - no addforce() code) then split (again in a random way). This should be fine, however some of the 'slices' seem to be exploding off in random directions - and I have no idea how or why. I'm telling the objects to 'split' from the OnCollisionEnter function - is this correct?   All replies greatly appreciated - and yes, that includes insults... NB: noob, trying to learn about the physics engine, so please expect noobish mistakes. P.S. The items being sliced are simple Cubes (with box colliders). Howeve, after slicing they are no longer cubes and have mesh colliders to reflect this.  Also some of the triangles aren't showing on the sliced meshes (never had this problem before), could this have something to do with it? I thought this would just be a 'visual' issue... P.S. The items being sliced are simple Cubes (with box colliders). Howeve, after slicing they are no longer cubes and have mesh colliders to reflect this.  Also some of the triangles aren't showing on the sliced meshes (never had this problem before), could this have something to do with it? I thought this would just be a 'visual' issue...
  4. https://gamedevelopment.tutsplus.com/tutorials/how-to-dynamically-slice-a-convex-shape--gamedev-14479
  5. Okay, final post for now - I promise this time!!!!   The missing triangles is because I hadn't catered for vertices residing DIRECTLY ON THE PLANE.  So make sure you follow that section from the article by Randy Gaul, if you wanting to do this yourself of course... Will prob post my basic solution on here at some point for other noobs like me to pull apart and have a look at.  It's nothing new, but might be a helpful stepping stone for someone.
  6. Okay, so I've solved the weird triangle problem, and I'm posting the solution in case anyone else stumbles upon this thread with a similar issue (although, we're now leaving the OP, so this will be the last post from me).   Basically, in an effort to be clever and efficient (2 things which were not necessary for this simple 'tech demo' that I'm working on) I decided that I wouldn't use duplicate vertices, just draw multiple triangles from the same points.   Problem is that this messes up the normals, which is why I was getting those weird white-ish stretches of colour.  Anyway, I simple added each vertex once FOR EACH TRIANGLE (thus, some points were enter multiple times) and this seemed to sort it out.   Still getting the occasional invisible triangle... would need to examine further. But apart from that - it's AWESOME! Thank you so much for all your help @RandyGaul!!!
  7. @WiredCat So have you been getting much luck with mesh slicing/destroying?
  8. Okay, so I've got it working fine 90% of the time (so it's still essentialy broken, but one problem at a time). But I'm getting this effect on the sliced meshes. [attachment=35782:Triangle1.PNG] [attachment=35783:triangle3.PNG] As you can see, the 'bricks' ar just cubes with a standard material, but as soon as they are sliced the triangles go a bit awry.  I've looked into UV's, and tried copying as much data across from the original mesh as possible, but I cannot work out what's wrong with this.   I've also run mesh.recalculateNormals() and mesh.recalculateTangents() (Unity) still no luck :(   This wouldn't be cured by using an actual mesh format by any chance, would it?
  9. Hi @RandyGaul Many thanks for the reply. I'm glad you've said that, I was sorta thinking in that direction, glad to have it confirmed. I've looked a bit into basic mesh construction (remember a lot from my attempts to learn gamedev straight in c++ and DirectX) and. Vertex manipulation, however I have no idea how to work out how add another plane to the mix and go from there. Is there a particular subject I should research and study? P.s. gonna look into (google) "plane slicing" and see what I come up with...
  10. Hey all,   It's been ages (years) since I've been on these forums.  Last time was a noob.  Now it's as... a slightly less noobish noob.   Basically, whilst I'm working on my little 'game/demo a week' challenges to increase my skill I would also like to expand my fundamental knowledge on a certain subject - namely destructible terrain/objects.   Now this, as far as I can work out, includes physics (architectural and structural to some extent) and an understanding of modifying meshes on the fly.  Admittedly, that last one is perhaps a LOT more in depth than is necessary, but this is going to be a long term subject I wish to learn.   Therefore, my question is (finely got there - sorry 'bout that) what sorts of subject (the more specific the better) should I learn to get a decent handle on this? And, yes, I know this is going to recquire learning new mathematics - I'm happy to try ;)   P.S. Further information:  I have already messed around with the basics of solid-wall-turning-into-bricks when "destroyed", however I would like to understand how to make objects shatter and explode (battlefield style) or slice (metal gear solid whatever style).
  11. Okay, What about the array? Is this not a good way to keep track of the grid?
  12. Hi all, I'm writing a basic Gravity Force 2 clone where players fly a ship around a level, fighting gravity and themselves. I'm self taught and am learning what I need when I need it. So now I'm needing to learn basic collision detection. Currently you can fly the ship around the map but you can go past the edges. The map is made up of large blocks (half the size of the players ship) and the player can (eventually) destroy them if they hit it hard enough and shoot them. But of course this doesn't work at the moment hence why the player can just fly for an eternity... But how do I perform collision detection? Now since I am a total beginner please assume that I know very little of the mathematics behind this, as I said I'm teaching myself as I go. Unfortunately I'm one of those people that learns best by getting stuck in, making mistakes and then climbing out of them again. So how do I perform basic collision detection (on basic geometric shapes) and what should I study up to understand these concepts? Thanks for the help everyone! Mike
  13. Cool Many thanks, I will admit that A LOT of that collision detection went over my head (as I said I'm learning as I go) . Think I'll do loads more research before I continue design/developing. Again many thanks!
  14. Hang on... Just remembered that weaponclass actually sets up a linked list of OrdnanceClass objects to handle the individual bullets and the like... However according to my above thoughts they still need to contact the playerclass to check for collisions...
  15. Thanks all - forward declarations are obviously whats needed here. As for WHY weapon needs to contact the player class allow me to explain - I'd be interested in your input on this matter as well. PlayerClass fires a weapon. Therefore contacts WeaponClass (which handles all bullets, bombs and the like) and create a new bullet to fly across the screen. Now to check the collision of bullet and player ship I have weaponclass cycle through all the bullets and check their positions against the players ships, hence why weapon class needs to contact playerclass. But I'm guessing from your above comments that this perhaps might not be the best approach? @edd, Yes I did include header guards. Will endevour to include more accurate code and error messages next time - thank you for the help