Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Aug 2002
Offline Last Active Today, 10:15 PM

#5309084 Recalculate trajectory?

Posted by on 01 September 2016 - 06:48 PM

How do you calculate the updates frame by frame so that no matter where the target moves to the effect is always heading toward them?

Pretty much just literally implement that description as code, and that's a reasonable way to do it.

Keep a reference to both the effect and the target of that effect.
Get the difference in position between them, and tell the effect to move in that direction each frame.

You can either base the projectile's speed on the total time-of-flight that you compute at launch (which means you just do some basic interpolation each frame), or you can actually have the projectile "drive" towards the target with whatever kind of seeking logic you want (head straight towards the target, continuously lead the target, etc).

In the arcing effect seen in the video, you could first compute the straight line along the ground to your target, and then set the height as a curve above that straight line. If the target moves, the "straight line" updates itself, and the arc height calculation stays the same.

Remember, when dealing with visual effects you don't NEED to realistically model the position of the projectile. You can fake it as much as you need to until it looks good enough.

#5308948 Mind blow null object

Posted by on 31 August 2016 - 09:14 PM

If you're using 'new SYC_BusinessDB' and SYC_BusinessDB is derived from MonoBehaviour, then Unity should be printing errors/warnings about that. I don't remember off the top of my head if improperly created MonoBehaviours start off "null" or not, but you might be right.

If your SYC_BusinessDB class doesn't ever need to be attached to a gameObject as a component, just don't derive from MonoBehaviour. You'll get a "POCO" - a "Plain Old C# Object". Those will work just like C# objects do in non-Unity projects and don't have any of the weird "pretends to be null" stuff.

If you DO need it to be attached to a gameObject as a component, then you'll need to properly instantiate it using one of Unity's methods, like GameObject.AddComponent<T>, instead of using 'new'.

#5308790 Mind blow null object

Posted by on 31 August 2016 - 01:09 AM

Unity objects have two "sides" to them - the C# side and the internal C++ side. A normal C# object cannot be manually destroyed as long as there is any reference to it, and this is still true in Unity. Another way of saying this is that *nothing* can forcibly null out variables that you're using in your code, but Unity tries to make it LOOK like it.

However, the C++ side CAN be destroyed at almost any time. When this happens, Unity has overloaded some operators in the base class that causes comparisons with null to be "true" (even though the reference is not ACTUALLY null) to indicate this has happened. It also has a customization in place to print null in the debugger.

When a Unity component/object is in this state, you can safely access any pure C# members of that object, but you will get exceptions/errors if you try to access any of the Unity-specific stuff (like the transform, containing gameObject, etc). Note: This is NOT like dereferencing a deleted pointer in C++ that just happens to have the old data around still. The C# object is still completely alive.

In this case, you've got some Unity-derived object in your m_cardDB collection which has had its C++ "side" destroyed, but you've still got a reference to the C# "side" of it in your collection which allowed you to access the m_Number member.

The C++ side has things like the transform relationships, the gameObject reference, the set of components on the object, etc. Stuff which the Unity engine uses internally.

The C# side has everything that you've written in any of your own C# files, including classes derived from MonoBehaviour.

To solve your actual problem, you have a few options:

- When the object gets destroyed, handle OnDestroyed to remove that object from your other C# collections (by posting an event or something like that).
- Periodically check your collection for null entries whenever you need to, and voluntarily remove anything that's null.
- Perhaps there's a problem that's causing the object to be destroyed before you actually wanted it to be, and you can fix that.

#5308131 State machine for beginner - how to shoot state AND jump state

Posted by on 26 August 2016 - 06:21 PM

Generally you only want to use a state machine when it contains mutually exclusive states. If you ever have two or more things that you can combine at the same time (like shooting and any movement state), either split them in two different state machines, or use something else instead of a state machine.

Sometimes you don't need a state machine at all and can do everything in a single Update function that gets called once a frame.

such as:
If health is <= 0 and dying animation not playing, play it and return.
If dying animation is done, do game over and return.

Check arrow keys, update velocity.
Check whether the player is touching the ground, if so reset the jumping flag.
If jumping flag is false and jump key is pressed, set jump flag and add lots of upward velocity.
If jumping flag is set and jump key is released quickly, subtract a bit of upward velocity to let the player perform a smaller jump.  Potentially add another flag to prevent the user from repeating this multiple times in the same jump.
If player is capable of flight, holding the jump key while jumping adds a little bit of upward velocity.

If fire key is down, and firing is possible now, then fire.

Apply velocity to position.

If in air, use jumping/flying animation.
Else If on ground and speed > large threshold, use running animation.
Else If on ground and speed > small threshold, use walking animation.
Else if on ground use idle animation.

#5308104 Does anyone have any advice for my unique situation?

Posted by on 26 August 2016 - 03:29 PM

Well... I've been doing this for at least a decade longer than most of you.  I was among the very first group of modern game designers that invented the process by which you make games.  I have already been involved with MANY published games, one of the second only to D&D in it's stature in the history of games.

Experience just means you're experienced. It doesn't mean your opinions matter more. Opinions are governed by respect, and respect is something you have to build from scratch every time you meet someone new. You don't build respect by quoting your experience. You build respect by suppressing your ego, and talk WITH people instead of TO them.

#5307978 Does anyone have any advice for my unique situation?

Posted by on 26 August 2016 - 12:38 AM

If anyone has any advice on where I am at now, I would love to hear it.

You've got a SERIOUS attitude problem present in almost every single one of your posts. You are constantly pompous and self-aggrandizing when talking about your own ideas, or ideas that inspired you. You are dismissive and reactionary when talking about other's. You are defeatist and whiny when talking about your own ability to make your ideas happen.

You constantly use passive-aggressive phrases such as "you people" and "your industry". These phrases invoke connotations that you should NOT use. I don't know where you get them from, but stop it. Separating yourself from others is not how cooperation happens. "You" is acceptable. "You people" is not.

You will never be able to cooperate with anyone, business partner least of all, if you don't learn how people talk to each other in real life.

Your ONLY two options if you refuse to change are: 1. Do it yourself, or 2. Give up. Those are LITERALLY your only two options.

#5307970 Graphic Editor Timed event

Posted by on 25 August 2016 - 11:58 PM

I was going to use a timer to then fire off the mouse down event again, is this best?

That sounds fine to me. It's probably the simplest solution. Just make sure the mouse down handler that the timer calls doesn't restart the timer :)

#5307678 Low level serialisation strategies

Posted by on 24 August 2016 - 02:15 PM

Being able to block copy something from disk directly into memory was pretty much the only thing I missed when transitioning from C++ to C#. You miss out on things like forward/backward compatibility, but the loading/saving code is so much simpler and load times are really fast. There's usually no debugging - either your entire set of structs come in perfectly, or you have the wrong endianness (which was only really relevant when building data on PC with little endian, then consoles reading that data using big endian), or the pragma pack is different.

We only used that technique for data loaded from disk, and not for network serialization.

#5306674 Event Management/Queue Design/Pitfalls?

Posted by on 19 August 2016 - 01:15 AM

Priority queues can handle the priority and time-delayed events. Despite their name they are usually implemented using a "binary heap", which are just binary trees with a parent/child ordering scheme that makes them really fast (and simple!) to check and update. If you had a single binary heap for timed events, you would barely need any processing time whatsoever to deal with it on the main thread.

I'm still not sure what kind of heavy processing you might want to do on a background thread. All gameplay events I've dealt with have been simple and fast enough that we've never bothered trying to thread them. The extra work of coordinating the threads seems like it might overwhelm any gains the second thread would have.

I mostly see instant events (which either use a C# 'event' or some similar type of callback) or timed ones (which use a priority queue ordered soonest-first). Anything on a thread usually needs some kind of case-by-case analysis to make sure race conditions don't occur. Threading usually falls into two categories - shared data with locks, or immutable data without. I don't see how you'd make a general purpose 'execute arbitrary code' event system multithreaded without ending up with a full actor system, since locking all over the place leads to overhead or deadlock hell.

Maybe an actor system would be the best for you - it's hard to say without knowing your whole game plan. The nice thing about actor systems is that when you get them working right, they scale up to any number of CPU cores without any tweaking. It's just kind of a pain to deal with the other constraints they place on you.

You could try looking at a few existing frameworks and see if they make sense for you.
TPL Dataflow

...or even just using the ThreadPool to start up short-lived Tasks with async/await might work.

#5306658 Event Management/Queue Design/Pitfalls?

Posted by on 18 August 2016 - 09:25 PM

- In it's own thread (running in parallel to main game).
- Buffering and arms length exchange/processing of messages (for the loose coupling as would be expected) 
- Register/Post/Trigger functions.
- Initially a simple set of event functionality (try and make this a success). 
- C# game btw - events can be as simple as notifying of enemy death.  I expect more complex functionality like Mission success/failure criteria to come later.

- Why threads? Does it need to be threaded?
- Why buffering? Why messages?
- Why not the typical C# 'event' keyword?
- Yes, start simple ("use the simplest thing that could possibly work") and only add complexity when you know you need it.

It sounds like you're trying to make your own Actor Model (https://en.wikipedia.org/wiki/Actor_model). They're generally completely overkill for game clients. They're more useful for distributed computing on server clusters.

#5306578 Code Blocks debugging

Posted by on 18 August 2016 - 11:49 AM

You might be able to tweak Visual Studio's options to make it less bloated/slow, as well. Perhaps one particular setting is causing your pain?

#5306466 I Need A Team

Posted by on 17 August 2016 - 09:12 PM

You may want to use "et cetera" instead of "excreta"! It's a very major difference.

Unless you really did mean to use "excreta". It's possible. It is psychological horror.

#5306096 Is it pathetic to never get actually helpful answers here?

Posted by on 16 August 2016 - 12:03 AM

People tend to not give me response after I ask them something. They just disappear. Never happened to you, huh?

Every single post you've made has had dozens of responses. As far as I can tell, it's never happened to YOU.

You have made five topics in your time here. Every single one has replies. You have replied in TWO of those threads. This is one of them. YOU are the one disappearing after YOU ask something.

looks like you like to look down on people who don't speak English, huh?

No, I thought maybe you can't understand our replies because of language differences.

Did I do anything to you personally?

Yes. You are guilty of wasting my time (and everyone else's) by asking questions that result in answers that you consistently say you are unable to understand, or leaving without any follow-up. And then you complain that YOU are the one whose time is being wasted. This is extremely bad etiquette, and personally offensive to everyone who uses the internet. And then you ask more questions in the same manner.

I apologize if anything in this post was too hard to read.

#5305534 Life as a Tools Engineer ( in game development )?

Posted by on 12 August 2016 - 02:00 PM

I do gameplay, systems and tools work. Personally I like tools the best, but projects typically don't need enough tools to have someone dedicated to them full time.

In my experience, tools work vs gameplay work has tradeoffs:

Standalone tools have relaxed constraints compared to game code:
- Your program only needs to run on developer machines (less need for testing on particular hardware configurations).
- You have more leeway to pick your libraries without worrying about code bloat or runtime memory consumption.
- You can use coding styles that are frowned upon in real-time game code (for example, in a Unity project you would tend to avoid LINQ-heavy code during runtime, but there's no reason to avoid it in tools).
- Standalone tools are usually much easier to debug than the game.
- Unit tests are usually much simpler to write since there are fewer interfaces that you need to mock. Sometimes you don't need to mock anything.

However...if you accidentally break a tool, or if you take a long time to deliver something that the rest of the team needs, you may have the ENTIRE team breathing down your neck - a very stressful situation.

#5305408 Estimating development time

Posted by on 11 August 2016 - 06:34 PM

Those social features will be 99% of the development time.