UTMV Fighting Game Progress Update #2 - 10.1.25
Hello, everyone.
It's been a while, hasn't it?
Someone very nice dropped me an ask (on my other blog? I can't find it now) re: how I was doing, so I felt like making a little update post.
I haven't been able to work on things (especially this game) much at all lately between family and work and other stressors, as I mentioned in that ask if you saw it. The thing I didn't mention that might be apparent is that I've just been depressed. But as my therapist tells me, this is a normal thing that happens sometimes and it is temporary.
For now, I figured if I don't have lots of cool progress to show you, I can at least open up a little about where I stopped in the process (because I think it's interesting).
VVVV
So, picture me. A tiny spider sitting at my computer.
I'm done with the basic tutorials of Game Maker and am trying to tackle actually making a game. The kind of game I want to make is relatively complicated, so I decide to make two smaller prototypes that'll focus on the parts of the big game that I think I'll have the hardest time figuring out.
A game that focuses on branching paths based on simple player choices with a short cutscene between each transition and endings that depend on your cumulative choices. (Temp. title: Hands.)
A game that focuses on the actual needs of a fighting game. Stage parameters, moves, epic finishers, etc. (Temp. title: Super Muybridge Fighter.)
I decide early on that I'm gonna borrow the photographic oeuvre of Eadweard Muybridge so I don't have to draw sprites just for some tests and spend a few days scanning in pages from collections of his work I've had lying around since my dad gave them to me high school.
Then what? How do I actually build this thing?
See, the way Game Maker thinks is by association. Every little action and instance needs to be connected to something else. You can't just tell the game to make a little dude walk. You need to associate his walking sprite with his game object, and give that object commands that interact with gravity and movement/positioning (which you have to define yourself) and the ground he's standing on and what room that ground is in and which room he gets sent to when he walks off the screen and how that transition is supposed to be executed. And then you have to remember to tell him to stop walking.
That all in itself sounds complicated, and it gets worse when you think about how to put together an entire game.
But there are ways to organize this. In fact, there are multiple ways. You can use indexes (basically making lists of things you can point at with numbers and tell the program to use) to keep track of different categories of thing and point at them when you need them. You can set up scripts that contain programming you want to use over and over, so you can just hand each little guy a script on how to walk instead of having to teach them all individually. And then there are tools for grouping scripts and making indexes that contain other indexes (maps, I think), and character parenting and instance execution code manipulation and many many other cool tricks to make connecting all your things easier.
In fact, there are so many fucking things to make it easier that it becomes really really hard to know what would be best for what concept and where the pitfalls are. And I realize a lot of that comes down to trial and error (and asking forums).
But I have two ideas. Mostly on how to tackle the branching path concept in Hands.
~~~~~~~~~~
Think of it like a theme park ride.
You, the player, move from room to room--with different actors and props for each room. When you get to the end of a room, you make a choice, and a door appears. As you step through it, you enter a little dark room where a cutscene plays, and then you go on to the next prop-filled room. If an actor must appear in more than one room, they're cloned to be in both places at once with a different shirt and lines to read. The room paths just split and split and split until there are tons of hallways, each with their own discreet end-room and exit door.
(The player object transitions between separate game rooms, and each room uses discreet instances of reused objects placed in appropriate rooms. Use character parenting and scripts for primary functions, edit secondary programming and execution code for specialized functions.)
Higher volume of pathways and copies of things to manage, but each thing has less-complex stuff to do.
~~~~~~~~~~
+++++++++
2. Think of it like a theatrical stage.
There is only one room. The game engine dresses up the room to look like a different room for each scene. When the player, sitting in the audience, makes a choice at the end of the scene, the curtains go down for a minute as they watch a cutscene, and the actors and props rearrange and redress themselves for the next scene.
(The player object is reset to the same room after room completion and choice made, but indexes/maps swap out background textures, enemy objects, characteristic variables, dialogue, etc. Actor objects contain all possible needed functions and dialogue and execute them during appropriate scenes.)
Lower volume of rooms and objects, but more complex use of the objects in play.
+++++++++
Anyway, as I figure out which will hurt my/your computer less (and my head), feel free to chime in with any advice if you have it.
Things are very very tough out there, but stay warm and keep pushing.
<3 Daisy
