Nicholas Sceusa

Gameplay and Level Designer

nicksceusa@gmail.com

Who Murded Dame Snow White - 12/30/25

This project is the result of my attempts to "spice up" an older project. The goal was to make it more interesting for my students as well as provide them with a reason to focus on optimizing their code. It's not super complex, but it highlights a couple of good habits to make while working with lots of production items. Lets start at the beginning.

Originally, this project was a simple Apple Catch game. A common tutorial used to teach students uses of cloning and aspects of collision. It's a good tutorial but it can feel a little lackluster. It doesn't really create an experience. It's fun but the engagement only goes so far.

To make things more interesting, I decided to incorporate a story. Mysteries in particular tend to interest people as there is always something to learn around the corner. The apples made me think of snow white, thus we had our murder victim!

My version of an "apple catch game"

One important detail to look at was how to handle the "scenes". There are both game play and cut scenes, making it necessary to control when each is loaded. This is where the "Director" sprite comes into play. The Director never physically appears in the game, but will track the scene and send out messages to the other sprites to load the required items. When a scene is complete, a "scene complete" message is sent to the director, the scene variable is updated, and another message is sent out to load the next items. A major benefit is this allows us to jump to a specific scene by changing the scene variable manually. This makes testing a lot easier and saves a lot of time.

What the apple catch game usually looks like.

I like to use a computer sprite for the director. Seemed appropriate. The sprite is always hidden and can never be accessed by the player.

Variable initialization on the left with some scene loading code..

Game mode code on the director sprite. The scene is referenced again so variables can be changed per game level.

The director also calls up the game mode when needed and controls the apple spawning. A lot of apple catch games simply put the apples on a timer. More control is needed to ensure a certain amount of apples, or clues for my version, are on screen at a time, they spawn at slightly different rates, and their fall speeds adjust per level.

The next item to tackle were the cut scenes. For this I decided to create a "flipbook" sprite. Essentially it holds all of the cutscene images. When the level is loaded, it looks at the scene number and sets the range of images that should be used for that scene. A separate variable can be tweaked to control how quickly the images change.

The flip book code. The code that displays the scenes has been set to a function as it is reused repeatedly.

The various "costumes" on the left are the different images of each cut scene.

Having the cutscenes in a single sprite makes adjusting and moving them around a lot easier. Plus it allows us to focus on the storytelling elements, finding the right images and using the right words.

Trying to do this while programming in each page flip would have been very time consuming. Some thought is needed to avoid adding too much text, as it can be difficult to read if the timing is too quick. In future iterations, I will include some functionality to have the player press a button to go to the next part of the scene instead a timer, but it works for this project.

The final task for this project was to ensure all the apples utilized the same sprite. Since all of the apples need to share the same core functionality, specifically falling, it made sense to update their costume and tweak a few variables as opposed to using a second sprite. And if more apples are added, it will help with organization. Lists were used to store the "apple type" and a function was made to control the randomization of the apple at the correct level. This falls in line with my C++ experience and Object Oriented Programming. Scratch doesn't technically have "objects" and you can't inherit behavior from a sprite, but this is one step in that direction and a good introduction to the students. Should they pursue higher level languages, this experience might give them a leg up.

Above: The apple sprite costumes.
Right: The code for the apples. Code for pulling up a random sound queue when a "clue" is found also helps the experience of the game.

Overall this project revamp focused on:

Scene Control with a "Director" sprite for order and easier testing
Cutscene Control with a "Flipbook" sprite for easier editing and play control
Grouping common sprites for "object oriented" organization
Include story elements, music, and sound effects to improve the experience

Scratch is sometimes looked down on as it is limited compared to other languages. However, you can do a lot of cool things if you work around them. Adding a story element made the project more fun to work on, but developing the tools for faster testing and story changes helped hold my interest much longer. Should I tackle a bigger project on my own in a different engine, the development of tools and technical specs will definitely make its way into my process.

If you haven't used Scratch, I highly recommend checking it out. You might find it useful in some capacity. Happy coding!

Page updated

Google Sites

Report abuse