|
Post by Sails on Nov 11, 2014 19:50:45 GMT -5
Hey guys, Drift--erm, vVv.Dissent here. Looking through some files, thought I'd share some various interesting things you may or may not have seen. To start, in progress sorting (alongside a tab at the bottom unmolested) of weapons data: docs.google.com/spreadsheets/d/1CgpSjr2C8X3MubRY8ChixiVg8aAV-qwwu_o66u8hSkw/edit?usp=sharingYeah, it's not the data you want. Why? The "attributestable.csv" is the weapons data from MW1. There's a bit of Ghosts data in these files as well. I haven't tracked down where the real weapons data is, but this at least has all of the variant stats for you to check out. On to the stuff I've noticed; REFERENCE GUN LANG_ENGLISH "Gun Game" Oh hello there.
|
|
|
Post by Sails on Nov 11, 2014 20:18:15 GMT -5
There is a TON of stuff in these files, a lot to look through. I've seen plenty of unused strings and leftover content from other titles in the series. I encourage anyone to take a peek and add in their interesting notes, I've been trying to hunt down the actual gun stats at the moment.
|
|
|
Post by ChloeB42 (Alexcalibur42) on Nov 11, 2014 20:50:21 GMT -5
"Note to Sledgehammer: Renaming an engine != a new engine. Might as well call it IW7 instead of S1. " Stopped reading there...well I may have read the developers gamertags/usernames
|
|
kalar
True Bro
Attack! Attack! Attack!
Posts: 451
|
Post by kalar on Nov 14, 2014 8:16:38 GMT -5
You guys bought a new call of duty game expecting something different? I'm not saying I'm better than you, but I stopped buying since MW3, and haven't looked back. CoD has been made on the same engine since 1, and it's evolved from being a cutting edge shooter to being the same shooter, but 12 years old.
|
|
banana
True Banana
Zoro > Law
Posts: 1,577
|
Post by banana on Nov 14, 2014 11:22:46 GMT -5
Have you played advanced warfare nigga
|
|
|
Post by kylet357 on Nov 14, 2014 15:47:12 GMT -5
You guys bought a new call of duty game expecting something different? I'm not saying I'm better than you, but I stopped buying since MW3, and haven't looked back. You're really cool
|
|
|
Post by Megaqwerty on Nov 14, 2014 18:55:47 GMT -5
Getting a new engine is easy: they can just license one, like Unreal.
The problem with Call of Duty is that we had two and now three developers that are effectively working on separate games. Treyarch has been adding new features to the Quake engine since W@W and none of these end up in IW games without IW rewriting the features completely from scratch.
If I were Activision, I would create an engine group with members from IW, Treyarch, and Sledgehammer that work in collaboration with the other teams to ensure that all teams use the same engine and the same code base and don't waste time reinventing the wheel. The engine team's duty would be to create an improved engine each year, which then becomes locked and is used by the team starting a new game that year.
This would prevent the problem we have where IW or Treyarch or Sledgehammer make cool stuff, but said cool stuff remains exclusive to their game.
From a business perspective, the resources wasted by the current scheme is ridiculous and I'm surprised it was tolerated this long given Activision's financial acumen; this can probably be attributed to the previous runaway success of Call of Duty that allowed extravagant budgets.
|
|
|
Post by mrbone2u on Nov 14, 2014 22:04:41 GMT -5
The problem with cod is its bounced around between too many studios and each one thinks they can make a better game. Sadly their ideas as of late in terms of a "better cod" is just to add more useless junk. MW2 for all its broken noob tubes, MLC and crazy kill streaks still had the best cod feel because it was simple. I still think stopping power needs to be put back into cod along with cold blooded in the same way it was in mw2. Instead of guns already having stopping power right from the start. Anyway thats just my 2 cents. Cod is overly bloated now and is taking a weird turn into halo style gameplay which im not really a fan of. Kudos to sledgehammer for at least making an attempt to be different but i feel this will not go down in cod history as a great version of the series.
|
|
|
Post by ChloeB42 (Alexcalibur42) on Nov 15, 2014 2:40:27 GMT -5
^ this is why each dev basically calls each engine different things, because they're all doing their own thing all at the same time. 3arc is already 1.5-2 years into development and IW is already .5-1 years in development. AW is constantly being worked on, DLC, patches, play testing, server maintenance etc... It also makes perfect sense why they also don't license an engine, 1. It costs money 2. It costs money to learn it 3. It costs money to make it work. 4. It costs money to fix it. I mean games have time tables and investors to answer to and CoD clearly has a lot of money flowing from a bevy of sources. It doesn't excuse it, but it's silly to ever expect a new engine in CoD. They've NEVER been about new engines.
|
|
|
Post by Megaqwerty on Nov 16, 2014 0:13:38 GMT -5
There's nothing wrong with the current engine. Yes, it's originally from Quake 3, but it's heavily modified at this point and perfectly serviceable, even on next gen consoles. The problem is that they are both working on games simultaneously. Hence why I said that the engine should be locked at certain points for the benefit of that year's developer.
|
|
|
Post by ChloeB42 (Alexcalibur42) on Nov 16, 2014 0:40:06 GMT -5
What does that even mean, to have the "engine locked at certain points"?
|
|
|
Post by Megaqwerty on Nov 16, 2014 4:07:13 GMT -5
When working with living code, a stable version is "locked" meaning that it is no longer modified and is ready for use. This allows the code to continue being updated and improved, but in a different version separate from the locked version.
This is necessary because continually updating the same code will introduce instability and require quality testing; by locking the code at certain points, the team that receives the code can be confident that they are receiving a stable release.
This is standard practice in fields where there will be software used in the field versus the same software being used in development that is more advanced, but less polished.
|
|
|
Post by ChloeB42 (Alexcalibur42) on Nov 16, 2014 11:49:08 GMT -5
When working with living code, a stable version is "locked" meaning that it is no longer modified and is ready for use. This allows the code to continue being updated and improved, but in a different version separate from the locked version. This is necessary because continually updating the same code will introduce instability and require quality testing; by locking the code at certain points, the team that receives the code can be confident that they are receiving a stable release. This is standard practice in fields where there will be software used in the field versus the same software being used in development that is more advanced, but less polished. Okay, now I understand, but I don't see how this is practical. That would require each dev to wait until the other dev releases their game to work on the engine, which would cause massive delays. So SHG just released their game. There's NO WAY 3arc could have waited for SHG to release in order to work on their game. Now say IW could wait for it, now 3arc would have to wait to use IW's version, and there's no way for SHG to wait for when IW releases their game. The release date might be in November, but they have E3 and Gamescom and all this other shit they have to get ready for before hand. 3arc right now has 6 Months to get a working version of the game for single player for the trailer drop and E3 reveal. Then they need to have working versions of the Multiplayer for gamescom and doing tests and publicity shit. The foundation needs to be done long before that.
|
|
|
Post by Megaqwerty on Nov 16, 2014 13:26:03 GMT -5
You said that it solves the issue of one team coming up with an idea and then the other having to implement it from scratch. If Iw is working with Locked engine #4, and then 3arc gets #5, what ensures that everything that IW put into #4 is going to work for #5? Because in this case, the developers themselves cease all engine work. They wouldn't need to improve or upgrade the engine because another team is already doing that. Okay, now I understand, but I don't see how this is practical. That would require each dev to wait until the other dev releases their game to work on the engine, which would cause massive delays. So SHG just released their game. There's NO WAY 3arc could have waited for SHG to release in order to work on their game. Negative. Let's say, version 7 is locked in March or something. IW takes IW7 and builds their game around it. Meanwhile, engine team keeps improving the engine and makes version 7.1, 7.2, etc. March rolls around again and a stable version of the engine is made, called version 8 or IW8. Treyarch takes this and builds their game around it. Engine team is still hard at work and then gives IW9 to Sledgehammer next year in March. (Ideally, the specific improvements implemented in the engine would be based on feedback from the team that will use that specific engine the following year (ex. custom flame effects for Black Ops games), but even basic improvements (ex. superior lighting effects) are still useful to everyone.) Because the engine is built and maintained by a dedicated team, the main developers themselves do not have to devote time and resources to engine improvements and any improvements that they would have made are not lost to the other two developers. Although the dev teams improve the engine repeatedly over their two year and now three year cycle, they also waste significant time repeating work done by other devs. This approach would prevent wasted work and thus allow the engine to evolve faster and more efficiently.
|
|
|
Post by ChloeB42 (Alexcalibur42) on Nov 16, 2014 14:08:05 GMT -5
Okay... I'm still not following. Say this team makes IW7 and it's done in 2015. 3 arc cannot use it. IW will most likely not be able to use it. Only SHG would be able to use it because 3arc is already done and IW is almost done. Now let's say SHG starts this new cycle with 7.1 with their game in 2017. It's already a 2 year old version, if they made a IW8 in the mean time you still run into the same problem we have now. You'd actually be wasting more resources.
Not only that but they have design the game before they start coding anything. They don't work on the engine until they know what about the engine they need to fix or update. On top of that they'd have to essentially relearn the engine every time instead of working on it themselves.
|
|
|
Post by Megaqwerty on Nov 16, 2014 22:21:16 GMT -5
I'm talking over you guys which is primarily because I've been writing these after playing a few hours of AW.
Each game consists of two primary parts: the engine and the content. The content is where most the effort is consumed since the engine is largely conserved between releases. Each CoD game is still effectively a total conversion mod for Quake 3.
(The conserved part of the engine is what allows IW/3arc to develop a AAA game in just two years, which is highly accelerated versus other game timelines.)
The engine invariably is modified between releases, but these modifications generally are minor. The problem here is that these minor changes build up over time: Treyarch diverged from IW4 six years ago and nothing they added to the engine appears in IW's code.
So what I proposed that a separate team exclusively does engine work. Simple enough.
The problem here is that if they continually work on the engine, it would never be stable in of itself for consumer use. My solution would be to have the engine locked at certain points.
Note: feature lock already occurs with each team. If I had to guess, the engine is locked a year or so before release. This is to ensure that bugs are caught, quality assurance, and to prevent infinite labor on the engine.
Regarding Mousey: the engine itself is not a significant portion of the game and thus this wouldn't limit the teams in that regard. A solution to this is to have the lock occur later in the development cycle. For example, having the lock occur two years (on a three year cycle) into a game would allow the engine to still mature and evolve during development.
alex: the large, working parts of the engine are highly conserved and there's no need to learn anything. Anyone who has worked with Quake is familiar with this engine. The current setup actually forces developers to learn engine modules if they look at the other developer's work. For example, Treyarch improved the lighting in the engine, but so did Infinity Ward separately. Each implementation is different so if a lighting developer were transferred to the other developer, he would have to relearn the unique implementation by that developer.
But this discussion is all pointless since this is even more removed than Activision picking up weapon balance tips from this forum. Still, I think this is an interesting topic. Call of Duty is still a juggernaut, but optimizing it and its development is more important now than ever.
|
|
Will
True Bro
K/D below 1.0
Posts: 1,309
|
Post by Will on Nov 16, 2014 23:01:04 GMT -5
Call of Duty is still a juggernaut No, COD is almost dead because of SBMM. ...
|
|
wwaa
True Bro
PC / PS4 / X1
Posts: 2,086
|
Post by wwaa on Nov 17, 2014 13:47:42 GMT -5
The engine invariably is modified between releases, but these modifications generally are minor. The problem here is that these minor changes build up over time: Treyarch diverged from IW4 six years ago and nothing they added to the engine appears in IW's code. So what I proposed that a separate team exclusively does engine work. Simple enough. The problem here is that if they continually work on the engine, it would never be stable in of itself for consumer use. My solution would be to have the engine locked at certain points. As there is a feedback loop between 1) creating ideas, 2) choosing the most optimal solution (how to use resources in the most effective way to convert decisions/ideas into a final result) and 3) technical execution each game must have its own engine (if any innovations!), being adapted from the first day till the last one, ideas being modified continously and optimization methods adapted adquately, which in turn affects technical execution. No project (and no game) can be done step-by-step: first ideas, then optimization, then realization, as problems detected on any of 3 stages affect the other two. In fact there is an exception: only very simple projects (works) can be done step-by-step, if problems can be detected in advance and solved before they even appear. ------------------------------ Long story: a) What is engine? By ‘engine’ I mean a set of algorithms, operating on triangles and displaying them on the screen using set of initial data. There is no need to rewrite basic operations on triangles, which were tested heavily for decades and work fine. If hardware is fast enough, some new effects might be ADDED, better reflection, refraction, dispersion or light scattering, etc etc., tons of effects. Looking for errors is easier if you know which part of software should not contain errors. b) One fatty or Three thin: I suppose that one general engine for all 3 studios would not be optimal/effective, each studio would have to disable some functions / algorithms (quality of ray tracing for example) to adapt engine and effects to ideas. It is easier to start from one small engine (Q3) and add needed effects, using resourcess as effectively as possible, than create an engine-monster with a lot of useless operations in every game. Do we need dogs-hair implemented in all cod games? What quality of water is needed? c) Real time In video-games we talk about real time graphics, which has diferent speed requirements than films (like Avatar, which is an offline presentation of months of work.) Real-time: If you improve „effect A” you must probably diminish „effect B” or ask clients to buy new GPUs, as dogs hair looks gummy. d) Main problem = hardware I suppose that developers have a lot of new algorithms designed to add to new games, but hardware is not strong enough. Algorithms work perfect in offline mode, but current GPUs are too slow to process them in real time. e) PS4/XBox Difference in quality between platforms will be visible in the next years. Argument: I see no difference - I buy slower GPU, is absurd. At least on PC a 20% better GPU is 20% better and it is visible with a naked eye : ) That is how I see it : )
|
|
mannon
True Bro
wordy bastard PSN:mannonc Steam:mannonc XB:BADmannon
Posts: 15,371
|
Post by mannon on Nov 17, 2014 14:33:26 GMT -5
I think the issue is that it's easier to manage each version of the engine by linking it to a specific product and that product's requirements than to share a single build. Due to the overlapping development schedules it's not really efficient to have a core engine. In fact it makes a lot of sense for each studio to develop their own branch since each studio is only working on one iteration of the core game at a time that means they are free to make and maintain changes without affecting any other products.
That's not to say there isn't any value in having an "engine team". But I think their mission would be different. I think this team would have two primary uses. The first would be to help port useful code from one branch to the other branches anytime a particular feature was implemented by one studio and deemed useful for all branches. (For example, dog hair probably would not be ported to the other branches, but this team could have assisted with porting pick 10 or new graphical enhancements, ect.) This team could also help develop enhancements and improvements to core systems that aren't otherwise being touched.
On the other hand, do you need an entire team for this? I think it's likely that the studios already share quite a bit and even if they don't use the same code they do share ideas. Having a diverse codebase is not necessarily a bad thing.
|
|