I've been watching Jason Weimann's videos on youtube the past couple of days on Unity3d and game development, including, right now, the recording of the livestream Q&A with Kyle Olsen about high performance game networking. I've got to say that these guys really know their stuff. I'm not in the games industry but I am software developer and it is very encouraging to hear these guys talk so knowledgably about everything to do with game programming, especially Jason's take from the perspective of having worked on Vanguard.
Anyways, I just wanted to share my renewed encouragement with Pantheon!
Shadowbound said:I'd love to take a peek at those streams, would you mind posting the links, at all?
Thanks in advance!
Sure!
zewtastic said:Not really understanding the talk about programming.
It will never make a game better, but it sure can make a game worse.
Yeah, if they didn't know the systems as well it could definitely kill the experience, like it did in Vanguard, in one video Jason mentions that at launch there was UI code written so poorly that it was having to do "1 million+ screen compares a second" that's insane and what killed it for so many people.
Good programming means the game design comes through loud and clear and you will probably never even think of the programming, but you will notice bad programming immediately.
I've been a software developer for 30 years (not games) and the kind of things Jason was saying in the stream were very encouraging.
When a coder starts talking about how great it is to get involved early in the project so they can develop the guts of the systems and avoid the problems they've seen happen else where (and had to try and fix elsewhere) you can be pretty sure you've got someone with experience who likes to do things right.
zewtastic said:Not really understanding the talk about programming.
It will never make a game better, but it sure can make a game worse.
Lol, either your being facetious or I'm totally misunderstanding your comment "it will never make a game better" without programming there would be no game at all.
Zorkon said:zewtastic said:Not really understanding the talk about programming.
It will never make a game better, but it sure can make a game worse.
Lol, either your being facetious or I'm totally misunderstanding your comment "it will never make a game better" without programming there would be no game at all.
Programming in this case, is about making something per a design request. If I code it right, it works. If I don't it works incorrectly, or not at all.
Programmers should not be modifying and designing on their own. They should be following strict design parameters.
Thus how a programmer is never making a game better. But possibly making it worse.
zewtastic said:Zorkon said:zewtastic said:Not really understanding the talk about programming.
It will never make a game better, but it sure can make a game worse.
Lol, either your being facetious or I'm totally misunderstanding your comment "it will never make a game better" without programming there would be no game at all.
Programming in this case, is about making something per a design request. If I code it right, it works. If I don't it works incorrectly, or not at all.
Programmers should not be modifying and designing on their own. They should be following strict design parameters.
Thus how a programmer is never making a game better. But possibly making it worse.
Having been a software developer for 30ish years, I will say there is a world of variables between a design and the coding, however strict and detailed the design (and you hardly ever get strict and detailed designs, even working with the like of banking systems, these days, where you would think you would).
100 coders could code to match a design and all 100 programs achieve the design goals (with varying numbers of iterations to get there), but you will have 100 programs working with different speed and fluidity and with different efficiencies and level of ongoing problems and bugs. Some of those coders will know how to fill in gaps in a design (because a design is never perfect and sometimes pretty bad) and when to push back and how to improve on a design when they know it can't be expressed well in code. Some of those coders will be sensitive to common problems and avoid them before they occur. Some coders will be aware of the kind of integration their code will have to achieve with other areas (even when not told by the design). Some of those coders will exactly meet the design even though they know associated areas will have problems interfacing, because they can't think outside the box or have no experience of other areas or even want the designers to look bad so the next design will be better.
I could make dozens more examples of how the quality of coders can make a huge and fundamental difference.
Saying coding either works or doesn't is like saying a meal is either edible or not and chefs are all the same if they just follow a recipe. As we know, the output from different chefs varies wildly and that is with something as 'simple' as a meal recipe. A program design is wildly more complex, variable and subtle and so are the differences between coders.
Saying coders should not be modifying and designing on their own is like saying a journalist should write exactly what his editor tells him to. It doesn't (and couldn't) work that way. The editor doesn't have time to write a brief (design) that detailed for each story. Journalists might not get to change their brief, but how they tell the story is hugely personal.
Whilst coders rarely modify a design, they generally have a huge amount of room to interpret and implement, which means, as with a chef or journalist, the is a huge amount of room for them and their varying quality to get things right or wrong and do things well or badly and to make the finished product awesome, awful or something in between.
zewtastic said:Zorkon said:zewtastic said:Not really understanding the talk about programming.
It will never make a game better, but it sure can make a game worse.
Lol, either your being facetious or I'm totally misunderstanding your comment "it will never make a game better" without programming there would be no game at all.
Programming in this case, is about making something per a design request. If I code it right, it works. If I don't it works incorrectly, or not at all.
Programmers should not be modifying and designing on their own. They should be following strict design parameters.
Thus how a programmer is never making a game better. But possibly making it worse.
You seem to have a very limited understanding of both programming and also the benefit of listening to someone with more expertise than you.
A good programmer, like anyone who is good at their job is able to stick to a design brief, but also communicate with the designer to help them understand system limitations and opportunities; which in-turn helps the designer to design something even better that they ever could have conceptualised alone before.
People working together and sharing their expertise is best; a team, that works as a team.
Not one person who thinks they know best and orders others to do what they want with no discussion or input from the people they work with.
Been coding for decades also worked in the game industry for a great many years.
Been in tech for MORE than 30 years @disposalist. My first pc had punchcards
It still comes down to delivering on the design parameters.
Programmers are NOT designing and NOT making little changes and nuances they think are needed.
Of course a programmer would inform a designer what is possible with the current framework, and also explain what has to change to make the design happen if it wasn't. That's a given.
A designer trusts the programmer knows how to code smartly to allow for future charges and upgrades..
This gets exponentially harder when you have a live game and are pushing out new content while keeping things running for your millions of players.
Any programmer that want's to last more then 5 minutes in the industry learns to be very careful how they get things done.
@zewtastic Well, let's not argue. There are many ways to skin a cat, but it's an interesting perspective to think that coding is simply implementing design and either done right or wrong with little added value from the developer.
Especially when talking about senior developers like Jason and in small teams like VR, I would have thought the coders will be involved in some/most technical design meetings and, if they aren't, they soon will be once the coding starts and it turns out, as it almost always does, that the proposed design has serious implications at the implementation level and that the coder is the only one who appreciates how all the different mechanics and systems need to cooperate and coordinate and, so, needs to push up design ideas - at least tweaks - from the bottom.
I do remember the days when designers designed and used a recognised design methodology that produced rigid specifications that coders would have a hard time messing up as long as they didn't deviate from them. That was for 1990s mainframe core banking systems with very precise and limited function, input and output and was done that way because that kind of critical business system cannot tolerate errors or even performance problems. Maybe that still happens for those kind of core systems in some companies, but not in anything client, server or middleware that I have worked on in the last 25 years.
I cannot imagine modern gaming companies being as rigid and prescriptive as 1990s retail banks, but I've never worked for a gaming company (as a coder, anyway), so maybe. Also sophistication of computer systems and the development that achieves them is exponentially more complex than the systems designed back then.
Maybe we are arguing semantics slightly. As I said before, even if a developer doesn't actually get involved with the design, to suggest implementation of a design is somehow something just done 'right' or 'wrong' and only needs competency from developers is just weird to me. Developers vary as wildly as any other person and so do the way they do their jobs. There are just so many ways to do the same thing in coding these days that it is more and more an art form performed with a linguistic flair than an engineering task to be solved.
I have worked in all area's of IT and tech for decades. Mostly corporate, some big, some startup.
Moving to work in the game industry was a huge culture change. It does not function like most businesses, companies, governments and corporate monolithes do.
You cannot apply what you know from non-game industry jobs.
It is usually very bleeding edge, dynamic, lot's of open-source. Flying by the seat of your pants. Making things up to fit your needs.
It's the entertainment business and you're only as good as your last game success.
What I experienced with studios I worked in is probably different that what VR is doing. But I did work with SoE people, DBG people, people that made UO, built Mekalia, Vanguard and so on. The game industry can be a bit of a closed loop.
Most outsiders have zero idea how things work inside a game studio. They think everyone is a 'dev' and that they have acute insight about how things work and are integral to all decisions. Only a few at the top of the food chain in a studio know what is really going on. How the sausage gets made. It's very complex.
It's very challenging for me to read all these fanboi forum posts based on pure fantasy and imagination.
Anyway that's all I got right now.
I've always been confident that VR has the talent to both conceive of and design a great game. Yes, I've been critical of many of their choices over the years, but my faith in their capabilities still remains. My confidence is near zero when it comes to the speed at which they can actually turn all these concepts, all these designs, into a released product. We are 6 years into this with no end is sight. No PA5 yet even after 14 months from the end of PA4 and the distinct possibility of needing a PA6...all before Alpha.
Vandraad said:I've always been confident that VR has the talent to both conceive of and design a great game. Yes, I've been critical of many of their choices over the years, but my faith in their capabilities still remains. My confidence is near zero when it comes to the speed at which they can actually turn all these concepts, all these designs, into a released product. We are 6 years into this with no end is sight. No PA5 yet even after 14 months from the end of PA4 and the distinct possibility of needing a PA6...all before Alpha.
I'd like to echo this sentiment. The talent is immense, but the speed is less than snail's pace.
zewtastic said:I have worked in all area's of IT and tech for decades. Mostly corporate, some big, some startup.
Moving to work in the game industry was a huge culture change. It does not function like most businesses, companies, governments and corporate monolithes do.
You cannot apply what you know from non-game industry jobs.
It is usually very bleeding edge, dynamic, lot's of open-source. Flying by the seat of your pants. Making things up to fit your needs.
It's the entertainment business and you're only as good as your last game success.
What I experienced with studios I worked in is probably different that what VR is doing. But I did work with SoE people, DBG people, people that made UO, built Mekalia, Vanguard and so on. The game industry can be a bit of a closed loop.
Most outsiders have zero idea how things work inside a game studio. They think everyone is a 'dev' and that they have acute insight about how things work and are integral to all decisions. Only a few at the top of the food chain in a studio know what is really going on. How the sausage gets made. It's very complex.
It's very challenging for me to read all these fanboi forum posts based on pure fantasy and imagination.
Anyway that's all I got right now.
I can see how it sounds like "fanbois" talk, but some of us are looking at the bigger picture. The programming is important, and likely the thing that is really slowing up release. But this philosophy of slow and steady compared to the companies I worked for, that were only concerned with meeting deadlines regardless of quality, is what gives a lot of us confidence in their ability to produce a quality pruduct. I don't consider myself a fanbois, but I am a fan; and having worked for companies like SoE (like yourself) I have seen programmers have to take shortcuts or not have time to peer review code and put trash out. I've been involved in producing great games like God of War to trash games like NBA The Life (which had a deadline because of annual sports obligations) and the difference in quality is tremendous when allowed to take years to develope a game compared to being given a few months.
Design conversations aside, I would love for Pantheon to avoid some of the technical problems that plagued games like Anarchy Online and Vanguard (just to name a few) at their launch. Thus, I am very glad that they have experienced programmers working on their team. I'm sure that there will be bugs (there are always bugs), but I'm hopeful that they'll be minor things that slipped through the cracks, instead of things that completely prevent people from playing the game.
As such, I absolutely agree with the original premise of this post. Jason and Kyle are both highly skilled and experienced and the team is better for having them - both in terms of the things that impact us like server stability and client performance, but also in terms of internal tools that make it easier for content creators and artists on the team to do their job. Is their presence a guarantee that Pantheon will be perfect? Of course not. Nothing is. But are they an asset to the team? Hell yes.