Jump to content
  • Advertisement

JoshGrams

Member
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

8 Neutral

About JoshGrams

  • Rank
    Member

Personal Information

  • Interests
    Design
    Education
    Programming
    QA

Social

  • Github
    JoshuaGrams
  • Steam
    joshuagrams
  1. JoshGrams

    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.
  2. Have you played other traditional roguelikes? Because...even for a stripped-down version focusing on one mechanic, my first reaction is that there's not much here. 20 items is emphatically *not* a large inventory, while 100 total items is a somewhat large number, but not exceptionally so. And for a game that's supposedly entirely about loot, it doesn't look like there's actually any inventory management involved, and very little gameplay about what you choose and what you leave behind. In Nethack you can have up to 52 stacks of items, plus more if one of those items is a bag. You'll usually run into the weight limits long before that, but your inventory often doesn't fit on a single screen. There are 10+ *categories* of items (amulets, weapons, armor, potions, scrolls, wands, rings, gems, tools, food), with 30-50 items in each class. Even lighter games often have more than this; in Caveblazers you have a 5x6 (30-item) inventory, plus 5 slots for your active items. And it doesn't come across as very polished: the trails are nice, but the pixel art is workmanlike at best. Needing to use a red glow around live enemies says that you didn't do a good job of differentiating between live and dead versions of the enemy sprites. OK, there aren't a lot of pixels there, but they could have been desaturated, or could simply fade out completely: it's not like you are going back to loot the corpses, so you don't have any need to know where they were. The text is quirky and fun, but you didn't pick consistent terminology and stick to it: sometimes you call it speed and sometimes initiative, leading to one Youtuber saying "initiative trials? Does that mean we're like in some sort of initiation training area, and it will get harder later?" The stat icons are cute, but most people who didn't stop to look at the initial help (and some who did) were just confused and had trouble remembering which is which. They're fine in the long run, but don't make a great first impression. I saw at least one person simply decide that the black potions were poison in one of the first couple of levels and carefully avoid them for the rest of the game. Neither the lightweight mechanics nor the slight rough edges are *necessarily* a problem. But in combination...it feels like you didn't define your audience carefully. I don't *think* it has enough depth to really hook the crowd that plays nethack and ADOM and DCSS, nor is it shiny enough and play up to its name and theme enough to really catch the eye of the people who are looking for something that "you can *almost* but not quite play on autopilot" (as Alec Meer said on RPS). It's clearly a good game, I'm just not sure it has anything that makes it stand out from the crowd enough to sell well. Not that I have *any* idea what I'm talking about, but that's my two cents anyway.
  3. JoshGrams

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

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

    WoA V - The Competition Thread

    Not as much progress as I had hoped, but I got a little bit of a start.
  6. 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. JoshGrams

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

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

    Week of Awesome V - Administration Thread

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

    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!
  11. JoshGrams

    Game-Based Learning to Hit $3.2 Billion in 2017

    Heh. I like to read reports about that sort of stuff, but only casually, so not at $500. Oh well. Sounds like an interesting piece of work though.
  12. 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. JoshGrams

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

    Abusing -1 rep

    I'm guessing you're familiar with the stackexchange model? If not, it's well worth looking at. You can argue with some of the ways that it gamifies things and favors quickly-posted answers that look good enough to get accepted vs. longer more thorough ones (though I'm not convinced that there's any way around that). But otherwise I think it works pretty well. New users can't be nasty right away; and downvotes are both weaker than upvotes and cost reputation to cast. You can earn a max of 200 reputation per day, and reputation can never go below 1. You gain reputation from having your question upvoted (+5), your answer upvoted (+10), your answer accepted (+15) etc. You lose reputation from having a question or answer downvoted (but only -2). Upvoting is free, but downvoting an answer costs 1 rep (downvoting a question is free because they want to encourage people to prune bad questions). You get to cast a max of 30 votes per day (I believe most people never come close to hitting that limit). You start off with no voting privileges at all. You can post questions and answers, that's it. You get the ability to upvote at 15 rep, the ability to comment on people's questions and answers at 50, and don't get the ability to downvote until 125. More here: https://stackoverflow.com/help/whats-reputation https://stackoverflow.com/help/privileges/vote-down
  15. JoshGrams

    Week of Awesome V - Administration Thread

    LÖVE has been my tool of choice for quick 2D prototypes for a while, so I'll stick with that. It's easy to throw in some bfxr sound effects, and I'll probably record some things for foley and sound effects and muck about with them in Audacity. Might noodle around on the piano for music if I get that far (there are also a couple of guitars, an accordion, a flute, and a trombone around, but I don't *really* play any of those). Probably Gimp for art since I haven't gotten around to digging up an old version of Krita that runs on my integrated Intel HD 3000 graphics. But I'll leave graphics until later on in the process, so if I get around to coding the shaders I might do some simple Blender models and render them to normal-mapped sprites, since even just basic diffuse lighting always adds a nice touch.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!