Text
A Small Update
It’s been a while since the last update, apologies for that.
A number of things have slid to the wayside while I’m working on a number of personal things, so today will be a short post to more or less say that I am alive.
I *will* however leave a small tease of what I’m currently working on, which is a new RPG setting and rulebook for sci-fi desert combat.
The finished project will likely be similar to my earlier Byre Malis project which can be found in my design portfolio section.
I intend to post more about the setting and rules after the new year, on which note, have a wonderful winter season everyone!
0 notes
Text
Symbiotic: Personal Postmortem
In all the collected notes and dev blogs on Symbiotic things have probably gotten a little scattered so I’ll start off with an overview of what the game actually is.
Symbiotic is a roguelite first person shooter in which the player must defeat aliens in a progression of compact arenas, with a miniboss and eventually a final boss at the end of each sequence of arenas. After the player defeats a certain number of enemies (determined by difficulty setting, and how many enemies they have already defeated) they unlock a choice of two upgrades for their gun. These upgrades can be something simple along the lines of more damage or a faster fire rate, or they can be more complex such as exploding shots, more bullets per shot, or shots creating damaging acid pools beneath the enemies they hit.
In addition to these unlocked upgrades, the player can also find one of two active upgrades in various spots in the arenas. These active upgrades are a grappling hook that can grapple the player to a targeted surface, and a black hole launcher that draws enemies in to a black hole.
There are three basic enemies, the swiper, crawler, and flyer. The swiper runs at the player and ‘swipes’ at them with a basic melee attack. The Crawler explodes when shot or suicide bombs the player if it gets close enough. Finally the flyer flies over the player and shoots at them from above. The two minibosses are bigger versions of the crawler and flyer, the crawler boss spawns normal crawlers when it dies and the flyer boss has a more powerful attack and an arena that requires the player to constantly chase after the high ground. The final boss uses a lot of different attacks but maintains a charge moveset that is reminiscent of the swiper.
Once the player has defeated each miniboss and the final boss, they can loop around again or end their run and return to the main menu.
The game has a steam page here: https://store.steampowered.com/app/1953760/Symbiotic/
In terms of what went right, Symbiotic is a playable game with a start and an end, it has a well formulated core loop, and the systems and mechanics are polished and mesh together to create a solid core of a game.
To skim what went wrong, there were a lot of ideas that were had too late into development, or had early and then forgotten until it was too late, that meant a lot of polishing on side mechanics didn’t get done and some things that should have been in the game got left behind. This is not a particularly profound thing to happen in game development, but it’s still worth mentioning.
To highlight what went right and wrong I will examine more closely, three aspects of Symbiotic.
Aspect 1: Story
As a narrative designer, I was onboarded to take what story the game had, and refine it into a larger and more cohesive experience.
Arguably Symbiotic came out with less story in the final build, than it had in the vertical slice. However, it came out with more refined story that helped build the core game loop.
The voiceover that would play during certain events in gameplay is no longer in the final core game. It was generally decided that the tone was too light and the experience we wanted to deliver with the game was more bleak in terms of story. However, we did get in codex descriptions of each possible upgrade, which are displayed during a pause menu the player can use to read up on the specifics of a given upgrade.
Additionally a lot of narrative work was done behind the scenes to ensure assets and mechanical choices were made to keep a consistent world behind the scenes, even if the player only gets brief glimpses of that world through what they see in the player character’s actions. The world of Symbiotic is mysterious, and that further feeds into the desperation of their character to escape the hostile alien world they find themselves on.
Aspect 2: UI
As we neared our deadline, a decision was made to reorganize some of the team members to fill alternate roles, one of which being my switch from narrative design to UI design for the final few sprints. This meant that for the final few weeks, I was mostly creating, iterating, and implementing UI assets. For the most part this actually went very well. However, towards the very end of this, much of the team decided they disliked the more minimalistic art style I was working with, and preferred the more detailed and intricate art made by one of the teams’ artists.
This meant that within a rather short window said artist had to make a lot of wholly new assets. While I definitely agree that their art turned out better than mine (I’m a designer, not an artist after all), this flipflopping close to our final deadline led to a lot of extra work being done where those hours could have been put into other areas, such as narrative or our next topic, AI.
Aspect 3: Enemy AI
This is one area that I had very little to do with, I was a narrative and later UI designer, so while I definitely worked with our gameplay designers and AI programmers, I wasn’t in the direct line of creating or polishing many of these systems.
Because of this, what I have to say is essentially limited to the fact that a good chunk of time in development was spent trying to implement AI behaviors that were ultimately cut, which resulted in the final AI behaviors of the ‘swiper’ enemy in particular being less than ideal. It is common rather than uncommon, to see said enemy stuck on platforms and other terrain features, whereas the crawler and flyer enemies do not seem to have this issue.
All three of these examples show that while the game works at a surface level, there were multiple cases of multiple members of the dev team being sidetracked with content that went ultimately nowhere in addition to having to be redone.
Again, this isn’t exactly new to game development, and that I am being critical here. Overall the game came out wonderfully for a Champlain studio project, and these are just the few things I can point out in a postmortem. There were no major interpersonal issues or anything adjacent to them.
As a developer this project has given me what I would consider my first wholistic dev experience, as many game studio games never get past the vertical slice stage, and those that do, are solo projects which are of such a small scope to begin with that the difference is minimal. I’ve been forced to fill differing team roles as needs changed, and I’ve worked on a game that ended up on Steam. I think that as a game project to end my Champlain experience on, I couldn’t have had a better one.
1 note
·
View note
Text
Symbiotic, Final Stretch
So, it’s been a while since the last update on this game. Overall we’re in a very good spot, we’ve gotten everything we wanted in and now it’s just a matter of polishing and bughunting until we hit our final deadline.
For testing the game out we’re setting up a steam and itch page for the team/game specifically that I’ll link to on this dev blog once it’s fully setup.
Since last time we’ve gotten much of the codex in the game itself
by pressing tab the player can bring up a screen showing all the upgrades they currently have and by mousing over a given upgrade the player can see the description and lore tidbit for every possible upgrade.
As a corollary to this, I’ve ended up acting as a UI designer moreso than a narrative one the past few sprints, this is a good reminder that as much as I style myself as a narrative designer, I really do try to be as generalist as possible so I can fill differing team roles.
One of the main things I’ve been working on has been new HUD assets, shown here is the new health, (the white bar), experience (an orange bar that appears in the empty space beneath it), and currently equipped active upgrade, that would be the empty square to the left of it.
Pictured above is a test version with a placeholder image for the active ability.
Another thing I worked on was a new damage overlay, pictured above. The old overlay, pictured below, was a lot less saturated but also reached far into the player’s field of view, which meant that not only was it less clear when it happened, but also would obscure some details of the screen.
Another new asset is the addition of a new upgrade top bar, rather than the stretched cube with rounded corners we’d had previously.
Finally, a new health bar for the final boss, with clearly delineated segments for each of the boss’ stages.
Overall, this has given me an opportunity to get back into asset creation and implementation that I usually reserve for solo projects where I’m working without artists. Additionally, the specifics of each piece of UI/the HUD allows me to push the narrative aspects of the game in little things, such as the interplay of technological and biological elements of the HUD for the player character, and then the much more geometric health bar for the boss. This helps build the distinction between the player (a combination of a human soldier and symbiote) and the enemies (crystalline structures and the planet itself tied together through symbiotic organisms).
1 note
·
View note
Text
Blackwood Itch
Just a heads up!
The first two Blackwoods interactive novellas, the Grensweald Girl and House on Halfway St., are now available on my new itch.io page.
Check them out in my design portfolio, or on my itch page here: https://alataii.itch.io/
0 notes
Text
Game Studio 3, Dev Blog 2
Ok, midterms for Symbiotic, let’s go:
On one hand, the team has made some decently large leaps forward in terms of content, aesthetics, and general design process, on the other, there were some hurdles of varying size that have detracted from our ability to work on the game in some ways.
To start with the negative there are two main issues the team ran into these last few sprints. The first is that of communication and documentation, with an influx of new people, myself included, there’s been a lot of changes in design choices made by the original team to expand in scope or change aspects of the game they were less keen on now that there are more developers to throw at the problem. This led to the team adding or changing several features and then removing some of them when the team found out we preferred the originals.
Our solution to this leads us to the first of several positives of the last two sprints. The team began sitting down and having serious, honest, and direct conversations about what features were in the game, what features we wanted in the game, and how they related to the intended player/play experience. These conversations were exceedingly helpful in focusing our development, and so far it seems that they will be very helpful going forward. Now, this isn’t to say we hadn’t been having these conversations previously, but to the time dedicated to them and the number of team members able to attend, these have been much bigger meetings. (scheduling a single class’ schedule around 16 college students with work and other classes is hard).
Now, we are on to the second pair of interlinked positives and negatives, stability
With the added and changed features, even the ones we were happy with, a lot of things were added to different branches of the build these last few sprints. Unfortunately, when these were merged for testing, several things broke.
Now, this issue is less within my sphere on the team, but it still affected the team’s work, meaning it was much harder to work on getting the narrative into the game if the game wasn’t functional in the first place.
This leads us for the final set of musings for today, me
Where do I as the narrative designer, and not a team lead, fit into these development changes?
As I said above for build issues, that is less my sphere than it is others, and so while it did affect my ability to get stuff in the game, it didn’t completely hamper my progress. What did though, was the ongoing design/development discussions. These questions of player value and intended experience really allowed me to work with the rest of the team on how we want the narrative to function within the game and get players involved with the gameplay. Particularly through sound, narration, and enemy/level design, all aspects which are being looked over for maximum player impact in the coming sprints.
0 notes
Text
Game Studio 3, Dev Blog 1
Alright, first dev blog with the new team, let’s do this.
As a brief introduction, Symbiotic is a first person roguelike in which the player has a symbiotic gun attached to their arm, and must defeat waves of aliens while upgrading the gun with one of two evolutions earned after killing a number of enemies.
When early team recruitment came up, I actually talked to the lead designer, Gavin-
(third from the right)
-about joining the team as a narrative designer, but at that time the response I got was that they didn’t really want/need one. However, apparently asking that question got them thinking about it as a team, and so now here I am, second from the top left:
The main challenge writing for/with this team was that they wanted a narrative to expand over the excuse plot they had, so called because it was little more than an excuse for why the player was there. However, the major aspects of the game were already set.
To approach the issue I drafted up a number of narrative elements/concepts as to what the preferred story would be, and how that could be done in game. The team went over these and we came to an agreement on what the story would be and how we would convey it.
To set the stage, the original plot was as follows. The player is dropped off on a seemingly barren planet, they are being used as a test subject by the Zertemic corporation, and must use their gun as part of a test. The alien enemies are a biomechanical security system of an alien race that used to live on the planet before they left or went extinct. The problem with this plot is that it is very surface level and not very original. Additionally it leaves less depth for art and other venues of story telling within the game itself. The original team themselves agreed to such and this was a good chunk of their reasoning for recruiting me.
The new/current story is that the player was being transported in a Zertemic spaceship that happened to crash on the planet, and upon entering the atmosphere let along exploring the surface realized that the planet was swarming with teeming and single-minded life, hellbent on killing them. The symbiote that attaches itself to the player is more or less the same species as the symbiote that has taken over the planet in its entirety, and is using you as a tool to kill the planet symbiote so it can grow and expand in its place.
This allows us to use all of the previous aspects and many of the same voice lines (biomechanical planet, corporate starship/involvement) while introducing new depth and originality in the execution of the story.
So far the execution of this new story is threefold. First, a spreadsheet of codex entries, to be made available in game, that cover each upgrade, enemy, level, and more miscellaneous game elements. Second, a new list of barks and voice lines for characters within the game. These lines play out at randomly triggered and scripted points during gameplay that both tell the player what to do and give context on to where they are/what happened. Finally, I’ve been able to work with the artists and designers in the implementation of new enemy types and how they appear. Using a mixture of organic and geologic forms, we as a team are working to create the fusion of animal and planet itself that the enemy forces are made up of.
All in all my integration to the team is all well and good, and working on the narrative for the team is an exciting experience. Working within the constraints of what has already been made has allowed me to write an engaging narrative that works with the game... symbiotically (sorry I couldn’t resist the joke).
0 notes
Text
Blackwoods: Interactive Narrative
https://drive.google.com/drive/folders/1VK2SVauZVFlx7SH5Ignt3xlGKEmrh5Yk?usp=sharing
Just some twine exports.
0 notes
Text
MTC Postmortem Part 2, Team Recruitment Boogaloo
Apparently the last reflection was the reflection *before* the postmortem, not the actual post mortem.
So, in light of my erroneous reading skills I am officially declaring this reflection postmortem part 2, recruitment edition. Additionally, now that the MTC team has been given the official feedback on why our game was cut, I have that to go off of for a *final* final reflection on the game.
Let us start with the feedback.
To get to the point as quickly as possible, the feedback was that the game, while interesting, wasn’t as far along as other games. This makes sense to me, due to the aforementioned death curse our team was experiencing (there were a total of three out of eleven weeks where we had everyone present and healthy), and a few weeks lost to exploring alternate options for the main combat system when turn based hex grids were taking too long.
On one hand, this confirms my earlier reflections and allows me to leave the project behind mostly in peace, as the game just needed more dev time and we were unable to do that mostly due to circumstances out of our control.
On the other hand, a part of me is annoyed that the issues were dev time (which we could have done more of next semester) and not conceptual. If I or other team members had worked just a little harder to make up for the lost time, if burnout had been pushed through with a little bit more vim and vigor... well, you get the idea. What if? will be the question that follows me about this game if I allow it to.
Anyway, recruitment.
As of the writing of this reflection it has been 21 hours since the recruitment meeting ended and while we were never given a concrete timeframe on when to expect answers to what teams we get placed on, I was certainly under the assumption that it would be the same night or early morning the next day.
While I do understand the reasoning behind being absolutely certain about recruitment, and potential errant factors that make that process take longer do exist, I am also definitely feeling the mounting stress.
Regardless, I still look forward to working on many of my potential future teams.
0 notes
Text
More Than Comrades Reflection: Postmortem
Much like Gaul, this reflection is divided into three parts.
Part 1: The Project
So,
first and foremost for our team, out of seven people, only two got through the semester without having at least one week taken up by a family/personal problem or hospital visit. Overall, I am proud of the team and the work we’ve done, especially through all the setbacks we had. However, I will wonder what me might’ve accomplished had we not lost several weeks to medical mishaps.
youtube
Above is the final trailer for More Than Comrades, from the bits of gameplay in the trailer, while everything we’d intended in our minimum viable product is there, some of the polish is lacking from what I would’ve been truly content with turning in. Especially on the gameplay side. RTSs are not currently as popular as they once were, and with our “en media res” approach to get right to the action, the game itself is confusing at first, especially if the player skips the instruction page, which serves as a temporary tutorial.
As I said above, the project could have used some further work, but from what we had to work with, I think it came out alright, even if that isn’t as evident or entertaining as we’d hoped it would be to modern a player base.
Part 2: Presentation & Demo
This part is likely to be the shortest. The night of the presentation went well enough, the order randomizer put us in the first third of teams but not the first team, which I prefer as a presentation slot. The actual presentation had two main issues, that being that we hadn’t gotten to testing the presentation equipment beforehand, and we took about 30 seconds on stage to get it working when the provided clicker for our slides didn’t function, and then the speakers were cut off at one or two slides by the person with the clicker, which had happened a few times in practice and I’d hoped to avoid it this time around. This I chalk up to nerves on the night of the presentation but regardless, I’m still a little disappointed that it happened.
As for the demo the night after...
the monitors in the Game Studio labs are frankly massive, and so our first tester of the evening got to experience the game on improper display settings, which cut off most of the UI. Luckily, the problem was solved by changing the settings for text size and resolution scaling, which fixed it for all subsequent testers.
Part 3: Future
More Than Comrades did not go through.
Honestly I understand why, for many of the above mentioned reasons in particular, though I have been told it’s the first game brought to capstone that was a dating sim, so that’s fun.
Of the games that did go through (there are seven), four of them I truly understand and agree with. One of them would not have been my choice but I comprehend why it was among the games that went through. Finally there are two among them that I assume are due to differing opinions on game design between myself and the studio members that were responsible for the decision. I’ve already made initial talks with three teams among the four I’m most enthusiastic about, all of them strong games that I know want/need a narrative designer.
Hopefully next semester I can come back with more reflections or dev diaries from one of these teams.
0 notes
Text
Capstone Reflection #4
An important part of any game’s life cycle is testing.
The testing pool at Champlain College definite has its preferences. Students tend to enjoy “cute” games and couch co-op games. Action and other fast paced games also tend to do well. Look at the success of past example like Frog Bath for this.
So of course More Than Comrades being a grim, slow paced, strategy game with story elements means that less people in our test pool are likely to “get” the gameplay right off the bat. And this is reflected to our test responses to a certain degree.
However, our strong LGBT+ themes and “anime-esque” art style has certainly endeared it to a certain portion of the testers.
We were also able to make our game significantly more approachable to a less RTS oriented player base, compare the results of the question “how well were you able to understand the UI/HUD” over three weeks worth of testing.
Of course, we also got our share of either deliberate trolls or people too far lost in the sauce to give usable feedback:
the above response is from a question asking for what the tester could guess of the setting based on context clues from the character dialogue, it is certainly an interpretation.
Overall our test data over the last five or so weeks shows that we have made slow but steady improvements in terms of giving strategic gameplay to people who don’t necessarily play strategic games. This also isn’t all due to repeated testers as nearly every week, the percentage of “yes” responses to the question “have you played MTC in a test before?” has hovered around 20%.
In terms of art we certainly seem to have conveyed the right message of “grim eastern European warzone”, yet we have yet to shake the idea that the enemies in the game are something other than dinosaurs. Though this is close enough to the point that squabbling over it currently shouldn’t be too high priority of an issue. The majority of the testers seem to accurately get the idea of “expedition to a strange place in alternate history Europe” through the context provided in character dialogue.
Overall our game is doing well enough in testing that I don’t worry too much, and what we are picking up on is to really push the player feedback to the highest quality we can before showcase, something we’ve been putting particular effort into this most recent sprint. A takeaway from this project is that even an idea that is a bit out there compared to a playerbase’s usual fair can be made to work for them if the appropriate effort is put in.
0 notes
Text
Capstone Reflection #3
As far as executing on the concept of More Than Comrades, in the past few weeks our team has made a few notable changes. One of which is a switch from turn based combat, to real time.
if we look at the player motivation categories from quantic foundry, we still note strategy and story as our main pillars of design, however with real time we add excitement. Making the player react quickly in response to situations means we are shifting our focus away from slowly mounting dread and anticipation like we might aim to do with turn based, and are now leaning towards constant vigilance and wearing the player down, they should feel worry and anxiety for the characters they are controlling, as a misstep on their part could lead to a gruesome end.
On the side of narrative we have moved our minimum viable product scenes from their prototype versions in twine, into more workable inky scenes that have allowed us to directly integrate the files with unity, as of this most recent sprint cycle we have story in game that meshes with combat. To finish out this sprint the team intends to tie in inky’s tag system so we can have our first instance of the player’s ability to impact combat via the story. The choice the player has so far is between which of two abilities each named character has.
on the topic of characters, we have added further difference and detail to the two named characters that take the spotlight for the minimum viable product, Sasha and Afrodita, it is our intention to make the player associate with the characters (story) in the limited time we have, to allow them to try the different abilities and how they impact combat (strategy), and when they face peril in combat and the story segments we hope to provide excitement for the player in defending them.
Overall we’re going strong as a team and everything we want to be in the game is there. At this point it’s a matter of orienting it as much as we can for player impact and enjoyment by tweaking variables and layouts in unity and making sure everything runs as smoothly as possible. At this point I am fully confident in the team’s ability to present and do well for the capstone showcase
1 note
·
View note
Text
Capstone Design Reflection #2
More than Comrades, an outside perspective.
More than Comrades competes for attention primarily with turn based strategy games like XCom 2 or Phoenix Point, and secondarily with games akin to it that focus on dating and character relationships, such as Fire Emblem. This is a relatively well explored space in terms of games though there is definitely room for new designs. For one, the combat system
This staggered turn system that focuses on overwatch fire rather than direct player action makes positioning much more important. Making sure lines of fire are layered and overlapping where they need to be means that individual soldier turn order matters less but the player’s turn as a whole matters more. Rather than focusing on one or two enemies at a time the enemies are fought as a singular seething horde, individual enemies matter less and the focus is more on covering your angles.
Additionally, from a story perspective the focus on LGBT relationships is, while not new to the industry, still a niche audience that can be accessed
It is for these, and other, reasons, that we are aiming to satisfy and market to players who best fit in the “strategy” and “story” categories in the Quantic Foundry player model
Strategy covers the main gameplay loop, with the player progressing through a mission using their soldiers to defeat enemies and complete objectives. For the story segments that occur during and in-between missions, the players we hope to satisfy are appropriately story motivated players, people who come and stay for the characters and plot. We intend to blend these groups by having the story segments act as an opportunity for the player to upgrade their soldiers and choose courses for upcoming missions, and for the strategic missions to impact story segments through completion or failure of minor and secondary objectives. (another example is that a character may comment on how many enemies they killed in a mission or whether or not they got injured).
Finally, on a more production side of things, we as a team believe More than Comrades has a showcase worthy minimum viable product that can be displayed to the game studio and used for senior production next semester.
The minimum viable product will be a single mission about 30% of the way through the game, in which the team of soldiers (and the player) arrive at the mysterious outpost 13 and enter through the abandoned bunker door. The player will be hounded on all sides by creatures that defy explanation, and seeking the only shelter that exists in the boreal wilderness, they must get inside the outpost and close the door behind them. This mission will show the outside environment that makes up a good section of the game while also having inside elements and the brutalist aesthetic of the bunker that we hope to delve into as we go forward. The gameplay will start offensive (getting to the bunker) and transition to taking defensive positions at the outpost. Finally, we intend to add story segments both introducing the mission, and closing it out with a grim choice as to who holds the line as the doors close, showing how player choices can impact the story.
Obviously this carries some risks of its own, getting players to know a character in a single mission, and making sure the build is at a suitable state. However, with appropriate work and testing put into the game we as a team believe this is doable.
0 notes
Text
Capstone Design Reflection #1
Getting an initial concept with a team is usually an interesting process. It’s the first real time the team goes head to head with itself (in my experience thus far) with any real stakes. You often have different ideas for what kind of game you want to make let alone which idea you want to go for.
(Invincible) -- arguing over game concepts
This increases with the number of people on your team, and the number of people on said team who share roles. If you have multiple designers like I have, you may disagree on aspects of level design, mechanics and systems, and design documentation. Similarly for artists you can get arguments over art style and aesthetic. When concepting games you can also have arguments over what a game concept would entail for work and the above, and it’s all hypothetical.
For my team at least, we had the benefit of knowing the team roster the semester beforehand, this gave us the summer to pitch initial ideas and bounce them off each other. It also gave us a head start when we began to whittle down our list of pitched ideas into a short list of games to concept for in our initial steps of development.
(Shadow of War) -- forging an agreeable game concept
From the start we knew that as a team we wanted to include elements of romance/dating sims and as a result a lot of the pitched game ideas had at minimum, some elements thereof. I myself was less enthused for this specific route and so I did my best to A: pitch non-dating games, and B: pitch dating games that I wouldn’t mind working on. I incorporated elements that I believe work well with dating sim aspects. When the time finally came to choose three to move forward with, our team gauged scope, and other viability factors of each of of our ideas and come down to the required three options. This went fairly smoothly, and I believe this again to be due to our time to mull over these ideas over the summer, and our larger than usual team size made some concepts easier to envision as a capstone project.
After narrowing our sights on three distinct concepts, we split our team into two smaller teams to explore the two concepts we’d worked on least, and gave the third concept, one we’d designated as the most “worked on” over the summer in terms of thought given, time to sit.
(Dramatic Crossroads)
During this time we were able to move faster with smaller “team sizes” which really allowed us to explore what we might be able to do if we had more time to work on each of the concepts. Splitting the team in half also meant there was only one of the role on the minor teams, myself as the designer, and each of the programmers and artists could just go by themselves and not need to worry about coming to an agreement on every detail. This really worked because it let us go at our own pace in discovering the possibilities for these ideas.
(Sprinting Start)
However, at the end of our week long concepting for the two ideas, we went back to our third game and decided it had the best prospects, this decision was unanimous with the team, and I so far believe it to have been the right choice.
So, to reiterate, as a team we were able to balance our individual wants with the team’s wants by A: having the space to work it out over a longer period of time B: splitting up to divide and conquer on smaller ideas, and as a final addition, C: being able to choose our capstone teams in the first place rather than being placed on teams, meaning that we were able to choose team members with similar skills and strengths for what types of games we want to make.
While we still have a ways to go for making this game (hopefully) production ready, I believe we are on track to do that, and that when we do, we will also be prepared to onboard more people and move forward with a cohesive design vision.
0 notes
Text
RTCS Postmortem and Semester Thoughts
Rootin’ Tootin’ Cowboy Shootin’, a project on which I worked as a general designer, and UI/HUD artist. As one of the original members of the team I was also the lead designer and product owner, this had its upsides and downsides.
Of course, as is usually the case with projects I lead for myself or others, I got a little over scoped in my planning and documentation, more so than we could hope to reach on the programming and build side of things. To be fair to myself, I was able to salvage from these documents a more reasonable game concept soon after, but the initial problem still exists.
Moving on, after onboarding two additional designers to help with documentation and systems design, I moved onto level/environment design to assist the newly onboarded artist, after dealing with the game having no artist for the concepting phase of the game.
This of course in the build looks like:
While I consider my own focus to be narrative design, I was unfortunately unable to really get a lot of that into the game, as the build never got to a place where that could be done on the scale initially intended, and that with the added focus on art as well as design, I simply didn’t have the time to dedicate to this project to do both. However, outside of what ended up in the game itself, this project did help with spreadsheets and documentation for player characters, NPCs, and enemies in a narrative sense, locating each character in the world and relating them to the story beats that could have been, if the scope of the project had been bigger. In this, at least, I was able to practice working on narrative documentation for a team.
Looking at the end of the project, I did end up having to step into a role adjacent to what I had initially initially intended, but I do think we managed to end the process with a decent game development experience. Considering the current situation with remote learning and coronavirus, I imagine we *could* have done better in person, but present circumstances accepted, I think the end product is decent. Granted, there are some thing we could have done better as a team, there are no singular team killing issues. We did struggle at the beginning with GIT practices and had some issues with that, but after some problems within the first two sprints or so, we were able to work out acceptable branching practices. Additionally, we had some problems with meeting times earlier in the project, after breaking into several subgroups that were able to maintain more focus on their tasks, we were able to gear our meetings to be more specific and precise on who needed to be there and what needed to be done.
0 notes
Text
Dev Blog 2 (Game Production 2)
Rapid prototyping, we got three games this time around, let’s see the roundup.
Week 1: Arena
Arena was a pretty simplistic design with a simplistic prototype. There wasn’t much scope to work with if we went forward with it and it was still the first week, so the team wasn’t entirely up and running. Being the first game with the given group and of the rapid prototyping sprints this game was the worst in execution but overall I think the game idea was solid. That’s about all there is to say about ARENA for the moment.
Next Game
Week 2: Thalassophobia
Thalassophobia had a much clearer theme and player experience in mind. As a team we’d begun to hit our stride and our prototype was actually pretty cool. We ran into some communication problems with how the camera was supposed to function, so while the prototype looked cool and had some neat code behind the enemies already in the game, the controls were... lacking. The scope issues present with ARENA were gone and had we gone forward with this game our scope may have been in the most ideal spot, and the next game which we ended up going forward with may have some scope issues but with the new team members onboarded we have a large number of people and it shouldn’t be as bad of an issue.
Which brings us to the final game with a half-introduction out of the way
Week 3: Rootin’ Tootin’ Cowboy Shootin’
RTCS was initially themed very differently with similar underlying mechanics, being a sort of metroidvania RTS with SCP/xfiles esque theming, though after some thought and deliberation we decided that defensive gameplay would be overall better than offensive, and with that the decision to change the theme came as well, one of the group members suggested cowboys defending towns under siege and the team as a whole really took to it. By this week we all knew each other’s working patterns and styles much better than the weeks previous and we were able to hit the ground running more or less and really get some core systems and mechanics working smoothly.
Upon getting our feedback for week three we decided it was the strongest of our ideas in potential connection to the player and went forward with it. Though with the greenlight presentation time limit there was some work that was done but didn’t get shown which I wish we had found time to do so but I suppose it worked out anyway. As I’m a designer my contribution to these prototypes was mostly in documentation and some code here and there and level layout. A little bit of everything to make sure the prototypes got where they needed to be to present. If I were to redo this I may have fought harder for the original theme of RTCS with some changes to gameplay, but that’s something I can do on my own time in the future. As is, I think we’ve done a pretty good job so far in regards to game development.
0 notes
Text
Dialogue Lessons Retrospective
Dialogue in writing is both very necessary for a work to feel complete, and also kind of wacky in terms of getting characters to feel like real humans. On top of this one also has to make sure that the dialogue more or less has a point, be that introducing the audience/player to the character, or getting information across from one character to another to advance the plot.
In interactive media specifically (as I am primarily working in) you also need to measure for player input, the player’s own dialogue needs to have an impact for it to be a worthwhile gameplay mechanic, if the player can influence other characters in the world by talking to them and making that connection, the ability to talk in that game is serving its purpose.
Personally I think getting characters to both sound real and sound different from each other is something I want to work on. I find it most helpful when writing realistic dialogue to write in a voice that sounds right, and doesn’t just read right, but the issue with that is that it becomes very easy to slip into your own voice and not into that of a given character, and when you do that all the characters start to sound like you to a certain degree. From there you suddenly have the old woman who runs the corner store, the grizzled town sheriff, and the young librarian all speaking with the voice of the 20 something college student.
(something akin to the written version of this)
Additionally I think getting more player interaction, differentiating between running an RPG and writing interactive stories requires that as a writer I allow for the player to exercise their own choice while being the one to write all those options and have them be both believable and different from each other. Again, any writing is done by me but must account for what the player may choose to do, ideally with amenable options for most people.
hopefully said options do not come across as the above
Overall I think this unit on dialogue has been exceedingly helpful, especially the timed/on the job sections, just being forced to write down *something* is helpful as always because once that’s done you can change and rewrite it to be better but at least it’s there. Like I’ve said, in the future I want to work on differentiation and further align dialogue to the character who is speaking it but for now I think I’ve already come quite a ways.
0 notes
Text
Dialogue Analysis 2, Walking Dead Final Season & Until Dawn
Today I am analyzing two dialogue driven games, that is games where dialogue is a mechanic in addition to an element of the narrative. First we have the Walking Dead the Final Season, and after that we have Until Dawn, and by looking at them we’ll see what makes good mechanical dialogue, and what makes bad mechanical dialogue.
Let us begin with Until Dawn.
(stare into her eyes and see death incarnate)
Until dawn is more or less a playable slasher movie, all of the characters (who are ostensibly in high school) are motion captures and voice acted by actors in their late 20s or early to mid 30s, the dialogue is exquisitely hammy, and frankly it is one of my favorite games. The game essentially has two main mechanics, quick time events, and making the choice of what what action the character you are current controlling takes for talking, paths to go down, and other pivotal choices.
Based on the choices you make, all, some, or none of the games characters will survive... until dawn. Many of the choices have objective right or wrong answers in terms of how to keep the characters alive and happy with each other (unless you’re trying to get them killed which is... fair). The game also has a character info page for each person in the story.
However, none of these stats matter when you are controlling the character, someone with a high honesty score could be made to lie or someone with a low curiosity score could investigate a strange and scary noise. These stats are affected by player choices but only matter when you are not controlling them. The impact from dialogue choices is often high and hard to gauge if you have not played the game before. Having low relationship status between certain characters can result in one of them dying, for example if Chris (second image) and Ashley have a low enough score, Ashley will let Chris die towards the end of the game.
Lastly are several sequences in which you play as an unknown character (whose identity is revealed later in the game) speaking with a therapist. The doctor will at times ask the player explicitly what of three things is the most scary to them, almost immediately after which, the thing you marked as scariest will appear. This is rather ham-handed in terms of scaring the player through dialogue and is wonderfully cheesy if completely ineffectual as after it happens once you can be sure it will happen after it happens again later in the game. Overall as much as I like the game itself, the dialogue system is quite lacking in terms of how it improves the game through player choice.
Moving on.
The other game I want to talk about is Telltale’s Walking Dead the Final Season. I’ve already analyzed the first game earlier and as such would point you to that for specifics. Anyone familiar with Telltale will know more or less how their games work. What makes TFS different is your companion character AJ. Mirroring the bond Clementine and Lee had in the first game, AJ will take in what the player tells him, and what actions he performs on his own based on what you’ve told him impact the game to a much greater degree than they did for Clementine in season one.
The big thing I want to emphasize in analyzing the Final Season is a sequence right before the end of the final episode, where it appears that Clementine has died (she hasn’t) and the player controls AJ. Unlike the standard interface of showing dialogue options based on what the character will say next like when the player was controlling Clem, Lee, or Javier in any of the previous games, the interface for dialogue options shows the reasoning behind what AJ is about to say.
Just the simple change in how the dialogue is displayed shows how AJ’s thinking process is different from Clem’s and those who came before her. The choices he can make are influenced by the lessons the player as Clementine chose to instill in him.
(Clementine dialogue for comparison)
As much as people like to meme on Telltale games, the long reaching effects of the player’s actions, especially in the final game, really allow the player to influence the characters around them and the relationships between them, and their relationships with the main character, if they exist at all.
All in all, Until Dawn and the Walking Dead Final Season are both games I enjoy immensely, though for very different reasons. In TWD TFS it is because I feel a real connection to the characters built from an understanding of them that comes from the ways the game allows me to explore their thoughts and feelings through dialogue. In Until Dawn it’s because the cannibalism murder monster died in normal human clothes and everything has torn/worn off except for the underwear.
(I will never not find this funny)
10 notes
·
View notes