karlduffy-gamedev

[karlduffy-gamedev]

GreedFall early thoughts

This isn’t a review of GreedFall, because I’ve only just started playing it - I’m about 12 hours in and the game is supposed to be 50+ hours long. But I wanted to say something about the game because it’s very good, and I feel it’s been overlooked by a lot of people who would normally be interested in this kind of game. (though to be fair, my opinion may change once I’ve completed the game)

The game was developed by a French studio called Spiders, who has a long history going back many years, but until now their games haven’t interested me. I did play their previous effort, the Technomancer, but I thought it sucked.

GreedFall is an action RPG in the style of older (but not oldest) BioWare games. (think Dragon Age, Mass Effect, Knights of the Old Republic and Jade Empire) It takes place in a fantasy world based closely on the age of colonialism, with a number of European-styled countries having recently discovered a new continent, and the mad dash to claim its resources. Everyone wears stylish coats and tricorn hats, including you. The player takes the role of a diplomat working for an independent merchant republic who is dispatched to the new world, called Teer Fradee, (almost an anagram of Free Trade) and naturally you get caught up in the politics and the affairs of the continent.

The game itself is mostly travelling around Teer Fradee and meeting with various diplomats and governors, which is a lot more interesting than it sounds - a lot of thought has been put into the setting and world, with complex alliances between the various competing nations and the native people of the new world. Most of the quests I’ve done so far have been very interesting - often a quest will have a fairly simple hook, but then the story will branch out in some interesting direction that I didn’t expect. All the quests feel like they’re a natural result of the goings-on of Teer Fradee, with few artificial ones of the “kill ten rats” variety. Even one quest that seemed to boil down to just killing some natives had depth and nuance to it. My only disappointment is that many of the quests didn’t give any options for affecting the outcome - which is strange, because many others offer multiple solutions with radically different outcomes.

The game also has combat, a fair bit of it. Fortunately it’s very good - it has some Dark Souls influence like almost every action RPG these days seems to, but it’s handled well. It does feel janky at times, but the fights are satisfying and when you die, you really feel it was your fault, not the game screwing you over.

And that’s about all I’d like to say about the game for the time being. It’s good. If you like that middle era of BioWare games after Neverwinter Nights but before Mass Effect 2, check it out.

[karlduffy-gamedev]

[karlduffy-gamedev]

When I started working on Super Skeleton Butler in 2018, I had a pretty solid idea of what I wanted the game to be like - a 2D sidescroller mashed up with a tower defense game. In my original design document I had all the weapons, traps and enemies planned out - though many of them changed over time. In retrospect I took the wrong approach - instead of meticulously planning out details like specific traps and enemies, I should have aimed to create the most pure, basic version of the game I could, make it fun, (easier said than done) and then build on it from there.

In 2020, this is the approach I’ll try to take for the future of the game. Rather than trying to build a game out of whole cloth, I’ll hone the basic mechanics of the game - setting traps, protecting the treasure and level layouts - until I have something that has a strong core to it, which I can then build on.

Right now I’m aiming for a tentative release date of Halloween 2020 on Steam. I don’t expect the game to make money, but given the ease of publishing on Steam I might as well go for it.

The current state of the game is as follows; the core mechanics of moving the player, the primary traps and weapons, enemies, and the basic gameplay loop of a stage are complete. The main things I need to focus on going forward are play testing to see if what I have so far is actually fun - something that’s extremely difficult to determine with something you’ve created yourself.

[karlduffy-gamedev]

Post Mortem Unit 7

The end of year project is finally over, and it’s a huge relief. There’s a laundry list of things I would have done differently, which I guess is good because it means I learned something. 

At a basic level I’m just glad the project was completed and I didn’t drop out from a combination of stress and despair. Our group, unlike a few of the others, generally had very good attendance and no dropouts, and the game we made was functional if not extremely polished. Given more time I think we could have developed the core gameplay mechanic more and reached its full potential, but that’s probably true of any project. I’ve become extremely aware of how important time management is when working with strict deadlines.

As a producer I have a lot to learn, though it’s a role I never wanted and will avoid in the future if I can. I got into game development because I want to work on my own projects, doing art, design and code myself, and maybe working with a small number of others, not to be a manager handing out tasks to other people who do the actual work. While I still had a lot to do on the project that was hands-on, like managing the Unity project, sketching out level design and play testing, I feel like the larger the group I’m in the less I’m able to reach my potential. My best work this year was the narrative unit where I was working completely solo, and could lean on my art skills and play to my strengths.

In conclusion, the unit was mostly a success and was useful for me in identifying the aspects of game design I like least - namely managing other people instead of doing the work myself.

[karlduffy-gamedev]

Post Mortem Unit 6

The pre-production unit was by fair the odd one out of the entire year. It fit in this awkward place where it’s technically it’s own unit, but the following one continues directly from where it left off. It also included a good chunk of actual production rather than strictly being pre-production - the Alpha build was due at the very end.

Meeting my team was fun, everyone more or less got along great and we were mostly on the same page about the kind of game we wanted to make. I think the idea we ultimately settled on has potential.

I would have appreciated being given more time to discuss and nail down our basic idea for the game, as it felt quite rushed and we struggled to come up with a good concept after our initial idea was rejected. If the unit had been structured so that the entire thing was pre-production and actual production was in unit 7, this may have been better - however that would have left less time for actual production so I’m not sure which would turn out better.

One of my biggest hurdles as producer was keeping track of everyone’s tasks and making sure everyone was on the same page as far as what everyone was doing. If I find myself in a producer role in the future, this is definitely something I want to work on and make sure that there’s no ambiguity about the number of tasks that need to be completed, as well as who is assigned to them and approximately how long they will take.

In conclusion, the structure of the unit was a bit strange and I would have liked more time to work on the actual pre-production component so we could hit the ground running in the production proper, but it wasn’t too bad.

[karlduffy-gamedev]

[karlduffy-gamedev]

Playtesting Post-Mortem

The playtesting unit was the smallest so far, lasting only three weeks instead of the usual six. The brisk pace meant it was over in a flash, but there was a lot of cool stuff crammed into those weeks. The highlight was getting to playtest games in development, both at AIE and at a studio.

The bulk of the unit consisted of testing a specific game, assigned to each of us. My game, Avion, was an interesting kind of flying sim where the player does not directly control their plane, but rather moves a crate around on top which weighs down different parts of the plane, tiling it in different directions. It’s a simple but quite clever design that I could see turned into a fully fleshed out game. (the version I played was a prototype, with only one stage) By its nature the game was pretty polished and free of issues, though I did discover a few minor glitches (mainly missing textures and colliders in some places) and some more amusing ones, such as a bug that caused the plan to get permanently wedged between some rocks.

Outside of playtesting Avion, we also collaborated with the Incubation program students - which I can’t say anything more about as I had to sign an NDA agreement. Very hush-hush!

I’ll admit I did find this unit less interesting than the previous two, as it didn’t involve a creative aspect. Play testing is obviously a critical part of game development, so this is another weakness of mine I need to work on. I’ve certainly struggled with my own projects when it comes to getting playtesting done and getting good feedback.

[karlduffy-gamedev]

Narrative Post-Mortem

The narrative unit was pretty similar to the programming unit, just with a shift in focus. Instead of being mainly about the coding aspect, it’s about the story/character aspect. This was far more up my alley, as the narrative aspect of making games is something I really enjoy, and this unit allowed us to go nuts with story and character stuff.

My game was called Radiant Heart, and it followed the story of a young girl returning to her childhood home after a nuclear war. I originally envisioned the game as a point and click adventure, and the girl would explore the town and slowly the player would learn exactly what happened. However, I thought this would be too complex, so I opted for a simple 2D side scroller where the story would be told entirely by the background visuals, rather than by interacting with and talking to various characters.

The idea morphed again into something more like a top-down Zelda game, but without the interactive components of that series. The player could freely explore in four directions, albeit limited by barriers that funnel the player down a particular path. This also meant the game would now be fully 3D, though still with 2D sprites - I took inspiration from Mario Party and particularly Octopath Traveler for this look, and I think it turned out really well. At this point I was sure the game had a pretty good atmosphere, it was just a matter of conveying the narrative I intended to. I did this through the use of static environmental objects, and I’m happy with how it turned out - even if it wasn’t completely clear what had happened, everyone who played understood that something very bad had happened to this girl’s town.

In the end, although the game seriously lacks interactivity and active events such as moving characters, I think I succeeded in playing to my strengths and delivered a pretty cool little slice of a game.

[karlduffy-gamedev]

Programming Post-Mortem

The programming unit was a big change from the previous one, as we would not only be working solo rather than in groups, but would be responsible for writing our own code. We’re not real programmers, of course, so we weren’t expected to write amazing scripts - just functional ones that allow us to make a simple prototype for a game concept. Since code isn’t my strong point at all, (I have some practice with GML in Game Maker Studio, which is basically Baby’s First Programming Language) I went with something super simple - a vertical shoot ‘em up/Space Invaders hybrid, with a colour swap mechanic similar to Ikaruga.

Originally the idea was to have a complex system where different colours would counter each other, like a rock paper scissors system - Red, Green and Blue. I also toyed with the idea of having colour blending, so shooting a red enemy with a blue projectile would turn them purple, and give some special effect - I vetoed that idea pretty quickly as I was already brushing up on my (theoretical) limits with C#. Ultimately what I went with was a simple “match the colour” system - shoot green bullets to destroy green enemies, red to red and so on. Again similar to Ikaruga, shooting an enemy with the wrong colour type would cause them to shoot back at you.

Another thing I wanted to include, but had to be cut for time, was varying enemy types. In my design document, I wanted four different kinds of enemies, each of which would be visually different and behave differently. In retrospect I should have known this would be too complex for my level of programming knowledge, and that it would take too long - ultimately, all enemies had very simple movement where they simply scroll downwards without moving or shooting. (except when shot at with the wrong projectile by the player)

Although it wasn’t an important part of the unit, I was pretty happy with how the game turned out visually - a nebula space background combined with simple Space Invaders-like alien ships to shoot. My original idea was a fully 2D game with pixel art, but Unity isn’t really built for good looking pixel art graphics out-of-the-box, and it wasn’t worth the time investment needed.

It was a great opportunity to work solo on this project. Although it was great working in groups on previous units, I do feel I excel when I don’t have to worry about managing other team members and co-ordinating tasks. This is definitely a weakness of mine as a designer that I recognize, however, and something that I want to improve upon moving forward.

[karlduffy-gamedev]

Paracosm Post-Mortem (Kinda)

I started working on Paracosm in late 2015. It was the first time I’d seriously tried to make a game with the intention of releasing it, rather than just a small hobby project with no real ambitions. Going into it, I had no idea what I was getting into and bit off way more than I could chew by trying to make a huge RPG, even as I (at the time) thought I was setting my sights low enough to make something I could finish.

The big inspiration for the game was Earthbound (and the rest of the Mother series) and I tried to replicate the art style as closely as I could, including the perspective (called an oblique projection) and style of the characters. It was also one of my first attempts at doing pixel art, so I figured trying to copy the style of a game I liked (without outright copying specific images and sprites) was a good way to learn. 

Selecting the engine to use for the game was another consideration. Being a total beginner, I had no programming experience at all so I knew I’d have to use a program that did a lot of the heavy lifting for me. At first I considered the latest version of RPG Maker (RPG Maker MV at the time) as I had some experience making small projects in the past with earlier versions. Unfortunately, MV wasn’t suitable as there were several features I wanted that it wasn’t capable of, at least without extremely heavy scripting in the engine’s own proprietary scripting language.

The first was the movement of the player, which by default is done on a grid. I wanted free movement pixel-by-pixel, as grid movement like in the old Final Fantasy games feels clunky and restrictive. The second was the perspective, which MV wasn’t capable of. Both of these were dealbreakers, so I had to look elsewhere for a more suitable program.

Ultimately I settled on Game Maker Studio, which is generic and versatile enough to make the kind of game I wanted. Originally I had planned to have first-person, turn-based battles, again similar to Earthbound, but decided this would be too derivative and opted for a system similar to Zelda II: The Adventure of Link, with top-down exploration, switching to side-view platformer battles when encountering enemies on the overworld.

Ultimately, the game proved to be more work than I could deliver. I was handling the graphics, design and coding all myself, with any of those being an endeavor all of its own. While I still want to return to it in the future, it’s been put on the backburner for the time being while I focus on schoolwork and smaller, less ambitious projects.

Most of what I learned about making pixel art, I learned while working on Paracosm. Actually, most of everything I know about making games I learned by working on Paracosm, so I don’t consider it wasted time even if I didn’t deliver a finished game.

[karlduffy-gamedev]

Super Skeleton Butler Development

I started working seriously on Super Skeleton Butler around mid-2018. Before then I’d done some mockups for graphics and had been toying with the idea of a side scrolling tower defense game and how it would work, but nothing concrete.

The game is pretty closely based on other tower defense games, specifically Cursed Treasure, Dungeon Defenders and Orcs Must Die! The latter two games have the innovation of letting the player directly control a character, moving freely around the dungeon to place towers/traps and fight enemies themselves. This combination of strategy and action interested me, but the real impetus for me wanting to make my own tower defense game in a similar style was the release of Orcs Must Die! Unchained. Not because I liked the game - I never actually played it. OMD Unchained is a free-to-play game focused on multiplayer, unlike the previous entries in the series. The first OMD was a single player only game, while its sequel, OMD2, added a co-op option. While this was a welcome addition, it also meant that most maps in the game were designed around having two players, making it less engaging to play in single player mode. With each entry in the series, OMD moved further away from what I enjoyed about the original.

I tried to avoid a lot of mistakes I made with my previous project, Paracosm. I wanted to get maximum bang for my buck when it came to the game’s assets, so I designed and made a versatile tileset which I could use to create a large number of radically different levels using the same basic building blocks. This is also how I approached the enemy design - by making the invaders all humans with different equipment, I could use the same basic sprite and animation for all enemies. This would allow me to create a lot of content for the game without going crazy on asset creation, which was a big problem when working on Paracosm.

I am very happy with how the prototype is shaping up, even if it has taken a long time. Visually I think the game looks great, the bright pixel art graphics and sprites make it easy to discern enemy types and the different traps and weapons. Gameplay wise I think it has a decent foundation, but still needs more playtesting and refinement.

[karlduffy-gamedev]

You Think You Do, And You Do

Last week, World of Warcraft Classic was finally launched on the 27th of August. For those not in the know, WoW Classic is a re-creation of the massively-multiplayer online role-playing game, World of Warcraft, as it existed when it was released back in 2004 - or as reasonably close as Blizzard Entertainment could make it. The modern WoW has 6 expansion packs under its belt, the latest being Battle for Azeroth, and the game has changed significantly in the 15 years since its original release.

So why talk about this old game getting a second go? The MMORPG genre is largely stagnant right now, with the big players being Elder Scrolls Online, Final Fantasy XIV and World of Warcraft itself. Many developers launched their own MMOs in the wake of WoW’s success, trying to copy its format of a theme park MMO, and most failed miserably. The history of the genre is littered with the remains of dead games that tried to challenge WoW’s dominance of the market. The ones that didn’t shut down outright were retooled into free-to-play games, like Lord of the Rings Online and Star Wars: The Old Republic. It became a running joke in the MMO community to say that the only thing that could kill World of Warcraft is World of Warcraft. In a way, that’s finally happened. After the release of its third expansion, Cataclysm, WoW experienced its first ever subscriber loss since launch - up until that point it had steadily gained new players during every month of its existence, peaking at about 11 million.

Anyway, long story short, a lot of people disliked the direction the game took with its expansions, particularly Cataclysm onwards. Quality of life changes, such as the Dungeon Finder, a system for automatically grouping players together for instanced dungeon challenges, hurt the game’s sense of community. Players no longer had to worry about their reputation on their server or forming bonds with the players they encounter, since so much of that became automated by the game’s systems. Private servers, unofficial game servers not endorsed by Blizzard, became popular among players who wanted to return to earlier expansions like Burning Crusade and Wrath of the Lich King, or even the original, un-expanded game itself.

All of this brings us to the present. I’ve been playing WoW Classic with some friends over the past week, and we’ve had an absolute blast. It’s tough, slow and difficult, but satisfying in a way that the later expansions aren’t. The game doesn’t hold your hand and shower you with epic loot, like the retail game does - getting a rare item means something. Grouping with players feels much better as well. The game is radically better when all of the gradual QoL changes added over the life of the game are removed. Gear matters. Grouping is important. Your rep on a server affects how other players treat you. This is a real MMO, not the glorified waiting room that most modern MMOs are. Maybe now that Classic WoW has reminded everyone, the genre can see some fresh blood in the future that stays true to its roots.

[karlduffy-gamedev]

Not Every Game Needs an Easy Mode

Not every game needs an easy mode. Recently there's been a lot of debate around the latest From Software title, Sekiro: Shadows Die Twice. Like clockwork, every time a new From game is released, demands appear for an easy mode. This was the case with every game except for maybe Demon's Souls, since the Souls series (or genre) hadn't yet achieved the level of pop culture saturation it enjoys now. This latest demand will be met with the same silence as all the others, and that's a good thing.

Sekiro: Shadows Die Twice

Not all games need an easy mode. That's not to say that difficulty modes are automatically a bad thing. Many games benefit from selectable difficulty levels, such as the Devil May Cry series and similar beat 'em up games (Bayonetta, Metal Gear Rising) use unlockable difficulty modes to extend replayability and offer greater challenges beyond the baseline experience. However, From Software’s Souls-like games (Demon’s Souls, Dark Souls I-III, Bloodborne and now Sekiro: Shadows Die Twice) and the titles inspired by them (Lords of the Fallen, the Surge, Nioh) are built around a baseline experience that every player must suffer through and endure. The sense of comradery from facing the same challenges as all other players is shown by the ghosting images of other players, which fade in and out of sight. We’re all in this together.

These games also have tools available to the player to make the experience easier, if the player so wishes, they just don’t take the form of a selectable easy mode on the main menu. Items, spells and upgrades for weapons and gear can all be used to make challenges more manageable. The player also has the option to summon help in the form of other players or NPCs for difficult boss fights or making progress through a difficult area. (though Sekiro, being a strictly single-player title, lacks this feature)

Bloodborne

Thematically, the difficulty of Souls-like games is important to their story as well. The sense of dread and hopelessness would be undermined if the player could just breeze through the game with little difficulty on a first attempt. Suddenly the maddening despair expressed by the characters would feel less impactful. Souls-like games are not difficult just for the sake of it - it’s weaved intimately into the entire experience, and subtracting the challenge undermines the whole.

There’s also the question of the games’ target audience. Not every game should appeal to every person, and trying to please everyone usually results in pleasing nobody. The difficulty is so core to the identity of Souls-like games that asking for an easy mode is like going to a Chinese restaurant and asking for a pizza. It’s not that pizza is bad, you’ve just come to the wrong place for it.

Demon’s Souls

The original Souls-like game, Demon’s Souls, was not very successful critically or commercially, but attained cult status by positive word of mouth, leading to the more successful Dark Souls, which has gone on to become one of the most successful gaming franchises in recent memory. Would Souls-like games have reached this level of acclaim had Demon’s Souls had an easy mode, allowing players to trivialise the challenge? Would the Dark Souls series even exist? Of course, there’s no way to know, but what we do know is that the difficulty of these games is a large part of their appeal. Taking that away can only detract from the experience.

[karlduffy-gamedev]

It’s Over

Unit 2 is officially over, and if I ever see another duck it will be too soon.

Although I’m happy with the work we did and I think our team worked well together, there’s a laundry list of things I’d do differently if we started over.

Our group did have some issues with communication - in the future I would try to engage the rest of the team more frequently and stay in more frequent contact outside of class, so everyone is up to speed on what everyone else is doing. Discord was useful for this.

One problem we ran into was use of tools. We had a number of issues with Tortoise SVN/GitHub, at one point requiring us to more or less rebuild the project from scratch. The lesson I took away from this is that it’s very important to become familiar with the tools we’re working with, make sure everyone in the team is on the same page when it comes to their operation, and making redundant backups of everything in case of problems.

When it came to asset creation, in retrospect I focused too much on small details and minor touches, (such as posters and other doodads that added to the detail of the stage, while not being critical) while neglecting the less interesting but more structurally important assets such as buildings, floors, supports and other large objects. In the future I will try to correct this by squaring away the most important things first and saving smaller details for later, and having a clear list of priorities so there’s no confusion over which assets are most important.

Much of our play testing was left to the last minute as an afterthought, and there were a few lingering issues that weren’t resolved before final submission. In the future I would plan to have the bulk of the actual work complete ahead of the deadline, so there’s sufficient time for testing to spot bugs, errors or any other issues before submitting the project.

Working on a level for Mother Duck was interesting. The unique “cloning” mechanic of the game, where previous echoes of the player-controlled ducks move around the stage during subsequent rounds was confusing at first, and I would have done more play testing to get a stronger grasp of how this affects gameplay.

In conclusion, the unit was a fun and interesting experience, and gave me a good idea of working in groups and coordinating tasks with others.

[karlduffy-gamedev]

AIE Unit 1 Post-Mortem

First unit is finally over at AIE, and it’s time to move on from generalized introductory stuff to more specific areas of game design. Next, level design.

Board game design - the crash course in board game design at the beginning of the unit was an excellent “hands-on” course in the basics of game design. Working with board games forced me to consider mechanics above almost everything else, as prototyping (using plain tokens and paper) didn’t allow for flowery setting and character designs, so the mechanics are the main focus.

Working in groups was a good experience, getting a different range of opinions and perspectives on different games, genres and aspects of design was refreshing, coming from someone who has mostly worked on my own on personal projects.

Getting feedback on my own work was interesting as I don’t usually seek it out for my own projects, though this was also mildly ego-crushing.

When it came to working on the Game Design Document, I think I did well when it comes to showing mechanics with visual guides, as well as clearly communicating the kind of game I wanted to make as well as the inspirations and sources it draws from. However, I struggled when it came to defining things like the game’s loops, and keeping information clear, readable and in the correct order.

All my work on personal game projects has been in 2D using Game Maker Studio, so I struggled with adapting to 3D in Unity. There’s always a learning curve when starting out with a new program or piece of software.

Overall the first unit at AIE was an excellent introduction and crash course in game design and I’m eagerly looking forward to the upcoming units, working on larger and more serious projects, and honing my skills.

[karlduffy-gamedev]

Die By the Sword Analysis

Die By the Sword is a real-time, 3D, third-person action game based around medieval combat and sword fighting. The player controls a fighter of their choice, using a variety of medieval weaponry such as swords and axes, and pits the player against various opponents in brutal duels.

The game’s main innovation is its dynamic weapon movement system, allowing the player swing their weapon in any direction, and at almost any speed, using either numkeys or mouse control. This is a significant innovation over traditional controls using canned animations, where the player is limited to using pre-defined attacks, although it does come at the cost of a much steeper learning curve. However, this system gives incredible freedom to the player, allowing them to perform feints, parries, ripostes, and a variety of other real-world sword fighting techniques. Furthermore, the game also includes a limb dismemberment system, interacting with the dynamic fighting system to allow limbs to be severed at any point. For example, a sword-swing that connected at the wrist would chop the hand of the enemy fighter, while leaving the rest of the limb intact. Fighters with a missing leg would hop around on one foot, which while amusing usually means game over for that player.

The game is primarily built around these two systems, and the levels themselves consist of small arenas with hazards such as spike traps and pitfalls designed for duels. 1v1 duels are possible, but up to 4 players can fight eachother in a free-for-all bloodbath, or in teams. If there aren’t enough human players, AI opponents can also be selected.

Die By the Sword also includes adventure modules, which are quests such as rescuing a loved one from a cave filled with monsters. However, these are short in duration and clearly not the main focus of the game, which is the competitive duels.

Die By the Sword didn’t leave much of an enduring legacy, as the unconventional control scheme proved to be a dead end of game design. The game did receive an expansion pack, Limb From Limb, but no sequel. The idea of fully-controllable sword fighting would later be explored in games like Red Steel and Wii Sports+ (which included a toy sword fighting mode) once the technology had reached the point of making it viable. These games too, however, would prove to be dead ends as Red Steel recieved one disappointing sequel and the sword fighting mode in Wii Sports+ received no followup at all. Once the fad of motion controls had passed, the idea faded into obscurity.

Die By the Sword is an interesting experiment, though not a fully successful one. While the dynamic sword fighting and dismemberment systems are innovative, the playability of the game suffers as the controls often feel cumbersome and unresponsive. Still, the game is fun to play just for its novelty and the high skill ceiling means the game has a lot of longevity if the player is willing to see past the control issues.

[karlduffy-gamedev]

Exploring town.