Handy Vandal's Almanac

This looks interesting — !

cMotion: A New Game Design to Teach Emotion Recognition and Programming Logic to Children using Virtual Humans

Publication Type: Journal Article
Year of Publication: 2009

Authors:
Finkelstein, S. L.
A. Nickel
L. Harrison
E. A. Suma
T. Barnes

Journal IEEE Virtual Reality 2009, Proceedings

Abstract:

This paper presents the design of the final stage of a new game currently in development, entitled cMotion, which will use virtual humans to teach emotion recognition and programming concepts to children. Having multiple facets, cMotion is designed to teach the intended users how to recognize facial expressions and manipulate an interactive virtual character using a visual drag-and-drop programming interface. By creating a game which contextualizes emotions, we hope to foster learning of both emotions in a cultural context and computer programming concepts in children. The game will be completed in three stages which will each be tested separately: a playable introduction which focuses on social skills and emotion recognition, an interactive interface which focuses on computer programming, and a full game which combines the first two stages into one activity.

- Digiplay Initiative

How very Phildickian: machines to teach children how to recognize human emotions. Martian Time-Slip comes to mind, with its teaching simulacra based on historical figures, e.g. the Abe Lincoln sim teaches self-reliance and related moral values. See also Do Androids Dream of Electric Sheep?, where androids — living secretly among us — are more human than real humans. And don’t forget: We Can Remember It For You Wholesale. Then again: We Can Build You. And, inevitably: The Simulacra.

In the gaming field, Valve deserves special recognition for pioneering the memorable virtual humans of Half-Life, Half-Life 2, and subsequent games. From elaborate models and scripted sequences to persuasive non-player AI to facial animation and voice sequencing, Valve has advanced game technology like no other company.

Question posted over at Stack Overflow:

I’ve tried to develop a 2D game with C++ in the past using mere objects, however, in the design process I don’t know how and what parts of the engine I should split into smaller objects, what exactly they should do and how to make them interact with each other properly. I’m looking for books, tutorials, papers, anything that explains the game engine design in detail. Thanks.

From the comments:

“You might want to take a look at XNA if only to see how the main game loop works.”

“Don’t use “mere objects”. Use whatever makes sense. Your game doesn’t have to be strict OOP. It has to work, and it should preferably be nice, well-structured code. Neither requires OOP. Write your game using every tool available. Classes, functions, functors, templates, procedural programming, object-oriented programming, functional programming, generic programming, whatever fits the task at hand. Don’t limit yourself to OOP just because some people 20 years ago thought it was the holy grail.”

“Mandatory reading: http://scientificninja.com/advice/write-games-not-engines”

“Why do you think you need a game engine? Write the code you need in order to implement your game. Modify it along the way as requirements change. And when you have a complete game, take a step back and look at what the result looks like.”

“I like the try & refactor approach. Crafting OO design takes experience.”

“Even with experience, it’s still 1) impossible, and 2) a bad idea to try to come up with a complete detailed design before implementing it. There’s a reason the whole “agile” thing has caught on so much. You will encounter issues you hadn’t thought of, so make the design decisions when you’ve got the information you need — that is, when you’ve tried to implement it, and found out what all the pitfalls are.”

“Give this a try: http://www.devmaster.net/articles/oo-game-design/”

“If you haven’t made a game before, how can you make an engine? There’s tons of free engines out there or you will be spending 20 years trying to get something done because you will be rewriting over and over again.”

“What makes a game good is the content not the engine, all good programmers ‘borrow’ other peoples code whenever they can.”

“Eberly’s 3D Game Engine Architecture and 3D Game Engine Design are rather heavy on the theory, but cover all of the bases quite well.”

- OOP Game Design Theory @ Stack Overflow

My own opinion: Don’t write a game engine. Start with an existing framework. Work within the framework, or modify the framework to meet your needs.

From an interview with Arnie Katz, co-founder of Electronic Games magazine, the first magazine dedicated entirely to video games:

Gamasutra: Have you followed casual games in the past few years?

Katz: To be honest, I put 20 years in playing games day and night, practically. They would not let me play any game for too long. If I liked a game, they shamed me into not playing. I did not play a game in 20 years when I was not thinking how to write it up, or edit it. You do that for a long time, and for me… it didn’t exactly burn me out, but it did reduce my enthusiasm.

- Arnie Katz interview @ Gamasutra: December 28, 2009