#game design document GDD
Explore tagged Tumblr posts
zentarablog · 21 days ago
Text
How Video Games Are Made: 10 Basic Steps Explained
Video games, from simple mobile apps to sprawling open-world epics, are a ubiquitous part of modern entertainment. What might seem like magic to the casual player is, in reality, the result of a complex, multi-faceted process involving diverse teams of highly specialized professionals. Creating a video game is a monumental undertaking, blending artistic vision with cutting-edge technology,…
0 notes
alienfromthedeepsea · 5 months ago
Text
Supposed to be working on a GDD but instead I'm scrolling through tumblr and interacting with rp blogs. I think I have a problem. 😔
2 notes · View notes
soloindiegamedev · 10 months ago
Text
How To Write A Game Design Document (GDD) As A Solo Developer
You have a great idea for a game! In fact, you’re so enthusiastic about showing it to the world you’re already working on it. But without a proper Game Design Document (GDD) it’s highly likely that idea will never materialize into a fully released game. Why? A GDD keeps you focused, makes sure that you stay within the scope of your vision, and is a major reference point as your game development…
2 notes · View notes
codingcorgi · 2 years ago
Text
Going to teach my Game Development Class! I'm nervous, because today's the first day I'll be presenting as a Creative Director!
On another note... anyone interested in a small video and template for game design?
8 notes · View notes
zagreusm · 2 years ago
Text
Tumblr media
Cover art of a "planned"* rpg horror game based on the spanish folk tale "The giant's ring" (El Anillo del gigante) done for a class
*"planned" as in "I had to create a videogame idea and do a lot of material for it but Im not necessarilly working to develop it"
5 notes · View notes
destructix · 3 months ago
Text
feelin' chatty cuz i took my meds
1 note · View note
meatyhandbag · 4 months ago
Text
Fangame Pitch: Sonic the Fighters 2: Chaos Control
Tumblr media Tumblr media
i love coming up with fighting game rosters and im a big fan of the underrated emerald that is the Clash of Ninja series, specifically their take on the Burst mechanic
This eventually led to be wanting so badly to make a Sonic fighting game. Sonic is actually PERFECT as an IP for a fighting game. they have a dense list of characters making branding really easy. But also the series originated as a 2D platformer and has developed to have very simple combo layouts for attacks in recent games. this translates REALLY well to a fighting game
And considering the franchise's affection towards 3 character teams, its perfectly designed to have 3v3 team-fights
CONTROLS
the game would be a 6-button game. 2 attack buttons, Light and Heavy, 2 tag-out buttons, a super button, and a cancel button (allowing what many fighting game players call a "Kara Cancel"). This is in addition to the directional-stick obviously
Light moves are fast simple attacks, while their aptly named Heavy attack counterparts will be stronger and slower. in addition Light attacks will link into heavy attacks for combos, but not the other way around.
Now like other fighting games with only 2 attack buttons, you will use the directional stick to create different variants on attack. Light-Foreward is different from Light-Down. and Jumping will unlock a whole host of new attacks as well.
Now, this game will only utilize "directional" inputs for their attack variance. This means no Charge or "motion" inputs like seen in Street Fighter. I know that seems scary to some fighting game players, but between standing, directional, and jumping, thats 16 different moves across light and heavy.
Plus some characters will have "combo moves" where if you do Foreward-Light, Foreward-Light, Foreward-Heavy, you'll unlock a whole new move than if you JUST did Foreward-Heavy.
in addition, players will be able to use the Cancel buttom to spend 1/6th of their meter to instantly cancel out of an attack. giving them even more freedom and control over their combos.
Supers will also spend meter, with each character having 2 Supers and a "Golden Super". Regular Supers will trigger when you press the Super button and its designated direction, instantly canceling out of any move you're currently doing and costing you 1/3rd of your meter, or "1 bar".
a "Golden Super" will trigger when you double-press the Super Meter while you have 100% of your meter filled. This will be easily indicated to the player by the golden ring at the end of the meter flashing. These will activate a cinematic super that deals a lot of damage and shows off the character's cool unique abilities. This will also use up all of your meter though so its a very high risk high reward move, often only used to guarantee a kill at the end of a match or by casuals who want to style on their friends. but they are very fun to watch
You can also Press Light and Heavy at the same time to do a basic Grab attack, and you can press Cancel and Light at the same time to do a Taunt
Directional Inputss
Pressinh Back will have you move backwardwards and put you in a block state and a golden ring will appear around you when you successfully block a hit. but if you block 5 hits in a row without attacking or pressing foreward, the gold ring will shatter and you'll lose all your meter. so don't abuse it.
Pressing Foreward will move your character foreward. If you double-press foreward your character will do a quick dash foreward.
Pressing down will put you in a crouching state, reducing your hitbox, giving you access to new moves, and if you press back and down at the same time you can crouch-block, letting you block without moving backwards
Pressing up will have your character jump. letting you move around the opponent and unlocking new attacks that can be done in the air.
TAG-OUT
Now, another input button i mentioned is the Tag button. because this is a 3v3 fighting game, players will have access to 3 characters that they will pick at the start of a match. You start each round with the first character you selected and you can use the Tag button to access the other characters
There are 3 different types of Tags: Quick-Tag, Full-Tag & Burst-Tag
a Quick Tag is performed by just pressing the Left or Right Tag button to bring out its respective character. they will appear on the screen and do a single attack before leaving.
a Full Tag is performed by pressing the same tag button a second time while the character is currently out on the field. this will switch control to that character and the character you were playing switched out instead. You can then cancel out of the tag attack as soon as you press an attack button
a Burst tag is special. While Quick and Full tags can be done whenever you are not in hit-stun and cost nothing but time to do, a Burst Tag is performed when your character is currently stuck in hit-stun. You press the respective tag button and the character will appear on screen, do their respective Quick-Tag attack knocking the enemy away, resetting the game back to neutral and swaps controls with the previous character. This is the bread and butter of the game and what the entire game is built around.
Because burst Tags are so powerful and can be done at any point in the game as long as you are in hit-stun, there is a cost. 2/3rd or 2-bars of your meter. This effect guarantees that no one can be locked into an infinite combo and that no one is left feeling helpless against a lucky hit.
Now, because Burst Tag is so powerful, unlike most other 3v3 and 2v2 team fighters, you do not regenerate health when tagged out. So keep an eye out on your health
CHAOS CONTROL
The 2nd mechanic the game is built around and the titular name of the game: Chaos Control.
At the start of a match when you are selecting your character, you will also be prompted to pick one of 7 Chaos Emeralds to bring into battle. Each Emerald comes with it its own unique power.
Tumblr media Tumblr media Tumblr media
Pressing Cancel and Super at the same time will activate Chaos Control, giving you the effect of the selected emerald. Once you use your emerald, you cannot use it again until it comes back. an Emerald will come back when 1 or 2 conditions are met.
You have filled up your meter you 100%. This does not cost meter. it just comes back when you fill up the meter
When you have only red health left.
Each Emerald will have its own unique effect and is designed to cover up a weakness a character might have.
Red/Grab will give you a powerful command grab that has some armor on it
Purple/Blast will give you a long-range fireball that helps win fireball wars and set up 50/50 mixups using it
Yellow/Push projects an emerald barrier aroudnd yourself, knocking the enemy away, dealing some damage, and putting them in hitstun. Useful as a reversal. It can also counter bursts
Green/Parry puts your character in an auto-block state that negates all damage. Useful if you need a Daigo parry for a powrful super without breaking your block guage.
Blue/Dash is basicalyl a directional teleport, letting you dash in any direction. its the only emerald that uses directions, but if you press it without pressing a direction it will dash foreward.
Teal/Heal will give you 15% of your health back. Warning, recording the emerald at red only applies once per health bar. if you are at red health and spend the healing emerald to get back out of red, you cannot recover the emerald again with that character.
White/Crush lets you do a powerful rush attack that helps you close distance and pressure the opponent
The purpose of the emeralds i to shore up weaknesses a teamcomp might have. You might have a bunch of slow bulky grapplers and need a way to win a fireball war or dash into the opponent's face. or you might want to zone the opponent out with a bunch of soft squishy zoners and want some extra health to go with
CHARACTERS
Now, i've talked at length already, so let me know if you want to know how each character would play. i'll make a follow-up post if people like this and want to hear mopre
0 notes
awitchatdinner · 9 months ago
Text
GDD Diary Entry 1: Title Page
Hi, My name is Chu BEE and I am an aspiring game maker. I am currently writing my game design document (GDD) and I have chosen to share it here to keep myself accountable. First things first Game Title: PularIntended game systems: I intend to use Unity to make the game accessible for Windows, Android, iOS and Kindle.Target age of players: 8-18 years old.Intended ESRB rating: E10 (Everyone 10+)…
0 notes
deusvervemakesgames · 5 months ago
Text
Project RBH DevLog 0091
I have not been doing my due diligence.
As you may recall from the early DevLogs, I have a Game Design Document, which is a way for me to keep my focus tight on the project and not just throw in whatever I think would be cool on a given week until I inevitably burnout and have a project so bloated with scope creep that it won’t see the light of day until the next millennium. And while I have done a good job sticking to that plan, the Game Design Document is meant to be updated in response to the realities of ongoing game development, and I have not been doing a good job of that.
So, having found myself a little unsure of what to work on next, I think it’s long past time I take a step back, update the GDD to include some of the things that have worked out—like, for example, upgrade chains—and how other systems have panned out—like the Procedural Generation—and then refocus myself from there.
Until next Devlog!
-DeusVerve
DevLogs like these are brought to you by Patron(s) like Haelerin!
Support me on Patreon to get Early Access to builds!
17 notes · View notes
ghoulishrose · 2 months ago
Text
Here's the GDD! Spoilers for the endings of the fangame.
And if you want to see more behind the scenes content, join the community!
3 notes · View notes
focusontheheart · 1 year ago
Note
Looking forward to the full game <3
Qs about the development process - how does the team structure for a given LI's route function? Does each route have an Artist-Writer-Programmer trio that collaborates to get a route completed, with the named Role Leads pulling everything together for consistency? With such a huge game, did y'all use version control and code repos to manage the scripts?
Hi, Game Lead kittleskittle here!
You're very close with the team structure! Each route has one or more writers, and the same goes for artists. Leads for each route were chosen by team members, and those leads report to the project leads. Whole project leads manage their specific department and collaborate with me to come up with standards and ensure route teams are adhering to them. It's a lot of work, but they've all done amazingly. Having such a structured team is a large part of why this project has been so successful!
As far as programming goes, I've coded the majority of the routes, the UI, and the background + other additional animations myself with support from other programmers on the team. This helps keep the standards I've designed for the game and the overall vision on track. However, we do make use of GitHub as a code repo for the project!
The biggest reason this project has worked, in my opinion, is our rock solid organization and standards. I've made these a huge priority from the start, because I believe that any project lives or dies based on the quality of its internal organization and leadership. We have many important documents in our project gdocs folders for just about everything you can think of, from the GDD (Game Design Document), to standards for sprites and scripts, to QA. We also have tracking documents for progress with assets such as backgrounds and audio, which have been a lifesaver in terms of measuring progress.
Hope this answers your questions, and thanks for asking!!
24 notes · View notes
dtlfacts · 1 year ago
Text
Joseph Tringali, founding member of 5th Cell and Executive Producer of Drawn to Life: Two Realms, has gone on record stating that he prefers not to share Game Design Documents (GDDs) and beta assets, as he may plan to use them in a future project. However, he has still shared two snippets of GDDs, one for the original Drawn to Life, and one for Drawn to Life: The Next Chapter on DS.
Tumblr media
This snippet of Drawn to Life's GDD explains the events of the Beach Gate, though much changed between this GDD and the final game, summarized below:
Instead of being called the Beach Gate, World 3 is referred to as the "Del Mar Islands"
The player brings back a "Lake Page" instead of the "Beach Toys" page from 3-1
The player must draw a fence around Crazy Barks
The player must build a fruit juice stand:
Tumblr media Tumblr media
Heather (called Hethers in this GDD) explains parts of her backstory after 3-2
The player brings back a "River Page" instead of the "Epic Statue Page" from 3-3
The player draws Pirate Beard a flag
Isaac (called Willham in this GDD) is corrupted by an object called a Shadow Stone and sets the village on fire
Tumblr media
The second GDD snippet, this one from Drawn to Life: The Next Chapter, doesn't explain any story elements, but rather a cut Map Minigame where the player would physically have to map out a course for Turtle Rock. Notable changes between this revision and the final product include:
Lavasteam is referred to as "Clockwork Canyon Isle"
Watersong is referred to as "Watersong Isle"
Color Jars have an early sprite not seen in the final game
19 notes · View notes
thefrozenmachine · 1 year ago
Text
Tumblr media
Penguin vs. Pirates Prototype FUNDED!
Thanks to the Canada Media Fund1 (CMF) we're pleased to announced that Penguin vs. Pirates' prototype is in FULL development.
Backstory
Back in the fall of 2021 Frozen Machine submitted an application to the CMF's Conceptualization Program2 in an attempt to get some seed money to work on the Game Design Document (GDD) for what we think will be our breakout game - Penguin vs. Pirates! This was a turning point for the studio where after almost 6 years of bootstrapping the company and every project the team was able to issue their first paychecks. 
After a really fun, creative-filled, summer the next logical step was to make use of another one of CMF's incentives - the Prototyping Program3! The application for this program was more involved so we reached out to other local studios4 who have successfully gotten funding from this program before. It took a few tries but in 2024 CMF got back to us with the positive news that Penguin vs. Pirates was fully funded under the Prototyping Program. 
What's next?
Now that we have room to breathe again the first milestone is to have a playable demo for Game Con Canada5 (GCC) in June, and bring it back to the Game Discovery Exhibition6 (GDX) in July. The remainder of the time after that we will be hard at work completing a full gameplay loop demo which we'll share more information about in the future.
Do you want to be part of the penguin colony? Or perhaps join the pirate crew? Sign up to our mailing list7 to get the exclusive scoop on all the future announcements for the game, or join our Discord8 to talk with fellow penguins and pirates.
More information will be shared in the future, until then watch our promo trailer9 and please remember - have fun creating!
Author: Adrian Published: 2024-03-24
------------------------------------------------------------------
Canada Media Fund: https://cmf-fmc.ca/
Conceptualization Program: https://cmf-fmc.ca/program/conceptualization-program/
Prototyping Program: https://cmf-fmc.ca/program/prototyping-program/
Local Studios: 
Only By Midnight: https://www.onlybymidnight.com/
Itzy Interactive: http://itzyinteractive.com/
Caldera Interactive: https://calderainteractive.com/
Crimson Herring: https://www.crimsonherring.com/
Game Con Canada: https://gameconcanada.com/
Game Discovery Exhibition: https://www.interactiveartsalberta.org/gdx
Mailing List: https://thefrozenmachine.com/contact/frozen-machine-links
Discord: https://discord.com/invite/XXHGEe3Vqn 
Promo trailer: https://vimeo.com/828014522 
5 notes · View notes
jaisrakesh · 11 months ago
Text
Game Software Development: From Concept to Code
Game software development is an intricate process that combines creativity, technical skill, and strategic planning to bring engaging virtual worlds to life. From the initial concept to the final lines of code, every step requires meticulous attention to detail. Whether you're an indie developer or part of a large studio, understanding the game software development process is crucial to creating a successful game. Let’s explore the journey from concept to code and the key steps involved in game software development.
1. Conceptualization and Planning
The journey of game software development begins with a concept. This is where the initial idea is born, often inspired by personal experiences, popular genres, or unique storytelling angles. During this stage, developers outline the core mechanics, gameplay elements, and overall theme of the game. A Game Design Document (GDD) is usually created, serving as the blueprint for the entire project. This document details the gameplay, characters, story, and technical requirements, ensuring that everyone on the team is aligned.
2. Designing the Game
Design is a critical phase in game software development where the concept starts taking shape visually. This stage involves creating sketches, storyboards, and prototypes to visualize the game's environment, characters, and user interface. Tools like Unity, Unreal Engine, and Godot are popular for building game prototypes that help developers test ideas quickly. Level design is also crucial, defining how the player will interact with the game world, navigate challenges, and experience the storyline.
3. Development and Coding
Once the design is finalized, the game moves into the development phase, where coding takes center stage. Developers use programming languages like C++, C#, or Python to build the game’s mechanics, controls, and AI behaviors. Game engines like Unity and Unreal Engine provide a solid framework, offering pre-built assets, physics, and lighting to streamline the coding process. Collaboration between developers, artists, and sound designers is key to integrating visuals, audio, and gameplay seamlessly.
4. Testing and Debugging
Testing is an ongoing process throughout game software development but becomes particularly intense as the game nears completion. Quality Assurance (QA) testers play through the game to identify bugs, glitches, and gameplay issues. Debugging involves refining the code to ensure the game runs smoothly and provides an enjoyable player experience. This phase is crucial for fixing performance issues, balancing gameplay, and polishing the final product.
5. Launch and Post-Release Support
After testing, the game is finally ready for launch. Developers release the game on chosen platforms, whether it’s PC, console, or mobile. However, the journey doesn’t end there—post-release support is essential for addressing player feedback, releasing updates, and fixing any remaining bugs.
Conclusion
Game software development is a complex but rewarding process that turns creative visions into interactive experiences. By following these stages, from initial concept to final code, developers can bring their ideas to life and create games that captivate players worldwide.
2 notes · View notes
2d-project-tjc · 11 months ago
Text
My Summer Homework. This is what I aim to do with my 2D platformer!!
2 notes · View notes
amadeusgame · 2 years ago
Text
September Devlog: Full Episode 1 Design Finalized
Tumblr media
Per last month's devlog, this month's primary task was to finish the narrative outline and complete game design document for the full Episode 1 release. And I'm happy to announce that this is done, I have a concrete vision to follow, and now it's a matter of ticking off boxes on the to-do list until this thang is RELEASED. I'm getting REALLY excited about this project, and feeling like it is becoming more and more tangible.
Some quick updates before getting into the details:
I'm sure you all heard the kerfuffle about Unity; I've discussed where I'm currently at on the Tumblr blog here.
I went to PAX West (and the Seattle Indies Expo) and talked to a ton of indie devs! I wrote about a lot of upcoming indie games on the Tumblr blog here.
As always check the linktree (https://linktr.ee/amadeusgame) for all resources related to Amadeus. Most frequently updated are the Tumblr blog and Discord server, but these itch.io devlogs will continue monthly as well.
And now, for this month's updates. 
TL;DR--
PAX West & Seattle Indies Expo: more details on these events, specifically how much it helped me as a solo dev meeting and talking with other solo devs.
New Mechanics Envisioned: made a new paper prototype & sought playtester feedback to determine final control scheme vision.
Finishing the Narrative Outline: process for sitting down and mapping out the full Episode 1 narrative to guide the GDD
Completing the Game Design Document: process for taking the new mechanics & full narrative to fully outline the design for Episode 1
Recreation: media I engaged with this month for fun and inspiration!
Details below for those interested.
PAX West & Seattle Indies Expo
This was my first time attending PAX, and it was incredibly valuable. The Seattle Indies Expo (an adjacent, and completely free, event) in particular was fantastic, because I got to have really in-depth, one-on-one conversations with a lot of other small developers. So many of us are working on passion projects in our spare time, and wearing 20 different hats - from music composition to coding to project management to marketing - while also doing something else to pay the bills. So it felt very grounding to have honest discussions with so many other people who are all in the same boat. It also helped to find that a couple other developers came to the same answers I did on certain topics (virtually all of us are in agreement that you absolutely have to have deadlines that you take seriously, or you will never finish...), and one of the developers I spoke with mentioned something really helpful: that if you only have 1-2 hours to work on your game a week, decide EXACTLY WHAT you will work on in that time slot beforehand, so you've already started dedicating brain energy to the topic before the time comes.
I met a handful of developers who I'm likely to keep in touch with for the foreseeable future. It was a fantastic opportunity. Those of us out here making niche little passion projects really do feel the passion coming from each other. Gotta find your people and support each other!
I'll go ahead and plug my Amadeus blog Tumblr post on the subject again, because I'm also genuinely excited about a lot of these games: 10 Upcoming Indie Games to check out!
New Mechanics Envisioned
Tumblr media
Never forget that busting out the sticky notes/scratch paper is an essential step in game design & development.
One of the major roadblocks I faced last month standing between me and finishing my GDD was that I knew I needed to rework the main interaction mechanic. I liked that it was WASD/point-and-click interchangeable, but it felt very unpolished. So one of my first tasks for this month was to figure out what, exactly, my vision for a polished interaction mechanic was. To do that, I revisited the very first step of game development, and made a paper prototype.
In doing this, I was able to identify the biggest source of my problem: I really like that you can control Amadeus - and not just a cursor, but this makes it impossible to interact with things that he can't get to (like looking at things in the sky). This is kind of at odds with the control scheme that seems most natural for the genre.
The central source of my problem was this:
The most straightforward control scheme for my game seemed to be point-and-click, where you don't have an actor you control but just directly interact with environments.
However; point-and-click mechanics are very hard on my wrists (because I have massively screwed up wrists), and I want to make a game that I can play comfortably - and for thematic reasons, this is all the more important!
Moreover; I just really like controlling a little guy and walking around as him.
I have come up with a solution that I think works well, at least on paper. One of my big goals this month is to prototype it in-engine, and hopefully get it in front of playtesters soon. The good news is that I got a lot of feedback from playtesters that the hybrid control scheme was a plus, and almost nobody used exclusively WASD or exclusively point-and-click, which tells me that my "utilize both" design philosophy feels right. Now I just need to polish it.
My goal is still to have a rebuilt demo, containing more or less the same content as the existing demo (unless...? but let's not get our hopes up too high!) with the new mechanics and control scheme, out this Winter. So far, still on track for that!
Finishing the Narrative Outline
THIS was truly the largest obstacle between me and a complete GDD. It is not possible to list out all assets needed in a game if you don't have a list of every scene in the game, and you can't have a list of every scene in the game without a complete narrative outline. Making the demo was easy in this respect - I already knew how my story started. I also knew more or less how it would end (or at least, several key climactic events). But there is no catharsis in a climax that lacks a rich, engaging, and well-developed journey to get there. That's the meatiest part of the game, and it's what I did not have.
Truth be told, I don't know whether the journey I am writing counts as rich, engaging, and well-developed. But I've finally made it concrete, and I think it has heart. This process was actually very rewarding, because I found that in asking myself questions (what is CHARACTER doing here, how does EVENT happen) I found really fascinating answers that made the entire story much more interesting than the one I initially set out to write.
I started just by creating a document titled "Episode 1 Outline" that looked something like this:
Intro
Prologue
Placeholder Scene
Placeholder Scene
Placeholder Scene
Climax
Outro
The reason I was actually able to get from that to a complete outline in less than a month is because, while it didn't really feel like it, I actually did a lot of "writing" last month. I spent the whole month watching a ton of werewolf movies and taking scribbled notes in my Amadeus brainstorming notebook, so I had a huge pool of ideas that were already swimming around in my head. This month's task wasn't to write a story I had no ideas about, it was to finally draw from all of my ideas and refine/organize them to a manageable and logical format.
Most importantly, I gave myself a deadline to finish this outline, and so the day of that deadline I sat down and looked at my intro, my climax and just thought of the "path of least resistance" to get from point A to point B that flowed well and made sense. The resulting outline is much, much shorter than I had initially envisioned (I had some utter delusions of an Umineko-length monstrosity of an introductory episode) - but it works, it tells the full story, and it's complete. And, as will be discussed in the next section, even this relatively "short" episode has so much to it that if it were any longer there's almost no way I would finish it on time.
I still don't have every single detail mapped out at this stage. That much was true for the demo as well. Many aspects of the story wrote themselves by building the game and the necessity of flavor text, signposting, etc.; so I'm leaving room for that. It is just specific enough that I know exactly what assets to make for it, and I know the purpose of each scene. This lets me write early scenes setting up to payoff in later scenes more effectively. I think it should be a good length to be engaging for the player while still letting me give it some polish. :)
Completing the Game Design Document
This was the big thing I needed to accomplish this month. I actually made solid progress on this last month, but I was unable to finish it because I didn't have a definite narrative outline, list of scenes, or finalized control scheme. Once I had these from my work this month, I was able to sit down and finish this document.
I want nothing more in the world than to share this document, because seeing it complete feels like such a massive victory. It shows that I know exactly what I'm doing and that I have solid direction for the development of Amadeus. It proves that this game is getting made. It's even color-coded!! Unfortunately, it contains absolutely GINORMOUS spoilers not just for Episode 1 but for Episodes 3, 4, and 5, which won't be out for years. So you'll just have to take my word for it.
The "Level Planning" and "Rule List" sections of this document needed the most attention, but they are also some of the most valuable for directing the full game's development.  
For the Level Planning aspect, I broke the scenes from my narrative outline down by gameplay type (point-and-click, pure dialogue, puzzle/other) and, in doing so, I found that I gave myself additional ideas for some things I wasn't sure about. Thinking about the narrative in a different way, by breaking it down into gameplay concepts, helped me make certain storytelling decisions and continue fleshing out additional narrative details. This is why I was OK leaving some things vague in my outline - I knew other aspects of development would help me fill in the blanks.
Creating the Rule List is something that, in a way, is helpful as a form of "pre-coding." It forced me to put some thought into how I will actually implement the mechanics I have been brainstorming and prototyping. I already have some ideas, and I already know at least a few edge cases/problems that are going to arise--but that means when it comes time to sit down and actually script things out, I won't be starting from scratch. I've already dedicated brainpower to considering the problem! It'll make it way easier to actually DO, since I've done the first step already.
I know I am repeating myself a lot here, but it keeps coming up because it's important. Putting thought into something before you sit down to "do" it makes it SO much easier to actually do it when that time comes. This entire month has been effectively just that for the whole game: in making this GDD, I have put thought into every aspect of the game's development, so now that I can focus on making it, it's going to be so much easier. I already know where I'm going! What a weight off of my shoulders!!
The last thing I needed to flesh out in the GDD were my asset lists and screen mockups, which there isn't much to say about that can't be inferred from the title. I'll include the mockup for a new menu/settings screen I need to create though to tease some features I hope to implement:
Tumblr media
I also included some (annotated) screenshots of the demo to remind myself what the game actually looks like with nicely drawn assets and not mockup scribbles...
Recreation
As with last month, I want to take some time to discuss media I've engaged with this month. This is for two reasons. First, I genuinely believe that it is impossible to create good art without engaging with other art. Second, talking about media I enjoy will probably give you a feel for my tastes, which may or may not inform how likely you are to enjoy the game I'm making. Although the best measure for that is still just playing the demo and seeing for yourself!
This month I spent the majority of my time playing Castlevania: Symphony of the Night with my roommate. Truthfully, I did not actually expect this to be relevant to Amadeus in any way because the genre is completely different. But I've never been happier to be wrong! The Halloween-y vibes are of course relevant as I am writing about werewolves, but I was also just so inspired by several really brilliant game design choices. This game features something that I like to call "style AS substance," and that is exactly what I want to convey in my own game. I also got a fantastic idea for something I've been brainstorming for Episode 3 thanks to this game, but I can't elaborate on that any further at this time.
Anyway, it was a fantastic game, and also fantastic inspiration. 10/10 would recommend to friends.
That's all for this month! There will be another devlog at the end of November, and now that the GDD is done, there should be a lot of development progress in that one. In the meantime, you can always bookmark the Linktree and check back for new resources.
7 notes · View notes