- Aug 7, 2017
- 155
- 178
Sorry, there are no cheat yet (other that Advanced Start, which isn't exactly a cheat).
- Nov 27, 2017
- 629
- 669
Lines 10144 and 10152 contain the money (did 10144 first, no change in-game, then did 10152 as well which did change in-game so may only need to change 10152) in the save file on my PC. Not sure why it takes 2 lines for 1 value, but since the file what appears to be 15kb worth of text (if even that much) replicated to take up 2.43mb I guess it stands to reason. At least it isn't encrypted like most PC games do so we can edit it with a text editor 
Now to locate energy & mood, should be interesting...they're only single digit values that are found a few million times because of all the space wasted in the save file...lol
Edit: Nevermind about the line numbering. I played 25-30min farther, saved and reopened it to find everything scrambled. You'll have to do a search for the current money amount to find where it is in yours (I did refind the money line with ease). I edited a bunch of lines and broke the save, games such a grindy thing for little/no reward (on top of unrealistic time constraints) that I uninstalled it rather than go through the annoyance of replaying.
Now to locate energy & mood, should be interesting...they're only single digit values that are found a few million times because of all the space wasted in the save file...lol
Edit: Nevermind about the line numbering. I played 25-30min farther, saved and reopened it to find everything scrambled. You'll have to do a search for the current money amount to find where it is in yours (I did refind the money line with ease). I edited a bunch of lines and broke the save, games such a grindy thing for little/no reward (on top of unrealistic time constraints) that I uninstalled it rather than go through the annoyance of replaying.
- Aug 7, 2017
- 155
- 178
Sorry to hear about your troubles. I am working on improving save game compatibility and, most importantly, the game-play. Hopefully I'll manage to include significant improvements in AVSB 0.3.2.Lines 10144 and 10152 contain the money (did 10144 first, no change in-game, then did 10152 as well which did change in-game so may only need to change 10152) in the save file on my PC. Not sure why it takes 2 lines for 1 value, but since the file what appears to be 15kb worth of text (if even that much) replicated to take up 2.43mb I guess it stands to reason. At least it isn't encrypted like most PC games do so we can edit it with a text editor
Now to locate energy & mood, should be interesting...they're only single digit values that are found a few million times because of all the space wasted in the save file...lol
Edit: Nevermind about the line numbering. I played 25-30min farther, saved and reopened it to find everything scrambled. You'll have to do a search for the current money amount to find where it is in yours (I did refind the money line with ease). I edited a bunch of lines and broke the save, games such a grindy thing for little/no reward (on top of unrealistic time constraints) that I uninstalled it rather than go through the annoyance of replaying.
- Aug 7, 2017
- 155
- 178
I don't know how many of you are aware of this, but both my games (AVSB and the new puzzle mini-game) are developed using a special programming language, C-Cup, that I created especially for making this kind of games.
As the next versions of AVSB are getting more and more complex, I'll be allocating the next few weeks for writing some improvements to C-Cup, my main goals being:
I would also like to add a new file format: .vrod (virtual read-only disk) which will speed-up game loading and will allow better code re-usability, but that only if the first changes won't take too long. I expect the main changes will take 2-3 weeks (plus 1 extra week for .vrod format), but this is just an estimation. It may take more or it may take less. All these changes are quite complex and development starts today, so wish me luck.
As the next versions of AVSB are getting more and more complex, I'll be allocating the next few weeks for writing some improvements to C-Cup, my main goals being:
- support the large number of stats AVSB will require and the general increase in complexity
- improve debugging capabilities
- prepare save-game compatibility
- prepare the language for publishing it, including source code, so that other developers can use it to make their own games.
I would also like to add a new file format: .vrod (virtual read-only disk) which will speed-up game loading and will allow better code re-usability, but that only if the first changes won't take too long. I expect the main changes will take 2-3 weeks (plus 1 extra week for .vrod format), but this is just an estimation. It may take more or it may take less. All these changes are quite complex and development starts today, so wish me luck.
- Jul 2, 2017
- 9,416
- 97,425
I'd notice that before the 0.3 v and realy think that you're doing a great job. Every update brings us a major improvement and the game comes more and more interesting, in addition to the progress in the gameplay. I don't think you need luck, I'm pretty sure you're going to achieve it, I just want you to be strong and continue as usual.
- Aug 7, 2017
- 155
- 178
Thank you very much for noticing and for you encouraging words. Many of the changes I have to make are very difficult . I know I can do it but people are expecting games, not code-behind, so I have to finish everything as quick as I can and resume working on the game per-say.
. I know I can do it but people are expecting games, not code-behind, so I have to finish everything as quick as I can and resume working on the game per-say.
- Aug 18, 2017
- 2,288
- 2,382
I like the game, and I think the girlfriend model is beautiful, but the game feels too focused on the very small business and not so much on the relationship, your girlfriend turns more into an annoyance that you talk, admire and fuck like a chore instead of for fun, and if you don't focus on the business you get easily bankrupt
right now I'm doing fairly well with the business, but that's how I feel with the girlfriend
right now I'm doing fairly well with the business, but that's how I feel with the girlfriend
- Aug 7, 2017
- 155
- 178
Thanks! I know Laura is a bit demanding but her attitude will soon change (not in AVSB 0.3.1 though) and soon her life with her will be much enjoyable
. That should normally start with AVSB 0.3.2 - 0.3.3 (next version and the one after that) but I am making a lot of changes in the code-behind, which likely will affect most of the code I have already (especially the changes I'll made for ensuring save-games compatibility). So I'll probably have to split AVSB 0.3.2 in a few minor releases (0.3.2.0, 0.3.2.1 ...). We will see about that once my changes are done, but if this will be the case, then her change in behavior will be delayed a bit (but will still be happening in the 0.3.2 - 0.3.3 interval).
- Jun 19, 2017
- 102
- 177
- Aug 7, 2017
- 155
- 178
As you know, since the year started I begun upgrading the C-Cup language in order to prepare it for the work ahead. Since then, I managed to implement the most difficult changes and prepare the code for the addition of the other, less complex changes I had in mind.
So far, the followings are implemented:
As I said, there are still some bullets left in my to-do list, mainly:
In addition, I would like to add to my to-do list:
Doing all these will complete the changes I need for C-Cup, except for anonymous type for which I don't have a good solution how to implement them, but I think I can live without them.
My goal is to finish all the above next week and then I'll start working on the new vrod file format, for approximately another week, before resuming the work on the game per-say.
The arrays, the collections, the events and the additional support for more commands and features will allow me to create more complex game mechanic, as well as to create plausible characters with personalities that evolve with the story progression and that are able to interact with each other and with MC based on their current personalities, rather than the originally scripted ones.
Additionally, these should open the path for save-game compatibility, from one game version to another. I think everyone will be happy to be able to resume the old save-games when a new game version is published
So far, the followings are implemented:
- full support for single-dimensional and jagged arrays.
- full overload resolution for C-Cup calls, including: "optional parameters", "named parameters" and "directional parameters".
- support for "get"/"set" property accessors, including those for reference types.
- support for some field/property/function attributes: "public", "private", "shared", "out". With this mechanism in place it is not too difficult to add the other attributes I have in plan adding: "overwrite" (partially implemented already), "serializable" and "const".
- support for chained functions and properties
- "function" (and "property") keywords are now optional.
- support for "generics".
- support for "List" and "List<type>". I will still need to add support at least for "Dictionary" / "Queue" / "Stack" / "Hashset", including their generics counterparts.
- support for "delegates", including type-safe delegates via generics.
- support for "events" (based on delegates).
- support for "Script" and "Instance" objects, which are two distinct ways to instantiate script objects (as shared reference or as classical reference).
- "New" keyword, with support for all reference type mentioned above.
As I said, there are still some bullets left in my to-do list, mainly:
- "Exception" types
- support for "try/catch"
- support for "throw" keyword
- support for code tracking via "calls stacks"
- support for "break" / "continue" keywords
- support for "for" and "for-each" loops
- support for "iif" keyword
- make the language type-safe
- support for additional collections (listed above)
- support for additional attributes, mainly "overwrite", "serializable" and "const"
- support for additional pre-parsing "directives", mainly for default value of attributes
- support for "constructors" and "destructors", including the "delete" keyword
- support for external "namespaces"
- support for external "aliases"
- and, of course, testing everything and fixing the corner cases.
In addition, I would like to add to my to-do list:
- support py-cup expressions (syntax sugar), at a very basic level, just enough to make sure the mechanism needed for further extensions works.
module.subtitle.set("Hannah", "hannah-laughing .png", "Oh, what a funny joke!");
I could write something simple like:Hannah: laughing, "Oh, what a funny joke!"
and let the py-cup extension apply the agreed conventions and convert the code to proper c-cup code.Doing all these will complete the changes I need for C-Cup, except for anonymous type for which I don't have a good solution how to implement them, but I think I can live without them.
My goal is to finish all the above next week and then I'll start working on the new vrod file format, for approximately another week, before resuming the work on the game per-say.
The arrays, the collections, the events and the additional support for more commands and features will allow me to create more complex game mechanic, as well as to create plausible characters with personalities that evolve with the story progression and that are able to interact with each other and with MC based on their current personalities, rather than the originally scripted ones.
Additionally, these should open the path for save-game compatibility, from one game version to another. I think everyone will be happy to be able to resume the old save-games when a new game version is published
So I just started and the only trouble I'm having is that the girlfriend wants me to hug/kiss/admire her more. I have yet to see an option for these, so how do I actually do that?
- Dec 10, 2017
- 194
- 162
Just hovering the cursor over her should reveal the options you 're looking for. Have fun 0/
- Dec 22, 2017
- 79
- 11
I just downloaded the game and started playing it. Very good game. Is there a cheat for the money at least? Thanks!
- Aug 7, 2017
- 155
- 178
No, there is no cheat, but if you are short on money, you can always work on your old profession. That will bring you a decent income until your business starts running smoothly.
- Dec 22, 2017
- 79
- 11
- Jun 19, 2017
- 102
- 177
- Aug 7, 2017
- 155
- 178
First of all, I would like to let you know that next week it will be my birthday, so I will take a week off.
And coming back to the status update, this is what I implemented last week:
. On 29th, when I'll resume my work, I will spend some more time on these expressions adding improved support and additional functionalities.
Other than this improved support for PyCup expressions, my to-do list still contains:
And coming back to the status update, this is what I implemented last week:
- "Exception" types
- "Throw" keyword
- Try/Catch/Finally
- Calls stacks
- "Break" and "Continue"
- everything is "Type-Safe"
- "const" and "overwrite" attributes
- external namespaces (basic support)
- "new" keyword, together with "me" and "me_trim" auto-declared variables
- "dispose" keyword
- multiple execution spaces
- "null" keyword/value
- "#include" directive (used to work in the previous version of c-cup)
- basic support for PyCup expressions.
. On 29th, when I'll resume my work, I will spend some more time on these expressions adding improved support and additional functionalities.Other than this improved support for PyCup expressions, my to-do list still contains:
- "for", "for-each", "iif"
- "dictionaries", "lists", "queues", "stacks", "hashsets"
- type aliases
- type methods
- vrod file format
- Dec 10, 2017
- 194
- 162
Happy b-day week, have fun! 0/First of all, I would like to let you know that next week it will be my birthday, so I will take a week off.
And coming back to the status update, this is what I implemented last week:
As expected, the PyCup expressions are wonderful and I think that ultimately these will make c-cup so simple to use that everyone interested to make his own Visual Novel game should learn c-cup
- "Exception" types
- "Throw" keyword
- Try/Catch/Finally
- Calls stacks
- "Break" and "Continue"
- everything is "Type-Safe"
- "const" and "overwrite" attributes
- external namespaces (basic support)
- "new" keyword, together with "me" and "me_trim" auto-declared variables
- "dispose" keyword
- multiple execution spaces
- "null" keyword/value
- "#include" directive (used to work in the previous version of c-cup)
- basic support for PyCup expressions.
Other than this improved support for PyCup expressions, my to-do list still contains:
- "for", "for-each", "iif"
- "dictionaries", "lists", "queues", "stacks", "hashsets"
- type aliases
- type methods
- vrod file format
And a little Margarita, those tend to go well with chilly winter days
- Aug 7, 2017
- 155
- 178
On Monday, I resumed my work and started with the vrod-format, which is the most difficult, and risky part of the remaining work. What I managed to implement so far is more like a proof a concept with many hard-coded parts, but it cleared most of the risks, proved it works, and that it can bring even more benefits then I imagined.
I still have some problems with loading fonts from vrod-files, but in order to test that, I'll need to be able to create more complex vrod-files and for that, I need a vrod-editor.
I already started working on one and I think it will be ready tomorrow. Once the editor is done, I can check and make sure fonts can be loaded from vrod-files, too.
I'll have to update the engine to load game resources from either vrod-files or regular asset files (.xnb and .c-cup) and create some c-cup bindings so that vrod-files can be configured from within my c-cup code.
The editor and the changes to the engine are the most complex parts, but I think I'll be able to have everything ready by Monday (evening).
Once I'll have implemented all this, I'll have a great tool for developing games that are more complex.
First of all, these vrod-files help isolate the complexity, and secondly, they provide some unified access facades. These unified facades mean that I can create a vrod for managing game subtitles and then, at some point in the future, I can also change the vrod by adding the mechanics for scrolling back to previous scenes (like Ren'py does when you use the scroll wheel of the mouse).
Doing this kind of change now requires me to edit all places where I use subtitles and make the needed changes. You can imagine this is a lot of work and prone to errors or omissions.
By using a vrod, I mainly have to replace one vrod with another one, in which I have coded a new functionality, and set up some configuration.
In most cases that is all I have to do in order to have the new functionality available everywhere. Of course, it will not be always that simple, but the necessary changes that remain to be done are far fewer than without a vrod if I intend to implement new features.
For better understanding, I present you some more examples what a vrod is good for.
One example of vrod usage is for storing all graphics related to a character (or for a particular equipment). In this case, replacing an old vrod with one with newer graphics will automatically change how that character looks everywhere (or when using that particular equipment).
Another example is shared game mechanics.
Let's say I coded something complex, like everything needed in order to have an inventory for one of the characters in the game (a screen displaying the list of items and their quantities, a mechanism for accounting additions and removal of inventory items, and a mechanism to buy/sell items for money) and saved all this code into a vrod-file. Using this vrod and the extensions I already developed for c-cup, I can reuse the whole mechanism in order to add inventories to other game characters. Additionally, any correction or improvement I make in that vrod will apply automatically to every inventory screen in the game.
Aside from these advantages, probably the greatest advantage will be that it allows me to drastically reduce the number of c-cup-files I have to review and account for when implementing something new.
I still have to be careful about the implications when editing the facade, as changes here need to be updated everywhere, but behind that, where the real complexity lies, I only have to deal with a small amount of c-cup code that can be freely changed as long as the facade remains the same.
Note: At some point, I mentioned that the changes I make for the vrod-format would bring even more benefits than I initially imagined. Here is an example: With these changes in place, I can easily add some code so that my game can load graphics from well-known file formats, such as .png, .gif or .jpg. This means you will be able to alter the game by editing some of the graphics yourself.
I still have some problems with loading fonts from vrod-files, but in order to test that, I'll need to be able to create more complex vrod-files and for that, I need a vrod-editor.
I already started working on one and I think it will be ready tomorrow. Once the editor is done, I can check and make sure fonts can be loaded from vrod-files, too.
I'll have to update the engine to load game resources from either vrod-files or regular asset files (.xnb and .c-cup) and create some c-cup bindings so that vrod-files can be configured from within my c-cup code.
The editor and the changes to the engine are the most complex parts, but I think I'll be able to have everything ready by Monday (evening).
Once I'll have implemented all this, I'll have a great tool for developing games that are more complex.
First of all, these vrod-files help isolate the complexity, and secondly, they provide some unified access facades. These unified facades mean that I can create a vrod for managing game subtitles and then, at some point in the future, I can also change the vrod by adding the mechanics for scrolling back to previous scenes (like Ren'py does when you use the scroll wheel of the mouse).
Doing this kind of change now requires me to edit all places where I use subtitles and make the needed changes. You can imagine this is a lot of work and prone to errors or omissions.
By using a vrod, I mainly have to replace one vrod with another one, in which I have coded a new functionality, and set up some configuration.
In most cases that is all I have to do in order to have the new functionality available everywhere. Of course, it will not be always that simple, but the necessary changes that remain to be done are far fewer than without a vrod if I intend to implement new features.
For better understanding, I present you some more examples what a vrod is good for.
One example of vrod usage is for storing all graphics related to a character (or for a particular equipment). In this case, replacing an old vrod with one with newer graphics will automatically change how that character looks everywhere (or when using that particular equipment).
Another example is shared game mechanics.
Let's say I coded something complex, like everything needed in order to have an inventory for one of the characters in the game (a screen displaying the list of items and their quantities, a mechanism for accounting additions and removal of inventory items, and a mechanism to buy/sell items for money) and saved all this code into a vrod-file. Using this vrod and the extensions I already developed for c-cup, I can reuse the whole mechanism in order to add inventories to other game characters. Additionally, any correction or improvement I make in that vrod will apply automatically to every inventory screen in the game.
Aside from these advantages, probably the greatest advantage will be that it allows me to drastically reduce the number of c-cup-files I have to review and account for when implementing something new.
I still have to be careful about the implications when editing the facade, as changes here need to be updated everywhere, but behind that, where the real complexity lies, I only have to deal with a small amount of c-cup code that can be freely changed as long as the facade remains the same.
Note: At some point, I mentioned that the changes I make for the vrod-format would bring even more benefits than I initially imagined. Here is an example: With these changes in place, I can easily add some code so that my game can load graphics from well-known file formats, such as .png, .gif or .jpg. This means you will be able to alter the game by editing some of the graphics yourself.