Jump to content

  • Log In with Google      Sign In   
  • Create Account

Nypyren

Member Since 19 Aug 2002
Offline Last Active Today, 02:29 PM

#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
Akka.NET

...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.


#5304818 What Would You Do If...

Posted by on 08 August 2016 - 10:44 PM

Of course, Nypren, that is common in many board games as well.  An un-played card with instructions to be executed during a future phase is that same thing happening in a board game.


OK, so I'm not sure why you bothered to use it as an example, then. You need to eliminate irrelevant information from your descriptions if you want people to listen to you properly. If you go off on tangents, people trying to listen to what you're saying will get distracted, then impatient, then will stop listening.


#5304795 What Would You Do If...

Posted by on 08 August 2016 - 07:54 PM

I really am just seriously looking for advice with what you do with such an important and unbelievable discovery


- Make a game with it, publish the game, make $, retire rich and happy. This is the best option, as it proves to everyone that your idea works in practice.
- Make a middleware package with it, license it to game developers, make $, retire rich and happy. More difficult option - it requires convincing people to try it.
- Open source it.
- Keep it secret, keep it safe.

Those are pretty much the only options available.


#5302978 Separate 32 Bit And 64 Bit Versions

Posted by on 28 July 2016 - 01:43 PM

I found this discussion on compiling for "Any CPU" vs. 64/32 bit:
 
http://stackoverflow.com/questions/516730/what-does-the-visual-studio-any-cpu-target-mean
 
It seems I can get away with offering 1 version. I just have to detect the system ingame so I can restrict the large maps to 64 bit systems and thereby prevent out of memory crashes.


As long as all of your DLLs are also 'Any CPU' it will work. If any of your DLLs are 32-bit, you'll crash if your EXE launches in 64-bit mode (and vice versa). You'll get a BadImageFormatException when the process discovers that it can't load the DLL.

There might be a way to provide alternate DLLs per architecture using the manifest, but I haven't tried that.




PARTNERS