Jump to content
Stray Fawn Community

Super Powered

Member
  • Posts

    12
  • Joined

  • Last visited

Reputation

9 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. So not directly related to Nibatus, but the other day someone posted this on the programming subreddit, and all I could think of while watching it was Nimbatus: It's just a (really well done and simple) explanation of how binary works and more importantly, goes into the details of how to make XOR gate and such, which I think is all pretty useful knowledge when building drone logic. https://www.youtube.com/watch?v=QZwneRb-zqA He also has one now for memory, building off of the first one, and it is equally as excellent.
  2. Same boat, and I agree. The reality is I kind of like having the blocks for the logic. I've actually been having my son take a stab at the game, and the blocks are something he can at least (somewhat) comprehend. I'm hoping it helps set up a better foundation for logic based thinking going forward... I mostly think we just need some more advanced parts. Parts that can store and manipulate variables, parts that can loop and iterate, parts that can store a set of logic as a function. Right now we're basically just writing giant if statements, which is fine and all (I mean, That's basically all that they used for the Age of Empires AI) but it's cumbersome, for sure.
  3. ༼ つ ◕_◕ ༽つ GIVE TEMPLATES ༼ つ ◕_◕ ༽つ
  4. This is also a good idea. Just in general the fact that you can make it so far in the campaign without touching fetch missions is a problem in itself.
  5. Right now if you make a drone that launches drone's via a factory or decoupler, you can't really see it's center of mass due to the rest of the robot. Could add a "fake part" or something similar that you attach to a part that notes that any of it's children calculate their own center of mass.
  6. Yeah, that's specifically why I called the "destroy x" missions out. You can currently get all the way to the last mission in the game by doing destroy missions. Also why making it an incentive would likely work better than a punishment. The reward / punishment would need to scale with the type of the mission, allowing collection missions & fetch missions to allow for more parts.
  7. Currently the programmer class feels a little to "easy" on "destroy x" missions in particular. Since there isn't any restrictions on how many parts you can add, and there is no deploy cost, you can basically make a single robot with an amount of weapons and a bunch of spinning lasers and fuel tanks and it can pretty much handle 90% of the destroy missions from the first to the last. Would be nice to give incentive to build smaller "meets the purpose" robots that use as few parts as possible. Maybe a pool of red ore that diminishes with every part added? Could likely exclude logic parts from this count. The inverse is to re add the deploy cost, but put it at a notably higher number. (and once again, could likely exclude logic parts from the count)
  8. This would be nice. Add a "priority" field to each battery/shield. Drain higher priority ones first, falling back to "first added" for parts in the same priority index
  9. Would love the ability to add a label to each part, so when I cursor over it I see the label I assigned it. Label doesn't need any functionality attached, just simply the ability to quickly look at a part and see what I named it without having to click it, look at the inputs and outputs, and then discern what it's job is, lol.
  10. Currently I handle this by using trigger gates to cycle between the various camera, (assigning a differnent key to each type of drone) But I agree it would be nice to have a logic part that can cycle through an array of cameras assigned to a key
×
×
  • Create New...