For my One Game a Month projects, I have chosen to undertake a unique challenge. Every other month I choose one "bad" video game and remake it into something playable and hopefully even entertaining.
For May, I decided to remake the NES classic Hyldide, and combine it with its official remake, Virtual
Hydlide. Together, they would create Virtually Super Hydlide Special!
While Hydlide is considered a groundbreaking classic in Japan, its late American release made it a laughing stock prime for AVGN. Virtual Hydlide, on the other hand, was pretty much universally panned. At best, it was a poorly implemented game with some good ideas.
Combining a game that half the world hates with a game the whole world hates... What could possibly go wrong?
One of the biggest issues players have with Hydlide is the combat system. Long before Zelda's exciting blend of action and exploration, Hydlide was all about walking into things.
No, I'm not kidding.
To attack an enemy in Hydlide, you walk
into him. You and the enemy each trade blows every time you step onto
his tile or vice-versa. The deepest strategy you can apply is to hold the A
button to enter Attack Mode. While in Attack Mode, the player
inflicts more damage, but also suffers more. If it looks like you
might lose the battle, you can just move away and wait for your HP to
Fortunately, we have a genre of games that is beloved despite its similar lack of gameplay: the MMO.
In classic MMO format, the player chooses a target enemy and trades blows automatically, until either the player dies or the enemy dies. This was actually the core concept I used when I started this remake, because it solved many issues:
- If I made this first person, I wouldn't need custom attack animations and could tie into the Virtual Hydlide style of gameplay.
- Because MMO combat-style trading of blows is so similar to the old style, I could keep the stats exactly the same and maintain the original balance.
- I could even keep the Attack Mode and Defense Mode distinction, and have it function the same.
The other major advantage is that I'd been working on a 3D sprite engine the previous month, and this would allow me to use the original NES sprites in a 3D world!
Note: The gameplay images in this article use custom sprites to avoid copyright issues. Virtually Super Hydlide Special uses the original NES sprites.
Finally, the sprite engine allowed me to import maps from a directly from a bitmap. In order to create my game's maps, all I needed to do was trace the original maps with solid colors and shrink the image to a reasonable size. The engine does the rest.
Looking back, it really was actually a pretty good plan. But, you know what they say about the best laid plans...
What Went Horribly Wrong
I Vastly Overestimated My Engine
I'd built my engine for old-school dungeon crawls. The largest map that I had built was about 30x30. The smallest I could make Hydlide's world map while keeping that expansive feel was 83x83.
At almost triple the tested size, this lead to a long loading sequence. This is problematic, because the dungeons are not large and you'll be loading the world map often. I ended up spending a few days implementing a streaming map, only to cut the feature later because I realized the loading screens were a good way to give the player information they needed.
The days I spent making the map stream were wasted. If I had taken the time to think about things prior to attempting to work through the problem, I'd have saved time and stress.
The other set of issues came from
modifying the engine to use a looping map. The tiles that I used were very
small and I needed to draw a lot of these to fill a reasonable draw
distance. This lead to visible slowdown as the map tiles looped around.
My solution? I loaded more tiles!
During the loading screen, I loaded
about twice the tiles that I needed to fill the draw distance. This
means that, as you walk, the map is already fully loaded and in
place, but tiles in the distance are loading in real time.
At this point, I modified the system to load only a few tiles each frame. To the player, it looks like the map is streaming around seamlessly, but beyond the camera there are holes in the world where it's actually being built a little bit at a time.
Overall, the engine worked, but it sure as heck wasn't as smooth as I had intended. I had wanted my core gameplay to be implemented by Day Seven, but didn't actually finish until almost a week later.
I Underestimated the Conversion to 3D
Because I put so much time into making the world map work, I didn't foresee this second major issue until I was well into the project. I have enough experience that I should have seen it coming a mile away.
The dungeons in the original Hydlide are mazes: The Original Dungeon Maps
It was forgivable in the original game, because a bird's eye view allows you to see the correct paths. But, as a first person game, directly using the dungeons' maps as I had planned would make things frustrating.
I couldn't import the levels as I'd planned, and so I needed to hand-make new ones. While creating short and functional maps was not a major problem, it was an unplanned expense.
I Was Overconfident and This Made Me Stupid
Two months earlier, my previous remake project, Ghostbusters Inc., had been amazing from a work standpoint. Everything fell into place, and I ended up implementing nearly every feature I had hoped for, while still working a reasonable schedule.
My last #1GAM project had gone extremely smoothly as well. I completely designed and implemented Tactical Strike Micro in a week. It had used the same engine as Hydlide, and everything worked out well.
I went into this month with good projects on the brain, and I ignored one of my most important tools: planning!
I'm usually a fanatic about taking the time to write down a schedule, plan features and dependencies, and correctly prioritize everything. I've seen and often taken part in the stupidity that comes from "winging it".
On the 13th>, I was still implementing core gameplay features that should have been either implemented or cut by now. Stress was beginning to get to me, and I could feel the developer tunnel vision coming over me. I was working hard, despite having lost sight of the big picture.
Honestly, I wasn't sure I'd finish on time. Half a month on a small project seems like a long time, but there was a lot that needed to be done, and it wasn't going well.
I often warn people about the dangers of blind passion, yet this project was a fine reminder that I'm not above it.
I Didn't Panic
I've worked with myself enough to know that this is an accomplishment. When things go south I usually enter a purely reactive emotional state—highly effective, but misguided. But I didn't do that here.
On the 13th, I realized that I was in trouble, and I stepped back to review my process. It didn't take long to see that I was so focused on controlling the steering wheel that I wasn't watching the road. I was fixing issues without any consideration for how they fit into the final product.
I took the entire day of the 14th off from development to outline a proper plan:
- Dates by which each part should be ready.
- A prioritized list of features and bug fixes.
- Questions that I needed to think about, such as "How will I help guide the player without NPCs?" With this list, I knew what to think about when I wasn't working.
When the plan was ready, I sat down and relaxed for the rest of the evening. I knew that stress had started to affect my thinking and I needed to clear my head.
Starting on the 15th, my productivity skyrocketed. I accomplished more in the next three days than I had in the previous week.
I was amazed how good the 2D NES sprites looked in the 3D world. All the enemies, dungeon walls, and terrain tiles are straight from the NES game, yet they stand out and make the game look unique.
While I've designed better games over the years, this one seemed to catch people's eyes. I actually received a lot of positive feedback on the way the game looks.
My Early Assumptions Were Correct
Thankfully, most of my original assumptions were valid. The combat system worked fine and was reasonably balanced, and even with the flaws, the engine did what I needed it to do.
Despite everything that went poorly, the game is fun.
While I did modify the combat system to be more action-oriented and less of a grind, I had a strong start thanks to the links to the original game.
My Dev Network
While this was a solo project that I built on my own, I didn't actually do it alone. Many of my friends are experienced game developers and they were an immense help.
The combat redesign came after talking to my friend Josh about the MMO-style combat. He expressed concern that it wouldn't be exciting enough. As the project continued, I realized that he was right, and that I needed to stray from the original vision.
The same goes for other features ,such as the "fairy guide" I implemented after my friend Rob got lost, or the new attack animations I coded upon his observation that I could just rotate the sprites to decent effect. Even Twitter came to my aid, linking me to information I needed to help guide the player wordlessly.
You cannot underestimate the value of having people to talk to, even on solo projects.
My Biggest Takeaway
Paperwork and scheduling are tedious and rarely accurate, but they are still beneficial.
Taking the time to put your plan on paper will force you to examine the project as a whole. As you break it down into specific features, you'll see which pieces are reliant on one another so that you can tackle them in an effective order. Then, you can stay in the zone between tasks because you don't need to switch between details thinking and big picture thinking.
The other nifty advantage is that having a list means that you can add to it during development. If you encounter a bug or feature that should be implemented, you have a place to write it down and stay organized.
I thought I could get away with avoiding the tedium, but I was wrong, No matter how experienced I might be, I'm not immune to mistakes. Pre-production is an important step, no matter how good you think you are.