Mako

Members
  • Content count

    95
  • Joined

  • Last visited

Community Reputation

74 Excellent

About Mako

  • Rank
    Bottle Rocketeer
  1. You're absolutely right. When a company has very little idea what it's actually doing with its product then yes, they should not release too much information. It would not be good for sales to show that you're not really sure what you're doing but promise to keep banging on a thing for a while to an unknown end.
  2. @KSK and @Red Iron Crown My argument has never been that anyone is entitled to more information. My argument is that providing more information to the public, both current and potential customers, is a good thing. The only time it's not a good thing is when the information is that the company is choosing to do something that is not in any customer's best interest. I believe Squad wants to make a good product. I believe they would benefit from communicating more with the public. I fully admit people will do act in an unpleasant fashion, and they obviously do so whether you communicate or not. A company can gain something from communicating, but they gain nothing by not communicating, and since people act lousy either way why not choose to communicate and gain something?
  3. So since some people will speculate anyway, ignoring everyone and withholding information so everyone can speculate together is a better solution than attempting to prevent speculation with information and attempting to correct misunderstandings and finally just ignoring individuals who refuse to accept the truth? If that's the way to go, why do we even have this weekly KSP Weekly?
  4. I do agree that without a roadmap for context these types of reveals with little to no details are unhelpful to just about everyone until clarified. Until clarified these types of unexpected reveals without context make it feel like Squad is lacking direction and vision for KSP. I know that it has been said by Squad staff that there is an internal roadmap, but I don't believe that is the best way to to work on an community-involved, open-development model game. If Squad wants to produce KSP in a closed-development style that's their choice, but everything they do says that's not the case... except for the lack of public roadmap. I've always wanted to see Squad commit fully to an open-development style, or at the very least talk about the intent for KSP. Without that, it's very hard to forget that they're new to making games and very easy to believe they have no idea what they're doing and they're making it up as they go while crossing fingers and hoping for the best and refusing to discuss the matter with the people who care the most: this community that they have always seemed so proud of. And don't get me wrong, I stick around to see what Squad brings to the table in the hopes I'll be pleasantly surprised, because I really do like KSP. I just feel there is a not insignificant amount of unrealized potential but I don't see much from Squad to show that they see the potential and intend to realize it before they call KSP finished. I, like most people, don't usually enjoy being wrong, but this time I'd welcome it.
  5. I agree that there is a failure to communicate that only Squad can remedy, so therefore they hold the blame. I disagree that Squad is solely responsible for unrealistic expectations drempt up by community members. Squad only has the blame for the disappointment anyone might experience when their wish doesn't come true if Squad officially announces it will definitely fulfill that wish and then refuses to deliver. Even in that situation I would argue that the user, while not causing the hope and subsequent disappointment directly, would be learning valuable life lessons: things don't always go as planned and life isn't always fair. Lastly, my argument with the swing set analogy is that Squad is reacting to the potential behavior of some community members regarding the reason for lack of public roadmap. Your argument seems to be that Squad is to blame for inciting negative behaviors. They are related, to be sure, but are not the same arguement. However I think we can both agree that Squad's prevention of negative behaviors from some members of the community by keeping any hint of a direction or fragment of public roadmap comes at the cost of some of the community's understanding, interest, and goodwill.
  6. Squad has not decided to employ a software as a service model for its product. So outside of that model for software development and sales, new major product numbers have a long history of being developed and sold as seperate products to the preceding versions. It is not at all strange to think that if Squad intended to make significant changes/advances to KSP that they would do so as a new product to earn money for all their hard work. After all, as you point out, there's very little meaningful lore or directed storytelling within KSP, so why should we consider it a narrative getting a sequel when it would more closely resemble a new major version release of a popular software title? If you propose that KSP will just be constantly updated, well, unless Squad has a plan for the slow trickle of long-tail sales or numerous paid DLC to provide the revenue I just don't see how that makes one darn bit of good business sense. Even if that were the case, I would suspect the current code base would eventually severely limit what additions they could make.
  7. @Terwin First, I accept your point about additional languages being a minor update. That is reasonable. I also accept that people would desire an easy way to share info with only a select group based on certain factors. This, however, was not even remotely what I was suggesting. I was suggesting a roadmap that is public and open to all, and that individuals who persist to misunderstand the purpose and information of the roadmap (whether intentionally or not), after being reasonably presented with clear and accurate information, should be disregarded by devs and peers for the duration of their misunderstanding(s). I believe that most of the community is capable of understanding the nature and intent of a roadmap. Squad seems to believe that no one should be given the privilege of a roadmap because it is sometimes misunderstood by a limited number of individuals. While I will agree that it is probably easier for Squad to refuse a public roadmap, I do not agree with anyone who might suggest that refusal is the best solution. Furthermore, I believe the best solution, releasing a public roadmap to all and ignoring individuals who persist in misunderstanding the roadmap, is relatively easy to implement and manage. At the very least I suspect it to be a break-even proposal: complaints about the direction of the roadmap could increase while rampant speculation, confusion about direction, and any related discussions would decrease. Also, your post seems to imply public roadmaps are not used in games development. Maybe I'm misreading or misinterpreting your post, but I will be happy to provide references and links upon request of games which have (or had during active development) public roadmaps. I can think of a few off the top of my head, and I'm sure if I do some research I can find even more. Having not previously done research on the reception or success of public roadmaps for in-development games, I cannot say with certainty that roadmaps are a net positive tool. I believe they are: the truth, whatever you may think of it, is still the truth and it is better than nothing. I can offer anecdotally that the still-in-Early-Access game Subnautica has had a public roadmap and its community was seems to have in general acted reasonably and favorably when deviations or changes to the roadmap were announced and explained in advance. Good PR isn't always easy, but I don't believe it has to be hard. I feel like Squad is making it harder for themselves, now more than ever.
  8. There has never been a guarantee that Squad would continue to work on KSP beyond what they were working on at any given moment. This has always been the case even when KSP was in Early Access. New versions have always been built and provided in such a manner as to be the final version even if more work was planned. Furthermore, Squad is currently working on KSP in a manner which implies they are focusing on revenue producing updates (localization to sell additional copies in newly available languages) and paid add-on content (the Making History Expansion). There's no way to know if this is motivated by necessity or not. If it's out of necessity, and the localization efforts and paid expansion do not provide as much revenue as expected/needed, it is not much of a stretch to picture Squad discontinuing work. This doesn't seem to be the most likely scenario, but we have no way of knowing for sure. All any of us can do is speculate. My speculation is 1.4 will mostly consist of more work on localization since Squad originally mentioned a desire to translate KSP to more languages than what we know is coming in 1.3. There would be a lot less speculation if there was some kind of public roadmap. I understand that Squad feels that since some people can't handle a roadmap no one should have one, but I feel like this is like removing the swings from the playground because a few children were injured when they used it improperly. I tend to strongly disagree with restrictions to privileges for everyone based on the actions of a small number of individuals. In this particular instance, I believe it's a privilege, not a right, to have a roadmap, but I also believe that most problems that can happen can be mitigated or resolved with clear and accurate communication. If excellent communication does not prevent or correct misunderstandings caused by a roadmap, it is likely that the problem is not with the existence of the roadmap but rather with the person viewing the roadmap (at which point there's not much anyone can do besides hoping the individual chooses to understand how the world works).
  9. @John FX The main difference I believe I've seen mentioned by Squad personnel is that missions are capable of complexity far exceeding that of contracts. I assume (and I know how evil it is to do that, but I have little choice) that since they're building the missions as a different system they cannot be shoehorned into the contract system without a lot of work on the contract system in stock KSP -- work which doesn't seem (to me) to benefit stock KSP and probably delay the release of the expansion. So complexity of missions versus simplicity of career mode contracts seems to be the only main difference.
  10. @XpertKerbalKSP If I were you I would look into using Space Engine for your movie. Nothing against KSP, but Space Engine is designed to allow you to set up planetary and solar system scenarios and watch them play out. Instead of using KSP's fictional solar system, you can use more realistic models from our solar system. It would probably be a less fun but more instantly recognizable and more accurate presentation. However, if you wish to continue to use KSP, as Street wind mentioned Kerbals speak recorded Spanish played backwards. I would perhaps consider using some mods, like Real Solar System, and Hyperedit to set up your scenes easily. I haven't really played with either, so I can give any more advice other than looking onto them. As a scene suggestion, since you asked, the first thing that came to mind was using Real Solar System and setting up the movie as the Kerbals have come to our solar system and are checking it out and trying to determine how it formed. Scenes can be Kerbals visiting various planets/asteroids and talking about the formation of these objects and their influence in our existence. You can show how Earth is in the "Goldilocks" just right orbit around the Sun, and show off Mars and Venus to point out what happens if a planet is just a little too close or a little too far in relation to the Sun. If you think that mods would make it too complicated, you can do the same kind of thing as if the Kerbals are exploring their fictional system and wondering where they came from. Then you can compare the Kerbals and their system to us. These are just a couple of quick ideas. Hopefully others can be of more assistance. Good luck with your project. Let us know how it goes.
  11. Unity also gets blamed for issues involving robotic parts like those from Infernal Robotics and the horrible PhysX wheel collider that appears to have been designed with one single use case in mind and is so inflexible that it took months upon months to implement and crazy workarounds to get to a point that's functional for KSP. These are things I'd love to see resolved, along with the inability to have part branches attach to other branches/main trunk. I don't know if robot parts can be implemented well under Unity or not, but the other two items could likely be fixed without changing engines. It would require a ton of work for very little actual gain, so I don't ever expect it to happen, but these are the kinds of improvements (along with general performance) I would most like to see. Obviously the impossible, perfect world scenario is the one where KSP is remade from the ground up on custom-built graphics and physics engines that are tailor-made for its specific needs. It is practically impossible that KSP would ever be moved to a new engine, so it's a moot point, but I wouldn't be surprised if some other engine exists that would better meet KSP's needs than the one-stop shop that is Unity. Ideally it would be an engine that allows the developer to have access to all parts of the engine and make changes as they needed. This is all pie-in-the-sky wishing, but so is entertaining the idea of an engine change and (I think) so is enertaining the idea of any major performance improvements to KSP.
  12. In the hypothetical situation that a engine change would be possible, the only reason I'd care to switch is if there would be a definite and significant performance increase. Graphical bells and whistles are nice, but a higher frame rate with a higher part count would be just about the only thing that would really interest me. That said, I'm not complaining about the state of things now, rather I'm saying I welcome improvements if and when they're possible.
  13. Staffing. Developers are often more fluent in one engine or the other, even if they have used them all. Most likely all of Squad is fluent in Unity, but have little, if any, experience in Cry or Unreal. But that really just comes back to money. Hire new people who know the new engine, or keep the same people and take even longer. Either way, any move that is going to take years is going to cost a lot for very little return. It's not a good investment. I do agree with you that the only way an engine move is likely to occur is if they decide to make a sequel. That's something new and people would be more likely to pay full price.
  14. Moving to a different engine would take a long time. I'd guess it'd take at least two years. And for all that time and work, there'd be very little other progress. The main reason comes down to money: Squad won't make much money from new sales in the 2+ years it takes to move, and they probably would not see much sales after the move either. Not many people line up to buy an 8+ year old game at full price. And in those two years of no progress and little to no income, they'd have all the cost of salaries and keeping the lights on at the office. There is no financial reason to move. And there's no guarantee moving to a new engine would improve anything. As to why Unity: no one involved with the creation of KSP had ever made a commercial video game before. They had a small team, I believe just HarvesteR himself, and a small budget. Unity provided a full engine and editor that was fairly easy to use at a great price. I wouldn't be surprised if Unity's cross-platform nature had something to do with it as well. And originally KSP set out to be a 2D game. It's very likely that by the time the limitations of Unity really started to be a problem, so much work had been done that starting over would have killed KSP completely (see above paragraph about moving engines). At this point there are game and physics engines that might be more capable at handling everything KSP needs, but I would guess that KSP is going to be a bit of trouble for most/all of them. It's one of the first modern 3D games that had "planet-sized" planets that are not only circumnavicable, but also able to be orbited, and a solar-system sized solar system able to be explored, all seemlessly and without pausing the action to load. That is not a thing that many (if any) existing engines are set up to handle right out of the box. I would guess that if not for Unity none of would have a KSP to play.
  15. If they're going to do it through Steam Workshop then they might as well forget about Steam Workshop and just do it through their "official" mod repository, Curse. Why do work twice, once in a way only part of your audience can benefit from, and agan in a way that all of your audience, including Steam users, can use? That's why I suggest building it completely into the game. Then no one, steam user or otherwise, would ever have to go anywhere at all to get missions for the expansion. @Azimech Actually, I hadn't considered distributing required craft files for missions, but that makes sense, too. My original suggestion was for the base game to be updated to allow for both expansion and non-expansion users to share craft files from within the game, and the expansion could use that infrastructure to make missions available as well. I realize this is a lot of work and the faster and easier way is to have a place external to the game where players upload and download missions for the expansion. I don't say that as a dismissive judgement; the amount of work involved is incredibly different between the two methods. I mention all this again because I believe keeping everything in-game is the best solution for players. I suspect this is entirely outside what Squad is trying to accomplish with the Making History Expansion, but I'd love to be wrong.