In a future where humanity has taken to the stars, and where alien symbiotes can temporarily share a willing human host’s body, play as an alien thrown into the middle of an awkward romance and mystery.
The Ishin aliens have the ability to transfer their minds into willing hosts – sharing the space with the existing consciousness.
The first host is a shy, in-love bio-engineer who hopes the alien can give him the confidence he needs to ask out the person of his dreams, but things don’t go as planned, and when the alien returns to the mine base and into the second host, it’s for a much more urgent, and darker reason.
Xenopathy is a hybrid romance/mystery visual novel that was written, drawn, and coded in two months for Yaoijam 2018
Good progress this week! The entire first half of the game (the first three days of in-game time) has been edited with a first pass. Looks like we’re landing on 19,137 words as the approximate size of the first half of the game.
Also all of the sprites and backgrounds are staged in!
The backgrounds will need some editing and/or replacing, the script could use another editing pass, and we still need to stage in all the music, but we’re approaching completion of the first half of the game!
I’ve also made some tweaks to the UI. The save/load screen and the preferences screens both look better now.
We slightly missed our goal of half the game being done by the end of June, but not by much!
Over the next week, I hope to finish up script edits, find and stage music, and finish the UI work, and then we’ll have at least half a game that is shippable.
Sorry for the delayed update this week; I was away for the second half of the week. Anyway, it’s week three of @yaoijam and there’s been a lot of progress!
@soulsoftea has finished three sprites (Axton, Bethan, and Cian).
He’s also started some character work on Erdon, who’s looking great.
In the writing department, we’re over 12,000 words into the script. We’ve still got sprite staging and music to go, but I think we’re in a fairly good place at this point.
Another week down in @yaoijam, and we’re making great progress!
The majority of what’s gotten done this week is spritework: @soulsoftea has been doing a great job churning out awesomeness. Since last week, we have final designs for both Bethan and Cian.
@pmscenarios has continued doing a great job on world building and character backstories. Almost all of the characters have been fleshed out at this point, and we have a good idea of the whole plot.
Stuff in the writing department (Bobco™ division) is proceeding perhaps a bit slower. I’m doing a rewrite of the first part, to better fit our desired characterizations and style. Life has gotten in a way a bit, but I aim to at least be through the rewrite of day one this weekend. Otherwise, the rest of the first half is fairly well stubbed out, except for day three.
We’re one “week” into Yaoijam (only because we started early), and we’ve made a lot of great progress!
@pmscenarios has been doing a lot of research, story planning, and world-building. There’s not a lot to directly show there, but suffice to say, this is probably the largest part of what’s gotten done over the past week.
@soulsoftea has been hard at work on the first sprite, Axton. We got a few different variants to start the conversation on character design, and got to a rough sprite for him, but he’s already looking amazing!
As for me, after getting some stuff done on the GUI, I’ve mostly been writing. We have a (very) rough draft of day one, along with the beginning of day 2. We’re also 7000+ words into it, so that’s some decent progress.
Next week is likely to be more of the same. My goal is to have a super rough draft of the first half of the game done, and possibly also some further GUI cleanup.
Part of the GUI work I did for Xenopathy was converting traditional buttons (in the quick menu, game menus, and confirmation screen, for example) into images, with hover tooltips that provide an explanation.
This is fairly straightforward to do in the quick menu/game menu case, where the location of the tooltip is fixed. You can even apply AT effects to the tooltip to make it fade out or whatever. I believe this is also the more “traditional” way of doing tooltips.
First thing’s first: We’ll need to define a screen to hold the tooltip text and a transform to show and hide it. In this case, the tooltip fades in as it moves leftward out of the buttons, and fades out as it moves rightward back into the buttons.
screen mm_tooltip(ttcontent): zorder 9999 text ttcontent: xanchor 1.0 yanchor 1.0 ypos 1035 xsize 300 ysize 100 at mm_tooltip_show font gui.name_text_font transform mm_tooltip_show(delaytimer=0.0, duration=0.25): alpha 0.0 xpos 1305 parallel: linear duration alpha 0.5 parallel: linear duration xpos 1265 on hide: parallel: linear duration alpha 0.0 parallel: linear duration xpos 1305
Next are the actual menu items themselves. You can lay them out however you want, but the important part is the “Show” action for their hover attributes. (I’ve also added ATL effects, not shown above, to the buttons themselves so they fade in and out, in addition to the tooltip text.)
screen game_navigation(): hbox: style_prefix "navigation" xanchor 1.0 xpos 1800 yanchor 1.0 ypos 1045 spacing 4 imagebutton auto "gui/menu/return_%s.png": hovered Show("mm_tooltip",ttcontent="Return") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), Return()] at qm_at imagebutton auto "gui/menu/main_%s.png": hovered Show("mm_tooltip",ttcontent="Main Menu") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), MainMenu()] at qm_at imagebutton auto "gui/menu/history_%s.png": hovered Show("mm_tooltip",ttcontent="History") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), ShowMenu("history")] at qm_at imagebutton auto "gui/menu/save_%s.png": hovered Show("mm_tooltip",ttcontent="Save") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), ShowMenu('save')] at qm_at imagebutton auto "gui/menu/load_%s.png": hovered Show("mm_tooltip",ttcontent="Load") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), ShowMenu('load')] at qm_at imagebutton auto "gui/menu/about_%s.png": hovered Show("mm_tooltip",ttcontent="About") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), ShowMenu("about")] at qm_at imagebutton auto "gui/menu/prefs_%s.png": hovered Show("mm_tooltip",ttcontent="Preferences") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), ShowMenu('preferences')] at qm_at imagebutton auto "gui/menu/quit_%s.png": hovered Show("mm_tooltip",ttcontent="Quit") unhovered Hide("mm_tooltip") action [Hide("mm_tooltip"), Quit(confirm=not main_menu)] at qm_at
So this is all well and good… but notice that we’ve had to hardcode the position of everything above. In particular, the location of the tooltip screen’s text was hardcoded to be placed next to the menu buttons.
What happens now when we’re dealing with a modal screen (like the confirmation dialogue) that isn’t always located at a consistent place on the screen? We can’t exactly place the text at a certain x/y coordinate and expect it to look right all the time.
I tried a few different things for this… the most naive approach was to copy the above approach, and use the “use confirm_tooltip” to include the screen next to the buttons. While this does indeed show the screen, it also strangely results in the screen being shown twice: Once next to the buttons as expected, but again in the top left corner of the screen on hover.
Instead, I kind of hacked around the problem, using simple text elements that are rendered (or not) based on the state, and attaching ATL effects to them. This is definitely not ideal, but it does work.
In this case, we only have one screen (the confirmation dialogue itself) and attach transforms directly to text elements within it.
screen confirm(message, yes_action, no_action): modal True zorder 200 style_prefix "confirm" add "gui/overlay/confirm.png" default tt_val = "" default tt_last = "" frame: vbox: xalign .5 yalign .5 spacing 20 label message: style "confirm_prompt" xalign 0.5 text_font gui.name_text_font null height 25 hbox: spacing 4 yalign 1.0 xalign 1.0 if tt_val != "": text tt_val: yalign 0.5 font gui.name_text_font at confirm_tooltip_show else: text tt_last: yalign 0.5 font gui.name_text_font at confirm_tooltip_hide imagebutton auto "gui/menu/confirm_%s.png": hovered [SetScreenVariable("tt_val", "Yes"),SetScreenVariable("tt_last", "Yes")] unhovered SetScreenVariable("tt_val", "") action yes_action at qm_at imagebutton auto "gui/menu/cancel_%s.png": hovered [SetScreenVariable("tt_val", "No"),SetScreenVariable("tt_last", "No")] unhovered SetScreenVariable("tt_val", "") action no_action at qm_at key "game_menu" action no_action transform confirm_tooltip_hide(): alpha 0.5 xoffset 0 parallel: linear .25 alpha 0.0 parallel: linear .25 xoffset 50 transform confirm_tooltip_show(): alpha 0.0 xoffset 50 parallel: linear .25 alpha 0.5 parallel: linear .25 xoffset 0
And… voila! I first attempted to do this with a single tt_val text element, and an “on hide” directive in the transform, but it didn’t work, for some reason. The second tt_last text element is a hacky workaround, but it does do the trick.
There wasn’t much to report for May… until a few days ago. The day job had gotten really busy, and there was no real YAGS asset progress – my sprite artist was on a crazy work schedule for his webcomic (and therefore has had no time for sprites since the first week of April), and my background artist had been unresponsive since January – so I kind of put gamedev and game projects (i.e. AFS) off to the side.
So, of course, the right thing in my dearth of gamedev motivation was to start a new game, for Yaoi Jam. (/s)
It showed up in my Twitter feed (on a rare day when I was actually checking it), and we came up with an idea, so now I’m working on a new game with @pmscenarios. It’s tenatively titled Xenopathy, and is a sci-fi romance thriller kind of thing that will hopefully be a lot of fun to write. (We’ve also enlisted the talents of @soulsoftea on sprites, which will be amazing.)
I’ve spent some of the long weekend working on the GUI for the game. It’s mostly done, minus cleanup of the screen contents (preferences, load, save) and a possible redesign of the start screen. But it’s already easily my deepest dive into RenPy screen language and ATL ever, and I think it turned out pretty well.
In YAGS news, I found a new background artist, Vui Huynh, to finish up the final two backgrounds, so I hope to have all backgrounds replaced in-game by the end of June. Here’s a sketch of the game room.
YAGS’ music is also making progress. We’re only missing two more demo tracks, at which point I can start staging music into the game. I also received the shortened version of the YAGS theme, which I’m going to use to throw together a game trailer (using RenPy!). I assume none of that is happening soon, given the game jam, but hopefully by the end of August we’ll have a lot more progress to report on YAGS.
So that’s been my May… it’s been busy, especially considering almost everything above has happened within the last week.
Not really sure what I’m doing with AFS at this point. I do want to finish it, at some point, but RenJS is proving to be a pain to work with because I can’t run the game locally, and I’m not in the right frame of mind to either be developing live on a server or uploading changes constantly for testing. I might have to research other HTML-based visual novel engines, because using RenPy (and forcing players to download the game and run it) seems like overkill.
