How to fix GAM Anonymous 02/22/15 (Sun) 04:08:20 783579 No. 543
Look, okay. I'm going to lay it all out. I've solved how to fix GAM classes and make them not total teach-yourself-how-to-make-a-video-game hot garbage bullshit. — GAM100: GAM100 is pretty good as it is. Yeah it sucks that if you don't know programming, it can be a pain, but whatever man, it's super easy to learn how to do basic shit with Zilch and make a game. (Side note: Zilch sucks shit and is the worst language, that's another thread for another time though.) You learn how to deal with teammates, team issues, how to scope your game, etc., in a relatively inconsequential manner. Definitely add a "how to use git" week or something, but overall, GAM100 is not a huge problem. — GAM150: DigiPen, for the love of God, revert to the old GAM150, but improve it, instead of having students use Zero to make their second game in a row. GAM150 was a great way to get me to learn how game engine concepts work and further solidify how to work as a team. Maybe give a lecture on advanced git usage, like branches and shit, I dunno. After they revert to forcing you to make a game in C, SPEND TIME AND MONEY INTO MAKING ALPHA ENGINE GOOD. Don't call it Alpha Engine, also; call it libalpha or something, it's a fucking library not a goddamn engine. Make libalpha modular. Make it so that setting up basic gameplay is super easy, just basic function calls. You got your basic game update loop, your object manager, whatever, make it really easy to get going making a game with libalpha. Alpha Engine is like 75% of the way there, just focus on honing it and making it good while documenting the fucking header files and removing those fucking #ifdefs for Android. (What the fucking shit? Who started adding Android support to Alpha Engine, before making it better?) Then, once that's done, make a rubric that has very, VERY basic gameplay requirements, with most of the requirements being about replacing the functionality of libalpha with your own code. Give a lecture (maybe this is CS230 now? I have no fucking clue) on how to implement each part. How to make a game loop. How to make a framerate controller. How to make a state machine. Etc., etc. Grade the projects not on how good of games they are, because fucking GAM150 is mostly RTIS and a few BSGDs, but instead on how you implemented the logic of what you learned into your Baby's First Game Engine. Give points for trying crazy shit, like packing your resources into a single file, or making a really nice asset pipeline. And above all else: don't make it so that we either need previous programming experience or three meal tickets from attending GAM150 Club in order to pass the fucking class. Teach game engine concepts, and make us execute on them. — GAM200/GAM250: Add a new feature to Zero that allows users to make projects with something called "Zero Core". Zero Core disables all the crazy advanced features of Zero, retaining only the most core features. This way, game designers (BAGDs and BSGDs, if they so desire) can spend the first semester prototyping and eventually building their game in Zero. Apparently, Chris Peters will give you the Zilch compiler if you ask him. That's awesome. Make this shit mandatory! Make it so the game designers are designing the game in Zero, and the programmers are basically creating their own stripped-down version of the Zero Engine (not the editor, just the underlying engine) for the first semester. This way, there's no bullshit about having to figure out how to design and make an editor on top of designing and building an engine. The designers just get to use ZeroEditor to make the game, and the programmers get to implement the engine backend. Give bonus points for engine programmers who not only implement the Zero Core features, but go above and beyond and add cool shit like shader support and dynamic sound shit and whatever the fuck else they want. Make the GAM200 lectures all about component-based design, both for programmers and designers. GAT240 has a lot of this, and the programmers never get to hear it, unless they're BSGD. — I'm only a sophomore so I have no perspective on GAM300/GAM350, but I don't see why it can't stay the same. At this point, you'd have an awesome engine that you built in your sophomore year, because DigiPen actually TAUGHT YOU HOW TO MAKE IT, and now you're customizing it further and adding whatever the hell other cool shit you want to it. You want JavaScript instead of Zilch? Sure, why not, integrate V8 or something. You want Oculus Rift support? Go ahead, and get a ton of bonus points for using it amazingly. I don't see why this is so hard, other than because a.) it's different from what the current status quo is, and b.) it would actually take time and money to fix, which is something that DigiPen fucking loathes . Teaching yourself how to make a game engine sucks, DigiPen can do better, they should just fucking hire me to make decisions like this, this is easy as shit. You have Chris Peters and the ZeroEngine team on staff, why are you not imparting their knowledge of engine design to the programmers? Why do designers have to spend the first half of GAM200 writing code in Zero, hoping that one day the programmers will figure out how to implement some sort of scripting language, so they can eventually put their skills to use in making the game rad? Oh, and make the BFA program more like the sound design programs. I know you have to teach them art shit, but let them be like the sound students and work on game teams almost immediately. At least GAM200. Come the fuck on. My solution makes every degree program involved in GAM feel better, and will make the games produced from DigiPen better, which is what DigiPen wants, right? Not only will it facilitate actual fucking learning, it will make for better, more awesome games that can be shown on the TVs all around school. Isn't that what they want? Isn't that what we want?
Anonymous 02/22/15 (Sun) 07:34:11 7b19f1 No. 555
>implying we have any say in how the courses are run In all seriousness these are all pretty good suggestions. Another suggestion would be to stop pretending that you can make a single omni-rubric that covers every possible team member's grade.