-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top
Overview
|
Download
  |
-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top
Design
SummaryHymn of the Sands is an isometric action game/dungeon crawler with light RPG and puzzle elements. As Egyptian god Osiris awoken from the dead, you battle your way through your tomb and five legendary bosses on a quest to regain immortality. You can regain your lost powers, upgrade abilities, and shift between the realms of the living and the dead.
Responsibilites
Overall Design Goals
|
|
Realm Shifting
Realm shifting in Hymn of the Sands serves multiple purposes.
- The player has different abilities for each realm. Some abilities are better against enemies than others, so player must shift realms multiple times to get the right combination.
- Some things are broken in the Nether realm, meaning players must switch over to the Living realm to pass an obstacle or vice versa.
- The visuals change drastically from a tomb in it's heyday in the Living realm to a destroyed tomb environment in the Nether realm.
Adding Personality
For Hymn of the Sands we didn't want to make a super serious feeling to it. We wanted players to have fun and enjoy themselves while playing. To help get the point of a more fantastical feeling and to add some humor I put skeletons in some unique positions.
-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top
Level 1
Design Goals
- Introduce players to the enemies and hazards.
- Teach the player the basics of the game.
- Provide a intriguing area that makes players want to continue on.
- Reuse the spaces.
Walkthrough
Image reference numbers from above correspond to the image numbers below.
-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top
Level 2
Design Goals
- Ramp up the difficulty by making encounters more varied.
- Bring hazards into a more prominent role.
- Create a combat-puzzle.
- Introduce players to Beetle Mounds and Guardians.
Walkthrough
Image reference numbers from above correspond to the image numbers below.
-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top
The Pain King
Design Goals
|
|
The Flames
-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top
Full Playthrough (Speed Run)
7:33 - Respite of Kehprir (Scarab Queen)
11:29 - Ptah: The Mad Architect (Guardian Boss)
14:10 - Akhenaten: The Pain King (Mummy Boss)
16:30 - Whadjet and Buto: The Snake Goddess/God (Snake Bosses)
18:57 - Amit: Devourer of Souls (Final Boss)
11:29 - Ptah: The Mad Architect (Guardian Boss)
14:10 - Akhenaten: The Pain King (Mummy Boss)
16:30 - Whadjet and Buto: The Snake Goddess/God (Snake Bosses)
18:57 - Amit: Devourer of Souls (Final Boss)
-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top
Post Mortem
What Went Right
Strong Vision - At the beginning we had an idea for what we wanted to do with Hymn of the Sands but never fully realized it. After I less than stellar POCG (proof of concept gameplay) the leads and I got together and discussed what went wrong, etc. We also further discussed what we could do with Realm Shifting. After this meeting we all had a good idea of what we needed to do and it showed. We were able to come back strong and had a clear vision for the game. This helped us to push forward and put out a lot of work.
Realm Shifting - We wanted this mechanic to be a large part of the game but had a lot of difficulties in the beginning on deciding the extent that it would be used. At one point we even discussed cutting it, thankfully we didn't. We realized that it would be a ability that just changed the visuals and abilities, with some changes to the layout. We decided to not go with changing enemies and reduced the cooldown from 3 seconds to .5 seconds. This saved us time in design/art and helped us to solidify realm shifting as a combat ability rather than just a puzzle/visual one.
Team Dynamic - Everyone in the team worked extremely well together. We all crammed into 1 room and sat in a group of tables with our respective disciplines. Whenever we needed something from a different discipline we were all comfortable with simply walking over to them and asking. Everyone was very understanding and helpful and we all had a drive to make this game great. We would not have been able to create what we did if we didn't have such a good team dynamic.
List Building - One thing that helped us stay on track and kept everyone up to speed was our giant list of bugs and issues. We decided to do a team playtest on Fridays where one person would play on the projector and everyone else would write down stuff they noticed that needed to be fixed. This was all compiled into a giant list we put in a Google doc online. Whenever someone was confused as to what they could do they could just look at the list.
Realm Shifting - We wanted this mechanic to be a large part of the game but had a lot of difficulties in the beginning on deciding the extent that it would be used. At one point we even discussed cutting it, thankfully we didn't. We realized that it would be a ability that just changed the visuals and abilities, with some changes to the layout. We decided to not go with changing enemies and reduced the cooldown from 3 seconds to .5 seconds. This saved us time in design/art and helped us to solidify realm shifting as a combat ability rather than just a puzzle/visual one.
Team Dynamic - Everyone in the team worked extremely well together. We all crammed into 1 room and sat in a group of tables with our respective disciplines. Whenever we needed something from a different discipline we were all comfortable with simply walking over to them and asking. Everyone was very understanding and helpful and we all had a drive to make this game great. We would not have been able to create what we did if we didn't have such a good team dynamic.
List Building - One thing that helped us stay on track and kept everyone up to speed was our giant list of bugs and issues. We decided to do a team playtest on Fridays where one person would play on the projector and everyone else would write down stuff they noticed that needed to be fixed. This was all compiled into a giant list we put in a Google doc online. Whenever someone was confused as to what they could do they could just look at the list.
What Went Wrong
Set Reachable Goals and Surpass Them - For some milestones we would get what we promised done, but sometimes just barely. This was seen as not ideal and we didn't learn until later on that we really needed to set goals that we would not only hit, but surpass.
Checkpoints and Backtracking - Checkpoints became a real pain for us because of how we were setting up a lot of the encounters and play spaces. This was especially apparent in the tutorial level where we implemented a lot of backtracking. This caused a real headache for us and was a large issue until Beta.
Balancing - Balancing is a very touchy area and it showed for us. Balancing these 7 abilities proved to be more difficult than anticipated. During playtests we would notice testers using mainly one or two abilities and not using any of the others. We would try to buff or nerf them accordingly but it always seemed that some were just more desirable than others for a majority of the game.
Checkpoints and Backtracking - Checkpoints became a real pain for us because of how we were setting up a lot of the encounters and play spaces. This was especially apparent in the tutorial level where we implemented a lot of backtracking. This caused a real headache for us and was a large issue until Beta.
Balancing - Balancing is a very touchy area and it showed for us. Balancing these 7 abilities proved to be more difficult than anticipated. During playtests we would notice testers using mainly one or two abilities and not using any of the others. We would try to buff or nerf them accordingly but it always seemed that some were just more desirable than others for a majority of the game.
What We Learned
Feedback - We learned how important playtesters are. Every time we got some people to play the game we saw someone do stuff that we didn't expect or have issues we didn't know existed. One instance we didn't realize was that there was no way to get health back while in the Living Realm only section of the tutorial level. We were all so good at the game by that point that we were never at risk of dying. During tests we noticed players getting really low and then having no way to get health back. We had no idea. We decided to implement health pots that players could break open to fix this and implemented them throughout the game. This worked great as we wanted some kind of breakables anyways.
Backtracking Should Be Avoided Whenever Possible - During playtests we noticed that players had a lot of difficulty in figuring out where to go throughout the tutorial level. People just didn't understand that they needed to turn around and go back where they came. We implemented orbs that would lead the player, paths on the ground, and even dialogue telling the player what to do; but none of it really helped dramatically. Backtracking also caused a lot of issues when building the level and for later on with checkpoints. We decided to go with backtracking to save time because we were falling behind at the beginning. It may have helped us catch up at the beginning, but hurt us later on.
Don't Keep Adding Feature After Beta - After our Beta milestone we felt really good. We were ahead of where we wanted to be and had done a lot of work. The game was looking great and everyone was happy with it. This is when we decided we could do better and tried implementing a few more features and other items to the game. Now, this would have been fine but each time we made something we world go and try making something else because it only took a little time. We needed to just find a spot to stop and just continue to polish.
Backtracking Should Be Avoided Whenever Possible - During playtests we noticed that players had a lot of difficulty in figuring out where to go throughout the tutorial level. People just didn't understand that they needed to turn around and go back where they came. We implemented orbs that would lead the player, paths on the ground, and even dialogue telling the player what to do; but none of it really helped dramatically. Backtracking also caused a lot of issues when building the level and for later on with checkpoints. We decided to go with backtracking to save time because we were falling behind at the beginning. It may have helped us catch up at the beginning, but hurt us later on.
Don't Keep Adding Feature After Beta - After our Beta milestone we felt really good. We were ahead of where we wanted to be and had done a lot of work. The game was looking great and everyone was happy with it. This is when we decided we could do better and tried implementing a few more features and other items to the game. Now, this would have been fine but each time we made something we world go and try making something else because it only took a little time. We needed to just find a spot to stop and just continue to polish.
-
Fast Travel:
Overview |
Design |
Level 1 |
Level 2 |
The Pain King |
Playthrough |
Post Mortem |
Return To Top