[adamrezich]

I think it's great that sophomores still have to make their own engine from scratch.

making two engines, one in C for GAM150, and another in C++ for GAM200, were extremely formative experiences for me. when I was attending DigiPen, it was at the beginning of the ECS craze, so, naturally, I implemented terrible, extremely naive ECSes, in C and C++. they were woefully inefficient and byzantine to the point of ridiculousness (look up Game School Simulator 2015 on the DigiPen student games site—its framerate is terrible, despite rendering just consisting of a few dozen sprites), but I learned so much from making them—both good and bad. I especially enjoyed GAM200 when we got to have artists who had any spare time to work on a GAM project, because working with them to integrate them into the workflow was an amazing experience.

I understand that DigiPen wants to provide students with as much career opportunity as possible, and that means Unity and Unreal. or rather, it did mean Unity and Unreal, until very recently—now, it's kinda just Unreal. and Unreal isn't going away anytime soon, of course—but that's what we would've said about Unity just a short while ago.

even though it's certainly the pragmatic choice as far as getting a job after graduating goes, personally I firmly believe it's a mistake to forgo having students make their own engines after sophomore year. at least when I was there, there was borderline zero education about how to even go about making a game engine, despite requiring teams to make one, so there was that—but there was also a vibrantly competitive culture of one-upmanship among students, and it was fun to see what other teams were working on, and strive to do better and cooler stuff yourself. (Josh Fisher, if you're somehow reading this for some reason, your shit was always way better than mine and I was always super jealous.)

if students stop learning about how video games work at any lower level than "just use an off-the-shelf general-purpose game engine", then who's going to make game engines going forward? some of the smartest classmates I had were guys who put their heart and soul into their engine projects, and they all went on to find success one way or another as far as I know.

perhaps more importantly—and I only say this now with a decade of hindsight and experience since then—you don't need to make a general-purpose game engine in order to make a video game. our GAM 150 game did not need an ECS written in C to function. when I look at the code now, it's completely unreadable—everything is strewn about in random files, tenuously connected, such that it's a real archeological task to even figure out how the (extremely simple) core logic of my GAM 150 game even works. like I said, I really appreciate having had the experience of making terrible garbage tech, such that I could go on to learn how to do better. but it would've been even better if we had better instruction from professors, explaining that you don't need any of these fancy features to make a fully-functioning video game, especially on the scale of what's expected of a GAM 150/200 team.

I worry that going forward, the new generations of video game programmers are going to be too entrenched in thinking about things in terms of how e.g. Unreal does them, rather than what the solution to a given problem necessarily entails at the minimum level. sure, these people will be able to go onto find work in the industry at Unreal shops, but then what happens in the (admittedly extremely unlikely) event that something happens to Unreal as it did to Unity?

I don't know what DigiPen has been like in the past decade, but after I dropped out and talked to students from other game schools, it sounded like they had always, even back then, been pretty much Unity-centric—what happens to their former students now that Unity's in the situation it's in? do they feel cheated, like the only way that they know how to make games, the way they were taught, has now been somewhat invalidated? if they jump ship to another engine like Unreal or Godot, will they adapt, or will they still be trying to fit an Unreal peg into a Unity-shaped hole?

when Zero Engine was heavily in development while I was at DigiPen, it was hugely inspiring, because Zero was a great product, and the Zero team were available to chat if you needed advice about engine development. it's kind of a bummer to hear that nobody's taking their GAM 200/250 engine into GAM 300/350...

[johnnyanmac]

>if students stop learning about how video games work at any lower level than "just use an off-the-shelf general-purpose game engine", then who's going to make game engines going forward?

could this be a specialization or "minor", perhaps?

IDK, it's tough. I want more students to be learning this stuff while in a proper environment, but the reality is that so much of the real tricks and sauce are either a) buried deep, deep inside some "public" repos, or more likely b) tribal knowledge at a AAA studio. Maybe Digipen is different as a gaming focused school, but I never learned about ECS or object pooling or profiler usage or especially cache coherency in college. And I'd struggle grouping all these important engine concepts into a course since the knowledge is simultaneously disparate but related. each topic could be its own thesis if you wanted them to be.

>what happens to their former students now that Unity's in the situation it's in? do they feel cheated, like the only way that they know how to make games, the way they were taught, has now been somewhat invalidated?

custom engine or not, I do adamantly feel like a proper game dev program should teach enough CS chops for this to not be a problem. using a high level engine is useful, but the rest falls on fundamentals. Data structures and algotithms to know what to use to group data together and the tradeoffs, systems level programming to understand memory management (yes, even in Unity. Intuiting the cost of allocating and deleting game objects only helps. Any one of mulitple of various domains (network, graphics, databases, UI) to get different perspectives on how data can be structured and processed, etc.

[adamrezich]

> Maybe Digipen is different as a gaming focused school, but I never learned about ECS or object pooling or profiler usage or especially cache coherency in college.

I could write maybe a short pamphlet's worth of information that I wish I was taught by professors while I was at DigiPen that would've made all the difference in the world to me at least. the existence of cache coherency is definitely one of these topics, but ECS definitely is not. it would just be a few other general ideas, like:

“hey, y'know how you just learned about malloc() and free() in CS 120 when you learned C? well, it's not a good idea to be calling those all the time in your game. instead, have something like this:

    #define MEMORY_NEEDED 1024 * 1024 * 4 /* adjust as needed */
    unsigned char all_the_memory_you_need[MEMORY_NEEDED];
    size_t end_of_game_memory  = 0;
    size_t end_of_level_memory = 0;
    size_t end_of_frame_memory = 0;

    void *alloc_for_game(size_t bytes) {
        assert(end_of_game_memory + bytes <= MEMORY_NEEDED);
        void *ptr = all_the_memory_you_need[end_of_game_memory];
        end_of_game_memory += bytes;
        return ptr;
    }

    void *alloc_for_level(size_t bytes) {
        assert(end_of_level_memory + bytes <= MEMORY_NEEDED);
        void *ptr = all_the_memory_you_need[end_of_level_memory];
        end_of_level_memory += bytes;
        return ptr;
    }

    void *alloc_for_frame(size_t bytes) {
        assert(end_of_frame_memory + bytes <= MEMORY_NEEDED);
        void *ptr = all_the_memory_you_need[end_of_frame_memory];
        end_of_frame_memory += bytes;
        return ptr;
    }

    void reset_frame() { end_of_frame_memory = end_of_level_memory; }
    void reset_level() { end_of_level_memory = end_of_game_memory; reset_frame(); }

    /* likely not quite perfect sample implementation but you get the gist */

check it out: now instead of malloc() and free()ing everything everywhere all the time and worrying about memory leaks, we have "lifetimes" now, one that's per-frame, and one that's per-level (if your game needs levels). you just use alloc_for_game() to allocate stuff that your whole game needs at the start of the program's execution, and then you reset_level() and alloc_for_level() when you change levels, and reset_frame() at the end of your frame and alloc_for_frame() during it, and bam, now you don't need to worry about memory leaks, you don't need garbage collection, and your temporary bump allocator is reset and ready for the next frame—and the only cost was resetting a single variable to zero in a couple key places. neat, huh?”

stuff like that—stuff that's super basic and easy to understand once it's explained to you, but that most people wouldn't intuitively conclude on their own, especially when you're new to game programming and just chasing cargo cults like ECS without sufficiently understanding how stuff really works. for example, the ECS I wrote in C was terrible in part because I only understood the high-level ideas at the time—the whole thing was (hysterically, when looking back now) implemented with linked lists, as I was approaching systems design in terms of API, instead of actual functionality.

once you've taken a CS course to learn the basics of C, and a math course to learn the basics of matrix math and how it pertains to game programming (both of which were excellent at DigiPen, by the way!), you're just a few pointers like these away from being able to completely—and relatively competently—implement your own 2D "game engine", given that you're using external libraries for e.g. rendering, input, and sound playback.

but then, of course, the resulting student games whose screenshots and video clips you gather to use for promotional material for your school wouldn't be as flashy, compared to contemporaries who only teach e.g. Unity...

[johnnyanmac]

>the ECS I wrote in C was terrible in part because I only understood the high-level ideas at the time—the whole thing was (hysterically, when looking back now) implemented with linked lists, as I was approaching systems design in terms of API, instead of actual functionality.

well that sounds awful. I wasn't making too deep a thought on which topics I'd throw onto a curriculum, but I'd hope that they wouldn't treat ECS like some pattern to memorize like some design patterns in my SWE course (literally called "software engineering". Quite confusing in retrospect). It should be treated as a way to apply and understand some data oriented design so you can make informed decisions on how to implement things.

I'm especially a fan of always identifying any and all shortcomings of an approach too. Because there's no better way to understand an approach than to reason about with its weaknesses. ECS is nice but you shouldn't try to shove it in stuff that requires tight complex coupling (e.g. a playercontroller), nor for random, infrequent events (UI input). And of course, if you are making a small game that can almost entirely fit in RAM anyways (well, in theory. Desktop OS's wouldn't allow this, obviosuly) these patterns are overkill and a half

>of course, the resulting student games whose screenshots and video clips you gather to use for promotional material for your school wouldn't be as flashy

well that is reflective of the modern game industry, haha. I imagine even in a place like digipen where you are working with motivated game artists that there's still technical constraints to consider with the art team (especially students). And building tools to help with that would take as long as the small game.

I did ponder if it'd be a good idea to have a CS game dev course each some basic 2d/3d art, and vice versa for an artist learning some CS101 style stuff. But the CS curriculum was already jam packed as is, at least at my alma mater. I believe the average course work required 170 units and CS (like other engineering degrees) was topping out at 190.