/digipen/ - DigiPenitentiary

Intensity curve.

You really don't. Just do the work and pray that you get a good grade.

>>819
I've gotten A in every GAT class. In 250 now.

Have any specific questions?

>>823
How inadequate do your BAGD teachings make you feel when it comes to making a video game?

>>823
Let me guess, you're a BAGD rather than BSGD

>>825
BSGD. In what -world- does a BAGD get an A on anything?

My design grades are higher than my programming grades (which are mostly Bs with the odd A peppered in). But nothing at this school has been impossibly difficult so far.

>>824

The board game shit helps a little bit, but you're right that there is a lot that doesn't translate. I mean… video games are so much bigger than not everything is turn based, ya know? But the map stuff is good, and we get in the right head space for thinking about things. Lets us weed out obvious problems.

>>827
Everything from how to make a character's actions feel satisfying, or how to make menus satisfying, or how to make camera movement fluid and not nauseating… it seems like the first- and second-year game design classes don't teach you a damn thing about anything like this, and it looks like the rest of them don't either. They don't even teach you that these are things that you should pay attention to, all they care about is the goddamn intensity curve and high-level shit like applying music theory to game design.

>>828
That is kinda true.

However, the way I look at it is: camera movement should be pretty intuitive. That sort of shit isn't -tricky- exactly, and there are other basics that need to be covered first.

Menus are for my artists. Fuck that noise. Honestly, I couldn't give a fuck and the only people I know that do menus well are terrible game designers. It's just a specialty that's distinctly separate from game design.

As for character's actions? That's been covered a bit in the GAT classes. Especially 250. I've had a lot of talks with Morrison about how to improve the feel of something. He just does a poor job of covering it in lecture.

>>829
Listen here motherfucker. I don't often brag, or talk myself up at all. Usually I keep this shit bottled up. But if you're going to talk bullshit like that, I'm going to lay it all fucking out.

—

I'm a BSGD who:

- Got over 95% on his first GAT250 project

- Made the underlying framework for an awesome component-based game engine from scratch for GAM200/250

- Made menus for his GAM200/250 game that the grading professors said were "Professional, not even just for a DigiPen student game, but for a professional published video game."

- Has nearly zero art skills

—

To me, being able to make the menus of your game good is the perfect embodiment of a good BSGD:

1. Figure out the problem: The game needs menus. You've seen tons of video game menus in the past. If you never paid attention to them, go play some games in your game library or check some out from the school library. Your menus are probably going to need multiple levels: you're going to start on the main menu, and from there, if you select "OPTIONS" and press the Confirm button/key, you're going to move to a new "menu layer", which you can get out of by pressing the Cancel button/key.

2. Approach the problem in a CS way. Make a "Menu" class. Make a "MenuEntry" class. Make a "MenuManager" class, or something. Menus are stored in the MenuManager in a stack. When you select Options, push an Options Menu to the menu-stack. When you cancel, pop the stack. Menus have an array of MenuEntries. Menus also have an unsigned variable called "selectedIndex", which represents which element in the array is currently selected. Maybe MenuEntries have sub-classes for "checkbox" or "drop-down menu" functionality.

3. Make the menus like a GD student (designer). Realize, as a game designer, that menus are an important aspect of the game. It's the first thing you see when you launch the game, Play a bunch of video games and see how their menus work. Note common frustrations, such as how sometimes menu transitions are too long and that frustrates the player because they can't select a different menu entry fast enough. Think about the layout of items and sub-menus; do you really need Graphics and Sound sub-menus, when they each contain no more than three entries? Should they all go on the same menu or shouldn't they? How do you make selecting different menu entries enjoyable? Do the entries change color, or do they stretch? What interpolation(s) algorithm do you use to make it all feel good? If you have inclinations toward art, typography, or sound, how can you use these to improve your menus further?

—

Not necessarily every BSGD has to be like me, and think like this, but fuck, man. There is more to video game design than just "take these ideas for mechanics and try to mentally arrange them to be good," like you do with a GAT210/211 game. Making a video game is like making a GAT210/211 game, but not only do you have to use paper, ink, and dice to make a game, but you have to invent and then manufacture the correct paper, ink, and dice, and make using them as fun as possible. This kind of thing doesn't translate well to traditional game design, and DigiPen doesn't fucking teach it.

And don't fucking shit-talk menu designers. I'm sorry I care more about user interactions than you do, but don't call me a lesser person because of it.