I'm not sure anything quite like this has been talked about yet on HMH, but I'm interested in hearing ways to create 'in-game' animations. Imagine an top-down rpg for example, where a character walks to one side of the screen, says something, then walks to another part of the screen, picks something up, etc. How would I specify that kind of thing?
A couple ideas I had were to make the characters controllable, and using some sort of in-game editor, capture the input as I control the characters, and save that input set as an asset or something. Another way would be to create a series of basic operations, such as "change sprite animation to walking left", "move from point 1 to point 2", "create object at point 2", "start dialog xyz" and make them something I could specify in either a text file, or the update function of a separate object that coordinates the animation and the state of the game (e.g. during this section of the animation the main character is not controllable).
What would the "HMH" way of doing things be?
A couple ideas I had were to make the characters controllable, and using some sort of in-game editor, capture the input as I control the characters, and save that input set as an asset or something. Another way would be to create a series of basic operations, such as "change sprite animation to walking left", "move from point 1 to point 2", "create object at point 2", "start dialog xyz" and make them something I could specify in either a text file, or the update function of a separate object that coordinates the animation and the state of the game (e.g. during this section of the animation the main character is not controllable).
What would the "HMH" way of doing things be?
Edited by Daniel Moore
on
If anybody was curious about what I decided to do, I ended up making a "Blueprints Lite (c)" style state machine editor using imgui that integrates directly into the game.
Here's a pic:
Some things I can probably do with this:
Program enemy behaviors
Make animations
Test for win conditions
Make a tutorial
I need to add some ability to call built in functions (play sound, move camera, etc), but already I'm pretty happy with the possibilities. I'm also thinking that I MAY make the graph compile down to C code instead of being interpreted (as it currently is), but I may not even have to, as it's pretty fast right now.
Here's a pic:
Some things I can probably do with this:
I need to add some ability to call built in functions (play sound, move camera, etc), but already I'm pretty happy with the possibilities. I'm also thinking that I MAY make the graph compile down to C code instead of being interpreted (as it currently is), but I may not even have to, as it's pretty fast right now.
Yeah, ImGui is nice!
HandmadeHero-way of this would be live code editing + game reloading. You just put C++ expression directly in code, looking at part of your graph it would be Something = Ball->Signal > Breakout(Player->Position); and edit/save/recompile/reload game dll. I don't remember which day, but I think Casey has mentioned this on stream - that he finds live code edition more powerful than these kind of graph editors for creating and tweaking expressions. You just write what expression you want, press few buttons to reload everything and it works. Instead of moving mouse and clicking mouse button, which would be a lot slower.
HandmadeHero-way of this would be live code editing + game reloading. You just put C++ expression directly in code, looking at part of your graph it would be Something = Ball->Signal > Breakout(Player->Position); and edit/save/recompile/reload game dll. I don't remember which day, but I think Casey has mentioned this on stream - that he finds live code edition more powerful than these kind of graph editors for creating and tweaking expressions. You just write what expression you want, press few buttons to reload everything and it works. Instead of moving mouse and clicking mouse button, which would be a lot slower.
I agree, all this could be accomplished in code, and probably faster. My original thought was that I wanted a way to monitor changes over a long period of time, where I can play the game and periodically check to make sure the flow is working properly. With this I can just visually inspect where my state machines are. In a way, this becomes my debug system - just in a very different form from what Casey is making. If my programming skills were better (hopefully one day), I would instead have have the code generate the graph instead of the other way around.
One benefit is avoiding writing lots of repetitive state machine code like switch statements, state change conditions, etc, which I tend to make a lot of errors on (missing 'break' statements is hard to debug sometimes). On the other hand, all that programming effort must be replaced by making lots of graphs. The BIGGEST reason - and I'm sure you can appreciate this - is that this is less about making a game and more about stretching my programming muscles, and finding excuses to try out things that I don't immediately know how to implement. If I end up with a game in the end, all the better!
One benefit is avoiding writing lots of repetitive state machine code like switch statements, state change conditions, etc, which I tend to make a lot of errors on (missing 'break' statements is hard to debug sometimes). On the other hand, all that programming effort must be replaced by making lots of graphs. The BIGGEST reason - and I'm sure you can appreciate this - is that this is less about making a game and more about stretching my programming muscles, and finding excuses to try out things that I don't immediately know how to implement. If I end up with a game in the end, all the better!