Jump to content
  • Advertisement

Dan DAMAN

Member
  • Content Count

    69
  • Joined

  • Last visited

Community Reputation

129 Neutral

About Dan DAMAN

  • Rank
    Member

Personal Information

  • Role
    Programmer
    Quality Assurance
  • Interests
    Design
    Programming
    QA

Social

  • Twitter
    @ds2001man

Recent Profile Visitors

2558 profile views
  1. If you just want to draw custom Gizmos without responding to the mouse you can do it by adding the draw calls you want to OnDrawGizmos or OnDrawGizmosSelected. This is a decent quick intro to them https://blog.theknightsofunity.com/custom-gizmos-ondrawgizmos/ When I first dealt with needing to drag custom gizmos around in the editor I found it was more complicated. This is what I did back in Unity 5.1. I used a custom editor for the component I wanted to add controls to. An empty one looks like this [CustomEditor(typeof(WaypointPath))] public class PathEditor : Editor { private void OnSceneGUI () { // code for drawing and handling mouse events will go here } } In my case I needed custom handles (the interactive parts of a gizmo) to drag control points for defining a path. Stripped down to just the code needed to drag around a single handle on a single axis you end up with something like this. This isn't what I'm actually using since the real code deals with potentially dozens of these draggable handles which would make it harder to follow what's going on. I've not actually compiled or run this code. Hopefully this helps in finding the information needed to create your own editor UI gizmos. void OnSceneGUI() { // generate an ID for the clickable part of your gizmo // in my case I used -10 then decremented for each additional handle // IIRC positive numbers cause problems int controlId = -10; float distFromMouse = HandleUtility.DistanceToRectangle(worldPositionOfYourHandle, Quaternion.identity, 0.25f); HandleUtility.AddControl(id, distFromMouse); // draw the handle, this is just an example of how it can be done Handles.CubeHandleCap(id, worldPositionOfYourHandle, Quaternion.identity, 0.25f); // handle events if(Event.current.type == EventType.MouseDown) { if(!Event.current.control && HandleUtilitiy.nearestControl == controlId) { // if needed, store the starting point of the mouse drag in a member variable dragStart = Event.current.mousePosition; // if you don't do this, you could click multiple objects at once Event.current.Use(); } } else if(Event.current.type == EventType.MouseDrag) { if(!Event.current.control && HandleUtilitiy.nearestControl == controlId) { // do whatever you'd like with the drag // example of dragging the handle along the X axis only float newX = HandleUtility.CalcLineTranslation(dragStart, Event.current.mousePosition, worldPositionOfYourHandle, Vector3.right); Event.current.Use(); // (change worldPositionOfYourHandle here) } } } Though if you just want to move an object around I'm not sure why you wouldn't want to use the built in gizmos.
  2. I thought std::vector was the standard container back in the day and was usually an array behind the scenes. While std::list was for those who specifically wanted the features of a linked list. I'll admit I only ever used C++ as a student or a hobbyist though so :shrug:
  3. I use Javascript, specifically Node.js, at work to automate tests of a webapp. JS is really nice in some parts and really obnoxious in others. Since it annoys me the most I'll post mostly about it What bugs (haha) me: Most type coercion. It's OK for formatting text sometimes but causes annoying little bugs way too often The Date class NPM updates constantly breaking things. Both bugs and breaking API changes. And when it isn't NPM it's Chrome How "this" is set up such that when writing OO code w code generation you need to call someObject.someFunction.bind(someObject) or else have "this" reference the wrong object The bizarre threading setup requiring practically everything that's otherwise blocking to be async (or worse promises, or worse still callbacks) I really like async/await for its intended use case. It's awesome to have code where I can do other work while waiting for what is normally a blocking IO operation. The problem is in the test framework I have to use basically everything is a network call so everything is async. However almost every operation that is typically done in a test needs to be done sequentially. Forget an await or two? Have fun finding the resulting race condition. If I'm lucky the test will fail immediately. Otherwise the issue can lurk for days before suddenly cropping up. In the past it was worse with lots of code amounting to a more nicely formatted version of this return foo().then(() => return bar()).then(() => return baz()); Other/multiple languages: Type erasure in generics in Java Checked exceptions in Java. Especially in deep call graphs and especially especially when the exception represents a bug and shouldn't have been checked in the first place! Certain people who catch exceptions and throw brand new ones destroying useful stack trace info needed for root cause analysis Me constantly mixing up names of various standard operations between multiple languages. To add to an array/list is it push, append, push_back, add etc Unity editor locking up completely without allowing me to stop the game if I accidentally write a tight endless loop somewhere
  4. For now I'm going to take a crack at something like the solution that Hodgman described since it fits nicely with stuff I'm already familiar with doing (render textures, generating meshes etc That sounds really cool and like a good way to get more variety in appearance so it's not obvious that the audience is only N characters duplicated however many times needed. I think with this I'm pretty good to implement a final solution for this and either post it up here or throw a blog up for it.
  5. I took a peek at some of the sports games on your website and they look really good! To clarify are you rendering the 32 characters to the sprite atlas in-game or using an atlas with pre-rendered images? I'm thinking for Unity something like 32 objects containing one skinned mesh and 4 cameras each. After a quick check it looks like I can use Viewport Rect in each camera to render multiple cameras to one texture. Switching to using jobs has improved the framerate to 50-60FPS for most of the time. Here's a little clip with all the characters doing random bored animations. The GIF has a much lower framerate than the game. Artwork is really early still which is why that horrible Z-fighting is happening. I haven't actually modelled anything for that corner and simply have a huge cube there. This one uses ten skinned meshes to seed animations into the audience.
  6. Thanks for the link, that looks like it could be quite useful for what I'm trying to do as well. I'll have to give it a look :) As for the rather poor documentation on IJobParallelForTransform. I found this post quite helpful in actually understanding how the interface is meant to be used. I was pretty mystified about it until I found the article myself.
  7. The slowest version was a few dozen lines of code total using mainly Unity built in stuff. Your advice is good in a general sense but not relevant to the specific issue I'm trying to tackle. The current problem is having an O(n) algorithm with way too big an n value. On that note, I have found another potentially feasible solution in Unity's job system. Specifically IJobParallelForTransform. A quick and dirty prototype has increased the framerate to 70 FPS. Hopefully I'll have something on that this evening or tomorrow.
  8. This is unhelpful. This sort of thing would be what I would consider add on features for after I get decent performance out of basic rendering of characters with variable animations. I like to solve one problem at a time normally :)
  9. I have some concerns about the sheer size of texture data that would produce but it's worth a shot. Thanks for the suggestion. I'll post back with how sprites work out. 40 FPS with no player, no enemies, no gameplay etc. Just with the audience. Kinda expensive for what amounts to decoration. Remove the audience and the framerate jumps to ~160 FPS Another idea I had is potentially copying bindposes on the SkinnedMeshRenderer or copying transform data so I'll probably try that too.
  10. I'm looking for a way of rendering an audience in a decently sized stadium with about ten thousand seats. Usually not all seats will be filled. The project is using Unity3D Currently I'm instantiating a GameObject with a skinned mech and armature+bone objects for each seat. Initially I simply animated them using Animator components on each but the framerate was unacceptably low. No real surprise there :) What I have now is a smallish number of identical skinned mesh game objects with actual Animator components on them. I then copy the transform data from the armatures of the animated meshes to the armatures of randomly assigned audience members. While this is better it still takes 20ms or more per frame to do this. After rendering, overhead etc it leaves little to no room for actual gameplay without dropping the framerate below an acceptable level. The problem seems to be the process of copying/setting tens of thousands of individual positions+rotations from the animated objects' bones to the audience's. I've tried splitting the copying across multiple frames which improves update time and overall framerate but makes the audience animations look choppy. Any ideas on how to either make this current implementation more efficient? Or any alternative solutions?
  11. Dan DAMAN

    Passing data with message system?

    This above could be pared down further. A barebones renderer shouldn't need to know how game assets are managed, what an asset is or even that it's being used for a game (vs any other real time rendering application.) The renderer only needs to know about data that you intend to pipe into the GPU. DrawCube(Matrix4x4 worldTransform, Material material); The worldTransform covers location, size and orientation of the object. The remaining transforms (view and projection) would be handled elsewhere since they're normally common across many draw calls. The material covers everything else pretty much. From here you could then make a more abstract function which DrawCube can use behind the scenes. DrawMesh(Mesh mesh, Matrix4x4 worldTransform, Material material) As a side note, if you're rendering objects using an API like this what you'll likely need to do behind the scenes is queue something to be rendered instead of rendering immediately. Once you start using stuff like multipass shaders, render targets and postprocessing drawing objects on screen becomes a lot more work than simply rendering a box at a position via a draw call. Even without that you'd should probably sort your actual GPU draw calls for various reasons. Finally, a warning from personal experience, if you want to make games it can be a good idea to stay away from engine code until you get a game or two under your belt. Engine code is a huge massive crazy time sink and if you're not sure what you want the engine to do there's lots of intellectual tarpits and blind alleyways to get lost in on your way to something useful. It's pretty fun if you want to do it but you're not going to be making many games very quickly. Be ready to throw away a lot of code as you learn what designs do and do not work well.
  12. Dan DAMAN

    Passing data with message system?

    I would suggest the first important piece is to decide is which systems need to communicate with each other first. Once you have that you can figure out what, when and how often your systems need to communicate. IMO systems that do infrequent, one way, communication are great candidates for message passing schemes. The sender is decoupled from the receiver and for implementations like the observer pattern the overhead for sending messages is usually lower than alternatives like polling. I also second what @erpeo93 is saying. Try not to get too attached to one solution to a problem. For many basic problems in system-system communications a bog standard function call can do the job quite nicely.
  13. Do your prefabs have Rigidbody components? Generally Unity treats an object with a collider but no Rigidbody as a piece of level geometry which cannot move but can be hit by other objects. Having overlapping colliders is pretty common when creating level geometry so static colliders cannot collide with each other. Check the "Collision Action Matrix" section of the Unity manual (link below) to see if your setup is something that will generate a response. From the Unity manual https://docs.unity3d.com/Manual/CollidersOverview.html
  14. I've done a few platformers with a friend using Unity 3D now. At the time we wrote our first platformer we used raycasting to handle the work of detecting walls and slopes and have used the same code, with tweaking, ever since. The system is a bit finicky to set up but works well after the initial work is done. You shouldn't have too much trouble getting most of what you want out of either option though edge grabbing might be a bit of a challenge compared to the other features. IIRC there were a couple reasons we went with raycasting since we built the system in 2015 a lot is very much an "at the time" thing and might be incorrect or outdated thanks to updates to Unity. I don't think Rigidbody2D existed at the time but I could be misremembering We couldn't find a way of having one hitbox for detecting walls and another for different important interactions that we were happy with. Even when we constrained rotation on all axes we still got slight rotations sometimes Getting a good control feel was extremely difficult. IIRC we kept getting weird issues (sliding, getting stuck, jitter etc. etc) that would crop up randomly which raycasts didn't have The way we did things was to have three rays (top, middle, bottom) cast for horizontal movement and three rays (left, middle, right) cast for vertical movement. Any intersection that's within the character's hitbox will result in the character being pushed back/up/down to eliminate the overlap. When embedded in a floor the player is always pushed up so it's impossible to get trapped though it does open the game to a class of exploit normally called a "zip" by speedrunners. Tweaking the locations of the bottom and left/right rays is used to control what sort of slopes that player can and cannot climb. Unfortunately I don't know of any good tutorials for setting up something like our system since we only really used the Unity manual, pencil and paper and hacking to implement our platforming system. I could write some blog posts or something on how our system works if there's interest. I don't think a forum post would be the best place for going into all the details on how we made our stuff work.
  15. Dan DAMAN

    How to avoid bugs

    I find the best way to prevent bugs is to write code that's easy to understand. Do what you can to make your intentions obvious through your code. Whatever you can't make obvious document via comments. Short term this helps prevent bugs since you can "gut check" your code to see if it's doing the right thing more easily. In team situations it makes the code easier to review as well. Most bugs IME are due to simple oversights when writing up code. The harder you have to work to "get" the code the more likely you are to miss a detail which leads to a bug. Longer term when you go back to revisit old code simple code helps even more. The more easily you can figure out what you were trying to do the less likely you are to add new bugs or bring back old bugs. A few suggestions Code small features one at a time, don't do too much at once. Work out how you want your small feature to work before you write it. Source control gives you a nice way to undo your changes and start over if you're completely stumped. Keep your functions short with few arguments. Keep your functions independent of each other whenever possible. Functions calling each other is fine but having something like prepareFoo then doFoo is more likely to lead to bugs since you could forget to call prepareFoo or make other mistakes. Avoid having widely shared data that can be modified in many places (e.g. global variables, singletons etc.) Avoid duplication of code. Fixing a bug once is enough work. Fixing lots of the same bug is an exercise in frustration. Fail hard and loud on unacceptable program data. The quicker a bug leads to a catastrophic event the easier it is to find and fix. This is what can go wrong if you don't throw up huge error messages or outright crash on bad input: https://arstechnica.com/gaming/2018/07/a-years-old-one-letter-typo-led-to-aliens-colonial-marines-awful-ai/ As other posters have said, you will get bugs still, but simpler code should make them easier to find and fix.
  • 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!