5 ms·
Wow you guys wrote Zero Engine? I used it in summer camps at DigiPen a long time ago, I really enjoyed using it and programming in Zilch (I wrote an AI that pla
by sakras 3y ago
Wow you guys wrote Zero Engine? I used it in summer camps at DigiPen a long time ago, I really enjoyed using it and programming in Zilch (I wrote an AI that played a galaga clone!). This Unity fiasco had me wondering how Zero was doing. Seems like it's going to have a resurgence! Super exciting!
- TrevorSundberg 3y agoThat's so cool! Zilch was my baby, that makes me so happy :D
- adamrezich 3y agoZero/Zilch was great, and I wish DigiPen would've stuck with it! I heard that these days, they don't even have students make games from scratch anymore, and everyone just uses Unity or Unreal instead—any idea if that's true? it would be a bummer if it were, because striving to make a cool engine (especially once Zero was there as something to aspire to!) was like the best and most useful part of my time at DigiPen. glad to see the spirit of Zero still going strong through Raverie, though!
- TrevorSundberg 3y agoI heard the same thing and I really hope what they're doing is for the best. It would have fundamentally changed my path if I didn't get that core low level experience of building game engines.
- DougZwick 3y agoI teach GAM 300/350 at DigiPen. We still require them to create custom engines in their sophomore year, but in their junior year (and beyond, in some cases), they're all using commercial engines. One of the main things we want to focus on is giving them a chance to work on a truly cross-discipline team, where every member has a chance to thrive at their work, regardless of their degree program. If you're a student of game design or art, it can be very stressful to be on a team with a custom engine, because the bar is so high for them to provide the features you need to get your work done and accomplish your goals. If the engine and its editor and other support tools are all already completed when the project begins, these stresses and barriers are removed. Meanwhile, the programming students get a chance to work in an existing engine, which is applicable for the career trajectories of so vastly many of them, who will graduate and go on to work for companies that are using an existing engine (possibly even the one they used in GAM class). If they use Unreal, they're often working in C++, interfacing directly with the engine code. These are valuable experiences as well. I have an imperfect perspective of the students' attitudes, but it seems to me that they tend to agree with my point of view: at the beginning of the year, I said, "Raise your hand if you wish you'd be working on a custom engine this year," expecting to see a few dozen hands go up. Surprisingly, only about one and a half hands were raised! Working on a custom game engine is an amazing and unique experience, but it's not the end-all-be-all of game programming.
- adamrezich 3y agoI 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...
- wahnfrieden 3y agodo you know what engine was in use or development during around 2002-2003? the engine was somewhat baked but flexible and had entry points where you drop c++ snippets in, I believe with a GUI
- sakras 3y agoWas it a 2D game engine? I recall before using Zero I used an engine called ProjectFUN, which is similar to what you described. That was around 2013 though, not 2002.
- wahnfrieden 3y ago2d yes