*beginning my own rant and wall of text*
--verboseLogging on
I have to say that some in this thread seem to not have a clue as in terms of the challenge or level of plumbing that needs to be added, or worse changed\reworked and retested, in the course of adding tunnels or wall to wall buildings two thing things that are hardly just cosmetic changes. Further more it makes me almost laugh at certain assumptions about the level of investment it may take to fix (in backward compatible ways) particular things, or assumptions some make that certain things are just a "gui" problem, which more than likely are not just "gui" problems at their root. By all means complain about what's broken or what you think is broken, but try and be somewhat careful about making assumptions about what's very easy to fix unless you really do know.
Also when it comes to something like night mode (which I might add I've seen nobody commit to adding), if one is talking about something beyond just literally making it dark out and having models with light sources, ie adding a full daily cycle and adjusting everything to work semi realistically to that new cycle, I don't think there is enough appreciation for the rework that has to take place for that to happen in a meaningful way. The present "time system" if you will, does not seem built with that in mind, actually for the most part it doesn't exist, and it's not the type of feature super easily tacked on after-the-fact. Now that's an assertion\assumption of my own, but it's basis is in actually having looked though a not insignificant amount of the games code to gain some overall picture (and by no means absolute), of how things operate presently.
But yes certainly there are some things wrong with whats in the game already, there are some bugs that never should have made it past Test\QA prior to 1.0, there are a few things that could have been implemented better if they'd know they were going to sell a million copies and have 25k+ items in the workshop in a month. I'd argue if they'd know they were going to sell 1m copies they probably would have pushed the release a couple months knowing it could benefit by some more fit and finish. There are things that seriously need to be added for longer term playability (some of these modders have spent countless hours adding), many of these items are well documented here already and at least some have been acknowledged by CO or PD. Some of these are are quite frustrating, it doesn't make anyone a "troll" for talking about such things unless they're going on insistently about it day in and day out. However, flying off the handle that it's been a mere couple weeks since the last update (apparently doing so even before reading the last update) is a waste of time and emotion and to do so in the matter that at least one poster did in this thread did not speak well to that person's character in my opinion. Particularly given that CO\PD gave a heads up that they would be in a down cycle communications wise for awhile. This isn't new, communications even during the build up to launch (outside the last couple of hype train weeks), had some up cycles and down cycles.
C\O is apparently in heads-down dev mode, if you've ever been there with lots of parts and plumbing moving around, it's usually not advantageous during such a phase to have your CEO or marketing team start putting out every detail of what they're up too, it's time consuming, sometimes puts out inaccuracies, and it risks setting expectations beyond that which can be delivered in a given time frame as things change. They now have on the order of ~1m customers (probably at least 500k more then they ever expected), all with competing interests along with they're own that they have to manage. Now maybe they're not doing as good a job as they could, or maybe their doing the best to balance it all at the present time, I don't know for sure, I'm not in Marina's shoes and don't have the visibility she or CO\PD team members have into the project. As to the small team aspect, no it's not an "excuse" for certain things but rarely has it been used as such by c\o directly when it comes to actual bugs, but more an explanation for decisions of what made it for launch, and what in some cases didn't, that's just reality, and one in most areas they were fully open about prior to release. Now posters use of it here is a another matter and has been varied and I agree in some cases\contexts used as an excuse where it really shouldn't apply so I understand some frustration in that regard.
What I do know though is the last thing I ever wanted was someone in marketing or sales telling our client or customers what was or was not going to make the next build beyond what was absolutely committed too or previously spec'd, or worse speaking about exactly how a particular thing would work internally in the next build when my dev team didn't even know for sure yet exactly how something was going to end up working, or if it would be ready for production at a particular time, or if something would even be "fixed" at all. Now some of that comes from having to manage expectation, some of it is my personal desire to usually under-promise and then over-deliver. But more than that it's because 'things happen' during these periods. You go fix something in X, you realize you break Y, so you go fix Y, and that makes Z work a bit differently than it used too because the system is highly coupled, so you often you have to step back and say "crap, you know we gotta re-think this design a bit and rework how X,Y,Z work, especially if we need to add A now, or B down the road which we never accounted for, or a third-party wants to plug-into C". Oh and maybe A now will have to work slightly differently then we planned or Y is going to work a little differently now under the covers, I'm so glad sales didn't commit to the client exactly how A and Y would work under the covers. That happens all the time even with some of the best "original" designs, needs and requirements change, and designs need to be re-engineered and that of course can add extra week(s) of dev and test time that might not have been in the plan. This one of several reasons why it's quite common for dev's when asked how long something might take they come up with what they actually think and then multiply it by at least 2 or 3 trying to account for the known-unknowns, or the unknown-unknowns that inherently come up.
Something else when it comes to the topic of the small team aspect is worth mentioning as well, with regard to the mention up thread to something like "hey you made a ton of money just throw more developers at the project". *sigh* Now I've probably used this comment or something similar in my life at some point too. But that comment in my opinion can show some ignorance when it comes to software development projects, or even more broadly for that matter, so let me opine for few seconds a little on "throwing more bodies" at something.
Sometimes that's not easily done, as useful as you might think, or even smart when taken too far. To the later part of that, you don't want to grow too fast, every team member you add has impacts and long term costs too, sure you can afford them today, can you afford them though to the next game and revenue cycle? Careful, you don't want to become Maxis 1997 and have to sell your soul because you grew too fast (yes I'm over simplifying). Then there is the time taken up by the interview process, and in any decent company this isn't just "HR" time, it's time out of at least some of the developers days to meet and talk with possible candidates, that's the time itself, some level of prep time and the time it takes to get their heads back into the depths of what they were working on prior such interviews.
That's just standard stuff, so lets just assume for the sake of argument they did decide to throw a couple more experienced dev's to the project along with say a graphic artist (is that term still used?) for helping with production of art assets, or even just brought on people on as contractors for whats needed. These people typically need some ramp-up time before becoming as productive as possible, that doesn't happen overnight, it can take several weeks, both from an actual work-product stand point and an interpersonal\team dynamics standpoint. So if you have a deadline in a couple weeks it may not help you meet that particular one, it might even slow you down temporarily as time is spend bringing others up to speed.
There are also cases where it doesn't actually help to add more cooks to the kitchen, creating issues where too many people trying to change the same parts at the same time, can cause issues that actually slow progress. Then there can be the logistics of it, if they're local do you have desk space for them? If they are working remote are you setup for that, how many timezones are they away from the rest of the team, what impact does that have with everyone staying in sync? My point simply is sometimes yes it's as simple as "throw some more bodies at it", to make something happen faster, if you need to move 1000 bricks from one side of a yard to another by hand more bodies will likely make that take less time, and the effect is immediate. If your trying to add all sort of things to a reasonably complex code base, sometimes it's less useful than it might appear on the surface, or at least it's benefits not as immediately seen. This isn't me saying C\O should or should not add team members, they probably have added a person or two, it's me trying to explain though that even if that is the case it doesn't always translate to faster release cycles so "throwing more bodies at it" may not produce the results one of the posters assumes.
As to the decision, or least perceived decision to add things to the game before fixing\tweaking certain aspects I would ask the following question. If you know you're about to make some semi-fundamental additions and changes to the game how much sense does it make to temporarily patch up a few existing items, test them and put out a release if you know you're just going to have to go back and re-work some of those very same items a bit anyway when you go to make the deeper additions?
Personally I tend to think it's better to just focus on making all the plumbing changes and additions up front, work though through making the existing stuff work with the new and seeing then what still needs fixing and tweaking, and doing so, in the same cycle, so that I don't have to touch and retest things multiple times. If that means pushing a release out a few extra weeks to not have to cause double the work in some spots, then so be it, assuming I have control of the schedule of course and any impact of the delay is minimal.
I don't know for sure if that's the case here, but it I can see the their logic of the decision of it was the case.
TLDR: errr idk, oh nevermind it's all going in one ear and out the other anyway.
