diff --git a/src/diary/entries/211201 b/src/diary/entries/211201 index b2e85a9..2168a78 100644 --- a/src/diary/entries/211201 +++ b/src/diary/entries/211201 @@ -35,7 +35,8 @@ december 1, 2021

sunday, november 21 - saturday, november 27

diff --git a/src/diary/entries/220114 b/src/diary/entries/220114 new file mode 100644 index 0000000..52fbc23 --- /dev/null +++ b/src/diary/entries/220114 @@ -0,0 +1,19 @@ + +

goalless games

+january 14, 2022
+#game-design #philosophy
+
+

goalless games


+Some developers are happy to make loose, meandering sandbox games without no true win or fail state. The concept of goalless games is controversial among semantic people, but I feel that the genre with Garry's Mod and all the dressup games and physics simulators is enviably successful if not totally legitimate. It's not like the overwhelmingly popular Minecraft and old RuneScape don't share one foot in this genre, either, with their relative lack of direction and gameplay dominated by self-driven goals. I don't even feel like a central story or overarching player goals would improve these games (especially after watching Minecraft tack on some tedious hunger mechanic and an awkward final boss).
+
+

my need for structure


+I'm just not a goalless game designer.
+
+A game designer can't force a player to share the game's goals, so there's no need to purposefully design a game to be goalless. For me, I feel like neglecting to set a game's goal reflects a lack of a game development goal. A goal is helpful to not only the player but also the developer. A vision of progression (game state, world, character, and story) will imbue each piece of the game with more purpose and help them fit together more seamlessly as a whole. It's a safeguard against filling a game with pointless, incongruent clutter at whim. Obviously not every developer needs a goal-oriented approach, but I do.
+
+No matter what philosophy the game designer has, though, a player will do what he wants to do, even if it has nothing to do with the goal of the game. Roleplayers are prominent members of MMO communities, and they might never max out a character or finish the main storyline. They throw out all the game designers' work and focus on finding a vista somewhere and acting out their own scene instead. There are plenty of screensaver simulators and 3D chat servers out there for them, but they turn up in "real" goal-driven games, too. There are touches of this aberrant behavior in everyone who doodles with bullet holes, names their player character something funny to harvest out-of-context dialog screenshots, or hoards a useless item.
+
+So in a way, game designers really don't need to design a goalless game. They can trust players to forge their own fun from even the most rigid hallway simulator. In my opinion, deliberately not designing goals runs greater risk of making players being too lost, bored, or overwhelmed to find their own fun or not even finding incentive to try the game in the first place. A better approach would be to build towards a purpose while taking a tip from goalless games by filling the world with interesting tools and interactibles that are fun for fun's sake. At the end of the day, though, obviously do what works for you!
+
+Last updated January 12, 2022 +
diff --git a/src/diary/entries/220127 b/src/diary/entries/220127 index 6e7fbfa..4a5ef2a 100644 --- a/src/diary/entries/220127 +++ b/src/diary/entries/220127 @@ -1,4 +1,4 @@ - +

hostility

january 27, 2022
#design #mechanic
diff --git a/src/diary/entries/220201 b/src/diary/entries/220201 index 1723cae..96f5ccf 100644 --- a/src/diary/entries/220201 +++ b/src/diary/entries/220201 @@ -38,10 +38,16 @@ february 1, 2022

friday, january 14

  • Before, I wanted to jump right in and force a murky concept of "in combat" and "out of combat" (or "hostility"), and it didn't turn out well. When I took a moment to research, draw charts, and write user stories, hostility clicked. Implementing a feature feels more instantly gratifying than the abstract process of design or devops. The temptation of coding from the hip is too strong to resist, but much of that code gets stashed and abandoned, including the hostility code. Instead of flailing around in the editor, that time might as well have been spent playing Divine Divinity if I really didn't feel like doing design work...When will I learn?
    • -

    sunday, january 16

    +

    saturday, january 15

    +

    sunday, january 16

    +
    Last Updated January 16, 2021

    diff --git a/src/diary/entries/220310 b/src/diary/entries/220310 index 9ebec60..501d36e 100644 --- a/src/diary/entries/220310 +++ b/src/diary/entries/220310 @@ -1,11 +1,11 @@ -

    ???

    -february 2, 2022
    -#design #mechanic
    +

    adding a bleeding status effect in godot engine

    +march 10, 2022
    +#mechanic #status-effect


    -

    what is hostility?


    -Hostility is a state that a character's AI state machine can enter. More specific states will inherit from the hostile state to prompt targeting, aggressive, and defensive behavior. It's a very similar concept to aggro in Guild Wars because weaving through patrol patterns and balling mobs is one of my favorite things from any game.
    +

    out of the norm


    +RPGs are all about the stats that define their characters. The values of each stat are constantly being jostled around by buffs, debuffs, enchanted equipment, environmental effects, and perks. If you allow each

    when does a character become hostile?


    NPCs generally will not seek out the player for combat. They will either stand stationary or follow their patrol route, oblivious of the player until becoming hostile.
    diff --git a/src/diary/entries/220324 b/src/diary/entries/220324 new file mode 100644 index 0000000..2d7c853 --- /dev/null +++ b/src/diary/entries/220324 @@ -0,0 +1,18 @@ + +

    factions

    +march 24, 2022
    +#factions
    +
    +
    +

    out of the norm


    +RPGs are all about the stats that define their characters. The values of each stat are constantly being jostled around by buffs, debuffs, enchanted equipment, environmental effects, and perks. If you allow each
    +
    +

    when does a character become hostile?


    +NPCs generally will not seek out the player for combat. They will either stand stationary or follow their patrol route, oblivious of the player until becoming hostile.
    +
    +Usually, if an NPC is hostile, that means a threat got too close. Currently, proximities in Blessfrey mirror Edward T. Hall's zoning for interpersonal distances. Intimate distance is the range for physical interaction and melee attacks and social distance is the range for assessing hostility and ranged attacks.
    +
    (image: A visualization of proxemics by WebHamster of Wikipedia. Around someone are 4 concentric circles with varying diameters: within 25 feet is their public space, 12 feet is their social space, 4 feet is their personal space, and 1.5 feet is their intimate space.)
    +(By WebHamster - Own work, CC BY-SA 3.0, Link)
    +
    +Last updated January 12, 2022 +
    diff --git a/src/diary/entries/220407 b/src/diary/entries/220407 new file mode 100644 index 0000000..289137d --- /dev/null +++ b/src/diary/entries/220407 @@ -0,0 +1,31 @@ + +

    designing blessfrey's first demo

    +april 7, 2022
    +#demo
    +
    +
    +

    my goals


    +The systems and game mechanics in Blessfrey are mostly present and functional, so I feel like it's a good time to practice releasing, hosting, and supporting a game. The first release will just be a tech demo. I want it to showcase all the features in the game, have a narrative structure and goals, and have some of the same gameplay feel of future releases. Hopefully it's fun, but we'll see when it's all bolted together.
    +
    +The core of the game is curating from a wide variety of skills and combining them into a viable skillbar. I'm going to try to get away with skimping on content to put more focus on the release process, but skill variety deserves the most attention. I'll shoot for 30 skills for now, or in other words, 3-4 skillbar's worth without repeats.
    +
    +

    finding structure


    +I could release a goalless demo, but I fear people wouldn't explore long enough to discover any depth. The demo will be more or less original instead of a ripped level from the finished game, so I can't steal a goal from the main game either.
    +
    +This demo should showcase more gameplay than story and world, so it should probably have more in common structurally with a tutorial room anyway. I'll just fallback on the demo bingo approach again and hope it never loses its luster. Bingo is a great excuse to list gameplay prompts for the player while giving them some choice on how to proceed. It's also a game in itself, so I don't need to take my game design much further: every full consecutive set of activities is a little win with a prize and a full board bingo is a big win with a big prize.
    +
    +The demo literally is a tutorial, though, since it is the first time unguided players will be able to play. I'll try to incorporate a stealth tutorial and see how it compares to a more conventional tutorial. Ideally, the bulk of the tutorial should be easy enough for veterans to breeze through it without being told what to do, but nudges and tips are given to those who need it. It'd be even cooler if the tutorial doesn't break immersion, coming from characters as believable dialog or from passers-by setting an example. Some popups and 4th wall breakers are probably inevitable, but that's my goal. Since I have the event system, it's just a matter of listening for lack of movement, unnecessary key spamming, stalling in quest progress, or any other apparent failures.
    +
    +

    world and story


    +I don't want any of the demos to exist within a vacuum. I won't be repeating the story or using fully realized locations, but the demos should at least conceivably fit within the full game. Besides the player character, two major supporting characters will be there, Chloe and Night. The entire demo will also take place in three areas at the school: the courtyard, the nurse's office, and the storage room. This isn't the real school, just enough of it to service a fun demo. The courtyard is a relatively safe area with some easier enemies to the far side of the map, guarding collectible items. If you die, the checkpoint is in this field, managed by Chloe. The nurse's office is an item shop, run by Night. The storage room is a maze full of monsters and treasure. It's not the best game in the world, but I think that's enough to test out the gameplay.
    +
    +I'm also using the demo to test sophisticated dialog. If everything works well, I can have the dialog responses affect things in the game and have characters remember details.
    +
    +

    areas left ugly


    +It's the first alpha build released to the public, so it's not going to be a polished AAA experience. There are a few bugs I know are still in there, some capable of crashing the game. I'm including pushing certain features to a bigger degree than I've ever tested for, so hopefully that'll turn out fine. I've never stresstested but plan to once this is released. Also, a lot of basic visual and audio stuff is not up to snuff - barely any animations, and all audio is from the public domain. If it's too ugly, it'll be cute in hindsight as an early version. :)
    +
    +Anyway, back to working on the demo!
    +
    +
    +Last updated January 12, 2022 +