Designing a "videogame design course" [HELP]

0 favourites
  • 8 posts
From the Asset Store
Game with complete Source-Code (Construct 3 / .c3p) + HTML5 Exported.
  • Hi everyone,

    With a graphic designer friend we're building a dual illustrator/construct2 course aimed at high school students in order to teach them the basics of videogame design. Our general goal is to provide a fun experience for the students more than breed a generation of top level game designers, so we want to keep things simple.

    We have decided on the following format: On the first class we show the students a complete game to showcase the power of the engine. We then show them a simpler game which they might be able to build, and thus set the goal for the end of the course. We alternate between illustrator and construct lessons. Each lesson should be designed to answer a group of key questions, all hopefully building towards completing the game, and we had this idea that whenever one of us is teaching his lesson, the other one sits with the students and directs the flow of the lesson by asking the current teacher each of the key questions. This serves a double purpose: It gives the lesson an interactive feeling while keeping the course's structure, and it makes students see that it's ok to ask questions whenever they have any doubts.

    The purpose of this post is to ask for your opinion on the format of the course, but also to ask for ideas on what the scope of it should be.

    • How technical do you think we can be without scaring the students away?
    • Which concepts do you think constitute the 'heart' of the engine?
    • What type of game could showcase all of those concepts while still being fun?
    • Most importantly, what type of game can be designed while following the 'key question' format and make it seem like a natural process?

    We want to make the students feel as if the answers to the questions are the building blocks of the game we're making.

  • An Angry Birds clone is undoubtedly the game you want to use as your example, easily relatable examples will make learning much easier, as students are looking at something they already know, but in a different way.

  • Thanks, I'll keep that in mind

  • I actually did a videogame design course wtih a main focus on art and business so I can tell you what I desperately wanted from my course that was not delivered.

    Firstly I wanted to actually make a god damn game. Talking about making a game isn't making a game, drawing concepts for games and writing a story and pretending to do the business side is still not making a game, only making a game is actual practice for games design so I'm glad you are hoping to do that with your students.

    I would recommend doing it as a group project, assign a kid a specific part of game dev, or split them into teams and do it that way (art, design, music, programming). Perhaps teach them all the basics first to make it easier to fit all the components together. If my college had done a little game jam like this I wouldn't have seen starting to make a game seem like such a huge wall to climb with months of planning. I'd probably have started making games 2 years earlier and been a lot happier because of it.

    You could even split them into teams and have a competitive game jam after you show them all the basics so they aren't calling you over to ask you rudimentary things.

    • How technical do you think we can be without scaring the students away?

    A lot of people enjoy the technical side of things while others shy away from it. This isn't really a problem because the people that shy away from it will get their chance when it comes to something they are more interested in like the art. This would also be aided by working in teams.

    • Which concepts do you think constitute the 'heart' of the engine?

    The behavior system is probably one of constructs best features. I would recommend showing them the main ones (bullet, pin, 8 direction, movement etc) so they can see how easy it is to make a simple game. You can make ghost shooter in under 5 minutes. Make it infront of them and get suggestions from the class on little things like the bullet and sprite image as well as death animations and the like.

    • What type of game could showcase all of those concepts while still being fun?

    Top down shooter, hack and slash, platformer, basically anything that has fundamentally simple gameplay.

    • Most importantly, what type of game can be designed while following the 'key question' format and make it seem like a natural process?

    Make a simple game in-front of them and take requests on certain things ("what should I make the enemy look like?") Show them how it all fits together using the engine. After it is done you can ask them "so do you guys think you could make this?" and then get them to make it, their own personal version.

    Straight away you have them making a game, using all the basics of the engine and at the end of the day they have their own game.

    I have 1000 more ideas on this so just ask if you want some feedback. I just think my course could have been 100x better than it was and I stay awake at night thinking of how I would do it.

    Good idea on the whole though man. Really happy someone is trying to show kids how easy it is to make games.

  • I teach a Game Dev I class at DePaul and thought I'd share some of the format of that class in hopes that it might be of use to you. The class is taught using Game Maker Studio. That's what the school is invested in, so it's what I'm currently teaching but I use bits and pieces of this when I visit highschool and some local youth groups to do workshops. I believe everything I do is applicable to Construct 2 and at some point will be using it for smaller/more condensed workshops and game jams.

    It's a game design class and an engine learning class. My focus is on game design so I spend a lot of time with processes and design patterns. This is a 3 hour, 10 week class (11 if you include finals) with usually about 30 students meeting twice a week for 1.5 hours and goes something like this.

    Week 1

    Introductions and identity

    Introduction to engine basics (sprites, objects, events, actions)

    Assignments - Create a splash screen to represent who you are. Using graph paper design the layout for a break out game. Create said game, include room switch from splash screen, ball, paddle, static targets, one moving target, one toylike interaction. (don't worry about scoring and what not, we're just worried about getting stuff into engine and getting it interacting in one room)

    Week 2

    Review Break out games. Delve deeper into sprites creation and working with them. Look at Shoot-em-up games with a historical review of shooters from space war to geometry wars. Deconstruct what's interesting about shooters. Delve deeper into creating behaviors with objects and creating game control objects that manage the flow of play.

    Assignments: Come up with an idea for a shooter. Write a one page treatment about it. Define the core play of this shooter, sketch out out the objects you think are needed and a sample level for your shooter.

    Week 3

    Look at shooter designs. Break into pairs and do design interviews. One person interviews the other about the game and takes notes on post-its, placing post-it's on large easel graph paper. One post it per event, interaction, object. Once done you have beginnings of asset lists and user stories. Switch roles. By end of session each student should have a collection of post-its to use as the foundation of their game.

    Assignment: Make one room of the game that shows core play in action. This is an ugly prototype.

    Week 4:

    Review prototypes. Get feed-back on how to make it work smoother. Discuss level design and verbs. The use of space outside of visible room, player feedback, the importance of sound, facilitating the player, timers and timing and timelines. variables and scope.

    Assignment: Finish game with 3 rooms/levels, splash screen, opt in entry point, win/lose screens that allow for opt in or quit. Every room needs to have one new opponent that behaves differently and that behavior is visible to the player. Some sort of scoring that is understandable to the player and visible.

    Week 5:

    Review games. Discuss planning and documentation. Present planning document template.

    Assignment: Each student conceives of a game they'd like to make. Plan out the game. This involves writing out any story notes, make asset lists for sprites, sounds, behaviors, etc. The game must have some sort of smart opponent. Create level design for individual levels. Build one level ugly prototype of this game. Create power point pitch for the game that shows off art target, look and feel, and scope of play. (This assignment is two weeks long).

    Week 6:

    Discuss rudimentary AI behaviors, discuss scripting and the math of building some behaviors that test for player distance, direction, and state. Talk about basic state machines. Talk about the needs of platformers.

    Weeks 7:

    Present pitches. Class votes on pitches electing 5 that will be taken to polish. Class breaks into teams that will work on these games to polish with game designer as lead. Discuss agile development methodologies, sprints, scrum, deliveries.

    Assignment: Using Trello, create user stories, prioritize them, and break them into 3 sprints (First playable, Feature complete, Polish and ship). Every week here after students must come in with a fully functioning build (executable). Running from engine can lead to failure of that milestone.

    Week 8

    First Playable Due: Present and lab work.

    Week 9

    Present and report. Show build and work in lab. Testing

    Week 10

    Feature Complete Due. Present, check-in and get OK move to polish and ship (I'm the client and they have to respond to my feedback). Make user stories for all known bugs.

    Finals Week:

    Present final game

    There is a lot of room for variation in here and I change it a little every class (for instance sometimes I make that first planning document be a reverse engineering of an existing game and then they can do one of their own). If the class is heavy on engineers I push a little harder. If the class is heavy on artists I push a little harder on look and feel. If the class is designer heavy I push harder on creating polished play that allows for emergence and visible feedback and facilitation.

    Since Construct 2 has so many behaviors built in to work with I think you can push more on making those interesting and polished. Also don't forget to push sound as feedback tool and a way to immerse your player. Games that neglect to include sound design will often lose 1 or 2 letter grades.

    I hope this is useful.

  • Skragaronomy Thanks for posting this detailed description of your course! (Yes, it is quite useful.) You inspired me to post a similarly detailed description of a course I just finished teaching.

    Just curious, what is the background of your students when they start this course? (In particular, what year do students typically take this course, and are there any prerequisite courses required?)

  • stemkoski You're welcome. These are early students, typically late freshman and sophomores. Since the class is available as a general elective I also get the occasional non game student from another field who has some interest in games or game-like activities. The vast majority of people are design or art oriented meaning that most have little to no programming skills. I will also get a small handful of engineering students who are just barely getting comfortable with a language. The designers and engineers usually move pretty quickly into GML because they tend to be self driven in terms of figuring things out.

    I do a lot of forcing people to slow down and incubate, document, and prototype which often drives the ego's of the engineering people crazy at first. But they find it saves their sanity by the end of the course when they're in big teams. Every now and then I get someone taking it as a late junior or senior and they usually comment that they wish they had taken it earlier. Most junior/senior classes are in Unity3D or pure code and some don't pick up the process habits I teach in those classes.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Interesting. The game design class (first one, and primarily 2D course) I took here at Elmhurst College went more like this:

    2 class days to learn about one game type

    1 class day to work on it in class

    1/2 class day to learn the more advanced version of it

    1/2 same class day to work in class

    As we learned about more detailed games types/mechanics, we'd be given more days to work in class and learn about the next step.

    No groups, and the majority of the work we did was on our own. Deadlines were pretty tight, but we had instructions on how to complete the tasks. We were also told to add variations to the games in our own style, and given guidelines as to what to add. Eventually we were on our own to find graphics and audio that worked with whatever we were developing, and we dropped the drag-and-drop functions to learn how to use the scripting language.

    We'd completed, I believe, 7 different types of games, and 2 extremely simple 3D games using Game Maker 8.1. I was told the second class, a 3D one, uses Unity 3D.

    All in all I really enjoyed my time spent since we learned about so many different game types, and created so many different types of games.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)