Overview: A group of friends gets together to play board games and end up role-playing a story that spans time, space, and game mechanics.

Mechanics: This is meant to be a collection of super simple board games played with NPCs. The twist is that game events serve as inputs to a procedural story generator, with NPCs and your own character interpreting things that happen in the game as story events. The title "oh boy, oh gosh, ..." refers to the fact that each minigame represents a campaign that provides a sequel to the ongoing story.

Minimum goals: For a proof of concept I'd like to make sure I get at least one minigame done with its events feeding into a story template.

Ambitious goals: I'd like to have several minigames, each with reconfigurable rulesets, that could be presented to the player in any order. I think it'd be cool if players had some ability to influence which minigames were played and how game events are mapped to story events. Beyond that, I want to spend as much time as possible working on the banter between NPCs during games and programming references to earlier events (e.g. building grudges, referencing lucky/unlucky dice rolls that happened earlier, etc).

The plan so far: I'll be building this as a web app, probably purely in HTML/JavaScript since that's what I'm most comfortable with. It's going to be a 2D game, with assets limited to player avatars, a game board grid, and circular game tokens. The UI will consist of the board game controls plus a basic dialogue system. I'm going to start on the character assets right away since that's the part I'm dreading most as a programmer, and having them done should enable experimentation with the fun design & programming stuff.

Story generation: I've mostly glossed over this, but I do have plans for it. The basic idea is that when you experience a setback within a minigame, your character draws a negative story event from a deck (and you'd draw positive events when you move ahead within the minigame). However, to make the mapping more nuanced, when player tokens in the minigame interact or are in close proximity to each other, story events can build on the relationships between characters. ...I know it sounds complicated, but it'll be cool, I swear.

Oh Boy, Oh Gosh, I've Got Some Work to Do

This sounds super cool! You could try to hook up with an artist on the forums, I know there were a couple looking for jam partners . Good luck, and keep us updated on progress :D

Thanks! I probably should have tried to find an artist to work with, but I didn't want to subject anyone else to my overambitious requirements and it's been fun trying to figure out how to draw anything.

Updates so far:

• I don't have much done, which is (almost) right on schedule and according to plan.
• I've sketched out templates for character avatars. So far, I have a design for a head with swappable eyes/mouth/eyes/eyebrows/hair. I'm making the mouth and eyebrows unisex, since they're used to express different emotions and I don't want to have to redraw them for different characters. For the other facial parts, I currently have one set of male features and one set of female features, though I plan to add more (at least for hairstyles). I was hoping to support non-binary characters and more diversity generally, but making interchangeable features is more work than I was expecting.
• I started doing some writing for the story, but nothing's close to finalized there. I'm still debating how tightly I want to author the story versus making it depend on procedural generation. My current thinking is that a scripted intro will set up the game and give a rough tutorial, then the game will alternate between (A) minigame phases in which dialogue is primarily triggered by game events and (B) transition phases in which characters discuss the outcome of the previous minigame and talk about how the next minigame will fit into the overall story. The transition phases will serve to drive the authored story forward, while the minigame phases will (hopefully) create some interesting procedural stories.
• On the topic of the dialogue system, I've been thinking about how to actually implement this thing in code. The dialogue system will likely maintain a sort of priority queue that tracks possible dialogue options and gives priority to scripted text, followed by contextually relevant options, dialogue that addresses open conflicts, callbacks to previous events, and lastly random filler. In the simplest case, I can rely heavily on scripted events and random filler to scrape something together, but the point of this project is to make this system as advanced as possible.

The plan from here: I'd still like to get a little more art done in the next day or two. If I have a version of character creation and a basic dialogue system testable by the end of this week, I'd be pretty happy. I also need to start designing the minigames and formalizing more of the dialogue/story systems.

Well, that's it for this update. Hopefully I'll have some stuff to actually show soon, because I'd much rather let this game speak for itself than to keep revealing my crazy plans which may or may not come to fruition.

Just from my quick once over of your ideas, this definitely seems like the kind of game you need to play to fully understand. But if I'm reading this correctly, the idea of creating a character to play a series of minigames that have greater implications/consequences sounds super fun.  Reminds me a little of how some RPGs deal with character creation. Torment: Tides of Numenera, for instance, has you interact with a number of stories in the beginning, and the decisions you make in those encounters generate who you are in the rest of the game. This seems like an interesting way of taking that concept to another level.

Today's update: I decided to scrap the art I had previously done and start over again, now that I'm more familiar with the tools and workflow I'm using. I'm happy with the results, which is fortunate because I need to start actually working on the game soon if want a chance to finish it.

I've been struggling a bit to find a way of framing the pitch for the game in a way that's more accessible to players. I felt the title was working against me a bit, since the sequel aspect only comes up after the first minigame is over whereas I'd like players to be engaged in the metagame from the very beginning. The revised pitch is "you've been invited to an obscure board games night, but the games are so obscure that no one knows the full rules for them. You collectively decide to invent house rules for each game with the most important rule being that everything that happens within the game needs to be explained in the context of an ongoing story.

Character creator is live: http://www.majugi.com/games/OhBoyOhGosh/CharacterCreation.html

I reinvented quite a few wheels for this. That's a fully-custom color picker written in JavaScript without external libraries (not even JQuery) for some silly reason. And it's a reactive website layout that re-arranges itself for small devices... even though it's probably still not very usable on small devices. Enough disclaimers, if you make a character you like (or find bugs you don't like) I'd love to see them! The page should let you save images of characters if you right-click on them.

Next goal: make actual game.

Well, this is just wonderful. Already in love with my devious alien pirate.

I didn't get a lot done in the past few days, but I made some important progress today, mostly relating to the game UI and engine structure.

I think I finally have a reasonably solid understanding of what the 'minigame' part of the game will entail and how that will be implemented. It's still highly theoretical, given that I won't have a working prototype of the game running until at least Saturday, which is alarming because the design I'm planning is also highly experimental and may require quite a lot of iteration to get right.

Current plan: I really need to finish off basically all of the engine work tomorrow (drawing stuff, handling inputs, handling game state). Then I need game mechanics and test content implemented by Saturday night, leaving Sunday for scripting the actual game, and Monday for polishing. That could happen. That will happen. Yes.

Assorted notes (mostly for my own benefit tomorrow):

• Although minigames are based on board games, I've ditched the idea of using dice or having multiple tokens / resource markers per player.
• Minigame game state involves only two things: (1) which tile players are on, and (2) what cards each player has in their hand.
• Each "board game" has a specific visual theme and consists of one board and one set of cards. Boards and cards can be mixed and matched to create minigame mashups.
• Every card has one to three stats listed on it (with the number of stats fixed in a given set of cards) and may additionally have one associated categorical value (e.g.: red, green, blue). The labels for these stats given on the cards don't actually matter, they're purely for flavor and are overruled by "house rules" which map stats to some combination of movement, attack (used to hinder another player), and support (used to help another player).
• A minigame ruleset consists of: a rule specifying how many cards to draw per turn, a rule specifying the minimum and maximum number of cards in the players hand at the end of a turn, a rule specifying how to translate played and discarded cards into movement/attack/support points, a rule specifying when how attack/support abilities work (can only use when on same tile as another player OR targets closest player OR choose any player within $var tiles OR pick anyone), a rule specifying what attack/support points do (move opponent, force card discard/pickup/swap), and finally a rule that defines the goal of the minigame (reach a tile, collect a certain number of cards, discard all cards, obtain a certain stat total in held cards, etc).
• Note to self: see notes.txt.

Thanks for the feedback, everyone! All I want to say at this point is that I will be submitting something, but don't expect it until we're minutes from the deadline. I probably won't post any other updates before then, because any free time I have today is going towards getting this done.

It's too soon after the jam for a proper post mortem, but I thought I'd write up some quick thoughts. I think some of the lessons are obvious: I spent a lot of time working on resizable web layout elements, remappable keyboard controls, and of course an elaborate character creator before making an actual game. With all of that initial polish and the dialogue that's mostly a tutorial for a game that never starts, it's inevitably disappointing when you hit the completely abrupt end. I briefly toyed with the idea of making that the point of the game: build up as much hype as possible before dropping a game over scene and promising a sequel (oh boy, oh gosh). I think that would feel like a conclusive punchline, but I didn't trust my writing ability in the early morning enough to pull off the last-minute switch.

A more subtle issue is that I never figured out how to properly structure my dialogue system and game loop and I underestimated the impact the dialogue system would have on the game loop. In my mind, the dialogue system and gameplay control were independent systems that could communicate with each other. In practice, the dialogue system IS the main game loop because game events have to be reported through the dialogue system and game events have to be triggered by the dialogue system to prevent the game from becoming out of sync with its dialogue.

When I was writing the dialogue system, I tried to make it reasonably flexible, putting in a system for substituting keywords with variables and even allowing parameterized keywords (e.g. the text "$TUTORIAL:1$" is replaced by output from a tutorial-text function with parameter '1'). I also let the dialogue system call arbitrary functions, which is extremely powerful but quickly devolves into unmanageable complexity because it's akin to relying on 'goto' statements for everything. One thing that really hurt the project was that dialogue snippets were required to specify callback functions that would ready the next bits of dialogue. There's no centralized loop at all, which is bonkers and leads to code that must contort itself to trigger events in sequence. I've never written a dialogue system before and in hindsight should clearly have spent more time learning about how they're normally constructed.

Another factor in creating a game engine from scratch is that I don't have very good tooling. Having editors that quickly reflect changes in art would be enormously helpful. Most of the art in my game is tweaked programmatically in some way, whether that's the avatar recoloring and layering, the procedural generation of playing cards, or the dynamic layout of UI. I often didn't know how things would look in the game until days after drawing the assets and my process for getting some assets into the game was incredibly cumbersome at first (I spent one afternoon manually saving dozens of layers from one drawing program as individual images, then loading them in another program to copy and paste into layers because the layers weren't being preserved between programs). I was getting better at all of this stuff towards the end of the jam, but it's been a learning experience for sure.

With all that said, if I were to do this again, I'd still try to write my own game framework instead of using a more established one. For one thing, it's fun. For another, I like that making things from scratch presents a blank slate for expression. While Unity and other engines are very cool, I always feel like they're trying to steer me towards making certain types of games. That may be because they encourage making coherent games with conventionally attractive graphics, but I think there's something to be said for the weirdness of homemade game frameworks.