Jump to content

iMAniaC

Members
  • Posts

    26
  • Joined

  • Last visited

Everything posted by iMAniaC

  1. It's nothing major and not even a bug, but with extra safety bubbles, maybe it would work well to have safetyBubbleRadius 0 as default in the next release? I've actually followed this thread for quite a while now and there always seem to be people confused by the safety bubble. If it's no longer strictly needed, it might save some confusion on the user side to have it zero as default and leave it as an optional feature for those who like tinkering with settings?
  2. Oh, okay. I was holding off on this suggestion prior to the new version of Unity, but I thought it was worth giving it a shot after the mention of the new Unity version in the ARM patch. I guess I'll have to continue using fuel lines, then
  3. I'm sorry if this has been mentioned before (actually, I'd be surprised if it hasn't), but I did a quick search and couldn't find it, so here goes: Basically, I think it would be nice if both of these designs were working: This currently works: This currently doesn't work: (In case it's hard to see from the screenshots: The design that works has a tank on top with a Tri-Coupler the right way (i.e. the default orientation in the VAB) underneath and three engines connected to the Tri-Coupler. The design that doesn't work has three tanks on top with a Tri-coupler upside down (i.e. flipped and rotated compared the default orientation in the VAB) underneath and one engine connected to the Tri-coupler). I figure that there's a problem with the fuel only flowing in one direction through the Tri-Coupler. In essence, it would be nice for the fuel to flow both ways Although I haven't tested, I guess this goes for all Couplers and possibly also the Adapters.
  4. Thank you KvickFlygarn87 and godarklight for your answers!
  5. Edit: Strikethrough because it wouldn't work after all. I, too, wanted to see a shared tech tree (and it's going to be awesome when that gets implemented!), but there might be a way to circumvent the implemented functionality by manually editing the persistent.sfs file. However, and I must stress this, that what I'm about to write is only a theory and I haven't actually tested it yet. However, I won't have the chance to test it properly until next week at the earliest and if it happens to work, it might improve someone's play experience this week-end, so I'll take the chance on posting it. But just to be absolutely clear on this: I haven't tried it and if you do, it's at your own peril! Also, if someone does try it (or knows right away that it won't work), please say so in this thread so that other people will know if it's worth a shot. Or perhaps a mod could edit my post, I wouldn't mind. I only want to share my thoughts about it in the hope that it will do someone something good. Anyway, the way the persistent.sfs file seems to work in single-player is that it adds whatever you've achieved to the file and what you haven't achieved is nowhere to be found. There is a separate section concerning R&D, so basically filling that section with stuff will give you achievements in-game. So the main idea is to sync that specific part of the persistent.sfs across all players after gaining science, retaining all flights and stuff, and only sync'ing the tech tree. It's slightly cumbersome, but it should work, I think, at least if you're only playing with a couple of friends and not on a public server. Step 1: Play normally Step 2: As soon as someone gets some science (and the game records it), make sure that no one else will get any science. However, you can safely play until everyone is in stable orbits or whatever. Step 3: Everyone quits KSP Step 4: Everyone locates their persistent.sfs file (in KSP/saves/KMP/persistent.sfs). Step 5: The one who got the science sends his persistent.sfs file to everyone else (via mail/skype/whatever) Step 6: Everyone else opens up their own persistent.sfs file as well as the one they received (preferably after having backed up their persistent.sfs file, just in case). Step 7: Everyone else looks within the file from the one who unlocked the science for the section that starts with SCENARIO { name = ResearchAndDevelopment (Make sure that the corresponding "name = ResearchAndDevelopment" is there or else you'll be copying the wrong stuff! You should see a lot of Tech { id = start ... } Science { id = evaReport@KerbinFlyingLowShores ... } etc, which corresponds to the unlocked tech and achieved science.) Step 8: Everyone else copies, from the file of the one who unlocked the science, everything in that SCENARIO name = ResearchAndDevelopment section, all the way to the last curly bracket (" } ") just above where it says "FLIGHTSTATE". For instance, someone who only took an EVA report hanging onto the module at KSC and unlocked the next tech, should have a section that looks like this: SCENARIO { name = ResearchAndDevelopment scene = 5, 6, 7, 8, 9 sci = 0.5999999 Tech { id = start state = Available part = mk1pod part = liquidEngine part = solidBooster part = fuelTankSmall part = trussPiece1x part = longAntenna part = parachuteSingle } Tech { id = basicRocketry state = Available part = fuelTank part = fuelTankSmallFlat part = GooExperiment part = stackDecoupler } Science { id = evaReport@KerbinFlyingLowShores title = EVA Report while flying over Kerbin's Shores dsc = 1 scv = 0 sbv = 0.7 sci = 5.6 cap = 5.6 } } Step 9: Everyone else replaces the section in their own persistent.sfs file with what they just copied. Step 10: Starting KSP again, everyone should now successfully have duplicated the tech tree of the one who first unlocked the science. Step 11: Play normally again. The next time someone gets any science, go back to Step 2 and rinse and repeat. Of course, the roles may not be the same if someone else unlocked the science this time around. In essence: Step 1-11: Replace the section for ResearchAndDevelopment in everyone's persistent.sfs files so that they are duplicates of the section in the file of the one who unlocked some science. That way, you'll have the same tech tree and science achievements. Rinse and repeat every time someone gets some science. The biggest disclaimer here is that I do not know if the persistent.sfs file for KMP 0.1.5 works the same way as it does for single player. However, I have managed to successfully sync the tech tree progress between two single player careers while the "receiving career" was mid-flight, so I'm hoping it's going to work in KMP, too. And again, if this doesn't work, please say so or get a mod to edit this post so that other people won't waste their time trying. And of course, it if it does work, please confirm Lastly, I have to say that you guys who are making KMP are awesome! Thank you!
  6. Sorry about the late answer, I was, uh, busy (you can guess with what ). Anyway, to answer your direct question, I have to admit that I haven't reached the point where I have bases on other planets yet (I started playing not long ago), so I wouldn't be able to say for sure. However, based on what I have achieved, I think that there won't be much of a difference between my Minecraft castle and KSP Duna base (when I finally build one). In Minecraft, I usually get a certain satisfaction simply from having achieved my objective and I expect it would be the same with KSP bases. I'll probably move some Kerbal around the finished base, look at it from various angles and feel good about myself and then move on to bigger and better things. If this is not how things play out, though, I'll let you know The last few days I have been playing with the idea of bypassing the idea of funds per time period. After all, it may be a very human thing to think along the lines of fiscal years or quarterly results (sometimes to the point of absurdity, but that's another discussion altogether). Instead of Kerbals siphoning off x money every year for something, they might have a mentality more like "Going to Mun? That's easily worth this much. Here, take my money!" That way, time is no longer an issue. You could do all the missions simultaneously or you could do them serially and Kerbalkind wouldn't care, because they focus on the achievement and ignore the time it took to get there. Initially, I thought about a set budget for every contract (and so the challenge would be to make a rocket within budget), but I soon realized that only having those would kill the opportunity to do missions the game developers had not thought of. Also, if it were all about the science, doing missions that do not return science would be wasteful in Career, so a space station around Kerbin is pretty much pointless if you've soaked up all the science from Kerbin's orbit already. But what if there were free missions in addition to contracts, based on a general game mechanic that calculated worth based on payload sizes and types of various situations? So for instance, getting a payload of x tonnes into orbit is worth x money to the Kerbals. The money gained is then scaled with certain factors; distance from Kerbin or Kerbin's orbit, whether the payload lands on another celestial body, whether there are Kerbals aboard or if it's only a probe, etc. In a sense, it would in some ways mirror the mechanic for determining science, but while science is used for unlocking the tech tree, getting payloads into space has an intrinsic worth. Note, however, that these kind of missions are based on returns and not on budget: It's the money gained from your previous mission that is invested into the next, rather than getting a specific budget before the mission is conducted. Such a system would also allow for an infinite number of missions that do not return science: For example, putting a satellite into orbit is worth a certain amount to Kerbalkind. Thus, if you manage to do it within the worth of the mission, you will get the money back, as it were, enabling you to build a whole network of satellites if you wish without going bankrupt. Speaking of going bankrupt, that is a very real possibility if a mission fails, since there may not be any return on the investment, as it were. So in the beginning, to make it more newbie-friendly, there could be a specific contract: "Getting to orbit" that would refresh no matter how many times you fail, giving you a specific budget again and again until you reach orbit. Likewise, if you go bankrupt after a long and successful Career (and you've already done all the Contracts), there could be a contract "Back to space" that would give you a certain amount to restart your space program. In summary, this is what I'm suggesting: Resources: -Science: Used for unlocking the tech tree. -Savings: Money hoarded up by the space program, used to build rockets for Free Missions -Budget: Money available for a specific Contract, only. -Reputation: ??? Maybe something to with astronauts. Mission types: -Contracts: Missions with specific parameters. Money paid up front as a budget. -Free Mission: Rockets built with savings. Successful launches return money to the savings based on certain factors. In the end, this post doesn't touch much on the topic of "Over time"/"meanwhile" mechanics, but it's meant as an elaborate way to avoid it altogether, in order to not force the players to do missions they don't feel like. Moreover, with contracts with up front money, the player doesn't have to wait for the return of his investment into a Free Mission and it will still be possible to do several missions at the same time and thus get closer to a continuous space program, if that's what the player prefers. I'm sure there are lots of things that have slipped my mind, so feel free to point them out. And congratulations if you made it all the way through
  7. It's already been Tuesday 27 minutes in my timezone! I can't take it any longer! Why must you torment us so?! In all seriousness though, SQUAD is awesome, take your time
  8. I'd like to share an experience I had playing Minecraft: I played it a lot and really liked it and one of the things that really appealed to me was the feeling of building something from nothing, which is much of the appeal of KSP for me, too, only better because it's in space Anyway, I started playing with a mod pack called Tekkit, in which there was a plant mechanic that allowed you to breed plants and getting new and/or netter plants through mutations and cross-pollination. There was also some mechanics with weeds and automatic removal of them. It sounded really cool and I started a project for breeding plants. However, the mechanics worked in such a way that you had to attend the plants every now and then, so whenever I decided to build an intercontinental railway or a castle or whatever, I had to take a break from my current project to tend the plants. Slowly, but steadily, I started disliking the plant breeding part because it always interfered with my other projects. In the end, I gave up on it altogether because it ruined the rest of my game experience. The point I'm trying to make (and sorry about the round-about way of saying it) is that I fear introducing time as a valuable resource in itself to KSP, will have the same effect on my enjoyment of KSP as the plants had on my Minecraft Tekkit experience. I love the freedom that KSP (and Minecraft) provides for me to do whatever I like whenever I like. I can leave my Minecraft castle half-finished and come back to it later, or I can put my KSP plane project on hold and take a trip to Duna instead. However, if I were forced to halt my mission to Duna because I had to do a manned mission to Mun before the probe arrives at Duna instead, I'm afraid it might remove some of the fun of KSP, at least for me. Of course, a time-dependent KSP might be a very good, challenging and fun game, but it wouldn't be the game I had hoped for, personally. All that being said, time as an indirect resource might work very well, I think. I think the fun (for me) in KSP is overcoming the challenge of building a rocket (or plane/station/whatever) that is able to do what I've set my mind to. Building a rocket that is able to win a race against time (like getting to Eve before life support runs out or whatever) is basically the same challenge. However, if all I want to do is go to Eeloo, then doing all kinds of other missions while waiting to get there might feel boring and take the fun out of those missions when they might have been my #1 priority if I could do them when I became excited about them instead of when I really wanted to do something else. A way to please everyone (or at least almost everyone) might be to have several options when starting a Career game (or adjusting while playing). Toggle on/off Tech tree, Building cost, Building time, Over-time game mechanic, etc. That way, the players get to decide themselves how much restriction and freedom they want. My two cents.
  9. I could easily imagine someone griefing other people's KSC's, though. If buildings can take damage, simply crash a rocket into a building. Or land a manned pod on someone else's launch pad so they won't be able to launch rockets at all. It doesn't take much skill and it could be done on the lowest branches of the tech tree.
  10. I've been thinking along those lines as well. I thought maybe there could be 4-5 equatorial KSC's, because those are the easiest ones, and then a number of KSC's all around Kerbin. Possibly even the option of placing your KSC wherever you like. (Extra challenge; place it in a slope so that all your creations have to take off from the runway or be built with a special slope-compensator leg). Of course, this should resonate back to single-player, so that it's possible to choose a start location in single-player as well. Implementing additional KSC's into the code will give modders a lot of new tools to work with as well, I think. I also think that it would be nice for several players to be part of one KSC, so that they don't have to have their own KSC far apart from each other if they don't want to. That way, they don't need to trade at all in order to sync their progress (if technology and science points are tied to KSC's instead of players). Perhaps we could get to build KSC's from the ground up, as it were, so that it's possible to have several launch pads for a KSC with several people. Having modular KSC's would also open up a lot of possibilities for modders. If only science results are allowed for trading, as opposed to trading technology itself, then it would not be game-breaking, I think, because the largest total amount of science input into any tech tree would only be the sum of all distinct science results among all the KSC's, instead of the sum of all science results from all KSC's multiplied with the number of KSC's (which could be achieved by everyone choosing a different tech after having completed one mission and then sharing it with everyone else). Of course, only getting to trade science results, wouldn't disallow people from choosing different technologies with the corresponding science points. Thus, one could end up with different players going different ways in the tech tree and open up for co-operation between players. Like, if one player goes for all the space station parts and another one chooses heavier rockets, then they could somehow co-operate in order to get the space station into orbit. This would require a joint mission functionality, but I think that would be a good idea anyway. Who wouldn't want to have a Kerbal from your own space program ride along with the rocket of someone else's I disagree with holding off on multi-player until single-player is finished because I think it may result in extra work, but I'll leave that decision to the game developers. As long as the end product delivers, I'm not really concerned about how they got there. (Also, they said that war is not going to be part of KSP and I really like that decision. Of course, enabling it through mods works really well, I think).
  11. I'm really happy about the announcement! I've had hours and hours (or rather days and weeks) of fun with my friends in multi-player Minecraft and I believe that there's loads of fun to be had with friends in KSP, too. I'm also happy about them announcing it for an earlier build than post-1.0. Minecraft started out as single-player only (iirc), but during development it became clear that their prefered solution for single-player, code-wise, was to have the single-player player play offline alone on his own multi-player world. If that is what SQUAD ends up with, then the sooner they begin implementing it, the less work it's going to be adapting stuff to a multi-player based code later. (Although, of course, that may not be what they go for at all. But if they go for such a solution, then it's a good thing they don't wait until post-release, I think).
  12. However, after having planted the explosives, it becomes clear that there's something wrong with the detonator. Onboard, there are two specialists from the Jool Fancier's Society and their professional commitment to the mission is so high that they decide one of them has to stay behind to detonate the explosives. They draw lots and the youngest one of them loses. However, the young one was going to marry the old one's daughter, so the old one sabotages the young one's EVA suit so the young one has to return to Kerbin and marry the daughter while the old one stays behind and detonates the asteroid. The Kerbals head home, mourning the loss of the old Kerbal, although one of the crew keep mumbling something about the kinetic energy of bowling balls... Just kidding, of course. Sounds fun.
  13. I like the general direction of these ideas. However, I think it would be more fun and "Kerbaly" to invert them: Not Dexterity, but Bravery: How much explosive power do you dare to light up beneath your seat? At first, maybe, say 20 tons, but when you've done that once, it's not as terrifying the next time around, so with the same amount of Bravery, you'll dare to light an even bigger rocket on fire the next time. Bravery could then be a static attribute, but you'd still have to "level up" the Kerbal to have him pilot bigger rockets, even though the Bravery attribute stays the same. Not Intelligence, but Stupidity: Stupid people learn from their mistakes. Smart people learn from other people's mistakes. In order to maximize learning, we need lots of stupid people to make mistakes to learn from. Stupidity is the key to progress! Thus, having a high Stupidity stat is good for progress. Not Leaderhsip, but Confidence: It's not the smartest who lead, nor the bravest. It's not even the one who is best fit to lead overall, but simply the one who manages to give orders most convincingly and with most confidence. Successful missions will give a confidence boost. However, there's a very fine line between fun leveling and grinding stats. If you have to spend a lot of time grinding kerbonaut stats instead of sending rockets to new places, the game will probably lose some of its appeal, I think. Perhaps the influence to the Bravery stat could be global, so that when other Kerbals see one Kerbal survive, say 20 tons, that becomes slightly less scary to all of them. That way, you won't have to go back to basic rockets if you happen to strand Jeb on Mun or something... Science experiments are also hard to get right. I think the way they are now, with diminishing returns, are inherently un-funny. However, I like that there is something to be learnt from doing the same experiment twice and I like that there is more to be learnt from bringing the samples back to Kerbin. Adding a kerbonaut's Stupidity into the equation makes for a really complicated way to figure out how much science is to be gained from a single experiment. That being said, I don't mean that Stupidity absolutely shouldn't count towards science, but it might be really hard to pull off in a good way. In the end though, since the developers have already announced that there will be a kerbonaut program, I'm sure they have some good ideas of their own. I'm looking forward to seeing what they come up with.
  14. I started playing KSP roughly a week ago. I started out as a total newbie and jumped into Career mode with close to zero research. This is kind of how it went, presented as an interview with Jeb. We're here with a Kerbal who does not need introduction; he is the only Kerbal that has ever been in space; Jebediah Kerman! (Accompanied by a KSC PR Liaison). So, Jeb, you recently orbited Mun, and can you tell us, what is the first step in achieving that? Jeb: Well, first, you have to get into an orbit around Kerbin and then, when Mun is approximately at 45° of your target apoapsis, you gun the throttle and hope-- Wait, wait, hang on. You're saying you went to Mun with only a vague idea of how to do it? Jeb: Pretty much. PR Liaison: What Jeb is trying to say is that he knew exactly what he was doing. This isn't the first time you have flown without using all the instruments available to you, though, is it? Jeb: That's correct. All of the launches until we finally made a stable orbit were made without the use of SAS. Why is that? Jeb: No one told me that the [Command Pod] Mk 1 had SAS, so I-- PR Liaison: Jeb can assure everyone that he knows all the rockets inside out and his decision to forego the use of SAS in those crucial first flights was a completely conscious one. Jeb: But I've used the SAS ever since I found ou-- PR Liaison: Ever since that was the most productive thing to do, yes. Jeb: And now that I know about-- PR Liaison: - has decided to use - Jeb: --the flight planner, it's going to be a vital part of every future mission. Okay. But anyway, you set a course to Mun without a flight planner. Was the lack of a flight planner connected to those several flights out to Mun's orbit which did not actually orbit Mun? Jeb: Yes. PR Liaison: No. Jeb: I simply mis-- PR Liaison: Those were planned flights to check out Mun's orbit without Mun actually interfering with the orbit itself. I see... Well, when you finally got into orbit around Mun, what was the first thing you did? Jeb: First, I sent back the test results from the [sC9000] Science [Jr.] Bay from high Mun orbit and collected data from the [Mystery] Goo [Containment Unit] canisters which would return with me to Kerbin. Then I waited until I would reach the periapsis so that I could slow down and get to an orbit around Mun. Then, while in low orbit, I collected data of the Science Bay and Goo canisters again, in order to take them back with me to Kerbin. What did you think about Mun, seeing it up close? Jeb: It's not just a huge rock, it's beautiful. It's the reason we're out there. And then you just headed back home with a mission well done? Jeb: Well, almost. At some point my orbit had become skewed relative to the equator, so I had to use some thrust to get back to the right plane. This was also the point at which I realised that I was dangerously low on fuel. PR Liaison: Plannedly low on fuel, yes. But you recovered and established a perfect path back to Kerbin, I take it? Jeb: Actually, since I was so low on fuel, I decided to swing by Kerbin and thrust when I was in that orbit's apoapsis. Smart move. So you entered an elongated orbit around Kerbin first? Jeb: Yes. ... And no. It wasn't a complete orbit, because it was so elongated that it would actually cross Mun's gravitational pull again and slingshot me out into space unless I did some corrections before that. PR Liaison: As planned. As planned. Jeb: Luckily, -- PR Liaison: - Plannedly - Jeb: -- the apoapsis came up before Mun so it would never get to that point. You said you were low on fuel. Were you ever concerned that you wouldn't have enough fuel to avoid the encounter with Mun and get thrown into space? Jeb: ... PR Liaison: Jeb isn't going to dignify that question with an answer. He has complete confidence in the fuel calculations of our people on the ground. Jeb: Erm... Yes. Well, anyway, there was enough fuel and I made it back into Kerbin's atmosphere, landing in the sea a short distance from the shore. That sounded like a very intense experience. What was your thoughts when the command module broke the surface of the water? Did you let out a sigh of relief? Jeb: Actually, at that exact moment, I heard the science module with its Goo containers break off from the command module, so all the scientific results I was taking back were gone... So I'm taking off again tomorrow in a slightly more sturdy rocket. PR Liaison: According to schedule. This was all planned. There you have it folks, Jebediah Kerman! Not only the first Kerbal to go into orbit around Mun, but also the first planning to do it twice!
  15. When I saw that planes came later than rockets in the tech tree, I thought right away that Kerbin does not have the same availability of oil as Earth does. Without oil, maybe Kerbin did not have the kind of internal combustion engine revolution that Earth had and thus planes were not really a feasible idea until they invented/discovered whatever fuel(s) the space program uses (like maybe some synthetic or bio-produced equivalent). That thought immediately appealed to the sci-fi buff in me. I've only played KSP for a few days, however, so there may be descriptions around in-game invalidating my thoughts about their no-oil society, but for now, that's the personal theory I'm going to stick with until evidence to the contrary (or a cooler idea) surfaces
  16. A friend showed me this game last week-end and I bought it right away and got instantly hooked on it. As such, I'm a real newbie at the game, but what I lack in experience, I'll make up for in inexperience: These thoughts are what I would like to give feedback about after a genuine first impression of the game as played by a complete newbie who entered Career mode right away. I'm only going to mention my thoughts about science and biomes, though, my other thoughts have been mentioned by other people before (I did a search of the forum before I started writing this). The first thing I did was build a rocket and launch it. It failed miserably because I built it from the ground up and my stages got messed up, but that's okay (because I'm assuming the tutorial is going to get implemented optionally into Career mode at some later point anyway). Miraculously, the pilot survived, so after having crashed my first rocket, I got just enough science to get the Stack Decoupler. Now I could build a rocket that would actually reach orbit! Cool! I also got Goo which I could bring with me to experiment on (although I didn't understand at that point that I should right-click it, but again, that's okay). Then I reached sub-orbit and finally orbit and got science points from that, so I could get more tech. I didn't feel ready to go to Mun yet, but I couldn't figure out how to get more science points either, so I checked the wiki and found out about the right-clicking, so I started grinding science that way, right-clicking at various heights and various biomes. Eventually, I unlocked aerodynamics and wanted to build a plane. I tried and failed (several times) because I didn't have landing gear, but I also soon realized that this way of playing the game, building new stuff and experimenting with it, wasn't going to get me further in the tech tree. A few days later, I realized that I had enjoyed my misconception of how the tech tree worked more than I enjoy the actual workings of the tech tree. So I wanted to provide that particular feedback, because I think this game can be a huge success and I want the developers to see all sorts of feedback, so that they have the best empiric basis on which to finish their kick-ass game My misconception of the tech tree (which I enjoyed more than the actual tech tree) was that there was slightly more causality to it. I appreciate the freedom the players have to choose what tech path to go down, but there are some choices that don't really make much sense to me. Like soaring through empty space (potentially) giving Aerodynamics. It's also kind of immersion-breaking to me that I have to go with a rocket to the north pole to get a sample from there, but at the same time, I'm able to retrieve the rocket from anywhere around the planet with a simple click. The guys who (presumably) are able to go anywhere on the planet to retrieve rockets, however, are not able to take samples from that place... I think it would be fun if specific goals (or one of several alternate goals and/or combinations of goals) resulted in specific tech being unlocked. For instance, Basic Rocketry could be unlocked by launching a rocket. The radial decoupler could be unlocked by launching a rocket and using the stack decoupler. Aerodynamics could be unlocked by launching a rocket with the Winglet or Aerodynamic nose cone attached. That kind of stuff. Also, of course, going places would unlock tech. Orbit around Kerbin, orbit around Mun, landing on Mun etc, could also unlock tech. Finally, the Goo and Science bays could of course also unlock tech. This also ties in with some of the ideas presented in the OP. Of course, finding the right balance between causality and total freedom to choose tech is a delicate exercise which I'm sure any suggestion doesn't hit on the first try. Another advantage to implementing slightly more causality, is that a player isn't penalized or rewarded for choosing a specific tech path. Not choosing the Science bay or Thermometer is kind of a huge disadvantage when everything revolves around science points. I've read other posts on the forum saying it was too easy to get all of the tech, and that could also be remedied by having to go through several causally connected stages instead of staging one ultimate mission that would give the rest of the tech tree (although with careful planning, I'm certain that would always be possible - but not as a first-time player). Also, with the implementation of funds/money, it would be possible to re-introduce the gameplay factor of having to choose which tech to spend resources on instead of getting everything for free (although that factor does not truly go away as the type of missions you decide to do would determine the type of tech you get in return, anyway). Additionally, by not requiring the player to meet all the goals for a tech, a player wouldn't be forced to do missions he/she wouldn't find fun. Finally, having specific prerequisites for unlocking tech and knowing those prerequisites before unlocking them would give some sense of direction for new players. 'Oh, I am ready to go to Mun, because that's what the next tech says'. Of course, the requirement could be worded more subtly, for example for Aerodynamics: 'Our engineers think that the winglet has exciting properties and would like to get more data on its interaction with the atmosphere'. 'Hmm, I guess I should build a plane, then'. Also, I think primitive wheels could be available from the start so that you can build horizontal rockets and rocket-driven planes without landing gear (although they might break during take-off, but that's okay, because that could unlock the landing gear). That's my two cents, based on the first impressions by a complete newbie. I'm sorry about the length; I'm not very good at writing concisely.
×
×
  • Create New...