# JoshGrams

Member

16

8 Neutral

• Rank
Member

• Interests
Design
Education
Programming
QA

• Github
JoshuaGrams
• Steam
joshuagrams
1. ## A Brief Introduction to Lerp

Note that your "springing toward" example (lerping a fraction of the remaining distance each time) is highly frame-rate dependent. So if your game isn't frame-rate locked (i.e. web-games running on machines with different monitor refresh rates, or even a locked 60 fps game running on a machine too slow to support it) different people may see different behaviors. The spaceship rotation in George Prosser's DRILL_BIT, for instance, is much harder to use on a slow machine. And the way you're doing it, scaling by the deltaTime, will only partly correct for that. For instance, if your framerate is twice as fast (deltaTime is half the length) then you actually need the square root of the rate (you lerp twice in the same time, essentially multiplying by the factor twice, i.e. squaring it). In the general case you need Math.pow: // Return a lerp factor for the given frame time which will result in // the value getting convergenceFraction of the way to the target in // smoothTime time units. I usually just use 0.9 or 0.95 for the fraction // and vary the smoothTime to get the effect I want. function smoothOver(dt, smoothTime, convergenceFraction) { return 1 - Math.pow(1 - convergenceFraction, dt / smoothTime) } For further adventures in non-linear interpolation things, Squirrel Eiserloh's Fast and Funky 1D Non-linear Transformations GDC talk is well worth a watch. Although note that with his later (curved) functions, he only mumbles once that he's "normalizing" them (meaning scaling them up so they are exactly one unit tall). Without knowing that, if you try to use some of the formulas he gives as written, you'll end up with something very flat that does almost nothing. But he gives a good intuitive introduction to how to think about constructing some of these things.

3. ## Too busy this week

Yeah...this week was just too crazy. I got a certain amount of time in, but it was all 20 minutes here and 40 minutes there and was just too fragmented for an idea this math heavy. On Friday I sat down and re-evaluated and sketched some level designs and progression on paper. I still think the idea has merit, and I still think I could have accomplished it in a more normal week. But family and work come first, so that's OK. I'll keep working on the idea. And maybe next year I'll try again and actually finish something. It has been a lot of fun skimming through everyone's progress, though I haven't made the time to comment. Best of luck to you all!
4. ## Day 1 - Do not use physics engines for platformers

One approach I've seen that seems to be a common thing with GameMaker on the tigsource forums (Zach Bell popularized this over there, I think?) is that if you hit an obstacle while moving sideways, try moving it up as well as sideways and rechecking the collision. Hrm. I think most of the stuff I've seen was only moving one pixel at a time (pixel-art stuff, so 60 pixels-per-second is fairly fast) but you could maybe extend this to more normal graphics (binary search?) without being *too* expensive. Dunno if that's helpful, but thought I'd mention it...
5. ## WoA V - The Competition Thread

Not as much progress as I had hoped, but I got a little bit of a start.
6. ## Game idea and...not much progress.

I'm going for Castles and Chain Reaction, with a game where you solve Slitherlink puzzles on free-form graphs indirectly by making big-picture deductions (this corner is even; this one is odd; here's a loop for the Jordan Curve rule) to let your robot bulldozer sidekick build sand-castle walls by chaining local deductions together. This isn't quite as simple as I wanted, so I may be slightly over-scoping. But slitherlink has been my favorite logic puzzle for years and I've always wanted to do something with it. And I *think* I have a pretty good handle on how to structure the graph data. So I'm going to try it. I haven't had a good first day: I came up with the idea, and have spent a bunch of time mulling over implementation strategies while doing the more repetitive farm work. But then we spent a whole chunk of the afternoon chasing down and catching a stubborn young steer, and now I'm beat. I put in about an hour and got some of the basic code structure in place, but I'm half falling asleep at the keyboard. So I'm going to bed now and I'll get up early and do some work first thing in the morning while my brain is fresh.
7. ## Strawberry Alert: Day 1

Looks like you managed to match the walking speed with the animation's foot movement pretty well: doesn't look all slidy like they often do. Nice!
8. ## Counting down from 2^6 hours...

Thanks! Yeah, feature creep and perfectionism can be major problems for me. Looking forward to seeing what you come up with this year: Gamut of Blob was pretty neat. Yeah, coding is mostly a hobby, though I like the theory and algorithms, and I'm kind of a language junkie, so I often find I know more about the inner workings of libraries and tools than many of the people who use them in their work, but then of course I have way less practical experience, and almost none at all on large-scale projects. :-) Do you do coding professionally? I sort of get the impression from discord that most people there do...

I wanted to make sure I was set with the blog system here for progress reports, so I made a pre-jam test post: Counting down from 2^6 hours.
10. ## Counting down from 2^6 hours...

There are about 64 hours remaining until the fifth Week of Awesome starts! I'm excited. I'm new to this jam (and gamedev.net in general), but I've done other small quick games. My folks run a small farm and Saturday/Sunday/Monday are our busiest three days with weekend retail sales and harvesting for the Monday wholesale deliveries. So while I've made four or five attempts at things like Ludum Dare, I just don't have the time on weekends and I've never completed one. A 7-day jam seems like more my kind of thing, even though we're shorthanded with most of the family away on vacation and this week is going to be crazy. As a programmer and mathematician I tend to get distracted by implementing interesting algorithms (e.g. Starling Burst for Daniel Pearce's new flocking model) and then never get around to making an actual game around them. But recently I have done a few little 1-hour toy/game things: Catching Flies, RGB Jet, Avalanche (Windows, love file), Gas Buffer (4 hours), so I feel like I've gotten the hang of making a very small working prototype. For this jam I want to try and stick with simple mechanics and try to focus more on content, since that's where I usually stop. I'll be using the LÖVE engine, which has become my tool of choice for quick 2D prototypes. It's a code-based engine, so it doesn't have an editor and doesn't have a lot of stuff built in. It's more like SDL or SFML, but with Lua. It does have Box2D built in, and there are other collision libraries available, plus I've written continuous collision for circles, and I have a demo with the Minkowski sum thing for configuration-space obstacles using convex polygons. So I have options there. And Lua is quite a nice little language once you get past the no-operator-assignment thing (It doesn't have +=, -=, etc) and learn to stop making fencepost errors due to its 1-based indexing. And the whole thing is nicely cross-platform. So...yeah. Probably not a great tool for everyone, but I'm comfortable with it. Hmm, what else? Maybe a bit about me? I've been a pretty serious hobby programmer since I was 13 when we got our first computer (a hand-me-down from my grandfather) in September of 1993, so almost 24 years now. Messed around with all sorts of languages from Basic to C/C++ to five or six different assembly languages to things like Prolog and Haskell, and of course most of the scripting languages. Spent a bunch of time playing with Forth and implementing toy Forth systems. Studied math at university, did a couple of years of web development after I got out of school. Wasn't a big fan of the desk job thing, and am now farming full-time on a small market-garden and family homestead on a lake in Maine with a couple of acres of vegetables, a couple hundred chickens, family pigs and cows. So...yeah. Best of luck to everyone!
12. ## What makes a combat system for fighting games?

That sounds like a reasonable explanation of the collision and animation aspects, but you left out one very important point: fighting games are pretty much always built around a circular rock-paper-scissors aspect so that every attack has a counter and it is a mind game to anticipate what your opponent will do next. The usual set is punch-block-throw (block stops a punch, throw ignores blocks, punch beats a throw), but you could presumably do other things, adding in more than three options, or having a different three actions. David Sirlin (http://www.sirlin.net/) has a bunch of writing about the design of fighting game systems and balance. You have probably seen his work, but if not, you should definitely check it out. Edit: He even implemented the punch-block-throw cycle as a turn-based card game called Yomi where both players select a move from their hands and lay it face down, then reveal them simultaneously. It has combos, more and less powerful moves, the whole deal. It's interesting to see that you can have the mind game without the reaction time parts. IIRC you can try it for free with limited character choices both as printable PDF cards and in the online version. Edit: Also (and this is minor) I think the tone of your piece could use a little work. It's not bad, but it feels a little amateurish with the vibe of "I experimented and thought things up and here are my ideas" when everything in it is pretty standard fighting-game mechanics. I couldn't find it in a quick search, but there's an article on the internet somewhere that covers almost exactly this same ground, using debug screenshots from one of the Street Fighter games (I think?) as examples. So some acknowledgement that you've done your homework and aren't just reinventing the wheel would make it feel more solid. And the anticipation/windup frames add a delay between the button press and the actual action, so in games with network play it also serves the purpose of helping deal with network delay and reducing the chance that the game has to be like "Well...we showed you kicking him, but actually he punched you in the face three frames ago, we just didn't know it yet, so...sorry!".
13. ## Quadcopter simulation and PIDs

That's the velocity needed to travel from Q to O in one time unit. Which...is probably not what you want? But yes, if you want to move at a certain velocity then your setpoint would be the target velocity and your process variable would be the current velocity. But then you have to figure out how to set the target velocity over the whole path, and it's not so great for maintaining position. I would more likely have the setpoint be a target location (and orientation) and the process variable be the current location. Then you can plan a path and move the target along it at a comfortable cruising speed and the PIDs should make it follow fairly nicely. Also, the "apply 1/4 force to each rotor" isn't exactly correct. Maybe you were just glossing over the details? To accelerate, you need to tip the quadcopter in the direction you want to accelerate and then apply enough force to the rotors to maintain height. So the horizontal acceleration you get is based on the orientation as much as the rotor lift. 2) I would think you would use the cross-product of the yaw (up) axis and the direction that you want to go to get an axis of rotation. Then convert axis-angle (I want to tilt this much on this axis) and convert to yaw/pitch/roll so you can apply it to the rotors easily (left/right pairs and forward/back pairs). Here I would definitely feed the orientations to the PID rather than the angular velocities. You can probably get away without worrying about gimbal lock for a while since you'll only be making small orientation changes. But if something bad happens (you crash into something, or whatever) then you might run into trouble. 3) I would do this empirically: that's kind of what the PID is for. Feed in the target orientation and the current orientation, and then tune the PID until the output values give you nice behavior. IIRC Wikipedia has a procedure for manual tuning that works pretty well. 4) Yes, the linear axes are independent, so one PID for each. There might be some better way to do the angular one? But one per axis should work well enough to get you up and running...