Jump to content

sherkaner

Members
  • Posts

    164
  • Joined

  • Last visited

Everything posted by sherkaner

  1. Is it just me, or does XP gain generally seem a lot less... granular than you expected? I figured it would be a thing of having levels at, say, 10, 100, 1000 xp with many types of activity granting XP, with diminishing returns for doing the same thing. As it stands, it seems like there are only a handful of XP points that it's possible to get, with zero gain whatsoever for duplication. It feels really odd that I can fly 20 different orbital missions with my pilot, but I still only get any XP at all for that first flight. Basically it seems like the game just tells you "nope, there is simply no way to have a pilot worth a damn until you get him to the moon somehow" which is kind of bizarre and constraining. While you'd want to avoid exploiting easy missions, I would think that players would at least have some option of "grinding" XP on their astronauts to get their skills up. In fact that seems like one of the main ways an inexperienced player would pull themselves out of being "stuck" when they have done the easy missions -- at the least they could (slowly) level their guys up a bit to make the more difficult missions easier and more lucrative to complete.
  2. Hm, so maybe this is ultimately a feature request then. CAD controls are only counter-intuitive if you don't spend much of your life in them. I certainly wouldn't want to force them on anybody, but the option would be very nice especially since I bet KSP has more than its fair share of engineers playing it. I'm on OS X, not Windows. Might be some remapping tool for that as well, although I'd really rather not have to go to that if I don't have to...
  3. I wager this must be a trivial question, but I can't seem to find an answer here or elsewhere: KSP lets you freely reassign the key bindings for just about everything in the game, but I don't see where I can customize the mouse controls much at all. Particularly for the VAB/SPH, I'd really like to change the mouse controls for rotate/pan/zoom. I imagine many are perfectly fine using the default assignments, but for somebody who does mechanical CAD at work all day, it's really disorienting to come home and have everything switched around when building stuff in KSP (I've caught myself at work a couple of times trying to use Kerbal controls in SolidWorks... ahem). I'd really love if I could assign combinations of mouse buttons and control keys to these functions (SolidWorks standard is middle-button for rotate, control-middle-button for pan, scroll-wheel for zoom). Is there any way, in-game or otherwise, of doing this?
  4. Is there anything else Squad needs to narrow this down; anything we can help test? At least for me this is distinctly a new thing in beta -- I never had crashes before. But maybe I just hit some memory threshold, although as others have said it doesn't seem like a physical limit as I have 16G and KSP doesn't seem to get close to using it.
  5. Agreed. I think part of the reason we're all pretty eager to bring this up now is that technically speaking it's relatively simple -- but gameplay wise I think it might end up being a core element around which everything else gets balanced. Once you settle on a tree like this to maximize flexibility, you can start thinking about how things actually get unlocked (such as my earlier R&D idea in this thread), how much things "cost" (in science, money, time, etc.), and the stats on the parts and parts options themselves. So now that we're in beta, I'd love to see the game start the probably-sooner-rather-than-later gameplay balancing process with a really solid tech tree like what we're discussing.
  6. Glad I'm not the only one seeing lots and lots of crashes on OS X with the beta. There doesn't seem to be any rhyme or reason -- sometimes loading a new scene, sometimes when just messing with a build. Hasn't happened in flight thought, now that I think of it.
  7. I just want to say that with the beta release, I started my career over again and it makes me want the tech tree system we've been discussing here so much more even than before. The current tree feels so arbitrary and constraining -- and not just in the way of making the game "hard" (I love the difficulty of the new moderate/hard modes), but in that I feel so limited in how I can go about things. Especially with the new Fine Print contracts, I keep wanting to build small simple aircraft to do flyovers, or try out clever ways of meeting contract requirements on a tight science/cash budget. But I'm constantly feeling like the tech tree virtually forces me to take a very plodding tech tree progression of filling out the lower limbs before going any further because there's some silly utility part that I need. Hopefully there isn't a belief that "bundling" tech tree parts as the game currently does is a game balance method. I think the per-part tech tree we've been discussing here could very easily be balanced with various costs while still giving the player the full freedom to develop technology in the direction of their choosing.
  8. Uh, I'm not sure why this was a reply to me since it didn't seem to have much to do with what I was saying. I'm quite aware that we're not getting anything close to a Navier-Stokes equation solution -- that's why I said "even if". But yes, you are factually correct with everything you say. Although it seems like your conclusion is that we might as well give up because nothing short of an accurate simulation is worthwhile? That seems a bit silly. The problem to be solved is trying to create something as good as possible within constraints of processing power and there are absolutely ways of approaching that problem. Toy models for the different aerodynamic regimes and effects should be able to get you a lot closer to something satisfying than what we have. Will there be edge cases and deviations from real behavior? Sure. But hopefully these can be minimized and at least kept within relatively sane boundaries so that the craft isn't doing anything patently nonsensical.
  9. I don't disagree with you, but it's not quite as simple as that. Even if Squad could simply load up the Navier-Stokes equations and have perfect aerodynamics applied, you would have problems because the craft themselves are greatly simplified from real-world craft, of necessity to make the whole modular easy-to-build Kerbal system work. In the real world, very fine details of craft design can have a huge impact on performance and that's just not practical or appropriate for KSP. So there has to be some kind of simplified model for that reason, as well as simply for processing power and having a more forgiving version of the world for gameplay reasons. The question (I believe) is to figure out how to best model an approximation of reality, even if it is not technically speaking fully realistic. I absolutely agree that people coming in with varying levels of familiarity with physics shouldn't be disappointed by incorrect behavior -- that was very much the point of what I wrote.
  10. I tend to think that there's not much point in us debating implementation details, since Squad (and perhaps a precious few modders like Ferram) are about the only ones with the basis to consider that with any confidence. In terms of what a player actually experiences, I think the focus should be on an aerodynamics model that adds fun through a sense of reality. Note that "reality" is not necessarily the same as having "realistic" aerodynamics. But I think people love that when something in KSP is hard or counterintuitive (such as orbital dynamics), once the hurdle is overcome there is a feeling of having mastered something "real" (you can read about how the Gemini astronauts had difficulty with the same thing!). However when the best way of doing something is more about exploiting or avoiding quirks in the game itself (such as taking nose cones off rockets because they actually add drag), the player generally feels let down. I think that's what's ultimately behind why so many people here get passionate about this aerodynamics topic.
  11. Exactly right. The strength of KSP is in its openness to letting the player build a space program the way they choose. The idea that the game is all about throwing caution to the wind and putting a kerbal atop your first rocket is no more or less valid as somebody else getting more of a thrill out of being methodical and measured, or somebody who wants to build a cartoon version of a real-life program, or somebody who wants an army of robotic probes gathering science across the system, or somebody who doesn't want to go to space in something that doesn't have wings. I think all we're talking about here, beyond the mechanics of the tech tree itself, is ensuring that in career mode the player has as much choice as possible as early as possible in the game, and throughout their career -- while still having to work overcome challenges that feel authentic (I hesitate to use the word "realistic") and meaningful.
  12. Exactly what I had in mind. Very similar to how science instruments have a concept of different locations of varying exoticness (with the game keeping track of what you've already measured), I imagine those same locations and exoticness could be directly used to scale the sort of R&D experience (and thus discount) you'd get for a certain part type. You'd get more R&D know-how from testing a decoupler in orbit than you would on the ground, and for either location you'd pretty quickly tap out what you could learn after a test or two. Of course there might want to be some additional logic for each part type -- experience with legs would be better derived via landing, whereas experience with parachutes might have more to do with air density and g-forces. But really, even if Squad didn't feel like going that far, a basic system would be pretty neat I think.
  13. The more I think about it, Jimmy, I think your suggestion is actually better than mine: using parts of a certain type would simply reduce the cost to get to the next level of that type, but you would still use science points to do the unlock. It's a less revolutionary change than what I'm talking about, it provides even more options for the player, and it still "feels" more like R&D -- you can throw all your resources at getting a part directly in the lab, or you can take a more measured approach of testing before making the leap. Although I still envision the test-driven "discount" on a part level to not be fixed testing missions, but the more open-ended usage approach that I mentioned before. I'd really hate career contracts to become discount grinds, but I do like the idea that if you're using a part a bunch (for whatever purposes you prefer), it's going to make you more of an expert in that and let you get to the next level easier. I think the per-part tech explosion tree, plus some usage-based science "discounts" on research levels, makes a really nice pairing -- sounds intuitive, open-ended, satisfying, and fun!
  14. No, sorry maybe I didn't explain well. Those lists of things to do were just examples, not meant to be fixed lists. The idea would be very much letting the player get the R&D experience with each part in their own way. Sure, you could grind it with lots of the same mission (with diminishing returns), but coming up with with different combinations of circumstances will get you there faster and so there would be lots of ways to R&D-up a part. Think of this R&D experience system kind of like the science system, but with the "resource" gathered automatically (rather than with instruments) and only for part types that are actually on the craft at the time. Then separate from that, science would be the same generalized bucket it is right now, and correspondingly would be used in more generalized ways to accelerate overall R&D or other things, rather than being able to directly buy parts access.
  15. Hm, how about this: We want players to have to run a diversity of missions in order to unlock parts generally. Currently that's done via science gained either from contracts or taking science directly, which gives you some options since taking science requires you to go to different places. But what if instead each part type (ie. branch on the explosion tree) had a sort of progress bar toward the next step, and actually using that part type in a variety of conditions directly caused that progress bar to go up. Essentially the game would be keeping track of the location, duration, g-forces, etc. a mission is experiencing and the wider variety of conditions a part is exposed over a longer period of time, the more credit you get toward the next level. Have weak little landing legs and want beefy ones? Create test craft and land it with your current legs on the flat, on a mountain, on a beach, on the moon, land it harder and harder until you figure out when they break. Want bigger a bigger rocket motor? Launch 20 missions with the ones you have, launch light things and heavy things, stick it on a space plane prototype and test it that way. This would encourage even more diversity of missions, give the player many many play style options, but still give a sense of actually "doing R&D" on the part types in question, working on branches directly rather than generally gathering a resource to buy steps with. I still like the idea of initially unlocking the part with a test contract, which would work well with this. And the reliability of the part could perhaps steadily increase as you proceed toward the next level of each type (although perhaps that's more of a "hard mode" option in general). I like your idea that "science" as "nerd bait" though. I can definitely see science being, say, a big multiplier on R&D, or providing other bonuses to spend it on in a more general way. Thoughts? Already suggested and shot down?
  16. Personally I wouldn't want to see it become a tool to take the thought out of anything. I like the idea of the mission planner just providing fixed reference waypoints. If you miss those though, you're on your own. I'm all for people having MechJeb and KER for more rigorous and "low risk" mission planning, but in stock I rather like the game being very seat-of-the-pants. It would be nice to have a tool to figure out what should be possible ahead of time as you're building and planning.
  17. As wonderful as KER is, I think a simpler tool in stock would be great for less numerically-oriented players who still want to figure some things out before designing and lighting a rocket. I like something like Excalibur's idea, although I agree that strictly doing it with maneuver nodes seems a bit under-powered and fiddly (much in the way that doing it live once you're in orbit is fiddly!). I wonder if somebody clever could come up with a nice intuitive, visual way of letting a player play with orbits and burns in a way where they can see things like the most efficient time to burn to a new orbit, or a good alignment of multiple bodies for a more complex mission.
  18. Yeah, I can think of those and a lot of other ways of doing it. A hybrid system occurs to me, where you unlock the part with science/money/time, but then the part is initially very unreliable and the next level of that part is unavailable to unlock until you've used it enough to make it reliable. Anyway, don't want to distract from the main tech tree topic at hand, but since we're talking about this per-component "tree" idea, it seems like it might suggest interplay with the way in which you unlock those components.
  19. A separate but related topic: Has there been discussion of other ways of "funding" the tech tree other than general "science"? The science system isn't awful by any means, but it does feel a little... arbitrary. I'm curious if there are any other ideas for something that feels a little more like R&D, where you wouldn't necessarily have to be gathering atmospheric data in order to get bigger rocket motors.
  20. Yeah, I was just thinking like an RT-10, nosecone, very basic probe core, and a thermometer maybe. Then no matter what other choices you make, you can at least play with some sounding rockets -- I mean, you're not going to be playing KSP very long without at least some rocketry anyway. But sure, you might be right that that might not even be necessary. Just a small point -- overall, this system seems certain to be a good thing.
  21. I think that looks fantastic; so much more intuitive and really seems to eliminate problems where you're stuck buying into a lot of R&D when all you need is a little on a particular thing. The devil may be in the details once you really start dropping in individual parts, but it sure feels like a massively better way of doing it. Layering on top of this, it still feels like there might need to be some concept of technology eras (perhaps linked to KSC states or something) that would prevent a player from *seriously* minmaxxing through one branch, but maybe it wouldn't really end up being a problem in practice. Even with the initial small amount of science provided, I think you'd also have to carefully select a good basic set of starting parts to automatically give the player, along with a set of basic initial contracts (which can still be addressed in different ways ideally). I just imagine some newbie situations where they make a couple of bad choices (blow all their science on tanks or something) and are unable to make any progress. Although I liked the idea somebody else had here to maybe have a small selection of initial states with starting parts and contracts: Maybe the Air Force option where you've got wings and such, but only the most basic rockets -- or the OKB-1 option where you've got some nice liquid boosters and tanks, but that's about it -- or the NACA/ORDCIT option where you've got nice guidance and instrumentation and some middling rocketry stuff.
  22. Yeah, this is definitely why I feel that both should be valid development paths up front. And perhaps for a beginner, the initial tutorials really should lead them primarily through the basics of unmanned rocketry up-front, due to the complexities of planes. The only reason I talk a lot about planes is it seems like they could be a satisfying (and realistic, not that that's the most important thing) path of development right from the start, for those who are so inclined, with just a few tweaks. Specifically to the topic of rocket-focused starting points: To be honest, when I was an absolute newbie starting out with KSP, it seemed really weird to me that I was dropped into a career with access to a manned command module, but no unmanned options at all and quite a lot of rocket motors. It felt to me like the game was saying "you're going to start with a Gemini mission whether you like it or not, noob". I really would have enjoyed starting out with some very simple unmanned sounding rockets to get a feel for how the game operated, without having to worry about Kerbal lives.
  23. Oh wow, something must be in the air because this fantastic graphic also just got posted to reddit. Gives a great sense of relative scale that I couldn't convey in my timeline. This one is also pretty sweet, with fewer items but a cool depiction of launch weights and rocket configurations.
×
×
  • Create New...