Despite my fumbling, I don't think the game is that hard to understand. If the upgrade screen had a confirmation dialogue that showed up if a player tried to return to the game without spending points, I think I would have figured it out.
Majugi
Creator of
Recent community posts
Thanks a lot for the feedback and the kind words. Reading your notes and Clyde's it occurs to me that "brokenness" of the game is thematically important. Now, you might be saying that just to be nice, but it's no coincidence that the name "Vangrolion" is based on the computer game "Vangers" an incredibly esoteric alien racing RPG that I never played more than a few minutes of at a time before giving up in frustration but still deeply love.
At the beginning of the jam, I tried to come up with a list of "player experience goals" since Danielle's always talking about the importance of them, but I didn't really know what I wanted players to experience. If I were to repeat the same exercise now, I'd say that I want players to have a shared experience with the NPCs of unpacking these impenetrable but tantalizing artifacts and making them into living games.
One of the inspirations for this is the card game "Mao" which is basically a game about figuring out the rules of the game. I actually tried to make a computer game out of Mao a decade ago, but failed to get anywhere with it (possibly because I didn't really have a clue how Mao is actually played). At any rate, I've retained a fascination for Mao and Calvinball and other games about inventing the game as you go. It would definitely be easier (and perhaps a better player experience) to avoid programming the minigames and simply use them as a narrative device in a visual novel, but it was important to me that players really do get to participate in playing and shaping these games.
In the original plan for OhBoyOhGosh, players would start combining decks of cards from various games together after the first game (shuffling different decks together is even technically implemented in the jam release, though of course that feature is never used). I hadn't thought of it in terms of a "failed" game night exactly, but I could see how it'd be fitting if some of the motivation for adding crazy rules was because the original game wasn't working.
When the Jam ended, I really wanted to get back in and fix the game to make it playable. Now that a bit of time has passed, I think I prefer leaving this version alone, since it really is the best I could do for New Jam City. I am, however, planning a spiritual successor with a different name.
ddnoa_win7.exe briefly shows the debug box but still doesn't launch the game for me. I tried ddnoa_32_v2.exe and that did work, but I thought it was broken because I could figure out the controls. ddnoa.exe also seems to work now, and I did figure out the controls with that version (it seems to be WASD + 'F' to select an action, but you need to select an action when it says "player turn" and the turns are time-based so it's kind of an RTS although you're limited to one attack per turn).
Windows issues aside, I thought that was neat. I tried to see if there was some sort of pacifist ending, since the messages seemed to imply there was some other possible outcome, so I took the final enemy down to its final sliver of health then didn't take the last shot. What ended up happening was that I got killed and then, when I went to start a new game, the boss and my body and the boss remained on the top level and I kept getting killed over and over before my reincarnated body could make it to the devil on the lower level. I feel like this is symbolic of something, but I'm not sure what.
Pictured above: me, in purgatory.
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.
Thanks for playing!
Your experiences match up pretty closely with what I was expecting. In my ideal version of the game, I'd avoid the rule dump by having the games be extraordinarily simple to start then adding in "house rule" rule changes throughout the game. The original concept for the game was that the game would evolve over time as the group kept making "sequels" to a base game. Winning/losing wouldn't matter too much at first since the game would be almost entirely luck based, which is why I wanted to do the Poker Night at the Inventory thing of making the main draw be the conversation around the game.
Ultimately, most of that didn't make it into this prototype since I started programming card rendering last night and didn't get to gameplay programming until after midnight. By the time I was coding the 'real' game, my brain was already effectively mush. The character creator represents at least 90% of the time spent on the game, which is why it's a little more polished.
Update: I have a dialogue system. This is a big relief, since I'll now at least have a talking simulator working, though I'd still like to get a game in there.
There's even a demo: http://www.majugi.com/games/OhBoyOhGosh/
I was feeling a bit down on my project lately because I'm lacking a functioning engine and art assets (aside from characters). It's a little tough working on one knowing the other won't be there, so I spent a bunch of time today essentially drawing concept art that I probably won't be able to use, just so I have something to look at.
I started with "box art" for fictional board games that are played within my game:
...and then tried to make cards and boards that would be a part of these games. I ran into the obvious and extremely predictable problem here that actually making art for several board games and card decks is rather a lot of work, even when using public domain images. I still made some funky designs though:
...after which I came to my senses and realized that I'm going to need to stick with my strengths and design cards that can be procedurally permuted instead of relying on manual drawing / photoshopping. I then went back to programming stuff, and now finally have a method for drawing character avatars in little circles to represent game board tokens while also being able to draw them at a different size in the avatar display box that's part of the dialogue system, which brings me one step closer to having a functional game engine (I just need card rendering, board rendering, and a bunch of control widgets).
Man, I've done so much work on this, and it's not even remotely playable yet. Game dev is stressful, y'all.
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.
This might be my second most anticipated game at the moment, after Pyre.
For the range marking, I think it could fit the style of your game to have the ground plane just change color in an area around each character. I think it could be made to look like some sort of corruption or force that's spreading out from each character (which would be more convincing if the range box left behind a fading trail so it doesn't just look like the characters are running in place on top of moving platforms).
Basically a better version of this:
It could be possible to roll the health bars into that visualization, since I initially thought your health bars were hitbox markers when I first saw them. Anyway, just an idea. Feel free to take it or leave it!
The glitch art seems like a good idea to me. I don't think it changes the "fairness" of using the original art one way or the other, but it could give your own project a more distinctive and cohesive look, particularly if you're using art from multiple sources. Making the image less static is a big plus in my opinion.
I don't entirely get what your UI will look like and how the glitches will play into the story, but I feel like there must be some way to spin the story for the visuals to make sense. Maybe your salvaged computer is having issues. Maybe the fluctuating power levels in the bunker mess with your screen. Maybe the apocalypse was something that specifically affected computer systems. Maybe you're watching your own stream so you can tell what viewers are seeing. Regardless, if there's one thing that video games have taught us, it's that players are usually willing to accept narrative dissonance if it's stylish/fun.
This was fun! I think I found all the endings (assuming there were four). I saved the "no romance" playthrough until the end, and was expecting it to be kind of awkward picking all the unsociable responses, but I actually appreciate that even in that scenario, the interaction feels friendly. The no romance ending does a pretty good job of subverting the expectation that starting a relationship is the win state, which is nice. I'd pretty much never consider speed dating in real life, but this game's helped me understand why some people would, which is also cool.
I'm trying to come up with some constructive criticism, but there's honestly not much that comes to mind. More #content would always be good, of course, but in some ways it's nice that the game is short enough to accommodate several fast playthroughs. Oh wait, I do have a criticism: socks are a cool gift for hip young people okay? Also, sharks are gentle ocean friends that wouldn't harm a puppy.
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.
Today was almost a really productive day, but I got stuck working on a few really annoying technical problems. I finally have character rendering working properly and just need to throw together a UI to set parameters (because I have a whole lot of parameters). I really wanted to get the character creator UI done tonight, because passing the "getting something interactive" milestone would be pretty satisfying, but I'll have to leave that for tomorrow.
Here are a few screenshots until then:
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.
This is looking real good. I like the idea of leveling on failure and how that ties in to the title (oh, I just got a little murdered, nice). I'd be a bit wary of making the game in such a way that "grinding failure" becomes an optimal strategy, but you probably don't need to worry too much about that sort of balancing issue for a jam game. It's also looking good in the literal sense; the aesthetic you've got going is great.
One thing that I always think about with 2D characters that can move along the third dimension is how hitboxes will work along that dimension. It'd be nice to have some sort of cue when characters are on the same plane (or about to be).
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.
Coincidentally, I now understand this idea because the FF12 Gambit system was discussed on Waypoint Radio after this was posted. It sounds like a really cool system and I'm looking forward to your take on it.
Goes to check out Twitch stream.
Twitch is protesting for net neutrality.
Some other time then.
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