3 ms·
Just because you can generate a hypothesis doesn't make something true. Its pretty difficult to compare the difference in required code for a modern 3D engine,
by greendestiny 19y ago
Just because you can generate a hypothesis doesn't make something true. Its pretty difficult to compare the difference in required code for a modern 3D engine, with lots of single player functionality like scripting and AI, and a multiplayer game with a lesser graphics engine. It should be noted that there are some simple multiplayer games that are hardly any code at all though. 500k lines all up for Gears of War certainly seems massively less than the industry average for that kind of project.
Just because you like Yegge's post and/or game doesn't mean his code needed to be that big. Judging from his post on code size it's not like he cares particularly.
- palish 19y agoJust because you can generate a hypothesis doesn't make something true. No, it doesn't. But I've seen what I described happen many times over three years. Its pretty difficult to compare the difference in required code for a modern 3D engine, with lots of single player functionality like scripting and AI, and a multiplayer game with a lesser graphics engine. It's not. There are many shared concepts. Scripting and AI, for example. Just because you like Yegge's post and/or game doesn't mean his code needed to be that big. That seems like why he wrote the post. Also, my likes and dislikes are irrelevant.
- greendestiny 19y agoI'm not doubting adding networking adds complexity. I don't think the comparison of complexity between the graphics and AI of gears of war vs the networking of Yegge's game is easily made. The interesting thing about Gears of War is that most titles of that caliber take a lot more than 500k lines. Yegge's game as a comparison point seems pretty fair to me, and I just don't buy the fact that the extra networking necessarily makes the code so much more complicated than Gears of War - thereby invalidating the comparison.
- palish 19y agoIt's not the networking. It's the fact that changes need to happen at runtime, and sync to any number of clients that may be watching. Also, your hypothesis that the prettier game the more complicated one is false. 2D physics and AI can be horrendously complicated, or elegantly simple. There's no way to tell just by looking at the game, except on a very rough level. Take the game Gish for example. I don't know how complicated that little blob's physics is, but it could be extremely tricky. Amusingly, the game rules are the least complicated component.
- greendestiny 19y agoI meant syncing the game state to be included under the term networking. Amusingly, Yegge's post about the length of his game was all about how massively bloated it was because of Java. His own estimate of what size he would like the game to be was 150k-200k. Apparently impossible in Java, but presumably what he felt he should be able to achieve that even given the game's distributed state management.
- pmjordan 19y agoI'm intrigued that nobody has mentioned UnrealScript in this context. I'm pretty sure they haven't dropped that for UE3, and language-wise that's apparently somewhat like Java. Historically, Unreal games have had most of their logic written in UnrealScript. And yeah, 500000 really isn't much in gamedev. I worked as an engine programmer for the year following graduation and worked on a almost-2-million-LOC behemoth (including tools, so the game was probably nearer 1-1.5m) which wasn't an MMO or even had that much data to look after at run time. (the Wii only has 88MB of RAM) I can echo the long compile and linking times mentioned elsewhere. Almost none of the code used templates, which would have been an obvious candidate for driving up the compile time. Linking really isn't fast anymore either once you hit a couple hundred compilation units. Of course, the code was a complete mess. Few people cared much about the quality of the code base, particularly as the game was released about 9 months late and everyone just wanted it out the door. (it was delayed mostly by management pushing for features rather than having bugs fixed for the 2/3 of development and large-scale changes imposed by the publisher late in development) Not a particularly pleasant experience, but boy did I get to practice my skills in understanding and debugging badly written, undocumented code. Typically code that nobody who still worked at the company had ever touched or seen. Or maybe that was the crazy overtime talking. ~phil