Due to changes in the RSI website introduced with the launch of Spectrum, the dev comment scraping provided by Parted Veil is no longer possible for the new Spectrum forums. For now, the site will remain and archive comments made on the old RSI forums until I have sufficient time to re-engineer it for Spectrum support.
|Lumberyard for those interested...|
Lumberyard and StarEngine are both forks from exactly the SAME build of CryEngine.
We stopped taking new builds from Crytek towards the end of 2015. So did Amazon. Because of this the core of the engine that we use is the same one that Amazon use and the switch was painless (I think it took us a day or so of two engineers on the engine team). What runs Star Citizen and Squadron 42 is our heavily modified version of the engine which we have dubbed StarEngine, just now our foundation is Lumberyard not CryEngine. None of our work was thrown away or modified. We switched the like for like parts of the engine from CryEngine to Lumberyard. All of our bespoke work from 64 bit precision, new rendering and planet tech, Item / Entity 2.0, Local Physics Grids, Zone System, Object Containers and so on were unaffected and remain unique to Star Citizen.
Going forward we will utilize the features of Lumberyard that make sense for Star Citizen. We made this choice as Amazon's and our focus is aligned in building massively online games that utilize the power of cloud computing to deliver a richer online experience than would be possible with an old fashioned single server architecture (which is what CryNetwork is).
Looking at Crytek's roadmap and Amazon's we determined that Amazon was investing in the areas we were most interested in. They are a massive company that is making serious investments into Lumberyard and AWS to support next generation online gaming. Crytek doesn't have the resources to compete with this level of investment and have never been focused on the network or online aspects of the engine in the way we or Amazon are. Because of this combined with the fact we weren't taking new builds of CryEngine we decided that Amazon would be the best partner going forward for the future of Star Citizen.
Finally there was no ulterior motive in the timing of the announcement. The deal wasn't fully finalized until after the release of 2.5 and we agreed with Amazon to announce the switch and partnership upon the release of 2.6, which would be the first release on Lumberyard and AWS. If you have been checking out our schedule updates you would know that we originally had hoped to release 2.6 at the beginning of December, not Friday the 23rd!
I hope this clears up some of the speculation I have seen. We are very excited to be partnered with Amazon and feel this move is a big win for Star Citizen and by extension everyone that has backed the project.
p.s. I wont be replying to this as it is Christmas and I am meant to be enjoying a bit of time off with my family (and playing some games - you may see me pop into a Star Marine or AC match or two!)
p.p.s Happy Holidays All!
|Itemports and Sizes|
I see there is some confusion over what was described in yesterday's design post. I thought it was clear but I can see that there weren't enough examples in the post.
The rule is -
You can only plug an item one size smaller into another item - so if you have a size 4 item and want to plug it into another item that has an itemport (a turret would be the most common example) the item would have to be at least size 5.
if you plug more than one item into another item the sizes of the multiple items are additive against the size of the host item. So if you plug three size 3 items into an item it will need to be at least a size 10 item; 3+3+3+1 (the 1 is because you lose 1 size point being a host).
You can think of the size of a hosting item being available points to be spent on itemports on the hosting item minus the two modifiers we've specified;
-1 being a host
-1 to be a manned turret (as you need room for the gunner)
Common "hosting" items would be Remote Turrets (what people refer to as Gimbals) and Manned Turrets, but there are other examples - the Rear Engines on the Cutlass also have a secondary itemport for a maneuvering thruster, or there could be simple mounts / adapters to just fasten two guns or missile pylons to a single ship itemport. This could be a way for you to get double weapons on a single hardpoint that doesn't have the necessary Pipe hook ups for a Remote Turret / Gimbal.
The system (which has been in since v0.8 but not really utilized to its fullest as we haven't created enough items nor finished all the ship item systems yet) will allow us to extend functionality of ships by chaining items together in ways that we may not have considered when first designing them.
For instance there could be a Size 4 Remote Turret / Gimbal with a Size 2 weapon slot and a Size 1 Targeting Computer slot. If you plug in a weapon and the targeting AI module it would allow the Turret to be a remote auto aiming turret that could fire independently of your control (you would still have high level control on allowing it to fire or directing targets but it will happily fire away at enemies independently of what you are doing if you tell it to)
One last and very important note. The current listed sizes and classes for ship hardpoints (what we call itemports) WILL change now that we are sharing the actual system the game / code uses. As the post explained there was crossover between the original weapon class hardpoint system (as it also involved size) and the size rating. So a Size 4 Class 5 turret was not the same size as a Size 4 Class 4 Turret. This is why we're normalizing it now and aligning it with how the vehicles and items are actually set up.
So please don't worry about multicrew ships being nerfed and not having any firepower - the listed sizes of the various itemports (formally weapon hardpoints) will be adjusted to keep them inline with where they were before (this of course excepts cases where we feel we need to adjust for balance reasons)
I hope this helps (of course i can foresee a whole new slew of threads popping up :-) )
EDIT: ADDITIONAL INFO TO ANSWER QUESTIONS -
1) The system is a general rule of thumb, it does not mean that you will be able to do every hypothetical configuration - it will be limited to the Turrets / Mounts we create / put into the game. If it doesn't make sense for a certain ship due to how the ship is configured - say if a Turret had a single Size 4 weapon that would clip into the ship's geometry but a Turret with two Size 2 weapons wouldn't we would only allow Turrets with Size 2 weapons to be mounted on that particular itemport.
2) Itemports that can accept Manned Turrets will likely only be suitable for Manned Turrets (so you could not a mount a Size 6 Gun on a Size 6 Manned Turret Item Port) as Manned Turrets itemports are open / have access to the interior of the ship for gunner access.
3) The plan for the Hornet is to make the itemport where the Canard Turret is mounted to be a size 3, where you could mount a Turret with dual size 1s or a single size 2 (this would be a different Remote Turret you could buy in game) or a fixed Size 3. The Ball Turret would be a size 5, allowing two size 2's to be mounted and the wing itemports would be size 3 allowing a fixed GT-220 (that would auto converge) OR a gimbaled Size 2 Gatling (the GT-215 'Scorpion' for instance) for a wider cone of fire.
4) The Constellation Manned Turrets will likely be rated Size 8 - 2x Size 3 Guns (the Panthers were what we used in our demo) +1 for gunner + 1 for host). Please don't think that a Class 5 Size 4 for this Turret meant you could mount dual Size 4 weapons! The size on the ship stats was about the Turret - which is a good illustration of why we are normalizing the itemport system so you can see the "potential" of each itemport on the ship you are buying beyond the default load out.
5) The Retaliator Turrets will be size 6, although right now we have some sizing issues when putting a Badger (they look a little oversized for the current size of the turret) vs. a Bulldog
|Rental Equipment Credits (REC)|
One last post before I get sucked down the rabbit hole that is forum debates :-)
I just want to point out that Arena Commander (and the upcoming FPS module) is a test bed. We use it to test, balance, and stress test functionality that will be in Star Citizen and Squadron 42. Along the way we decided it would be cool / useful to have it be a game within a game so players could learn and train without having to risk their hard earned ship and weapons in the PU. Until SC is finished, AC is very much a work in progress that is more a test bed than final, polished game.
Yes we have added game like functionality; leader boards, different game modes the proposed REC system but its really all for test reasons. By "gamefying" our test bed we hopefully make it fun for people to spend time in it which helps us make SC better in the long run. Part of what I think is the revolutionary aspect of how we are developing SC is that we try to make following and participating in the development of the game fun for everyone in the community that wants to participate.
Where it becomes frustrating is when people start treating AC like a finished game and making assumptions on how SC will turn out based on a very much work in progress (and changing) AC, which only affords a small window into what Star Citizen and Squadron 42 will be like.
REC is something that takes extra work to implement and wasn't in our original development plans but it is something that we think is definitely worth doing. Only this past week I reinforced to the Area Commander team that "AC Bucks" (REC) was not something we could push back and re-prioritized other tasks to make this possible for AC v1.1.
So yes, I got a little exasperated when after making a requested community feature a priority to get accused of turning SC into a "freemium" game with all sorts of "grind". The point of REC isn't to decide on the game economics or prices for weapons, or turn SC into some sort of the Korean MMO grind fest, its purely to allow a route for players to earn things by playing so they aren't forced to pledge for them but this is entirely optional. Just like no one needs to do anything more than pledge for the most basic ship, no one needs to spend a minute of their time in AC. If you do then we are grateful to have your participation and you'll be making a better game.
REC allows us to give an incentive for certain parts of the game to get tested. Right now testing different player ships against other player ships is more important for the ongoing balance of the game, which is why REC is focused on the PvP side of AC. We recognize that people don't want to be put into the current completely open bear pit that is ranked AC games, so we're also working on the ability to have brackets to match players of similar ships and / or skill in games and also allow people to opt out of the public leader boards. This will be after v1.1 though.
There is nothing to stop us from deciding that we need some more focus on PvE - perhaps a mining scenario we want to test out and so we reward players with REC if they mine a certain amount or open up REC for Vanduul swarm - although I do believe you need to segregate progression on multiplayer from single player or else you'll just end up with Super Hornet vs Super Hornet in AC multiplayer!
So think of REC as a tool to allow us to encourage a larger player base to focus on areas of gameplay we would like to get a larger sample / bigger stress test on. Its also something that we can give out and not impact the PU (unlike UEC) and there is still nothing stopping us from making a certain ship or weapon free or greatly reduced in REC for a limited period in order to get people to test an area we feel we need more data on.
I hope this helps in understanding our intentions with REC.
|Rental Equipment Credits (REC)|
Who would have guessed that a feature we're adding to allow people to earn the ability to fly ships or use weapons they haven't pledged for would cause so much controversy?
It is much easier for us to NOT do this. We are specifically implementing a way for backers to earn ships via gameplay much earlier than we originally planned because this has been one of the main community requests. But it does take engineering time both on the client, the game servers and the web platform, which means it costs money - and takes away engineering time that would be spent on other aspects of the game.
In our view it is worth the investment as it will allow someone that has supported the game to have the same choice that they will have in the final game to play the game to earn new ships and items or if they don't have the time to do this pledge for new items, which supports the ongoing development and running costs of the game (and yes 300+ people, petabytes of data and dozens of servers are not free).
We're doing it now rather than waiting for the PU to be functioning to give people a progression and reason to play Arena Commander, which helps us balance and test the space combat aspect of the game. It is a win for development and I think a win for backers but I'll happily run a poll as to whether we implement REC or not. I suspect the majority want this system but I could be wrong.
One thing that wasn't clear from the Friday post was that REC time is not real life time - its based on daily play. A week in REC is not necessarily a week in real life as the 7 days don't need to be concurrent. If you log in over 7 days over a month that would be the same as logging in for 7 consecutive days. The example in Calix's design overview of needing about 7 hours to "earn" a Hornet for a week was on the rational that playing 1 hour a day for 7 days would earn you a Hornet to fly for 7 days. Seems a pretty fair trade off - especially for a ship that others have contributed $110 for the right to fly the same ship in the PU and AC.
Don't forget that these contributions are what is allowing us to build a game with the unparalleled ambition of Star Citizen - no other crowd funded game comes even remotely close - by the time we're done you'll be playing a game that will have well over $100M sunk just into its development costs, including a single player component Squadron 42, that will have more play time and quality than most retail AAA first person action games.
What REC allows us to do is give people that haven't got got the same financial resources to contribute another way in our quest to make Star Citizen the BDSSE by giving us their time to help test, balance the game and then reward them with ability to try out ships and weapons that they would otherwise have to wait until the game is finished to be able to fly.
It is something that I hope most people would think is a good thing, not a bad one!
Moderator note: for additional information and context, a follow-up post from Chris later in this thread is located here:
|[Clarified as a misquote] CR told PC Gamer CIG would invest 100 Million of "it's own money"|
I read the PC gamer and the I found a discussion on reddit (and a quick search here brought no result) that CIG will probably bring 100 million of "it's own money" into Star Citizen. That's pretty interesting and for me it is suprising as well. Does anybody know were that money is coming from?
This is a misquote - What was said is that we'll probably have invested at least $100M into the development of Star Citizen by the time it "launches" to the public. This is based on our intention to invest all the money we raise during initial development back into the game (which I've been quite public about) and the fact that we will most likely raise this much by the time the full vision of Star Citizen is polished enough to be called "public" (of course all you guys will be experiencing Squadron 42 and the PU before this as part of the benefit of being backers and being part of the development process)
You guys are literally setting the budget and ambition of the game with your support which in itself is a pretty amazing thing and something I never would have believed possible two years ago.
Hope that helps!
|Biggest ship you can buy in-game is the Idris|
I'm just going to point out that having a question answered by one of the many developers on the project over a year ago with his understanding at the time (when the Idris WAS the biggest ship that we had sold) does not make it an "official" position on what we will be doing.
Unless it comes from me or through an official channel like a front page post it's just one of our dev's knowledge / opinion at the time. It's part of the downside of being so open. We could vet every post but then it would greatly reduce the amount of questions that could get answered and generally make the process slower and less informative as we would be forced to not answer any question that doesn't have an official position or final design on them - which would probably be the majority of the Ask the Dev questions. When you Ask a Dev, you're getting that Dev's answer to the best of his knowledge from his small view on a huge project (We have close to 300 people working on this game and keeping everyone informed and up to date on all aspects of the game is an impossible challenge)
As you can see from the stretch goals we have promised that players can fly ships all the way up to a Bengal Carrier. The truth is that we haven't fully decided on what the largest ship that will be offered before launch in aid of funding Star Citizen to be a game more ambitious than any publisher has ever attempted. Right now we've decided after a LOT of requests and petitioning by the community that we'll seed a few Destroyers into the player mix.
The Javelin is a BIG ship (some 350m long), with a LOT more firepower than the Idris - and will require a decent player crew to run, so its really a ship for a group of players. It, like the Idris, offers different play options and since we want the PU to have player driven drama and conflict in addition to the NPC scenarios, getting some of these ships into the hands of a few organizations will enable more varied encounters between players (or players against NPCs). We want a mix of small single seater ships, medium sized ones with 2-4 crew members and bigger ones like the Idris and Javelin that could become the focal point of a bigger engagement.
As I've stated many times there will be no case that you can pledge for a ship before launch that you can't get in the PU. So if we're selling the Javelin now there will be opportunities to purchase one in the PU with UEC, capture one or perhaps get one as a reward for some huge accomplishment. But just like now the number will be limited as the production of big ships like this and the Idris is slow and the UEE doesn't decommission and sell its older capital ships that often.
I hope this clears things up for people.
|Australian Server will be in Singapore not Australia Until Infrastructure is created|
Personally I interpreted 25Mio strechtgoal like the Aussis: having different servers all over the world so ppl can play/test early alpha state with acceptable pings. Im am located in Europe (imho biggest group of backers...so why the hell first and only gameserver is located in USA and not closer to biggest group of backers ???) and disappointed like the Aussies.
The biggest single area for Star Citizen is the USA at 38%, the next is Germany at 13%, then the UK at 9%, then Australia and Canada are tied at 7% each.
There is a large team of people working very hard to fulfill a very large vision. Many things are being worked on in parallel. One of them is a flexible and dynamic back end that should help reduce latency in matches (assuming there are enough players in a co-located to make a local instance viable). I just wrote a detailed post outlining the concept and where we are in its implementation. Its kind of hard to have servers in multiple geographic locations before the dynamic server system is completed. Once it is we will start spinning up local game servers on demand based on where the players are in automatically matchmaked games. You will also be able to override this (in the case you want to play with your friends in the US or somewhere else in the world)
As the largest group of backers are in the US, and the backend team and live ops are all in the US, it is common sense that the first servers would be in North America. That has always been the plan. With the $25M stretch goal we decided to accelerate our plans to have geographically co-located servers to handle the low latency game servers as we now have the funds to cover the additional operational and engineering costs that this entails. This is in process.
I know patience is a hard thing to have but these things don't instantly happen.
Remember everyone isn't playing Arena Commander v1.0 yet, let alone the later versions like 2.0 and 3.0 that bring the full suite of space combat features to play so please don't expect a full featured backend just yet.
And for everyone who is wondering; I'm not still in Australia - just suffering from Jet Lag (and need to sleep rather than play forum warrior!)
|Australian Server will be in Singapore not Australia Until Infrastructure is created|
15 pages for a debunked OP. What the F is going on with the mods around here?
Does everyone assuming the worst and raging on here realizes that the only servers that anyone is playing on are in North America at the moment?
I did NOT say there would not be servers in Australia. And contrary to everyone's outrage the $25M stretch goal doesn't promise servers in Australia right away. What we said was that our initial plan was to spin up servers in North America, then slowly expand to have servers in other areas like Europe and Australia once we launch to help decrease latency. The $25M stretch goal was to allow us to start this sooner, and allowing for servers in more than just North America for the early testing. We are STILL doing this. The stretch goal did not say Australia gets a server right away for early test BEFORE everyone else but North America.
For the record we currently spend north of $80K a month on a combination of our servers and CDN (Content Delivery Network). This is all for early testing - it costs money for everyone to download the patches (yes we're working on making them smaller) and to have servers running 24/7. This doesn't include the Live Ops cost of people that maintain this - currently we have a 6 person team that focuses on this (this doesn't include the web team of Turbulent BTW). I'm pretty sure we're investing much more than anyone else to keep its community involved and up to date on a game that's still deep in development.
We have chosen Google Compute for our initial cloud implementation as we think its the best combination of power, price and flexibility. We are attempting to build a dynamic server system where local nodes can be spun up to handle the hi-fidelity server "instances" in areas that would help reduce the ping for people that are matched together. Arena Commander is our test bed for this. When you join a multiplayer match you are currently connected to a game server by the matchmaking service. This server eventually will spin up on demand in an appropriate location to the people that the match maker has put together. In the PU as you travel around a Star System (or jump from one to another) every time you come out of "warp" (or jump) you'll be handed off to one of these server instances that will be spun up on demand taking into account where the people that have been contextually matched together are playing from. As we're first prototyping / building on Google Compute this will naturally happen where there are Google Compute data centers. With some extra work we can fold other Linux Server Cloud providers into the matchmaking and server management. But it doesn't make sense to do this before we've even finished the base system on Google Compute. Right now we spin up a fixed number of servers in the Google NA data center for the current multiplayer. One of the ongoing engineering tasks is to make this dynamic based on demand and then at different data centers around the world. Once this happens we would be ready to expand it to other cloud server providers if need be. Its pretty likely that Australia will get a local Google Compute data center before this but if not we would spend a little extra time making the backend system game server provider agnostic.
So I would appreciate it if everyone put their pitchforks down, took a deep breath and actually be happy that we're thinking about how best to use the power of the cloud to allow for a better game experience for everyone, Australian's included.
|Australian Server will be in Singapore not Australia Until Infrastructure is created|
Hi all. After the Pax FPS reveal I was able to get some time with CR to discuss the location of the Aussie Server and where exactly it would be. He was able to confirm that it will in fact be in Singapore. Although I was expecting this as we have been told on numerous occasions from the 25 Million stretch Goal that we would have our own server. The stretch goal states the following
Horse's mouth here.
The discussion about Australian servers was taken out of context.
The issue is that we're building our PU server framework on Google Compute and doing a lot of things like dynamically spinning up and down servers on demand. It is possible for us to have a non Google Compute server extension but that will require additional logic and code. So for the early stages (like pre-Star Citizen v1.0 launch) we will probably be limited to places where Google Compute is available. Which is where Singapore came up as I believe the closest Google Compute data server to Australia is based there. If Google sets up a data center locally to Australia then we would enable nodes there. In fact part of the design we are going for is to allow us to spin up and down game servers via Google Compute as geographically co-located as possible - not just limited to the usual suspects like North America, Europe and Asia Pacific. This is the longer term goal but one where you get to harness the true power of "cloud computing" for a better game experience.
p.s. I am writing this from Australia :-)
|(CryEngine Video) Making Ends Meet [Salvaging/Scavenging]|
Hey Community! It’s me again.
Awesome video! You just visualized some of the encounters / gameplay we're planning for the PU :-)
|Thor's beard, CIG, what the hell did you do to the 300i?|
I've driven MRAPs that handle better than this "luxury touring" ship.
If the 300i got worse from v0.9.0.1 to v0.9.1 then it wasn't intentional. There was no balancing on ships or items in v0.9.1 - it was pretty much for control customization and SLI (and a lot of little fixes).
Likely someone changed something that had a ripple effect on the 300i and QA didn't catch it. I've asked QA to look at it in the am and also want to institute a balance review before releases to help catch issues like this (its hard as although we have a big team we're actually quite understaffed for enormity of the whole project that is Star Citizen)
But the basic rule is if the patch notes didn't say balance tweaks on the 300i (or on weapons its using) any degradation of performance was not intentional.
v0.9.2 (our internal R13.2) has some significant aiming / targeting / fine flight control changes that I hope people will appreciate - it definitely is a much better set up for fixed weapons but also doesn't go back to auto aim. I think this will also help with some of the complaints from Aurora and 300i pilots versus Hornet pilots. There is also a limited look / aim assist mode for gimbaled weapons for josytick users so they get some of the benefit of a gimabled weapon even though they don't have a good way of controlling their look / aim (you can also set up the joystick for flight and the mouse for look BTW)
|Evasive Maneuvers Useless!|
Been saying it for a long time, nearly every simmer i know said that about AC as well, the entire flight sim community says that as well.
I think a key part of space combat does boil down to "put the most guns on one target". I don't know why that is a put down. The issue is in achieving that goal. With Eve its point and click and with Star Citizen it is most definitely not.
Even in the early stages of Arena Commander There are some amazing dogfighters out there - and if there was no skill involved it there would be no way that players in a Aurora or a 300i could beat a Hornet. There are clearly good and bad pilots in Arena Commander and if you spend time watching the matches, looking at Twitch streams and reading the Arena Commander forums you could see the combat is nowhere near as simple and "casual" as you seem to think it is. It is just different than what you are used to. Arena Commander still has a long way to go - and with v0.9 there will be more features that will further add to the depth (and leader-boards that will show there is a clear skill hierarchy), then a lot more for v1.0 and beyond.
However if you're looking for an atmospheric flight model in Star Citizen you are going to be disappointed - I made a deliberate choice to embrace what space combat maneuvering (at low speeds) would be like. Games should have their own personality. I don't want Star Citizen to be a rehash of other games. I think its great that Elite:Dangerous and Star Citizen have different approaches to the space flight model - that allows for diversity and difference in game experience (who wants to play the same game rehashed over and over again?).
One other thing to consider is with Arena Commander people are only seeing a very small window into what the world of Star Citizen will be like. There's going to be much much larger play areas, much more need for system, energy and radar signature management, huge multi crewed ships mixed with small single seater ones, play geared to both cooperative play and single play, combat that works for both PvP and PvE. There's going to be plenty of stuff to challenge even the most skillful players but you also have to remember the game needs to be accessible - not everyone is a "simmer" - some people want to explore, some want to trade, some just want to sight see. My objective is to make it easy to get the hang of flight and combat but difficult to become truly masterful. I strongly believe the current design will deliver this in spades once all the features come on line.
|Video: 300i vs. Hornets - huge balance issues.|
Nice flying! And a great Voice Attack set up! "This is bullshit!" gave me the biggest smile of the day!
|Biggest (only?) disappointment is CIG's communication style|
I keep seeing this, especially recently. I DID NOT promise the DFM no matter what in my interview with Nathan Grayson (who writes for Rock, Paper, Shotgun). This is a misquote. What I told him is that the community would get something before the end of the year no matter what, but said the multiplayer DFM making it was up in the year because of the issue of the backend (do it right or delay) and I wasn't sure about doing single player only. As you know we delivered the shooting range and a few other things for the end of the year as fun bonus for the Hangar.
Whether or not Mr Grayson was deliberately trying to stir things up or made an honest mistake I will let you guys decide but don't you think if I was making this promise you could find a direct quote from me or it would have been somewhere on our site?
As for the DFM, well you wont have to wait much longer :-)
|Chris Roberts reply to what the role of the "Community Ambassador" is in relation to TNGS|
I posted a reply in the comments section of the TNGS but I'm going to repeat here.
Everyone seems to be getting worked up by the "Community Ambassador" moniker. Dan Gheesling is NOT the ambassador for the community for Star Citizen. He's the Community Ambassador for TNGS to bring his reality TV competition experience combined with his genuine fan hood for Star Citizen to help the teams with the community.
Everyone should know that Dan is an ORIGINAL BACKER from October 2012 (long before we were the sure thing we are now), a Wing Commander player (and a gamer) since he was a kid. He talked to us last year about the assistant community manager position working with Ben, It didn't work out because he didn't want to relocate from Michigan (for all of those that think he's too "Hollywood!") but instead offered to help out TNGS when we were putting plans together for it last year. In fact he introduced us to some of the behind the scenes crew (and yes, they're from the "evil" reality TV world - but that's how to do these kind of shows efficiently (and therefore economically)) I know everyone thinks something like TNGS (or even WMH) are simple to put together and you just need a cheap camera and a YouTube account but they involve a lot of pre-production and logistics - and we have an added complication due the time it takes the competitors to produce work (as opposed to a singing competition where you can hear someone sing a song in 2-3 minutes). You need people with experience in this world to mount something this logistically challenging. I am sure you would all be upset if I hired a bunch of people who had never programmed before or made a video game and tasked them with making Star Citizen!
Personally I thought his interview was really good - I've never been asked some of those questions before - they're normally pretty softball.
I'll admit we should have explained the Community Ambassador moniker better or perhaps called it something else like "Team Ambassador" - the idea is that he'll spend time with the teams and help them with building their support bases in the community and how they pitch to judges. Something that you cant argue he has experience and has been successful at in the past.
I thought Episode 1.8 of TNGS had GREAT content - really impressive updates from the various teams, we found out which two teams were "saved", saw a little more of Mustang and had a nice in depth interview with me.
So it is disappointing to see so many comments NOT about what 95% of the show was but about!
I get that a lot of people hate reality TV, and maybe that background should have been much less emphasized and more Dan's genuine excitement and passion for Star Citizen. I know its easy to be critical in comments / forum posts but this a real person and what's worse he's a backer that's been there from the beginning and is doing this to help!
Everyone should all be proud and excited that Star Citizen has backers from ALL walks of life.
That's what I love about our community - I'm constantly surprised by the different people I meet that are fans of space sims, my past games and Star Citizen - pilots, lawyers, bankers, teachers, firemen, policemen, doctors, nurses, actors, athletes, politicians, chefs, gardeners, rescue workers, soldiers, plumbers, electricians, construction workers, miners, oil rig workers, scientists, and even reality TV stars!
|What I was expecting for damage states... [NOW w/Post from CR]|
You just saw a PART of the damage system in the video. There are other layers like laser marks / burns, bullet / armor hits (achieved with decals + height maps) .
Something that people may not have picked up is that while we have discrete states of damage for every part each state has multiple pieces (panels etc) that can break off. At the beginning of the state all those pieces are attached to the base damage geometry and then are broken off if there is a laser / projectile hit in their vicinity. So between the projectile hit decals, bits of the geometry breaking off near the impact point it will definitely look like the ship is responding to exactly where you are hitting.
Transitions between states - which is flexible in number of states per part as it really depends on the size of the part and how much fidelity you need so the progression looks right (and available artist time) - is more absolute (i.e. when you go from damage 25% to damage 50% the same thing happens although the impulses of the detached geometry is random), so the wing will break in two or sheer off when you hit 50% damage (although if enough damage is done it will skip a state, which will have the effect of feeling / looking different).
We're also accurately tracing all projectile hits so if a bullet breaks through the shield and armor it's path will be traced inside and if that projectile collides with an internal component it will inflict damage.
Every ship system has a physical location and collision geometry even if it doesn't have render geometry (which is the case with an internal system). If that system is damages or destroyed it affects the ship on a fully systematic way. The obvious answer is the power plant - that gets damages (and doesn't blow up) its power output will decrease or stop. Every system has a power input and if its no longer receiving power will cease to function or in the case of reduced power either function at less power or not at all (depending on the device). Of course if you have some batteries / capacitors then the systems hooked up to the batteries will have some reserve power before running into trouble. A less obvious illustration is the ships main computer which provides CPU cycles for the ship's avionics (you can think of this computational power instead of energy power). If ship's computer is destroyed or damaged the targeting computer wont be able to resolve targets / function (as a targeting computer needs power, CPU cycles and a working radar). All ship systems either produce / supply some form of consumable (power, CPU cycles, heat, fuel) or use it. Heat is the negative consumable (you want to dispose of it not store it) - most weapons and some systems generate heat and if you don't efficiently deal with it (or your cooling vents get damaged) you'll risk damaging your ship & systems and at the very least increase your heat signature which makes you a much easier target for another ship's radar / targeting computer.
This is all built in ships with a plug and play system so we just create item "ports" on a ship and plug weapons, radar, power plants, engines, thrusters, fuel tanks, batteries, CPU (more cores means more cycles), targeting system, navigation computer, jump drive, cooling vents / radiators etc in and they hook up the various "pipes" that carry power, CPU cycles, fuel or heat.
Each of these items have their OWN damage states (for the ones that you can see)
So you can see there's a level of fidelity in what we are doing that I haven't seen before in a game and the video today just showed a window into part of the things we are doing to graphically show damage...
On Snowdrop - its a really pretty looking engine and I showed it to the team the moment it was demoed at E3 as I was very impressed. Having said that its not really do much more or different than CryEngine already does - the "procedural" damage that is demonstrated in the video has been something you have been able to do in CryEngine for years (bullet hit decals, breaking a plane of glass, puncturing tires and the car drops onto the rims). Its very well done (beautiful art & lighting) but I didn't see anything that we don't have the tech for in SC and that we are not planning to do (well I guess you cant shoot tires out on a ship but you could on a buggy!) Its been my experience that the very high end engines - CryEngine, Unreal 4, Frostbite all are pretty much equivalent on feature sets and capabilities - its more about how good you artists are and your programmers are in finding cool ways to show of the features of the engine.
Last note (in my wall of text) -
I've known about the BeamNG folks for a long time and talked to them as early as Dec 2012 about working on Star Citizen. I even have a prototype test they did with a Hornet flying in space using their system, crashing into asteroids! The problem with their approach (and soft body physics in general) is that it is really computationally / simulation heavy - its great for demo videos or something like a car game (there's a reason why Forza or Gran Turismo cars always look so good its because they're usually simulating less stuff than you would in a FPS like Crysis 3). Between the network bandwidth issues and client rendering / simulation issues (simulating softbody physics on 50 ships and having a frame rate that is above the single digits) a full softbody system isn't practical for SC just yet even on the high end PCs we're hoping everyone will have!
That doesn't mean that I am against trying to do a streamlined version for damage modeling - I was hoping to get the BeamNG guys to do some R&D on a stripped down system that just focused on the damage modeling / deformation (not so much the full physical simulation of every hinge etc) for SC but at the time we talked they had other commitments (like finishing university) and wanting to work on their car game so we never ended up working out a deal - which doesn't mean that I wouldn't revisit this as they are super talented but right now it looks like they are doing well and living their dream of building their own game (and who am I to stop them?)
This doesn't mean that we don't have procedural damage modeling via deformation in our R&D task list for the SC Graphics Engineering team (which is 4 programmers internally at the moment). We need this solution for capital ships as you want to see large hulls indent or buckle from hits / collisions and if we do something that we're happy with (and meets our performance criteria) we'll probably also apply back to the smaller ships adding just another level of detail!
So I guess the TL;DNR version is be patient grasshoppers!
|CGI: please continue to honor the pledge - UPDATED: Now with more Chris Roberts.|
I'm proud of the frequency and amount of information we share.
I've backed a good number of other crowd funded projects, including pretty much all the high profile ones and I would challenge anyone to show me one that gives a more steady stream of updates and visual updates than Star Citizen does once the initial crowd funding phase is over. I would say Elite:Dangerous and Limit Theory are probably the best of the ones that I've backed as they have monthly updates that include video for LT and in conceptual imagery and occasional video for Elite. Behind this would probably be Broken Age, knocked only because the videos were't always monthly, but they were probably the most polished. But no one is close to us in terms of video (Over 200!), updates (at least 5-8 a week on RSI), conceptual art (we usually share at least 2-3 images per week and then there's a whole bunch more for subscribers in the Vault and Jump Point) or interaction with the community.
I get it that most people are so excited for the game that even at this quantity it is not enough information on Star Citizen. Based on the forum and organization activity, even if we were a 24/7 operation in terms of sharing information with the community it would probably still not be enough!
This is a high class problem to have :-)
One thing that I would like people to remember is that authoring the updates for the community is not trivial. We have some members of our staff, like Ben, Michael Morlan and David Ladyman that this is their main focus and responsibility. But anytime we do a behind the scene (BTS) piece, craft a lore / design post for the website or have a developer answer questions on a forum it is a commitment of someone's time that is important for the development of the game.
I know it's easy for people to off handily throw out that it should only take a few minutes to update the community as we're sharing existing work but if you ask yourself honestly you will realize that's being unfair. To put it in context if you ever had to prepare a report for school, or a presentation for your boss and wanted to impress would you only spend a few minutes on it?
Typically it will take between 1 and 1/2 day of a developers time to shoot a BTS piece and doesn't include the preparation of the assets to show which can take days (this isn't counting the time that someone like Michael Morlan has to put in editing and handling post after the raw material has been shot). Putting together a post with some pictures isn't quite as involved but can easily be half a day depending on the complexity. David Haddock doesn't write his posts in an hour and even an update with pictures or a poll can take hours once you factor in rounding up the art, formatting and getting sign off. Answering questions on a forum will take hours. I spent about two hours reading this current thread and will have probably invested about an hour in crafting this post.
Having said all this I think you all should know we are committed to upping the game in terms of the quality of information shared this year. One of my edicts for 2014 was to have more actual information and BTS material for both our video content and our website. We're actively looking to hire up a few more people for the community communication side and one of the meetings we had at last week's summit was a BTS planning session where every studio working on the game mapped out various things they thought would be cool to share and when they could share them. We decided to move the format of Wingman's Hangar to be built round this - where we show a BTS piece as the center piece and then have hard questions from the forum themed to the BTS subject matter and also have an interview with one or more of the developers working on the feature. It just started and its got a way to go before its running well (does anyone remember the very first episode of WMH - that was pretty rough!) and it wasn't helped that the first feature was the Production Summit, which just ins't sexy or visually interesting (its why you'll never see a show on TV called "The Scheduler"!)
Between employees and contractors we have about 170 people working on the project presently and we're going full steam ahead on all aspects - Space, Planetside, FPS Combat / Boarding, Squadron 42 and the Persistent Universe (which includes all the backend). We have over 10 conceptual artists working on fleshing out the visual look of the universe. There will be lots of content that will be coming down the pike. I don't believe there is a another crowd funded game, or even another PC game that will be able to compete with us in terms of content generation and ambition (thanks to all your generous support), so there will be plenty of stuff to see - just be patient. Development isn't always linear - sometimes you'll have a lot of stuff to show all at once and sometimes there will be a scarcity as you're working on areas that aren't so visual (backend server work which is a major focus right now falls into this category) or you're still developing a look and are not ready to show it publicly. But don't worry that we are deliberately holding stuff back - we're proud and excited by the work we're doing and keen to share it with you as soon as possible.
There will be a 10 for the Chairman on Monday then a WMH with something a little more visual on Wednesday and the final round of the audition finals for TNGS on Friday. There is a lot of pretty amazing stuff in the hopper and I think as we ramp up the team to help us share our progress and the new formats settle in, I'm hoping you'll be happier.
I'm not fooling myself though. I know it still wont be enough :-)
|Eerie space roar.|
Reminds me of 2001! (the Film)
Thanks - nice link...
1st Person view vs. 3rd Person View
I'm pretty sure you'll want to stay in 1st person view during intense combat.
Using the demo a source or argument or examples from other games like BF or PS2, which treat vehicles as add-ons is not an accurate guide.
I told the team to switch to the exterior views to show the ships off during the combat because I'm very proud of the visual fidelity of the game / dogfight - especially at this early stage - it looks more like pre-rendered cut scene than real-time action.
As for me I hopped out in 3P because the waypoint locator was missing from my HUD (a bug on that particular client). I did this a second time when it looked like I was getting hit and as the HUD ship status display, the 3D radar or the various effects like physical impulses from the direction of the hit, internal cockpit damage (which is supported by the system but the damage hadn't been modeled yet) wasn't functional for the demo I popped out to see if someone was behind me. And even then - if you notice closely - I had to spin the camera around to look, which takes valuable time, time that could be the difference between life and death in tight dogfight. This was done using the "orbit" view which is not the official chase camera but a debugging camera we use - the current default chase camera doesn't allow you to orbit the ship - just slightly adjust your "chase" offset from behind (so the only advantage you could possibly gain here is a wider FOV, which is nerfed by the lack of all target info & control, plus the delay in switching back to 1P). We'll probably have some form of "orbit" camera in the final game as its great to check out your ship in flight, but it will be set up so there will be some inertia / delay to the movement - which not only makes it feel more "filmic" but also negates the advantage of view popping (as immediate response is critical for combat)
We played the dogfight every night the past week and during this time neither the team nor I used 3P in the manner you guys are all worried about. That would be the quickest way to die as by the time you've oriented yourself, even using the orbit camera someone would have gotten a bead on you and killed you! From inside the cockpit I know the targets, which way to turn if they are off view and when they are in view where to shoot to hit them. There was NO benefit going into 3P. It was actually a challenge / badge of honor if you managed to kill someone in 3P in our internal sessions - and this was with very limited HUD and targeting info.
I'm aware of people's concerns - but don't worry - 3P will be for admiring your ship and space around it but it will not gain you a tactical advantage in combat.
As much as I hate Wiki.
Yeah but in all the G-Force literature I've seen -/+Gx is also referred to as lateral (across the body). Even in the quote you pulled from Wikipedia (that bastion of accuracy :-) ) its really talking about eyeballs in / out (when you are face down left / right acceleration would still be -/+Gy as you've just rotated around the Y axis). +Gx is probably the most tolerant based on the rocket sled data so that would make sense to experiment with head down.
However thank you for some more links to recent research / data on G-Forces. I don't have any particular axe to grind - I've just been going on the research I was able to dig up on the (and as you can see for -/+ Gy its pretty sparse). I'm happy to go with whatever the current scientific thinking is on the matter.
My goal would be to take something from the real world like human tolerance to G-Force and use that in an interesting way to give some rhyme and reason to why SC dogfights happen at relatively low relative velocities (which we need for fun and also physics engine reasons). It also gives reasons why one maneuver (say a roll and pull up) maybe tolerable than another (yaw or stick forward). So a little science to make the fantasy seem grounded, which is what I feel works best in the sci-fi I like.