Topic: AAR Development (Read 64771 times)

dreamchaser · « **Reply #75 on:** December 23, 2020, 11:57:18 am »

I have just implemented a solution for the low income people complained about that I am pretty happy about:
Cafeteria aside, your income depends on your reputation and lust stats.
I have just added value descriptions for these stats (Aside from money, students and staff numbers (which are countable), these where the only 2 stats that were missing these descriptions).
Then I adjusted the income formulas for tuition and surveillance to take those changing descriptions into account. As soon as you get a better description, the multiplier for the income improves. Since it still scales with the stat itself, you get a roughly quadratic increase, but in steps.
I think that reflects real life better, and it gives a stronger sense of progression. You have concrete targets to shoot for where your income increases measurably, and in the endgame, it will be higher (about double of current). At the start of the game it will be a bit lower, but already on the next tier up it will be equal to the current income.

In the same way, I have changed the cafeteria income to smoothly scale with morale and reputation instead of being a flat value per student (it scales with square root of morale and linearly with reputation).
Numbers tweaked so cafeteria income is halved at game start (12 reputation, 10 morale), but 4.5 times higher than current in endgame (100 reputation, 100 morale).
The cafeteria will never be a main income driver, but now it isn't completely insignificant anymore:
In the end game, the cafeteria now produces about 18% of the income of the tuition.
I think I also like the fact that high morale now has at least some influence on how much money you make. I think that fits nicely thematically.

dreamchaser · « **Reply #76 on:** December 23, 2020, 03:28:06 pm »

Bad ends implemented:
- You lose if you start a day with a reputation <=0 (the board fires you for trashing the schools reputation)
- You have a 5% chance of losing each day you start with behavior<2 (the students burned the school down - behavior value description adjusted to hint at that)
- You lose if you start a day with staff_support<0 (the board fires you because multiple teachers offered their resignation)

So now there is actually an official way to lose the game.

dreamchaser · « **Reply #77 on:** December 28, 2020, 12:12:52 pm »

Progress Update:

All is looking very well. It went both smoother, and I had more time for it than hoped.

- I have done a second pass on Gallery variants for all the events. You should now never have to make any choice inside of such a replay. Or the other way around: Every choice you make during an event, should unlock its own variant, which locks you into the choice. I am sure there will be small errors about event variant unlocking for the gallery. But I tested all gallery variants, so I don't think any crashes got added, and if a variant doesn't unlock properly, that is no problem for the main game. And easily fixed once somebody reports it.

- I have changed the way rollback works in the game: From 0.4 on, your choices won't be changeable when you rollback, for that you have to load a save game. I have done this to keep players from casually unlocking multiple choices at once in the Gallery just using rollback. It is accepted and unavoidable that this is possible using save and reload. But at least then it's a conscious decision.

My to-do list for 0.4 is done with this.

Now all that is left is some playtesting and changing whatever I dislike while playing (and fixing any bugs I come across).

I think with this I can now guarantee that the release will happen by 3. January 2021 (might even happen earlier if I think there is nothing left to polish).

EDIT: Quick check done: the combined modpack seems to work perfectly fine in the new version (though, reminder, classic events do not unlock entries in the Gallery). So the new event summary and the Gallery did not mess anything up about classic Ashford Academy events.

caffarella · « **Reply #78 on:** December 29, 2020, 01:34:33 am »

Sounds great, can't wait to play da new release!

OutofUniqueNames · « **Reply #79 on:** December 29, 2020, 03:36:45 am »

Same!

dreamchaser · « **Reply #80 on:** January 02, 2021, 06:31:41 pm »

Ho boy, it is finally done.
Finishing up all loose ends I could find, and generally increasing the quality of the release turned into quite a bit of work.
It was rewarding though, I am proud of 0.4.0

I am quite content to just fix all reported bugs for a bit and answer any new suggestions people make.
Other than that, I'll take a small break again before coding up new stuff. Not that long though, I do look forward to what I envision to do for 0.5:

0.5 is going to be about polishing up and balancing the existing content (as opposed to the game engine and metadata focus of the current release).
I want to make the existing events scale better across the different states your school can be in, and to more strongly reflect that state in their text and effects.
I also want for the player to be better able to steer development just by the acts he picks in daily planning. Maybe I'll also offer an option to spend a whole week with just a single activity, to give an option to pass time quickly. Not sure though whether that is really needed - in my test game I had no problems with too much repetition (the increased income of 0.4 helps a lot).

That's it for my personal comments and brief look into the future.
Enjoy the game, and stay healthy!

mezz · « **Reply #81 on:** January 03, 2021, 04:22:16 am »

Thanks for your work!

Do clubs need to be unlocked now?

a915329096 · « **Reply #82 on:** January 03, 2021, 05:28:24 am »

Thank you for hard work man.

dreamchaser · « **Reply #83 on:** January 03, 2021, 12:53:51 pm »

Quote from: mezz on January 03, 2021, 04:22:16 am

Thanks for your work! Do clubs need to be unlocked now?

Clubs need to be unlocked in all versions of AAR.
There is only 1 club into the game, "Cheerleading". You should see that as an option in the unlock menu.

Ashford · « **Reply #84 on:** January 04, 2021, 09:04:47 pm »

A good start of the new year!

Cheers,
Ashford

dreamchaser · « **Reply #85 on:** January 09, 2021, 10:53:45 pm »

After fixing the 1 crash in 0.4.1, there luckily weren't any other bugs requiring a new release.
I am gathering a few very minor fixes, but so far, all good - knock on wood.

I found one other crash while playing around, but that falls clearly into the "well, don't do that then" - the game crashes if you try to save while in "seen events".
Fixing that unfortunately will take a bit of redesign, so I'll just leave it alone for 0.4.x

I have made a copy of the game code, to start implementing a few ideas I have for 0.5
As I already wrote, the focus of 0.5 will be polishing, expanding and balancing all of the existing events (which is a substantial amount of work, so don't expect that release to happen any time soon).
Obviously I want to implement all ideas I have to make my job easier, first.

These are the things I have implemented for 0.5 so far:
API:
- in events and event conditions, v has the value of the event variable (writing allowed)
- you can now check for flavor in img_e e: tags, they now get evaluated per image
- new tag ef: (entry from dict eval_flavor) - combination of flavor, conditions, and executed statements
Debug:
- when evaluating the event condition in events screen, ignore ^act==' conditions
- gallery event screen: if event condition fails, show the failing condition
- gallery event screen: show event label and image name on top of screen

I think especially the ef: tags will be quite useful to make event definitions shorter, while making the game more reactive at the same time.
Let me show you my test case:
in images/base/data/general.rpy:
eval_flavor['panties_below_skirt']={'e':["inhibition<80 or dresscode_o.at_least('sexy')"],'set':["inhibition_o.dec(0.1,60)"]}

Here I define the meaning of the ef: tag 'panties_below_skirt' once:
-images or events tagged with it can only be selected if inhibition is below 80 or the dresscode is 'sexy' (or 'nude')
--reasoning for the inhibition<80 condition (stat level description): Girls are embarrassed if anybody sees their underwear. Yet somehow, they often fail to notice when their panties are visible below their skirts.
--reasoning for the 'sexy' dresscode alternative (policy choice description): The skirt must risk showing the panties, if worn.
-if an images/event with that ef: tag gets executed, then afterwards the code "inhibition_o.dec(0.1,60)" executes, which lowers inhibition by 0.1 if it is currently over 60
--reasoning: below inhibition 60, students have to be dressed only in their underwear to be embarrassed
-and implicitly, "panties_below_skirt" is added to the flavor list.

One of the picture definitions in images/canon/data/image_tags.rpy:
img_prefix("school_grounds")
...
img("1-6","u:normal","f:day","f:ff","f:sky","ef:panties_below_skirt")
->so this picture will only be available for inhibition<80, and slightly lower inhibition if chosen.

And the cool thing is, that after having defined this logic in eval_flavor, the image and event definitions don't care about these details, and I can fiddle with the numbers and logic at one central place, and it adjusts everywhere.

The improvements to the debug view of the gallery event screen should make events easier testable. I can set up a situation where the event should be available, and then check there whether it is. And if it is not, it will tell me why.

I've also implemented 1 balance change:
- for all stats other than dare_points: if an event only changes the stat value up to a specific limit, the change will be halved if less then 10 points below the limit, and if the normal change is>=0.4, it will still change by 0.1 if less than 10 above the limit

Example: An event lowers inhibition with the code:
$ inhibition_o.dec(0.5,30)

In 0.4, this is was all or nothing: if inhibition was >30, it lowered it by 0.5. If inhibition was <=30, nothinging happened.
In 0.5, the effect will be more gradual:
-If inhibition is >40, it will lower inhibition by 0.5
-If inhibition is >30 (but below 40), it will lower inhibition by 0.3 (0.5/2, rounded up to 0.3)
-If inhibition is >20 (but below 30), it will lower inhibition by 0.1 (since normal change >=0.4)

Similar to the :ef tags, logic that is defined only once makes the game as a whole more reactive to your stats.

I have attached an image of how the debug view of the event screen currently looks like:
- all existing events for that mod&activity on the left (not new)
- all dresscodes, images and variants selectable (not new)
- internal event name and image name on top (the example image I chose above, with "ef:panties_below_skirt")
- below "Replay Event", it shows the condition that is failing: "inhibition<80 or dresscode_o.at_least('sexy')" (truncated) -> that's the one coming from the ef: tag!

- if the event had an event variable, its value would be a line below the failing condition (not new, this event doesn't have one)

dreamchaser · « **Reply #86 on:** January 14, 2021, 07:32:46 pm »

Since I am not getting any new bug reports, I'll be cutting 0.4.2 this weekend. Baring any serious bugs, that will be the last 0.4.x release.

I've got a pretty big new user visible feature for 0.5 to show of: Goals and Achievements!

Compared to the Event Gallery, this was much simpler to implement, especially being able to use parts of the Gallery code as a template.

These will serve multiple purposes:
- They are something to collect, like the Gallery, so might improve player motivation
- They are a way to hint to the players where they can go look for some worthwhile content
- "Is there anything to this game but events that are an image with a line or two of text?" - "Yes, have a look at the goals" ->It's a statement that there is some deeper content to be found in the first place.
- They give the game a way to know whether to declare victory without having to hard code it. A victory screen is not implemented yet, but with goals, the logic should be simple now, at least.

I have configured 4 goals for now, so that I could properly test the system. More will be added when I make my pass through the events, but there won't be that many either - they are supposed to be the special stuff, not for every little thing.

The goal screen is accessible from the day planning. The achievements screen (showing only reached goals, but of all save games) is accessible from the main menu.

Documentation:
========Goals / Achievements========
To add a goal and achievement to the game (every reached goal is an achievement), make a new Achievement object.

Constructor: Goal(<name>,<nice_name>,<img_reached>,<desc_new>,<desc_started>,<desc_reached>,**kwargs)
name: the internal name of the goal. If that changes, the game will forget about old progress
nice_name: the name of the goal that is displayed to the player
desc_new: the description when the goal has not yet started
desc_started: the description when the goal has been started, but not yet reached
desc_reached: the description when the goal has been reached
keyword arguments:
active: eval, if True, the goal will be shown in the list of goals (default: True)
failed: eval, if True, the goal will be marked by the game as failed (default: False) (ignored if the goal has been reached)
reached: eval, if True, the goal will be marked by the game as reached and the achievement will be shown (mandatory)
started: eval, if True, the goal will be marked by the game as started (default: False)
img_started: Name of the image to show if the goal has been started (default: img_reached)
img_new: Name of the image to show if the goal has not been started (default: "gui/unknown.png")

I am attaching 2 pictures of the goal screen, one with a new goal, and one with a started goal. The goals are sorted by progress first, and alphabetically inside the same progress category.

dreamchaser · « **Reply #87 on:** January 16, 2021, 01:50:29 pm »

Rewrite for Periods and Activities done.

This is mostly a purely internal change.

It will matter to any mod writer though.
Up to 0.4.1 you couldn't add activities to periods at all, so for 0.4.2 there will be a new parameter period_name added to dp_choice as a stopgap measure.

Documentation for 0.5:

========Activities========
You can add new activities to any period.

Constructor: Activity(<period>,<name>,<action_desc>,**kwargs)
period: the name of the period ('morning, 'afternoon', 'evening')
name: the internal name of the activity
action_desc: I was just about to <action_desc>. (Also shown as tooltip)

keyword arguments:
title: name of the activity as shown in the day planner (default: <name>, with underscores replaced)
active: eval, whether this activity can be chosen (default: True)
nude_ok: if dresscode is "none" and this is True, the students may be willing to choose to go nude (default: False)

Example:
Activity('morning', 'gym', "check in on the gym", active="building_gym > 0")

==Changelog==
Bugfixes:
- When saving in day planner, changed activities in current planning are saved
API:
- dp_period and dp_choice replaced with Period and Activity, all_acts renamed to activities
- labels morning, afternoon and evening no longer exist, since periods aren't hardcoded anymore (I don't think any mod uses these labels)

dreamchaser · « **Reply #88 on:** February 28, 2021, 01:46:22 pm »

Rewrite for event class

Okay, codewise, this is a really big one:
I am reworking the event code, which is the core of this game's logic.

Until now, I have not touched the event code AAR inherited from the classic game (after my rewrite of the Activity and Period code for 0.5, this is actually the last remaining block of code not rewritten by me).
Because it's a big and intricate piece of code, actually more of a library file. And I didn't completely understand how it worked when I first coded AAR.
And of course, it is needed to maintain backwards compatibility.
So whenever I needed new functionality, I figured out where to attach a new add-on.
That is why I made the img_e function to encapsule event creation. That is why I made a new event.img class, and that is why I added the Reg Class to store additional information.
The problem is, that with each such additional add-on, the whole thing got more complex and error prone. The code is harder and harder to maintain and further extend.

Now my plan for 0.5 was and still is to make a complete pass over all events to update, unify and improve them.
To get a solid foundation for mods and for adding new events into the base game in 0.6.
So any changes to event definitions should happen right now, because later on, they will become harder (which is not to say that adjusting how 300 events are defined is not hard enough on its own).

So with that reasoning, I have poured a lot of time into completely reorganizing and rewriting the event code.

The old logic was:
img_e(...):
- calls event(...)
- adds event.img object
- extracts and links Reg object
event(...): untouched old code

Example call:
img_e(2,"inhibition <= 85",Reg("horsing around","a group of girls horsing around in the water"))

With the rewrite, the new logic is now:
Event(...):
- defines that object
event(...): calls Event(...)

Example call:
Event(2,"horsing around","a group of girls horsing around in the water",["inhibition <= 85"])

There is no more event.img and no more Reg objects, their code is now contained in Event
Because there is that event(...) wrapper, events written for Ashford Academy classic should still work, but obviously it has to be tested (potential for new bugs).

So that appears to all work, the event is found, the conditions are evaluated. Probably quite a few bugs in all that new code, but they will surface as I convert and test all existing events, so I have no fear that they will stay undetected.

Converting the existing events will happen as I make my pass over them all (which was the plan behind doing this change now, after all).

There are no mods for AAR by others yet which use img_e (that I know of). If anybody is working on one, now that for 0.5, you will have to change your event definitions.

Event constructor:

Code: [Select]

    class Event(object):
        def __init__(self,ending,title,desc,cond=[],variants=[],tags=[],**kwargs):
        #ending: string - used to construct the internal event name (see prefix)
        #title: string - nice name of the event
        #desc: string - description
        #cond: array of condition strings and event.* objects
        #variants: array of <variant>. <variant>: [<id>,<title>,<condition|assignment>*]
        #tags: array of strings - format "<key>:<value>"
        ####kwargs####
        #priority: int - evaluation order, from low to high (default: 100)
        #force_prio: int - if given, used as priority, with event.only and event.once
        #start_msg: string - if given: introductory event, check ignores selected activity
        #var: <any> - initial value of event variable
        #ban: bool - should this event be banned at game start? (default: False)
        #group_count: eval - how often this event is entered into the pool events are chosen from (default: 2)
        #act, mod, group: string - the activity, mod and event group this event belongs to (if not given: any)
        #prefix: bool - should ending be prefixed to generate the event name? (default: True)
        #gallery: bool - should the event be added to the gallery? (default: True)
        #gallery_reduce_dresscodes - should dresscodes be removed as gallery options that offer no new images? (default: True)
        #==image logic==
        #auto_img: bool - should image logic be handled by the event class? (default: True)
        #max_img_dist: int - when to accept another dresscode, see array dresscode_distance in img.rpy (default: 0.5)
        #first_img: bool - use the first registered image from the image group (default: False)
        #solo_img: string - if given, use this image instead of an image group
        #pre_img: string/bool - if bool True, keeps the chosen image from being displayed
        #                       if string image name, that image will be shown instead
        #on_replay: string - executed before starting a replay (useful for setting vars, default "")

Wrapper for classic event definitions:

Code: [Select]

    class event(object):
        #only classic events define their events with this constructor
        def __init__(self, name, *args, **kwargs):
            Event(name,"Classic Event","",list(args),
                priority=kwargs.get('priority',100),
                group_count=1, act=None, mod=None, group=None,
                prefix=False, auto_img=False)

HentHighSchool Development Forum

News:

Author Topic: AAR Development (Read 64771 times)

dreamchaser

Re: AAR Development

dreamchaser

Re: AAR Development

dreamchaser

Re: AAR Development

caffarella

Re: AAR Development

OutofUniqueNames

Re: AAR Development

dreamchaser

Re: AAR Development

mezz

Re: AAR Development

a915329096

Re: AAR Development

dreamchaser

Re: AAR Development

Ashford

Re: AAR Development

dreamchaser

Re: AAR Development

dreamchaser

Re: AAR Development

dreamchaser

Re: AAR Development

dreamchaser

Re: AAR Development