A game by Aksel Kolasinski, Yifan Xu, Xatrik Bera, and snoopy
Artist’s Statement:
Vineyard of Eden is a dark fantasy, semi-tactical RPG which draws on classical and biblical imagery to create a world confined by the branches of the Tree of Life. It is played in a hybrid digital gameplay + analogue combat form, and is intended for a young adult audience and those familiar with RPGs and strategy games. The game is intended to display a rich narrative experience alongside strategic combat gameplay. The story begins after a vengeful surge in power on a small town, where the Tree of Life’s vines sought further to punish mankind’s vanity for leaving its cradle. Rasmus, a warrior who would have died under the branches’ judgement if they did not regrow his maimed figure, is discovered and nursed to health by Edtze the medic, who weaves the vines growing from him into musculature such that he can use his hand again. The survivors fiercely resist the Tree of Life’s attacks, but Edtze believes peace can be achieved. The player, as Rasmus, navigates the remaining town, meets the survivors who each hold a different opinion of him, and engages in battles. On a 5×5 grid, Rasmus and Edtze advance toward the enemy, avoid debris, and fend off the ever-encroaching vines. We wanted the players to be immersed in the narrative experience of the game, personifying the strategy-rich battles.
Modeling the Game:
Because of our choice of RPG, we recognized our players would interact with the game through two different game phases: combat and exploration. For combat, the characters the players controlled – and their abilities and interactions with the combat board – would dictate the player’s experience. We wanted to plan out how combat would proceed operations-wise, and how different playable-characters could interact with their world to achieve a win-state. From there, we could identify the goals of combat and the resources needed thereof – and thus the mechanics of combat.
We identified some mechanics we would need to incorporate:
- Action Economy: being turn-based, players have limited actions, and so maximizing an action’s potential is essential
- Movement vs Action: players will both have an action and a movement phase, and actions have spatial restrictions. Managing movement is thus important
- Interaction with Board and UI: players will interact with a UI in order to manage these actions and movement
- Resource Tracking: playable and enemy characters will have HP (health points) and SP (skill points) to keep track of
Players would get most of their narrative, however, through the exploration and cutscenes in the non-combat gameplay. In order to flesh out the experience thereof and what we would need, we began to map out what gameplay would look like.
Since we wanted a rich narrative for the player, we felt an initial cutscene would help convey the theme and setting most tangibly. We recognized exploration would be essential for building the narrative, so we identified what planning and resulting mechanics would be needed. Players would move through the small village in a few stages, and so we would need to design a map and order-of-events. We recognized the character would interact with this phase of the game through a few mechanics:
- Movement through the Map: the player would navigate the map and terrain to see the environment they were in, and to interact with the things in it
- Interaction with NPCs/Dialogue: the player would interact with NPCs for dialogue and quests
- Cutscenes: cutscenes would trigger at the beginning to help personify some of the map and characters
Initial Decisions on Formal Elements and Values:
We wanted to make a game that blended challenge and narrative. With both a rich world to explore and moments of strategy-rich combat, we felt players could manage both! The objectives of the player would be to advance quests, either by interacting with NPCs or reaching certain (often enemy-guarded) locations. The player would learn how to interact with NPCs and engage in combat, which means the systems governing such would be the very procedure the player would follow to advance the game’s state.
While we wanted the game to feature an inventory system, the primary resources to the player would be their party members’ HP (health points) and SP (skill points) – with HP being a minimum criteria for a party member to take an action, and SP enabling a wider breadth of skills to advance combat and allow for strategy. HP and SP would be used up (and partially replenished) during combat, with out-of-combat quests and items helping to replenish these stats.
The player would additionally be limited by both the game’s boundaries and rules. While we knew the physical map terrain and borders would limit the player and define their explorative experience, we also wanted to recognize that the rules we set for how the player can interact with the world and its challenges will also dictate their experience. With movement top-down and 2D, everything immediately on the screen would be the world to the player. It would thus be important to implement efficient environmental design to not only guide the player, but help describe the world and lore to them. We wanted to take advantage of evocative storytelling elements (i.e., biblical themes and common symbols) to help reduce the burden of learning so much lore at once, since our setting was near otherworldly.
As a tactical yet narrative-driven RPG, we felt there were two primary elements to optimize from a design point of view: the narrative, explorative gameplay and the tactical, turn-based combat. We wanted to make sure that player goals and expectations were not fundamentally at odds with each other in each phase of gameplay (a phenomenon that game designer Alex Jaffe would call “cursed” game problems). We wanted players to feel like both elements were helping to personify the lore and immerse themselves in the role of the character and his party. With this in mind, we were able to narrow down the implementation of some systems of the game. For example, while the character could buy items in the game to help with combat, currency was limited and items could not be resold – eliminating an economy and preserving the “loot” feel.
Scope of the Game:
We initially planed for the game to be a slice – aiming for a polished but limited section of our RPG. We scoped for all the necessary systems to allow for such (combat, inventory management, NPC interaction/dialogue, shop UI, etc.). However, as we continued in this development and realized that these systems were extremely cumbersome to implement, we scoped back and changed to a MVP. We finished the systems we had implemented, and supplemented our missing systems with analogue counterparts (as would be seen with the analogue combat mechanism). We still, however, were able to take advantage of this format to test the elements we intended: our systems, our strategy building, and our narrative. By offering the players a narrative in the digital version, with minimal NPC interaction and questing, we were able to see the introductory reactions to the digital systems in place and iterate them accordingly to make a fun and engaging experience. Similarly, by providing a semi-polished analogue combat counterpart that mimics a digital system, we were able to gauge both player interest and engagement in the system, but the evolution and balancing of strategy in our game.
Testing and Iteration History:
Playtest 1: Beginnings of Combat
At this stage, we were still programming much of the initial game – however, we still wanted to have players test some mechanic of our game. In our first, most basic combat iteration, we wanted players to interact with the board and move the character pieces. We initially planned for them all to start at the end and move forward toward an enemy line – and with character classes not yet fleshed out we had each character have one attack and one ability. The three enemies similarly were not differentiated and had the same HP and attack.
Our playtester noted that while a vision could be seen, there were not enough mechanics to create meaningful tactical decisions. Movement and combat would need to be refined further.
We recognized we would need to iterate:
- Meaningful class distinctions, with abilities that help complement each other and gameplay. This would be important to create a tactical feel for the game
- Similar enemy distinctions, so that enemy engagement is equally tactical
- Pieces and a board that would be visually distinct, so play feels engaging
Playtest 2: Stepping into Strategy
For our next iteration, we had made a more concrete grid, but our in-game board and characters seemed to make a more fitting and robust iteration board – so we used it! We now had designs for our characters, with their attacks and abilities fleshed out. Character turn order was introduced, allowing players to systematically use and learn each player’s attacks and abilities to defeat the provided enemies.
Our playtesters told us that the additions indeed allow for strategy to begin to develop, with the board and skills allowing for more meaningful gameplay. However, the additions of so many new resources meant it was difficult for players to keep track of them in their heads. Additionally, the importance of movement was still unclear, as there was minimal incentive to move the players once an optimal position had been reached.
From this information, we felt it was important to iterate:
- Easier to see and digest display of player and enemy stats
- More diverse enemies (increased strategy and reason for movement)
- Environmental hazards (reason for movement)
We felt these would be easy to implement in the digital version, once the systems were implemented. Digital sprite progress continued, and the analogue playtesting board was left as-is.
Playtest 3: Digital Gameplay
This was our first non-teammate playtest of explorative gameplay. We finally had enough programmed to allow for minimal walking around and exploring of the barebones map. Without a cutscene system established yet, we had the player watch the cutscene before gameplay. Players could then see what the feel of the map was and explore the dialogue system.
Playtesters noted that exploring a map, even in its basic form, was an enjoyable experience and appreciated the sense of space (entering in and out of a building, walking around, etc.). Dialogue, however, proceeded too quickly for players and was too easy to skip. There was also very little to interact with, and many points where the player could exploit boundaries to leave the map.
From this, we felt it was important to iterate:
- Slower dialogue progression, with important dialogue boxes unskipable
- More encompassing map borders, with non-critical detail not able to be reached (detail can be beyond borders)
- Continuing progression of map detail and systems that allow further NPC interactions (dialogue trees, quest-dependent dialogue, etc.)
Playtest 4: Adding Strategy
For our next combat iteration, we added differentiated enemies, as well as environmental obstacles. To fit with our theme, not only did we add static tile blockers, but we added a dynamic set of vines that would encroach upon the player party every number of turns. We additionally added a potential for critical hits, so that there would be more stochastic elements to the game and decrease the certainty of certain first-order optimal gameplay strategies.
Playtesters noted that complexity increased in a way that positively impacted the strategy of the game. Movement was more favored – but still, movement did stagnate after a series of critical moves. Additionally, with the potential for critical hits, healing became more critical of a skill, which was viewed as underpowered in its current implementation for the game’s only source of healing: the medic.
From this, we identified the following iteration opportunities:
- Increase the potential for healing in the game. While the medic can be the main healer, allow lesser healing abilities by other party members (increase redundancy and opportunity for new strategy)
- Increase purpose of obstacles. Limit attack ranges and damage, and have obstacle positioning affect this
- Take away critical hits, and allow for “buffing” (reducing damage taken, at cost of a turn. Strategic damage-taking)
At this stage, however, we recognized that there were too many digital systems not yet implemented. It would be impossible to implement the complexity of the tactical combat system we wanted, while simultaneously fixing all the bugs in our non-combat gameplay systems (for map exploration, dialogue, questing, cutscenes, etc.). We thus decided to boil down our combat to a purely analogue system, polishing that experience to allow for smooth integration with our existing digital systems.
Playtest 5: More Cohesive Analogue Combat
Gameplay now consisted of playing through the digital game, until the player reached a battle point – where gameplay was now transitioned to the analogue gameboard. Three battles (a tutorial battle, a normal battle, and a boss battle) were implemented, with matching 3D models for each of the enemies. 3D-printed counters recorded HP and SP of both party members and enemies. The player would move between digital and analogue gameplay to progress until the final battle and end of the game.
A much more fun and cohesive gameplay experience was witnessed, which was very rewarding! Combat was lengthy and strategic, with the player engaging positively with the challenging elements implemented. The player was intrigued with the cutscene and exploration, and felt it added narratively to the later combat. The transition between digital and analogue play was still rough, and digital gameplay felt lacking in purpose with some of the questing systems not yet fully implemented. Additionally, there still seemed to be some mental overhead with remembering what skills and attacks each character possessed, along with how the players could move and attack.
This inspired us to make some final iterations:
- Polishing the digital components of the game, and cutting non-critical story elements that obfuscate player flow
- Adding player character cards, that show skills and abilities of each character, and how they interact with the board
- Completing 3D models of party members
- Adding more explicit wording to the board
- Increasing resolution, polish, and size of the gameboard
- Providing the player with the final story ending (written) upon defeating the final boss
Playtest 6: Final Playtest
Our final playtest featured a completed map and story – with intro cutscenes, exploration (including a fetch-quest and rescue), three battles (tutorial, normal, and boss) with refined combat, and smoother transitions into and out of digital/analogue play.
Excitingly, our playtester grew more engaged throughout the playthrough, following the storyline and engaging in strategic thought and discourse for each battle. The transitions between digital and analogue play, especially after the tutorial battle, seemed less abrupt and confusing, and the combat mechanics were now easily digested. Digital play was minimal, but provided enough story and lore to give the world the feel we wanted. With the systems in place, we feel like we could expand into additional quests, add further NPCs, increase the map size, and make the world more expansive.
Our playtest is recorded in the link below:
https://www.youtube.com/watch?v=TZUo_tIB4go
We felt the following timestamps were important:
2:18 – Initial play. Somewhat stoic, not narrating lines. Just neutral and experiencing.
7:22 – 7:40 – First smile! Bad roll, then engagement, and already following the rules of the special ability (damage done = health gained)
8:59 – Please not another 1 roll… tutorial victory!
9:35 – Player more engaged with digital! Narrating lines and exploring with excitement.
9:53 – Finds trimmers, notes it looks important (will remember in quest at 11:05).
11:29 – Already is used to transition for analogue play, moving into it organically.
13:33-13:57 – Explosive intro to play. Has a plan! But rolls low.
14:18 – wants to heal. Looks at rule sheet instinctively for learning new rules.
20:54 – Exploring map for fun before battle, noting “locked” terrain.
23:08 – Explosive move forward into battle, expressing strategy.
28:10 – Prior movement makes enemy unable to attack, with poison doing damage in meantime. Player happy that strategy is working.
32:20 – Rolling another one, happy engagement, strategy following.
33:44 – Notices movement problem with encroaching vines and has to change strategy. Counts forward several moves, planning very far ahead now. Player familiar with game enough to do so.
36:44-37:02 – Wanting to be risky. Engaged in game, having fun!
41:38 – Making move, moving resource counters by himself, engaged and knows exactly how many resources he has.
42:24-43:06 – Several ending moves. Isolation by vines, bold attack and end stages of strategy.
43:38 – Victory
45:32 – That was fun! Player thoughts.
Future Work:
To make our project work, we had to substantially down-scale from our initial vision. Continuing, we would like to implement the digital combat system, with its respective sprites, UI work, and action/inventory system. Much of the fantastic sprite work has been done already.
We wish to implement additional quests, as well as an out out-of-combat inventory system, so to allow the player to plan for future battles. This would have involved the completion of our work-in-progress shop system and worshiper (shopkeeper) NPC – one of several NPCs that have yet to be implemented (but have art, sprites, and a place in the story!).
Furthermore, with play more engaging, and with the digital version more portable, we are excited at the thought that playtesting can be easier and more accessible – letting us prototype and implement our changes more quickly and easily.
How to Play:
Digital Game:
https://fishbone-dev.itch.io/vineyard-of-eden
Analogue Print-&-Play:
Acknowledgements and References:
Much of our artwork was made by hand by our hardworking and talented teammates. While some fonts were imported, sprites and background tiles, interiors, mapwork, etc. were all handmade without the use of AI. The game was coded in Unity, similarly by hand and without AI. While this made our process a bit slower, it also made it more rewarding. We hope it shows!
