As I mentioned last week, this week we had the quarter’s walkaround! During the quarter, we got tons of great suggestions, and then we continued iterating on our design. We mainly came up with two ideas, and finally, we chose those the puzzle nodes as our first choice.
Quarter’s Walkaround And Sitdown
During the presentation, we were clarifying what our project is, what our deliverables are and what our approaches are. Also, we were showing them how we will playtest our project and how our project differs from the last Alice Adventure project.
Project Description
- A continuation of the ETC Alice’s Adventure project
- Developing a 2D adventure game creation tool for people with little game design experience
- The secondary goal is to teach introductory game design concepts
Deliverables
- A point-and-click adventure game editor
- An engine supports adventure game features
- A game creation guide for naive game designers
Our Approaches
- Game-to-Engine Approach (more detail in previous blogs)
- Engine-to-Game Approach
Playtesting
- Target Audience: Middle schoolers
- Content
- The usability of the game creation guide
- The usability of the sandbox interface
- The process of game creation guide
Differences
- Focus: from CS concept to game design concept
- Features: Navigation and story-telling
- Guide: Add a guide that helps game designers to create games by answering questions
- UI: Programming-centric to design-centric
- Platform: Windows only to cross-platform
Feedback
We got tons of feedback from our faculty, mainly from three perspectives: understanding demographics, being aware of the project management and some tips about puzzle design. For puzzle design, they recommended us to prepare some puzzle libraries so that the puzzles won’t be unsolvable. That was one of the great suggestions we got from the quarters and we started to iterate on our work based on that.
New Design Proposals
Though we had compiled a puzzle list on the weekends, after the quarters, we found that those puzzles were still too generic. Thus, we decided to specify those puzzles by providing specific puzzles like “go to X scene” puzzle. When working on that approach, we had two different ideas in our team. One idea is to consider an action like “Enter a scene from a door” as a node, which can be manipulated and connected by the user. Another idea is to consider a puzzle like “A door locked by a key” puzzle.
Action Nodes
Pros: The action nodes are quite intuitive. It acts like storytelling. “The player enters the room, unlocks a treasure box with a key and gets all the golds”. It’s very clear that there should be three actions: enter a scene, unlock a locked container and get items from unlocked containers.
Cons: However, it has some potential disadvantages, the result of one single action might be very fuzzy. For example, what is the result of talking to an NPC? To design this action, the user will inevitably add some temporal state as a result of an action. Back to the example above, the result of “talking” action can be the NPC is convinced (state). This kind of states are very abstract and hardly be mapped to the real-life experience, which makes the game design process hard to learn.
Puzzle Nodes
Pros: The puzzle nodes approach is rather a different one. Instead of providing action nodes, we provide puzzles. All the temporal states like “the door is unlocked” or “NPC is convinced” are encapsulated by the puzzle nodes like “Unlock a key-locked door” puzzle or “Trade with NPC” puzzle.
Cons: While it also has its own downside. When composing an adventure game with those puzzles, game designers might need to think backward. The puzzles related to winning condition will be made first and then propagate to the beginning scene.
Conclusion
By talking with our client and laying out some of the examples, we finally decided to stick to the second approach because it’s more beginner-friendly and easier to understand. Though the game designer needs to think differently, it is actually something we should teach the naive game designers!