dev-blog #33 - techDemo 0.7.1 and "Patreon Censored Version"

it's christmas time so what better opportunity there is for a new release, right? Right!

After all the struggles I went through prior to my hiatus I can finally show some new features for the game. Unfortunately Patreon changed a part of their ToS during that time which has a big impact on my game: the banning of incest and rape
this directly impacts on how I inteded this game to be and already lead to the demise of the scene that should have come with this update (the scenes concept was worked out way before Patreon changed their ToS).

Since I dont want to miss out on the opportunities and chances Patreon offers I will adapt my game accordingly which means that you won't be able to have any sexual relations with your direct relatives anymore or be able to perform violent rape acts on any other character in the game, as long as you play the "Patreon Censored Version". These changes will take effect with the next release of TechDemo 0.8 as the development of 0.7.1 was already beyond adaptability from coding side.

but now on to the good stuff, whats new in TechDemo 0.7.1:

• BGM integration
  there are now 20 music tracks included in the download that will loop as background music during the game. you can adapt the volume of it to your needs or silence it completely via the Settings menu
  
  
• Foto Mode
  a big part of the final game will be the ability to snap pictures of candid moments either for your own pleasure, leverage or as trading objects with other NPCs. You can test it out in the Shower Scene
  
  
• new Smartphone UI
  originally the Smartphone was inteded to be just "another" menu where you can take a look at the pictures you took in the Foto Mode but then I decided to make it more versatile and replace the quick menu with it. the Smartphone now houses all existing menus and has room for those yet to come.
  
• Area Lockdown
  as many may have experienced: you could get stuck in school really easy. mainly due to the door and dialog system not set up to handle any other "encounter" outside the intended school time because the player should not be there any other time anyway. and now that system is finally in place to make sure nobody gets in to places at times they should not be there. (PS: who wants to be at school on weekend anyway, right?)
  
  
• New NPCs: Deon and Suki
  both, Deon and Suki, are classmates and can be found in the classroom during school time. for now they serve no other purpose than to fill up the place a little but they will get their share of interaction with the coming updates.
  
• file size optimization
  this might not sound too fancy at first but given the intended scope of my game it became clear for me that I might end up with a massively large game package if I keep the almost raw PNGs for my scenes. I did some tests with image optimization tools to find the sweet spot between file size and quality which lead to a overall file size decrease of ~70%. In the long run this will be vital to keep the games download size to an acceptable amount.

and of course many fixes and tweaks.

so what about that "Patreon Censored Version"?

good question that is! I had something in mind like a "patch" that will add in the content Patreon doesn't allow so they get the censored version on their page and anyone who wants to can get the patch from my blog. works like many of the "censored" games on steam that provide an extrenal patch to deliver content which is not tolerated by steam.
But I first need to adapt the backbone of the game engine to account for that change so it could not be added in a quick way to already have it in place for this update.

dev blog #32 - techDemo 0.7 release info and future plans

it's finally time to bring out the completely reworked techDemo 0.7!

20$+ Patrons can already get it here
10$ Patrons will follow on 16th and a
public release will be on 23rd of September


you can check out some of the changes here in the preview videos

apart from a complete UI overhaul the main part of the work on 0.7 was to completely rewrite the code for the new game engine GameMaker:Studio2

in the process of rebuilding the game from ground up I also rewrote many of the internal functions to improve on stability and future proofness for later updates

I completely changed the way that dialogs and "events" are handled
in previous versions it started to become a real mess because there was no clear hirarchy on what gets executed first and which element can influence or change another element

for example each dialog was stored in its own file and was activated or "called" either by an event or an interaction with an object (like another NPC) or by another dialog (yes... chained dialogs)
this turned out to be a lot of trouble because I lost track of who pokes whom really soon and there aren't even that many dialogs in the game yet

so I changed the way it works: dialogs are now stored in groups of the same (like all dialogs concerning the Ficus are in one file) and easily adressed via "flags" so instead of manipulating the dialog directly the game engine switches the state of the corresponding flag and when the player now interacts with something, that something checks its stored dialogs and compares them with the flags and if a flag and a dialog match, you get that dialog shown
this way it is much easiert to keep track of the whole mess and things like Mike bringing Tamara home after school can't happen anymore because Mike has other flags available than Lena so the dialog that triggers the scene with Tamara and Lena will only appear for Lena in the first place.

so in general a lot happened under the hood and not much on the visible side with this update but there will be another content update later this month right in time for the projects one year anniversary at the end of September!

what happened to Gemini?

Gemini is complete now, it has both CPUs and both GTX1080TIs on separate watercooling loops now and is running like a charm.
I already did some test renderings on it and also a little animation render test

that was especially awesome because I once did an animation render test with my older PC (dual GTX970) that was around 3 seconds long (25 frames/second) and had a resolution of 480p (853x480 pixel)
but that animation I rendered on Gemini is around 8 seconds long (also 25 frames/second) and has a resolution of 1080p (1920x1080 pixel) which is 4x the pixel count and twice the amount of frames

and it took Gemini around 5 hours to render all those 200 frames in 1080p which is roughly the same amount of time like my previous computer took for the 90 frames in 480p!

Patrons can get the original 1080p animation file here

speaking of Gemin, thats how she looks now in her final form:

I also designed and built a custom case just to fit that huge Z800 motherboard and both 360 radiators in it. That "little" DIY case project cost less than buying an equally sized computer case and I think it is a fitting case for this hacked together ex-Z800 workstation :D

btw the GPU loop never exceeded 40°C during that 5h render marathon having both 1080TIs running at max load so I'm very satisfied with its performance

so... we can has animations?

well... yes... kind of.
Rendering them is not an issue anymore and I am more than willing to spend render time on animations!
BUT: I need to find a way to integrate animated content into the game that does not consist of loading 200 images in 720p into your RAM for a short fucking loop
I don't know why but GM:S2 still does not support media files natively so I need to find a script or plugin that allows me to add, play back and control media files (like webm) easily so I can pre-fab the animation files as single media files and then just inject them into the scenes or dialogs when needed
this sounds more than doable so I'm confident that I will find a way to add animated content

ok, whats next?

well, as already mentioned there will be another update this month delivering content
this will include the "drunk dad" scene with Lena and Steve and some other content I'm not going to spoil yet :P

dev blog #31 - techDemo 0.6.3 public release and big news

it's time again for a public release!
techDemo 0.6.3 is here and you can get it from the download section.

I fixed some bugs regarding the job minigame so it is now possible to work more than once per day (but not at evening or night)

to trigger the new scene with Candice and Lena (30 CGI) you first need to pay Candice for a show (at the left pole) and then offer Mercedes your help so you get access to the backroom area where you need to talk to Candice to start the scene!

and now onto some news on techDemo 0.7:

I feel like repeating this over and over but development for 0.7 is progressing well and steady.
If nothing major happens to slow me down I think I can finish the transition finally at the end of this month.

Some of the "visible" updates can be seen in these preview videos while other things like game engine and backbone changes of the game are not visible to the users eye and more of changes to the code.






now besides the progress of Twin Star I also launched a new side project called:

Project Gemini:

what's that one might ask. Project Gemini is the upgrade project for my render PC.
As I already announced on Patreon, I plan to upgrade the current render PC with some new hardware, including the new powerhouse GTX 1080 Ti and other hardware.

The upgrade process will be divided into several phases containing different steps of hardware additions. This is mainly due to the current Patreon support level where I have to save up some months before I can make the hardware purchases.

Phase I:
originally I intended to buy one GTX1080Ti in this phase but I figured since I already have a GTX1070 it would be better to swap phases and leave the GTX 1080Ti for later.
Instead it's time to upgrade the backbone of the render PC:

The motherboard will be a server grade dual socket motherboard from a HP Z800 Workstation housing two hexa-core Xeon X5650 processors (6x 2.66 GHz at 3.06GHz boost) giving me a total of 12 cores and 24 threads to work with!
For the start each CPU gets 12GB of ECC server RAM which will be upgraded later to 24GB for each CPU (48GB in total)

The Z800 motherboard was the optimal choice in terms of dual socket motherboards that also provide 2 slots for graphics cards which doesn't cost a small fortune.
A more modern LGA2011-3 dual socket motherboard would cost 2x or 3x the price of the Z800 and one Xeon would cost more than this whole Phase in total. That's why LGA1366.

With an additional 1000W 80+ Gold powersupply this hardware cost around 700$ which is less than the original price of one X5650 when they were released in 2010.
But why this old hardware? Because it is still good and incredible cheap to get!

So what next?
Well first off I need to wait for the parts to arrive over the next weeks and when everything is assembled and functional I can start to render on Gemini instead :)

and then?
depends on how well Gemini works with the installed hardware.
It might be necessary to optimize the CPU cooling first which will result in both CPUs getting watercooled (because those 6-core Xeons get HOT).

Additional 24GB of ECC server RAM are also planned so each CPU has 4GB per core available.

And not to forget the planned dual GTX 1080 Ti that will get watercooled too at some point in the whole upgrade phase.

The watercooling is an essential part of the whole project because both CPU and GPU have clock boost when sufficiently cooled.
The Xeon will boost from 2.66GHz to 3.06GHz without manual overclocking and same goes for the 1080 Ti's as they will also auto-boost.

Watercooling is also way more quiet than pure air cooling with fans as you need less fans to cool the water down as if you would need to "blow" the air on heatsinks on the components directly.
And quiet is what i need! I don't have the room space to put Gemini anywhere else than the room where I work and that's why I will optimize it for beeing as quiet as possible too.

dev blog #30 - bring some order into that chaos

this is just a small update on the progression of 0.7.
Today I had a big breakthrough regarding how to prevent fuck-ups like the mess currently in 0.6.x

as I wrote in a previous blog post, the way I handled dialogs and events was kind of chaotic

this resulted in problems like NPC not responding to you anymore (Mercedes stops giving you job offers after the first round) or responding to you despite they should not (Tamara not rejecting Mike's "learn together" invitation)

initially I thought the system I came up with was future proof but after adding only a handful of interactions with the NPCs and objects it turned out to be more of a "wild west" situation than a clean and structured handling of tasks.
major problem here is that everything could interact and manipulate everything

(simplyfied diagram of the chaos :P )
dialogs could start events or manipulate NPCs directly and events on the other side could do the same which resulted in me loosing track of "who poked whom"
this is a problem especially in "content related" dialogs that should only trigger on certain occasions or with certain NPC so to fight this chaos I came up with a more "centralized" manner of handling dialogs:

events now no longer activate or manipulate dialogs directly. instead they change the state of the "dialog giving" object (NPC, container, door, etc) and based on that the dialog to be displayed is selected which will lead to a more manageable way of interaction because now there is only one place where a dialog trigger can be manipulated

also, instead of letting the timekeeper handle content related dialogs (daily recurring stuff like jobs, school, etc) now each NPC and other objects handle that themselves because that also was another source of problem
keeping the trigger control in one place (on the object that gets interacted with) should eliminate the current state of lost overview, just like the saying "too many cooks spoil the broth"

dev blog #29 - techDemo 0.6.2 - public release and some info on 0.7

the small techDemo 0.6.2 update is now available for the public!
get it from the download section or any of the various mirros on Patreon

you can trigger the new scene only as Lena (for now) when you talk to Tamara after class and invite her over to "learn together"

"that's all after one month of waiting?" you might think now but to be honest I almost decided to not spend time on rendering this month because programming takes up so much time right now.

as I already said in the previous blog entry, I am hard at work getting the game up to the new software version so spending over a week for rendering the scene was a lot of time I did not spend on code.

I will do the same for this month too so don't expect any changes on release schedule or content yet.

The next update will be techDemo 0.6.3 and it will include another new scene that will most likely show Lena and Tamara together (the poll on that is still on for some more days if you want to have a vote on that)

so let me repeat what I already wrote on Patreon:

Progress on 0.7:

so I was rather quiet here and on my blog over the past month (compared to previous months) and I feel like I need to give at least a little bit of update on the progress of techDemo 0.7

in the recent update 0.6.2 there was only a new scene added and nothing new in terms of functions or gameplay features.

also some of the major bugs are still not fixed (mainly problems at the stripclub) and there is only one reason to that:

there will be no more code changes in the 0.6.x versions of the game because all the time I currently spend on coding goes into 0.7.

for those who did not read the previous long post on my dev-blog  on that matter, here is a quick summary:
the game engine is completely self-built from scratch and some code turned out to be not as practical as anticipated in the long run.

and the software I use to make the game (GameMaker:Studio) got a new enhanced and improved version with new features that can help me in development (GameMaker:Studio2).

initially I did not want to change to the new software version because these switches always come hand in hand with a major re-work of the code because many parts of it will not work the same way as in the previous version.

but since I already needed to re-work parts of my code to fix the problems in 0.6 I finally decided to make the transition to the new GameMaker:Studio2

and that's what is currently going on: I re-work some 5 months worth of code to run at the new software version and at the same time improving my own code to a more stable and less complex way.

but since this is almost entirely game engine and framework related work it is hard to "show" the progress because the game looks almost the same anyway with only some minor visual changes like the new quick menu I showcased in the video


so bear with me a little longer until I finish the transition to GM:S2 for the new techDemo 0.7.
once 0.7 is done there will be regular gameplay mechanics updates and bug fixes again because the current state of the game is by far not what it is intended to be ;)

dev blog #28 - techDemo 0.6.1 public release and what's next

the techDemo 0.6.1 is now available for the public!

go check it out in the download section or here

if you haven't read it yet, here is an overview of what's new in this release

now that the public release is done I can completely focus on the next steps of the project.
the mess I made with 0.6 is still a big concern for me so I spent the last week figuring out how to minimize/avoid this to happen again later in development.

the main problem really was and still is the overly complex dialog/event system that grew with the project over the past techDemo updates. it worked as long as the game was rather "small" but it now already showed its limits on how it will perform once the game gets more complex with story line and missions and all the "fun" stuff a game is made of.

so I put a stop to all "new" features development and will now focus on fixing this issue as my top priority! this means that there will be no techDemo 0.7 until I figured out a better way for the dialog/event system.

in the meantime I will still release new scenes for techDemo 0.6 as I already announced here so you guys get something new to look at! but there won't be any new gameplay features until 0.7 is ready.

I will now go a bit into details on what I already figured out over the past week so if you are not interested in the "development" aspect of the game you can stop reading here (and go get that new release! NOW!)

probably the biggest decision I already made in the past week was to step up to the new version of GameMaker Studio!
the latest version, GameMaker Stuido 2, has some very neat new features that can help me out a lot with the development of Twin Star.

originally I didn't want to switch software during the development of TwinStar because moving from one release to a new release of GameMaker had many issues in the past which almost always requiered a partial re-work of the project in question.

BUT: since I already have to re-work a good portion of the game to fix the dialog/event issues I figured... meh... why not switch to GMS:2 in the process to profit from the awesome new features it has over GMS:1.

and so far I already encountered the anticipated problems... a lot.
for starters the advertised "easy import from GMS:1 project into GMS:2" didn't work...at all...
but I already expected that so it was not a surprise (I would've been surprised if it had worked as intended!)

but what I also tried out right away were some of the new features I put a lot of hope into helping me in development.
to list the most anticipated:

• new room editor:
  with the "layered" room editor making new "areas" for the game will be a hell lot easier compared to GMS:1
  I already toyed around with it and I am very pleased with the performance of this new feature
   
• auto-tilesets and tileset brushes
  now that's something most RPGMaker developers are familiar with and love.
  and I too was very happy when this feature was announced for GMS:2 as it makes development of game worlds much much easier.

one could now say "well duh, why don't you use RPGM in the first place then?!" which I can only answere with: it was the only advantage of RPGM over GMS while GMS was way more customizeable and versatile if you know how to programm.
but I'm not going into further details about the pro and cons of either development software as I am commited to GMS:2 entirely :D

so apart from these 2 very nice new features there are many more minor improvements over GMS:1 which I'm not going to list here

so what I can say now after working for a week with the new tool is: once you get used to it's new interface it is way more powerful than the previous version!

ok, enough now with licking YoYo Games balls and on to some more infos on how the progress of the game now stands:

since the import of the GMS:1 project file failed I literally have to build the game engine from scratch in GMS:2. at first this might sound like a horrible thing to do regarding the fact that the GMS:1 project is worth 4 months of development but it's not that bad at all.

while it does take some effort to re-build it I don't have to entirely start from 0 as most of the "logic" in the existing code still applies to the GMS:2 environment and I don't have to figure out how stuff works again. so while I can re-use 80% of my existing code I still have to make some improvements to existing things otherwise the whole transition from GMS:1 to GMS:2 would make no sense at all.

so there are already 3 things I changed for the 0.7 build:

1. "true" portable mode
   the portable (or non-installation) deployment of the game started with techDemo 0.4 but still caused some problems with some windows users.
   due to the nature of GMS and how it handles "host environment" it is almost impossible for developers to gain access to the filesystem of the OS the game is running at (they call it sandboxing)
   
   so the only options to "save" game data to is either the %appdata% directory or the directory the game is launched from.
   
   and up until now my game was using the %appdata% for savegames and temporary file storage which caused problems when you run the game on a restricted user account or from certain types of external storages or drives.
   
   so in order to eliminate this problem the new 0.7 will handle ALL file storage in its own directory like a portable application should.
   
   a benefit from this new approach is also the easier patching capabilites which allows me to add content to a game version without you having to download the whole package again but just add the new content instead.
    
2. screen resolution/aspect ratio handling
   
   
   
   now this is something I had discarded until not long ago since resolution handling in GMS:1 is a bitch.
   
   but GMS:2 changed some things regarding this matter so since I rebuild the game engine I also decided to add support for multiple screen resolutions. I took the "January 2017" list of the Steam Hardware Survey as available options.
   
   and there is no fullscreen mode anymore as GMS:2 also has the same flaws as GMS:1 regarding that so I ditched it in favor for the now selectable resolutions (up to 3840x2160).
     
3. improved internal data handling
   now this change is for preparing for the improvements I have to do to deal with the growing complexity of the dialog/event system and the still to come mission and story system.
   
   apart from switching to DS_maps and grids for storing game data instead of arrays I also need to find a better and more manageable way to handle the dialog/event files
   
   for easier editing I stored all the text and data in external text files (which I can also edit outside of GMS) that got loaded into the game when needed but this approach prove very complex because despite me maintaining a summary list of the textfiles I quickly lost track on what textfile contains what and which textfile can affect what in the game.
   
   now while it is very common to store dialog and text this way I think my approch of it was not very sophisticated so I'm going to work on that too
   

dev blog #27 - what a mess ....

so what happened with the release of techDemo 0.6?
only the 20$+ Patrons know it but I did some really bad quality checking before I released the early access version for them....

in short, there were several game breaking bugs in this release which forced me to release a bunch of short term hotfixes until I could re-compile everything into a new techDemo 0.6.1 version.

There is no excuse for that but I feel the need to give at least some explanation on how that happened and what I'm going to do about it in the future to minimize the chances of this kind of fuckup happening again.

To be clear: bugs can happen in every game development stage and release.

that said I'm going to give a little insight of my development process and what lead to the current situation.
If you don't care about details and just want the redemption gift scroll to the end of the page ;)

so, what happened?

what you are looking at here is my "relationship-diagram" for my events. Events are handling certain things in the game. they add or remove dialog options, place or move NPCs, modify the open/close status of doors etc etc.
in short, events are what make the game interactive.
each event has its unique ID and events can also call other events.

and here is where it gets tricky:
until now I only had a simple excel sheet where I kept a list of event IDs with a short description of what that event does. nowhere was noted the exact actions that event would start or which things it would modify.

this lack of detail resulted in a big messy bunch of numbers the bigger the game got. and to be honest the game is not very big at all so it also came a bit surprising for myself that my ID system already hit its limits at this stage of development.

so I sat down today and started to bring some clearance into the ID system. I made this diagram to have a visual aid on which event causes what. right now I only listed the events that get called either by the "new game event" E0 or the character related events E1 (Mike) and E2 (Lena).

those events are also embedded in the "timeKeeper" which controls the day and time related events so things like scenes and other time related things "happen"
.... or don't as it was the case now with 0.6!

because one of the events embedded as an "evening" event also triggered a "time increase by 1" it caused the game to skip "night" time and thus preventing the player from starting the brand new scene at "night"

due to the lack of detail on my ID excel sheet I simply overlooked it and unfortunately as it already was, the last minute changes I made to the game directly involved that said event...
and I did not test everything again that had worked previously because I was already two days behind schedule for other coding problem reasons....

so in order to minimize the chance of such fuckups I started to keep track of all the events in a much more detailed way.
a similar ID system is in place for all the dialogs in the game and dialogs can call events and the other way round. and it is a big messy pile of numbers already and not only once I had the feeling of getting lost in my own IDs....

BUT with the now visual diagram overview I'm going to maintain from now on I'm positive that I can keep those kind of problems under control.
it does also mean that I have to put even more time into "project management" as I already had to but that's how it is with such projects anyway.

so now for the gift:
all 20$+ Patrons will get access to a special archive that I will upload soon. this archive contains all the CGI that I rendered for the Mom/Dad scene. I rendered a total of  119 images in 1920x1080 and only 64 of these made it into the final scene reduced to 1280x720.