Three hours, Three videos, Three discussions

nemoma

(Yes I’m referencing another certain game there, I know that the video involved runs for about six hours in total.)

Why are we here

So, recently, in the spare time of programming, I heard our professor recommended some videos for us to watch, and all of them are programming or game industry related, so I went to take a look.

And what a look that is, it’s six hours of content that worth about 20 blogs. However, there are some of them that left a very special impression since it’s actually related to what we’re currently doing, and the discussions in-class recently.

I also has some discussions with one of my artist friends, she can draw very good stuff, but knows nothing about programming and think it’s magic (really). So she is one of the best targets to conduct “rubber duck debugging” on that’s not a rubber duck (lawl), some of the comments below may came from her and surprisingly something in those videos are really more common sense than anything.

The videos are of follows:

The three videos runs for about six hours. I spend about 3 days to watch them all. This blog are finished in one sitting, though.

The 1st hour: John Carmack on Game Industry and Engines

First video is John Carmack’s presentation on Quakecon 2013, One of the first thing that amaze me is that he literally talked for about 3 hours nonstop while constantly changing the topic, However, in my opinion most of the interest stuff are past the 1 hour mark,

Namely, Carmack talked about the modern game industry, about how the game developers should do to fit with this industry. Which makes me think of the presentation our professor made back in MIGS about the value of self-made engines and pre-existing, third-party engines and/or game makers.

Both parties agree that developing an engine is a heavy investment, which extra time on making the engine itself work. It is true that developing on third-party engines will save both time and cost since there are existing reference manuals and other developers’ experiences built on them. However, again both parties points out the fact that a new engine is a method towards something bigger.

In Carmack’s presentation, he reminds us that most programmers who works Multi-Paradigm tend to do the bad things, because they are used to work with something that’s not theirs. They may have experiences working on Unity and/or Unreal, but when it comes to making decisions, they are sometimes forced to make the worse and the most brutal way because their ability are limited to the engine. In his words, “They don’t have an escape plan.”

Note Carmack’s presentation didn’t actually points out “make an engine of their own!” to be the solution of the problem, instead, his standpoint on this matter seems to be letting the programmers do more and see more stuff, which according to our professor, can be done by making an engine of their own.

“But how about money and time?” My artist friend raised an objection.

The point here, in my opinion, is how far we as game developers plan to take game developing.

For example, as of now, our game (the one we are doing, not related to school projects) builds on a game engine, and we have nearly zero to work with, we have little time and money to justify the action of spending years to make an engine of our own. In this case, I think it’s okay to use other engines and make “implementation” top priority.

However, to really do something different, after gathering some money and free time (due to having more resources to work with), then working on an engine is a fast way to gain experience on actually working with questions, instead of writing code. Which leads us into the next video’s standpoint (don’t worry we’ll be back)

The 2nd hour: Mike Acton on how exactly do we program for

Mike Acton’s video presentation is about “Data-Oriented Design”. Which emphasis on the thesis that the basis of any programming is to turn some certain data into some other kind of data, thus, data-oriented design. Mike bashed on the common sense model of “Real-World modelling” at the beginning of the presentation, stating that while this is common sense and sometimes correct, in the data-oriented design, the format of the data won’t always match that of their real life counterparts. Also, as a programmer, our job isn’t to simply program, but rather, solving questions. Programming itself is only a tool to help us with solving a certain question.

The reason why Data-Oriented Design is mentioned is because in game developing, the project are most of the time with a Deadline, and with limited resource to work with, additionally, sometimes that the developer’s situation don’t quite match the situation of the target. (Since Mike is working on consoles, namely PS4)

In other words, Data-Oriented Design makes us more efficient with programming and design.

“But I don’t see that doing things without template or not referring to real world models are efficient.”

Which is also true. From my understanding, the efficiency Mike mentioned, together with the examples and codes he demonstrated in the later part of the presentation, are more like a way to speed up the CPU efficiency by grouping calls and setting up variables so the program only need to be working with data and how to convert those data to other formats to be outputted.

This line of thinking may be a case of sacrificing the programmer’s efficiency but makes sure that the program itself runs faster on most test cases.

In my opinion, both efficiency are important, it’s similar to the last case about engines, the question is how the programmer needs.

Mike’s project are under limited resource and time, and he has only so much to be working on (since every PS4 have the same hardware options). In other words, he has a definitive problem to solve, and this particular problem need a certain solution that requires a way, or the only way to max out the efficiency of the CPU.

However, sacrificing the programmer’s efficiency sometimes don’t quite justify the CPU improvement if you know your target market won’t have these problems to begin with.

That aside, the thesis of Data-Oriented programming is very solid, especially the part about solving problem VS simply writing code. Code is used to solve problems, you don’t code for code.

The 3rd hour: Nicolas Fleury shows why C++ is still efficient in AAA Games

The 3rd video is from Nicolas Fleury, who is working in Ubisoft, listing the reason why and how C++ is still used in their AAA Games.

Nicolas argues that C++ is still efficient because he can, and did modify some of the core functions to make the program runs faster. In other words, this is a balance point between human-readable code versus machine-understandable code.

In his example, he modified an entire Singletons to control the lifecycle of the program. With a controllable lifecycle, the program showed a notable increase of efficiency in tight loops.

In fact, in our everyday programming in school projects, we are always trying to invoke more functions in the engine that extends on existing code. For example, in our 2LoC Engine, there isn’t any code to read the animation files exported by Maya. So the sensible solution of this problem is probably to extend the keyframe related classes to somehow read those keyframes in outputted files, or write something entirely else to implement these unique keyframe animation yourself.

Related to Mike’s presentation, we don’t need to write something brand new just to let the engine support what we need, or conversing what we need into something the engine could understand. In this case, the animations maya outputted are data, the stuff people see on the screen when they run the game, is just another form of data. Thus, instead of focusing how to make the engine read a new kind of data, we should focus on how to let the engine read the original data, and let the engine do the job of conversing them to the new format of data, in this case, the animation that will show up on the screen that people see.

“But the end result is the same, right? At least I saw the same stuff…”

Yeah, what the user saw could be the same, however, Mike points out that sometimes your resources are limited, and lack of CPU time will ultimately cause a difference in performance, and these small problems stack up quickly.

Conclusion

in other words, The balance between what we read (human-workable, Programmer efficient), and what the programming(CPU time, code efficient) really does are a key element in this two video presentations.

These are all experiences that we can only gain when we are actually working with our own engine, instead of only implementing our stuff on some other engine. Which makes Carmark and our professor’s claims valid as well.

 

Until next time.

Post a Comment