Official MICRO-blog THREAD for "Finish Your Damn Game Engine"

Make games! Discuss those games here.

Moderators: Bob the Hamster, marionline, SDHawk

User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

Taco Bot wrote:Obligatory request, if someone hasn't already said it: ability to set animation speed of players/npcs. Would make running at higher framerates way easier.
Even though I wholeheartedly support this request, I figure this is a great time to share with you all a great workaround that you should all be doing with your games now that we can set the FPS ourselves:
My Fake Plotscript, which looks better here as a quote than that 'code' tag does wrote:global variable (1,fpswait)
global variable (2,movespeed)
global variable (3,standardheroset)
global variable (4,waveanimateset)

#tag 2 = slow speed (or original speed that the OHR has been running at for years, 18 FPS)
#tag 3 = normal speed (30 FPS)
#tag 4 = full speed (60 FPS)
#this script assumes that a menu selection for slow, normal, or fast (or 18, 30, or 60) exists and will sync with the speed of the game

#note: speed equals ticks per second

script,how fast shall we go,begin
if (checktag (2)) then(
fpswait := 18
)
if (checktag (3)) then(
fpswait := 30
)
if (checktag (4)) then(
fpswait := 60
)
movespeed := (fpswait/9)
end

#this next script assigns animation sets to variables, where values equal npc walkabout sets

script,quick reference,begin
standardheroset := 0
waveanimateset := 1
end

script,animate my bro,begin
variable (wave)
#let's make the hero walk...
walk hero (0,south,2)
#then let's make him stop...
wait for hero (0)
#then let's make him wave to the camera
set hero picture (0,waveanimateset)
for (wave,1,5) do(
set hero frame (0,0)
wait (movespeed)
set hero frame (0,1)
wait (movespeed)
)
#now let's prep him to move again
set hero picture (0,standardheroset)
walk hero (0,south,2)
wait for hero (0)
end
The idea here is that you can change your animation speed with a quick script modification, or even menu selection, if you plan ahead and use variables for your waits instead of numbers.

That said, I'd still love it if we could affect FPS via plotscripting. Then we could have the players choose their own speed, and then a script like the one above would make even more sense.

I'd also like to see a more sensible walking speed adjustment to the different FPS settings so that 60 FPS doesn't equate to my hero flying across the screen when he's supposed to just be walking. Even at a speed of 1, he'd be walking almost faster than the average speed of 4 at an 18.2 FPS setting, which makes it impossible to set anybody to a more lethargic motion, which is about what most wandering NPCs are set to move at. Not even sure how well pixel-based movement would fix this. One of the drawbacks of being mostly restricted to tile-based movement in a world where games are rated negatively on Steam for not offering 60 FPS gameplay.

For reference, the variable "movespeed" is set to the FPS / 9 to mimic the "wait (2)" command I use for animations in nearly every instance in all of my games, including Tightfloss Maiden, which is best known for its animation.
Place Obligatory Signature Here
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Taco Bot wrote:Obligatory request, if someone hasn't already said it: ability to set animation speed of players/npcs. Would make running at higher framerates way easier.
That will be one of the benefits of switching to the new animation system: the default walking animations will be framerate-independent. In fact I'm just going to retroactively apply that fix to all games. It boggles the mind to imagine how many scripts Pepsi will potentially be able to throw away thanks to animations!

But I still haven't decided out how to replace NPC/hero move speeds with a more flexible system; that will be harder.
Last edited by TMC on Sun Feb 19, 2017 4:34 pm, edited 1 time in total.
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

So hero speed needs to divide evenly into tile size, which is why the only speeds are 1,2,4,5,10,20

Another way to think about movement speeds is the number of ticks it takes to complete a full tile move

Ticks | pixels per tick
20 = 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
10 = 2,2,2,2,2,2,2,2,2,2
5 = 4,4,4,4,4
4 = 5,5,5,5
2 = 10,10
1 = 20

So what if the pixels per tick didn't have to be the same on every frame? What if we wanted a full tile step that takes 7 ticks?

7 = 3,3,3,2,3,3,3

Would that type of movement look jerky? Maybe? But maybe not. And it would still probably be better than not having the option at all.

It would also be possible to come up with a system that works for other tile sizes too
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

I can't imagine that being noticable jerky, especially not at high framerates. Ticks per tile could work, and it seems like it has a broad enough range of speeds, although the gap between neighbouring speed becomes large for very fast movement.

But I was hoping for a solution that's independent of tilesize and especially framerate.

I decided that animation waits should be measured in milliseconds which then gets translated to frames according the the 'nominal' framerae, meaning the target framerate not the actual one that the program runs at on a certain computer. So that the animation rate is always fixed relative to the game logic.
This means that if you change the framerate for the game, then the number of seconds an animation plays might change a bit, especially if there are single-tick delays, but overall the speed is about the same. And no data has to be updated.

So the same thing could be used for move speeds: display frames per tile, but store everything in ms per tile. Make the units ms per 20 pixels instead and you get tilesize independence for free!

Also, the reason that we require to move in complete tiles per X ticks is that firstly our collision checking breaks down otherwise. But if we fix that, then we can allow arbitrary speeds. If an NPC/hero reaches the destination tile with some movement left over then that can be credited to their next movement if they move immediately.

But the problem with ticks per tile is that it's inverse speed, not speed. It's harder to compare/reason about.
So a different option might be pixels per second. E.g. the default speed of 4 at 18.3fps is 73 pixels/s. This can then be converted either to pixels per frame or ticks per tile, which is actually displayed/edited, like animations.

It seem that any solution is going to mean get/setherospeed and read/alternpc(npc, NPCstat:movespeed) commands will be obsolete and need replacements. That's OK.

-----

I started on the proper animation editor (what I showed before was really a very early start on the new spriteset editor which could play animations)

Image

There's heaps of work left to do.

Also, today I implemented one-way walls. On a whim. Because [s]Brotoad[/s] April was asking how to do that. This is a new per-tile flag, which turns all the walls on that tile into one-way walls. The flag is actually a special zone.

Image

A funny thing: it only took me 10 minutes to implement a fully working prototype by repurposing the obsolete 'O' overhead bit, including a per-map option to enable one-way walls and disable the overhead bit. Then I threw that all away and reimplemented it using a zone, which took something like 5 hours, probably mostly due to the necessary user interface work, as well as endless problems and more deadends, etc.

Oh and I also implemented sound effects volumes, though that's not complete (eg no script commands yet), so more on that later.
Last edited by TMC on Tue Feb 21, 2017 12:44 pm, edited 1 time in total.
User avatar
The Wobbler
A Scrambled Egg
Posts: 2817
Joined: Mon Oct 15, 2007 8:36 pm
Location: Underwater
Contact:

Post by The Wobbler »

TMC wrote:Also, today I implemented one-way walls. On a whim. Because Brotoad was asking how to do that. This is a new per-tile flag, which turns all the walls on that tile into one-way walls. The flag is actually a special zone.

Image
Love this.
User avatar
RMZ
King Slime
Posts: 1695
Joined: Tue Oct 16, 2007 12:39 am
Contact:

Post by RMZ »

Will there be additional frames added to the heroes for animation? How will this work exactly in terms of graphics. Will the designer be able to pull from other sets? If so... wouldn't that be messy when we script changes to hero sprites?
User avatar
Taco Bot
Meat, Cheese, and Silicon
Posts: 484
Joined: Fri Jul 18, 2014 12:15 am
Location: Santa Cruz
Contact:

Post by Taco Bot »

TMC, you're my hero.

Also, quick question. How difficult would it be to up the hero definition/reserve limit? Would it kill backwards compatibility or something?
Sent from my iPhone
User avatar
guo
Metal Slime
Posts: 749
Joined: Fri Dec 04, 2009 9:12 pm

Post by guo »

One way walls, amazing.
vvight.wordpress.com
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

RedMaverickZero wrote:Will there be additional frames added to the heroes for animation? How will this work exactly in terms of graphics. Will the designer be able to pull from other sets? If so... wouldn't that be messy when we script changes to hero sprites?
I can't speak for TMC on this one, but I am pretty sure that the plan does NOT include pulling animation frames from other sets-- but it does include the option to add more frames to sets
Taco Bot wrote:TMC, you're my hero.

Also, quick question. How difficult would it be to up the hero definition/reserve limit? Would it kill backwards compatibility or something?
This is something I was working on before I got sidetracked.

First the item definition format has to change
That will allow room for the equability bitsets for more than 60 heroes.
Then the number of hero definitions can be increased.

As for the limit on the reserve size... I actually can't remember any remaining barriers to that, it is just a matter of finding all the places where the current reserve size limit is hard-code and updating them to a variable limit.

More heroes is still high on my to-do list, I just don't know when I will be un-distracted again
User avatar
RMZ
King Slime
Posts: 1695
Joined: Tue Oct 16, 2007 12:39 am
Contact:

Post by RMZ »

Bob the Hamster wrote:
RedMaverickZero wrote:Will there be additional frames added to the heroes for animation? How will this work exactly in terms of graphics. Will the designer be able to pull from other sets? If so... wouldn't that be messy when we script changes to hero sprites?
I can't speak for TMC on this one, but I am pretty sure that the plan does NOT include pulling animation frames from other sets-- but it does include the option to add more frames to sets
So if this is right, then theoretically we could customize hero sprites pretty much to no end. I hope this is right. It sounds awesome.
User avatar
FnrrfYgmSchnish
Metal Slime
Posts: 741
Joined: Thu Jun 18, 2009 4:37 am
Location: Middle of Nowhere

Post by FnrrfYgmSchnish »

Wow, customizable animations and possibly expanded hero definitions/reserve coming soon -- all kinds of great news in these last few posts!

One-way walls are a pretty neat addition too, sounds like they'd be good for a sliding-down-a-hill-of-slippery-sand sort of effect where you can't walk back up the hill after you've hit the bottom. Good to hear they won't actually be replacing the overhead tiles, too.
FYS:AHS -- Working on Yagziknian NPC walkabout sprites
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

As James said, increasing the number of hero definitions is far more work than increasing the size of the reserve party, although I don't know how much work he's already done on rewriting items. Larger reserve parties could happen soon, but it's personally not on my near-term todo list.

Huh, I didn't think that that many people would have a use for one-way walls, because in many cases where you might use them, like slipping or jumping off a ledge you would still want to write a script to do a simple falling animation, etc. It would definitely reduce how much you need to script, though. (Also, you're also using the overhead bit Fnrrf? I wonder how many people still are)

I now regret implementing one-way walls using a zone; it would have been better to use expand the passmap to use 2 bytes per tile instead of one. We'll want the extra bits for more features in future anyway.
Right now the one-way flag doesn't behave at all like the other wall bits in the map editor, meaning for example none of the drawing tools work with it. It'll be a pain to fix that, which it turns out is going to require making the passmap virtually behave as if I HAD expanded it... understand my regret?

....
RedMaverickZero wrote:Will there be additional frames added to the heroes for animation? How will this work exactly in terms of graphics. Will the designer be able to pull from other sets? If so... wouldn't that be messy when we script changes to hero sprites?
That last bit is an excellent question. In fact the first time we were planning an animation system, a decade ago, the whole conversation and proposal died when James asked the same question and we couldn't answer.
Different spritesets could have different numbers of frames, which is problematic.

It would be possible to add a Transmogrify animation command to permanently switch to a different spriteset, but this would be drastic, cancelling the current animation if it's specific to that spriteset. But a command like "show frame X of spriteset Y" requires keeping lots of extra state, so I won't be doing that. Why do you want to share frames between spritesets?

My solution involves putting frames into groups/ranges, with consecutive ID numbers. So in existing walkabout sets, the Up frames would become frames 0, 1, Right become 100, 101, Down are 200, 201, and Left are 300, 301. Now you can add some more frames for three-frame walking by adding 2, 102, 202 and 203. And add more groups with IDs 40x, 50x, etc for completely separate animations. You will be able to create an animation out of a group of frames with a single animation command, or specify a frame by ID number to jump between groups. I hope I can make all this obvious and simple; honestly I've been uneasy about it for a long time. I still haven't decided whether to allow assigning arbitrary ID numbers.

So, if you switch between different spritesets by script the current frame can be matched up easily, to the same or nearest ID. And you can define a single shared "walk left" animation for all walkabout sets that works for all of them. If you want an animation to continue running whether you switch spriteset, then you need to define it as a shared one and make sure the appropriate frames have ID numbers that match up between animations. Otherwise the animation will stop and the Idle animation will start.

....

Related: I've always found the flashing walls in the wallmap editor annoying, but there's good reason that they're so thick: against some tilesets, walls which are less glaring wouldn't stand out easily. But why not make that customisable instead?

Image
(+/- keys to adjust wall thickness)

....

OK, I've committed all my sfx effects volume stuff. There are also two new menu options, "Music Volume" and "Sound Volume". A lot of cleanup went into the audio backend code.
Still not done: the ability to adjust the volume of individual songs and sfx in the editors, script commands, and maybe advanced features like panning and playing the same sound multiple times at once.
(If anyone wants to implement those script commands, this should be an easy task; I'm not going to get around to it for a while)

The existing Volume option in the main menu only affects music Volume*, but I wanted the ability to set the SFX volume in existing games, so I added another menu which you can access by pressing Enter on Volume. (That menu is not customisable; if you don't like it don't use the old Volume option).
I'm a little bit uneasy about sort-of changing the main menu in existing games, but I think it works out OK:
Image
I almost removed the bar behind the old Volume, to force you to use the submenu: Notice that there are two music volume bars on-screen which both update, which looks weird.

(* BIG caveat: On Windows Vista or later, the ability to independently set the MIDI volume is gone, so changing the volume while a MIDI is playing changes volume of all audio for the program. This is basically impossible to fix in music_sdl, but I think music_native2 is OK since it sets per-note volume instead. Strangely, I only hear people who play ports of DOOM complaining, as if no other games use .midi music anymore.)
Speaking of which, when was the last time anyone used music_native or music_native2? They now only play MIDI for me. I want to revive them on Windows.

You can now adjust the volume in Custom too. You know, it would be nice to be able to access the volume setting from *anywhere* in Custom. Hmm, I can think of some other things I want everywhere...
Image
(Press F9.)
Adding options to go directly to the various editors is a bit more work. It'll happen someday!
Pepsi Ranger wrote:Yep, you should allow designers to name that particular NPC, right up there with appearance. We can name everything else, like heroes, villains, attacks. Let's name NPCs, too.
I forgot to respond, but that's a good idea and actually pretty easy, so I hope someone adds it :)

....

OK, that's a bit much, time for me to take a break from working on the OHR for a while.
Last edited by TMC on Tue Feb 21, 2017 1:03 pm, edited 8 times in total.
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

TMC wrote:Huh, I didn't think that that many people would have a use for one-way walls, because in many cases where you might use them, like slipping or jumping off a ledge you would still want to write a script to do a simple falling animation, etc. It would definitely reduce how much you need to script, though. (Also, you're also using the overhead bit Fnrrf? I wonder how many people still are)
I still use the overhead bit. It's the best way to hide NPCs who already have both of their appearance tags in use. Specifically, I stick them up in the corner of the map where no one will see them anyway, and then play extra cautious with the overhead tiles. Most of my maps have coordinates X0-X3 or 4 on rows Y0 and Y1 under overhead blocks to hide all of the people I don't want being seen. Do I have to do it this way? No. But it's easier to keep track of things if I know I can put them in the corner when I'm not using them. The overhead bit makes it easier to hide them without worrying how the tile looks or what layer I've assigned to it to hide things.
Place Obligatory Signature Here
User avatar
RMZ
King Slime
Posts: 1695
Joined: Tue Oct 16, 2007 12:39 am
Contact:

Post by RMZ »

I use the overhead bit all the time too. Heck, the entire top left of the map of Surfasaurus is that to hide all the townspeople.
User avatar
Newbie Newtype
Reigning Smash Champion
Posts: 1873
Joined: Mon Oct 15, 2007 9:44 pm

Post by Newbie Newtype »

I used the overhead tile as well. It's useful for hiding the hero and walling them off from appearing in the rest of the game when I still want to use the hero walkabout for the default quit screen.
<TheGiz> oh hai doggy, oh no that's the straw that broke tjhe came baclsb
Post Reply