Refining & Formstorming

For Activity 2, we explored our inspirations and vision for the project, creating our own personal moodboards of our specific tastes, played games, and wants for the project.

Making the moodboards honestly helped quite a lot. I am a visual person, and seeing everything laid out made our project feel a little more real, rather than just a bunch of ideas in our heads. Pulling references for environment style, camera feel, and UI examples (like simple but effective inventory screens, readable icons, and that “2D assets in a 3D space” look) helped us spot patterns in what we all keep gravitating toward when it comes to video games. It also made it easier to communicate with the rest of the group, because instead of using vague words like “cozy” or “stylized,” we could point at specific screenshots and be like “this lighting” or “this UI layout”. Overall it tightened our visual direction, gave us a shared language, and made our concept feel a little more unified.

Game Engine Comparison

After proposing our idea to Steve, we were told to look into different game engines(Unity, Unreal Engine, Spline) and their pros and cons. I decided to take care of this task as I've used all of these engines before for different purposes and have some basic knowledge of each. I made a simple table to lay out all the key points for each engine and see how they compare. The clear winner for our idea came out to be Unity, as the pro version is free for post-secondary students and it is build primarily for 2D or stylized 3D games in the style that we are trying to acheive.

Testing Action Research

This is our action research workshop slide deck. We chose to use this article to gather more information about Action Research, which we summarized in bullet points. We then went into our first steps, and we had gathered links to tutorials to get us started.

Peer Feedback Sumary & Reflection

Across all three test groups, the feedback landed on two big themes: the concept is exciting, but we need clearer ideas and tighter scope. Test Group 1 liked the idea right away and described it as “decorating an island,” with comparisons to Mario Maker and even The Sims because of our time and biome changing idea, which tells us that the cozy customization angle is coming through. Their main issue was confusion around our hero image, especially the stacked islands, so they were not sure if the experience is one island, multiple islands, or layers, and they suggested we focus on getting one or two features working really well first, instead of spreading ourselves thin. Test Group 2 went deeper into interaction details and asked practical questions like whether rotation should be a smooth 360 or snap every 45 degrees, and if it snaps, they suggested making each rotation actually do something meaningful like changing seasons or time of day. We are still not sure how we can do that in Unity, but that’s something that could be really interesting to explore. They also pushed us to think about the selection process for each map and they wanted a stronger “dopamine loop” through progression, unlocking, or something that changes over time. Additionally, they further solidified our idea of adding fun visual “toys” like foliage, lighting variety, ambient sounds, and small interactive details to make the world feel alive and more satisfying. Test Group 3 was mostly production focused and basically told us to stick with Unity, leave publishing (itch.io for example) for the end, and handle scope creep by building the core functionality in Unity first before worrying about heavy 3D modelling and asset creation. They emphasized getting super specific about mechanics, like how object placement works (drag and drop vs button spawn), how rotation works in Unity, whether the player uses a character inside the island to place objects, and even what the island context is (skyblock, ocean, void, etc.). The overall takeaway is that we make our idea a bit more clear, ideate and lock in what the island system actually is, prototype the main interactions early, and only then add extra features like biomes, time, and tiny world details once the core mechanics feel solid and achievable.

Next Steps

Next, we need to lock the scope and turn the idea into a concrete game plan. Step one will be defining the “rules” of the experience so we stop being vague. Is it one island or multiple, what is the world context (ocean, void, skyblock style), how does rotation work (smooth or snapping), and how does object placement and other mechanics work (drag and drop, button spawn, or character based placement). Then we should make some placeholder assets and prototype the core loop in Unity as soon as possible. Since rotating the island, placing objects, moving or editing objects and save the result in some simple way are our core mechanics, we need to get those down first. While that is happening, we should turn the moodboard into actual style guidelines (palette, pixel density, UI style and sizing, icon style, camera angle) so our assets and UI stay consistent. After the base prototype feels solid, we can tackle all the fun polish in a controlled way, like foliage, lighting changes, ambient sound, tiny interactive details, and a simple progression hook (if time allows us). Finally, we can worry about sharing it online (like itch.io), or getting a stable build ready for a demo, since a finished prototype isn’t hard to wrap up.