We hope you are enjoying the pre-holiday season! Time flies when one is busy. And we surely have been after the latest big //TODO: today update. After a few days of rest we jumped right into the Yuri Game Jam 2019 as we’ve announced before. We thought it would be interesting to change things up and make a cute game about girls and music!
However, we didn’t only explore new themes...We wanted to use this time frame from late October to the end of November to try a new project pipeline at BL+ as well! ᕙ( ˘ ∧ ˘ )ᕗ
So Felix who’s been writing and scripting in Ren’Py for our visual novels learned to apply his programming skills to the open source engine Godot. He’s been making 3D art in the past as well and went back to that but put down 3DS Max for Blender.
Rohan who’s mainly been our 2D artist and designer, who had only touched Maya on few occasions, also learned to use Blender. One could guess that this game wasn’t any usual 2D visual novel styled game. That’s right. We wanted to make a music game (unlike classical rhythm games!) in a cute 3D setting with a lighthearted story.
Now with November having ended, our time for this experimental project is over and we plan to be back on Brassica in December. Therefore, we couldn’t finish it. ( ･ิ,_ゝ･ิ)
Buuut if you’re curious about what we learned during conceptualizing a music game, working in Godot and Blender and how we fought through this project - get comfortable and let us tell you about our project Songbird’s Song!
We began thinking of games we could make for the Yuri Game Jam since August. We soon agreed on two things: One was that the both of us didn't want to make a game with unnecessary violence and the second was that we wanted to make a game that’s not exclusively a visual novel.
By October we have thought of an adventure RPG that features mechanics of a rhythm game and eventually decided on a simpler game concept which focused on the music and had a brief storyline. In short, something we thought we were able to produce in this limited amount of time. (´-ω-`)
You can read about the details on game mechanics the section about Gameplay + Mechanics.
The visual development began after we put down the foundation of the concept. Routinely, the both of us then spent time researching interesting themes and putting together moodboards we then present to each other in a meeting. More details on what we agreed on in Characters and Environment Modelling.
A girl. A crush. And a confession. There's lots of singing involved. And a little songbird with the wisdom of the ages teaches our heroine how to move others through the gift of song.
We can’t tell too much here. Wouldn’t want to spoil anyone, should this project be picked up again in the future. :x
We kept our character cast as small as possible. At the core we planned to have a protagonist, her crush and a character who guides the player into the gameplay mechanics. An additional (optional and expandable) group of side characters would help liven up the world of Songbird’s Song.
For the visual style of the characters we looked into games with simplistic depictions of characters and low-poly models by various artists. We also kept in mind that we needed to be efficient when creating assets for the game. Unnecessary details or ones that would make the production complicated were kindly let go.
Searching for interesting themes for our project we also found that taking inspiration from Art Deco poster art would be interesting. These are mostly minimalistic and focus on composition with a limited colour palette. Especially covers of fashion magazines and fashion related ads and photography depicted female figures with such a confident laidback elegance that I was instantly inspired to add these to our collection of character references.
We thought that our heroine would be someone who has never created any music before, although she was very motivated to learn about it. We wanted her to be an artsy person with interests relating to music. Because lyrics are an important part of the songwriting process we decided she would be a literature student.
I didn't want to give her the stereotypical glasses and went for a more adventurous yet uptight look. Her colours were inspired by Art Deco posters but also by colours of tropical birds. The shapes of her clothing and her hair were also inspired by these themes.
Historical Side Note:
Women in Western countries during the 1920s and 30s began cutting their hair short, even going so far as to go to the barber’s with their female friends for the chop. Aside from being a widespread and hotly debated fashion trend, this was also a movement of women who wanted to promote the rise of intellectual women at the time and their independence from men as well.
I imagined the crush to be someone who’s graceful and invited her into this musical world. She would be someone the heroine admires. The crush has a feminine and mysterious air surrounding her as well. Crushes are mysterious beings after all.
Guiding our novice singer is a great, but very very small, songbird. The name of the bird species I mainly referenced is dreadful. The long tailed tit. It’s a really beautiful bird. When they have dark colourings above their eyes, these can look like very fierce eyebrows. They also have a dark colouring along the sides and back of their head which resembles the balding mane of an old man. A perfect combination for a fierce little bird who knows it all.
About Concept Art for 3D Modelling
If you’ve seen my concept art for our other visual novels I’ve made, you will see that these are a bit different.
If a concept is intended to be taken as a reference for 3D-modelling it’s very helpful to show characters from different perspectives. It can be a waste of time to stubbornly draw a front, side and back view of any character though. That’s why it’s economical to draw the character in a pose that shows most of their design clearly first. I didn’t pose them in any fancy way for that reason. I might have been lazy too. For parts that are hard to understand just by looking, for example ornaments or parts that are covered but important to know during the modelling process, it’s best to draw them out separately.
I think it’s good for a concept artist to understand that they are communicating ideas to other people. People who they might not have the time to explain every detail of their designs to, so the pictures (and annotations) have to. Most people who call themselves concept artists probably already know about this. ( ･ิ,_ゝ･ิ)
It’s good to always consider the person(s) who will model your designs too. Felix had already modelled designs I made in the past, so, smooth sailing! But whenever I draw concept art meant for 3D-modelling some of the questions I ask myself are:
“Are they experienced and good at understanding your designs?”, “Do they interpret a lot and do things their own way?” or “Do they need extra annotations and detailed front/side/back/top/bottom/3/4/alternative views because they’re new to character modelling/the model needs to be perfectly recreated/it’s part of their workflow to know?”
Project work is a collaborative matter so it’s best these questions are asked directly as well! If possible, the process of creating the character should be done with regular feedback between the artists.
The main idea at the core of our concept was that of writing a love song for your crush. To translate that into gameplay, we decided that there shouldn't be one correct way to create such a song because it is so highly personal. Instead we tried to design the game in a way that gives the player as much freedom as possible while still providing an interesting and sometimes challenging experience.
We discussed a couple of different approaches for this, but what we ultimately decided on (in part because it was the simplest to implement), was to create so called "Song Books" that each collected melodies the player would be able to combine into a song. Because we never got around to implement the whole system, the exact logic behind which melodies work well together and which don't is still a work in progress. One thing we decided on though is that this is mainly dependent on context and the kind of song you are supposed to sing in the game (spoilers: there's more than just one!).
Another idea we had, that was ultimately cut because there was no time to implement it, was to let the player improvise and sing melodies that aren't predefined. This would have involved creating a whole grading system that analyzes the player's melodies and decides what is musically interesting or not and also might have been overwhelming if you're just thrown in at the deep end of improvisation without much direction. So if it had made it into the game, it probably would have been in the form of limited sections in a song in which you were supposed to improvise.
Because singing is a really broad concept and we didn't want to run into a situation where the player practically needs sheet music and a MIDI controller to play (although that could also be cool), we thought about ways to limit the singing mechanics to make things easier for the player and for us. One inspiration for this was Zelda Ocarina of Time and the titular ocarina because it only has five notes (that are required for gameplay, you can actually play much more complex melodies) but all the playable songs in the game are still very distinct and memorable.
We also needed to think about what key we wanted the music to be in so everything the player could play would sound harmonic in the end.
The keys we decided on were D-Major and B-Minor because they go well together and we thought having more than one key at your disposal would open up the player's possibilities even more. Even so, different keys wouldn't equate to different melodies. You could play any melody from the Song Books in either Major or Minor, the only thing that changes because of that is the meaning of the melody and how it's evaluated in the context of the song.
So with the keys out of the way, the next step was to figure out which notes we were going to use. We decided to use five notes just like in Zelda, because it's a relatively small number but the potential for playing different melodies is still a lot bigger than with three or four notes. Actually deciding on the notes involved a bit of trial and error though. I made multiple scales that omitted certain notes to narrow it down to a total of five. To make sure melodies would translate between Major and Minor, I used the relative position of notes in their respective key so if one scale started with a D4 in the Major version, the Minor variant would start with a B3 and so on. We then listened back to these scales and fairly quickly decided on the ones we were going to use because some simply sounded better and more flexible than others.
Gameplay + Mechanics
Out of everything we've made for this project, the gameplay is still the vaguest aspect, simply because we weren't able to fully implement it. That said, we had a lot of discussions about the game design and defined quite a bit of it. Whether or not it would actually work out exactly like we planned and also be fun to play is another matter but we want to at least give you an idea of what we had in mind for this game.
As mentioned earlier, writing songs is pretty much The core concept behind it all. You start out with a basic Song Book that has a handful of melodies you can use to write your song. How exactly this would look to the player was still open for most of the jam, but in the end we decided on splitting the gameplay into two sections: one where you plan your song and one where you perform it. During the planning stages you would have a certain number of bars (the musical kind) to fill and possibly different sections of a song (chorus/verses/etc.). Having different sections would complicate the evaluation a little because using certain melodies in a verse might have different ramifications than using them in a chorus but we also thought that it could be a helpful guide for the player and add a little depth to the songwriting.
The performance would then mostly be about executing your planned song as best as possible. We didn't want this to be a rhythm game so when exactly you'd play a note or for how long would be up to you, but this is definitely a point that would need some iteration to get right. We considered implicitly setting a rhythm with the background music which would probably just add some ambience and/or simple percussion. Having a time limit or a set background track would be an alternative way to handle this but could also make the game more stressful than we wanted it to be. In our current plan, the time limit is a little more subtle because it's not actually time but how many notes you can play.
Another mechanic of the performance is breathing. We decided to set a limit to how many notes can be sung in a row before you run out of air, in part because it made sense narratively (our heroine isn't a formally trained singer after all!) and also because it seemed like another way to make the performance more interesting. Because melodies can have different lengths, you would have to plan when to breathe so you don't run out of air in the middle of a melody.
To add some variety to the gameplay over the course of the game, we also wanted to include different challenges to make the player think more about how they construct their songs. So the actual evaluation of your arrangements would differ depending on what your goal was. That way, the same song that was a success in one challenge, might be a total failure in another.
Between challenges you would also unlock new melodies and sometimes new mechanics (like switching between keys). Increasing the amount of notes you can sing between each breath was another way of progression we thought of that also made sense narratively because at the end of the game, the protagonist would definitely be a better singer than at the start of it!
One of the reasons we decided to work with Godot is because it's open source. I tried it out a few weeks before the jam to see a bit more of how it works and how it compares to engines like Unity or Unreal Engine 4 and actually really liked how lightweight and streamlined it was. The fact that GDScript is similar to Python also made the transition from Ren'Py a lot easier so even though I only really scratched the surface of the engine, I felt confident that at the very least for this project, Godot seemed like a good choice.
For the first week or so of the jam, I worked on a prototype that included the basic singing mechanics and the logic to figure out what melody you are playing.
Because I needed some sounds to actually build this prototype, I spent the first day or two developing the voice of our protagonist and the technical details of how it would appear in the game. We briefly discussed how we wanted her to sound and ultimately landed at a Vocaloid-esque voice that was clearly recognizable as a singing person but didn't have to sound completely naturalistic. I used the free Alter/Ego plugin by Plogue because I already had some experience with it so it seemed more sensible than trying to get into Utau or actually investing into a Vocaloid. After experimenting with a few different voice banks, we decided on Karoryfer's Marie Ork because it's easily the cleanest sounding voice available for Alter/Ego (and it's also free). The next step was to customize the parameters until it sounded like our protagonist was supposed to sound and then the fun part began! By which I mean I basically built a simple sampler instrument to handle the singing sounds in-engine.
Avoiding repetition was one of the most important parts of creating the sounds in my opinion so I knew I wanted to include something like a round robin feature (in samplers this basically describes variations of the same note that are played either in sequence or randomly just so you don't hear exactly the same recording every time you repeat a certain note).
Using basic syllables of different vowel sounds, I exported eight versions of each note and set it up in Godot so every time you pressed a button to sing, it would move on to the next variation. I briefly considered adding loop sections so you could hold a note indefinitely, but not only did this prove difficult on a technical level, it also didn't fit the image of a novice singer and therefore our protagonist. Each note can be held for about four seconds which was more than enough for what we needed anyway. Because you can also just tap a note, the actual length that is sung is highly variable. We didn't plan to explicitly make this part of the gameplay but instead thought it would be a good way for the player to give some personal touches to the predefined melodies since the rhythm was entirely up to them. Because the notes could be ended at virtually any point in the sample, I also added a subtle reverb on the channel the sounds were played on to make the end less abrupt.
The logic side of the prototype was relatively simple. Once the controls were implemented, I basically just stored the player's input in an array and compared this with the list of predefined melodies. At first this was hardcoded, once we had written all the melodies though, I put them into a JSON file that was read and parsed at startup so that we could simply modify this one file if there were any changes or additions to the melodies.
To summarize the melodies’ structure: each note corresponds to a number between 1 and 5, so a melody is basically just a list of its notes. I stored them in nested dictionaries so we had all the Song Books separately and also had a name for each melody and room to add tags or other meta-data to them so the game could evaluate them better.
Because making mistakes while playing melodies was inevitable, we also needed to give the player a way to reset the melody they were playing and start over. Our solution to that was to give the player a dedicated "breathe" button that did exactly that! As mentioned in the section about the game's design, we also decided to make breathing a part of the gameplay by limiting how many notes you could sing before you run out of air.
Switching from D-Major to B-Minor is also done by simply pressing a key (pun not intended) and all it really does in the game is change which samples are played when singing each note. While storing the input, it also turns the numbers negative so singing the first note in a Minor key would result in a "-1" instead of a "1". By doing that, we are able to give unique tags and qualities to the Minor version of a melody without having to hardcode it in the game logic. Additionally, it also makes sure that you can't just switch keys within a melody and still have the game recognize it as being played correctly.
Well, and that's about as far as the prototype went. The functionality to check melodies for tags in order to evaluate their placement in a song is there but between work on this and doing all the 3D character art, I unfortunately didn't have the time to actually implement the song logic that would turn this basic prototype into a game.
Character Modelling + Rigging
Before BL+, 3D art was actually my main focus so as far as theory goes, none of what I had to do to make the characters was new to me. The main challenge was to get back into Blender after not working with it for well over three years (and adjusting to all the changes in 2.8) but even that stopped being much of a problem eventually.
For the protagonist, even though most of her body is covered by her skirt and coat, I started by making a base mesh that we would be able to adapt for other characters as well. I used the side view from the concept art as a main reference for the proportions and eyeballed the other perspectives based on the concept (and help and directions from Rohan).
The face and hands remained fairly simplistic. We chose not to model separate fingers and instead treated the hands more like mittens. Similarly, the nose and eyebrows are the only modelled features of the face because we wanted to keep the eyes and mouth 2D. To that end I also made sure to find a good compromise between modelling a believable face structure and keeping the parts where eyes and mouth would be as flat as possible so there wouldn't be any distortions in the texture.
The skirt and coat of the protagonist were also closely referenced with the concept, although it took me a while to figure out a good (and efficient) way to model the rounded edges with even sizes and roundness. We decided to keep her clothing single faced because with the graphical style we were going for, it didn't really matter whether or not it actually had volume and only having half as many vertices would simplify the next few steps in the pipeline.
Because single surfaces are also invisible from the other side, this approach would have forced us to use double-sided materials in the engine but within this single month of development we didn't get to this step quite yet.
Her hair also turned out to be the most challenging aspect to transfer from 2D into 3D so once I had finalized the basic topology, the final shape was created almost entirely in dialogue with Rohan.
Since we only had flat colors and no patterns or gradients, we decided to make a texture atlas for all the characters to save some memory and to also save time in the UV mapping and texturing process. The UVs could be really messy because any stretching that would occur with more detailed textures is invisible with flat colors. All the areas of the model that were supposed to have a certain color basically just have their UVs scaled down into the corresponding square on the texture atlas. This also meant that any details that weren't a separate mesh (like her belt or her vest) had to be "modelled" as well.
And by that I mean that I added additional edges onto the surface of the base mesh, that are really only cosmetic in nature. Another upside of this is that no matter how close you are to the model, the edges are always nice and sharp, but of course their roundness is also subject to how high- (or in this case low-)poly the model is.
The bird that teaches our protagonist how to sing (affectionately called Sensei within the team) was even more closely based on the concept art, because for him Rohan made orthographic views from pretty much every important angle.
I based his size on the protagonist since I had her model already and there was a handy guide in the concept how the two relate. I then started by blocking out the basic shape of the body.
During that process I also tried to keep in mind how he would move and what topology the model would need for that. For example, I briefly considered adding additional edge loops to the neck in case we wanted to stretch out his head from time to time for expressiveness but scratched this idea because one of his appeals was how compact he is and for most of his movements, having a smaller number of edge loops would probably lead to smoother deformations.
For Sensei's tail and other markings, I followed the same technique as with the protagonist and simply modelled out the lines where different colors would be. His feet were definitely the most finicky part of the modelling process because as it turned out, he was small enough that Blender started culling the view when I zoomed in close enough to do some fine tuning on the topology.
Compared to the rest of the model (and especially the protagonist) the smaller details of Sensei are more high-res than they should have been relative to their scale, but we figured even if they were essentially single pixels in the game-view, you would still see if he had separate claws or just a single block connecting them all. As a compromise, I made it so his legs and toes have a triangular cross section, meaning they would keep their volume from all perspectives with as little complexity as possible. I also didn't add any edge loops outside of what was necessary for the shape because only the heel and the knee had to bend.
Sensei's beak and eyes are separate meshes to keep the topology of the body as simple as possible and even his eyebrows/hair are their own object because the shape was complex enough that it was easier to just model it by itself instead of trying to cut it into the topology of the body.
The wings were made in a similar fashion as the protagonist's clothing, in part because there were similar shapes involved. The feathers are once again one-sided and a single connected mesh. Only the upper part of the wings has volume and merges into the surface of the feathers. Whether Sensei should be able to fold up his wings was probably the one aspect of the models we discussed the longest, because wing rigs that fold up neatly can turn out really complex and we didn't have the time for any risks that weren't strictly required.
(A side view of Sensei, showing the flat nature of his wings.)
In the end, our graphical style and Sensei's small size were the main reasons I thought it would be possible to make his wings fold because any stretching within the model would be invisible and we didn't have to strictly adhere to realism.
The rigging process for the wings was otherwise relatively straightforward. I simply treated them like arms and set up an IK rig for them. I added three bones to control the feather surface and parented and/or constrained them to the "arms" so they moved along as naturally as possible. Because there wasn't much time, the rig isn't the most comfortable to animate because the feather bones all need some manual adjustments for wing movements to maintain a nice shape, but it seemed like the best pay-off since investing any more time into the rig wouldn't be worth it for how little time we had for animations. I set up the rest of the rig manually, with simple IK chains for the legs and basic FK chains for spine/neck/head and the tail.
(Sensei's rig and a simple showcase of how his tail bends despite only having three bones.)
Blender's automatic weights worked surprisingly well for most of the body and only needed some adjustments for the legs and hip and for the right balance of clipping and deformation around the head area. I also smoothed out the weights of the tail so it would bend a little better with how few bones I used and did some general cleanup so there were no unwanted deformations at other parts of the model.
(A test animation for the folding wings.)
Skinning the wings was definitely the most time consuming process as far as rigging Sensei went. The main problem I ran into was that I had fewer bones than wing segments so it took a lot of fine tuning to not completely destroy the round feather edges while the wings moved. Aside from that, I also made sure that the "arm" bones had little to no influence over the feathers. I did this because the way I wanted to handle folding up the wings was to scale down the feather bones and let them clip into Sensei's body so we would end up with as compact of a shape as possible without any obvious deformations.
(Turnaround of Sensei.)
(Turnaround of our heroine.)
For the rig of the protagonist I used Blender's Rigify feature because that was the fastest and easiest way to set up a humanoid rig that has all important features and custom controls. I still customized Rigify's metarig quite a bit because we didn't need more than a thumb and a single finger to control the hand (and even then I removed one joint in each chain since those parts are very low poly and we wouldn't need too expressive hand movements). I also deleted all the bones for the face and just added a single bone for each eyebrow.
Generating the final rig from the metarig took some trial and error because Rigify discards any custom bones that aren't assigned a type and all its types not only lead to different controls but also each have specific requirements for how they're set up. Not meeting the requirements leads to an error during the build process but once you figure out how you have to use it, it's actually a really powerful feature!
(A test pose with our rigged heroine + temp face and badly skinned buttons...)
For the skinning I started at the bottom layer and adjusted the weights of her body before moving on to the skirt and then the coat. In hindsight, it maybe wasn't very economic to make sure the arms and legs deform correctly when almost their entire shape would be hidden behind clothing but if we ever end up making the other characters or show her with different clothes, this will maybe come in handy :'D
I also think having the lowest layer move properly helped to make sure the ones above it also look correct when they move.
Skinning the skirt turned out much easier than I expected but the sleeves of the coat caused a bunch of problems because there was a lot of clipping around the shoulder area and making it look good in one arm position often lead to clipping or weird deformations in another. Ultimately, I managed to fix most of these problems but even now there are probably ways to improve the rig and skin weights. For what little time we could spend on it, I'd say it's good enough though!
I have used Maya in my past to model very simple things. And most of my time using Maya I rigged, skinned and animated models. So starting to use Blender for modelling seemed scary for me at first. It has been two years since I worked in Maya too. Although this long break turned out to be advantageous for me. (ﾉﾟ▽ﾟ)ﾉ
Like we’ve mentioned above, to make our work more feasible the style we decided on would be simple with a low poly count. In addition to what Felix already researched, I collected more reference images, mostly screenshots of other games, of assets that were closest to what we wanted in Songbird’s Song.
Then I switched to concept design again and collected references of furniture and interior design. We agreed on a look that is inspired by Art Nouveau but would be contemporary. After having collected a useful amount of pictures I began sketching in Clip Studio Paint. However this process of pushing objects around in CSP and adjusting colours took so long - I thought: I was going to do the same in Blender so why not go directly into modelling now?
Although the designs weren’t done I had the gist of what furniture and other pieces we needed for the first room. The heroines bedroom and the regular hangout place of Sensei. This sounds kind of wrong haha. Not having pinned down the exact designs meant that I could change them depending on what I could easily make in Blender. But it also meant that I was searching for more reference pictures during the modelling process. This can be distracting during work.
I started off with making something I thought was easy to get familiar with the Blender 2.8 UI and some simple shortcuts. I watched part of a modelling video to understand how object modelling can be approached in Blender and went into modelling a shelf. Which is basically a fancy box. Then the other things followed.
Now, I’ve said that taking a break from Maya was advantageous. This became apparent when I began using Blender. I had to look up Blender shortcuts to do what I wanted, but my basic knowledge of how object modelling can be done in a 3D software was still there. It seemed that these two years completely erased Maya shortcuts from my muscle memory and my knowledge about where certain things can be found in the UI. In the end I wasn’t confused about “switching” to Blender at all.
Here is what I could finish in the short amount of time. To keep the environmental objects consistent to the character designs I mostly used the same colours for them and extended a texture atlas Felix made with more varieties of closely related colours. The object size is close to real life measurements but were set in relation to the size of the model of our heroine Felix sent me.
The assets are lit by the viewport flat shaded lighting in Blender which is great as a reference, as we wanted a similar look for Songbird’s Song. I tried to recreate this flat shaded look and adding more interesting coloured lights but I couldn’t get it to look right. Setting the object’s materials to “emissive” seems to be a good starting point though.
Project Work Approach
We changed most of our pipeline for this little project for the time being as well. This new type of project for BL+ demanded a different approach. We have written in past devlogs that we usually manage our project tasks through Clubhouse which is similar to JIRA. Because of the Yuri Game Jam setting we passed on Clubhouse and wanted to work more spontaneously and flexibly so not to put any extra pressure on us. This also meant that communication between us was more frequent as we had to keep close eye on our progress.
The conceptualizing phase was the same for Songbird’s Song as for any other project we worked together on. A bunch of meetings and long discussions on the way home, exchanging and researching ideas.
The production phase started with Felix beginning to prototype in Godot while I designed the characters. When the designs were done Felix used them to start modelling characters and I began working in Blender. This is roughly the phase we were still in when November ended. These main tasks were put on hold when Felix went back to the engine to expand the prototype, after meetings in between to further develop the game mechanics and systems. On one evening, when the office was empty except for our team, Felix started his DAW and I took out my ukulele and we played some music to determine the melodies. This was a nice change from our usual work.
During the weeks of October to the end of November we learned a lot of new things. There were several reasons why we didn’t manage to hit the deadline with a finished project though. One of them was our more relaxed scheduling (without Clubhouse). However, this was an inevitable reaction to our latest works.
We’re usually very passionate about making our games but this fire has burnt us too many times, leaving us exhausted (you know, burnt out, lol). And usually we just keep pushing in spite of being tired. Although, this approach could be a short-term solution to ongoing tasks, the exhaustion drags on out to future projects, we realized. Surely not recommendable. We have started to take measures against such scenarios since the beginning of this year, but we’re still evolving and always trying to improve. We hope you’re regularly checking in on yourself and hope that you’ll take your time to rest between work or studies! (●´□`)♡
So while we're still happy with the concept and what we managed to produce during the Jam, at least for the near future we don't plan to continue working on it since there's already a lot on our plates as far as projects go.
And finally, we realized that we are able to work projects that aren’t visual novels as well. New types of projects mean that it’s harder to estimate the time needed to finish tasks. On a whole this is big news though! Because BL+ could embark into new kinds of fun and interesting projects from here on out! (oﾐﾟﾛﾟﾐ)o
PECTIN + eZombo
The core team of BL+