Lemonade Stand

You have been placed in charge of a small lemonade stand at College and Yonge for a week. You start off with $10 in your pocket and you should try to make as much money as possible.

Weather conditions (cloudy, sunny, rainy, stormy, hot, or snowy) affect customer demand through lookup tables stored in the string array `a$`, whose 17th and 18th character positions hold CHR$ codes used as raw numeric parameters in the sales calculation. The demand formula at line 600 uses a price-sensitivity factor `1/(10-(l-p))` to reduce sales when the selling price strays from the wholesale cost, and a random vandalism event can fire after day 2, docking $20 from funds. The shop display is drawn with block-graphic characters and animated PLOT/DRAW routines depicting two lemon jugs filling line by line.

---

Program Analysis

Program Structure

The program is organized into a main game loop and several subroutines and branching sections:

1. Lines 10–50: Setup, title screen, and initial subroutine call
2. Lines 60–70: Variable initialization (money m=1000 i.e. $10, rent r=50, price p=3)
3. Lines 80–760: Main daily game loop — weather, input, sales simulation, bookkeeping
4. Lines 780–1100: Graphics subroutine (shop display with animated jugs)
5. Lines 1110–1180: Bankruptcy ending
6. Lines 1190–1300: Success ending (7-day completion)
7. Lines 1320–1400: Random police/vandalism event
8. Lines 1410–1480: Instructions subroutine
9. Lines 1490–1570: “Quit after vandalism” ending

Variable Roles

Variable	Role
m	Total money in cents (starts at 1000 = $10.00)
p	Wholesale cost per cup in cents (starts at 3)
r	Daily rent in cents (50 = $0.50)
l	Player’s chosen sale price per cup in cents
c	Number of cups prepared by the player
d	Weather type index (1–6)
a	Cups actually sold (also reused as loop variable)
n	Raw demand value before price adjustment
day	Current day counter (1–7)
w$	6×18 string array of weather names
a$	6×18 string array; positions 17–18 hold demand parameters as CHR$ codes

Weather and Demand System

Six weather types are stored in w$(1..6). Demand parameters for each weather type are encoded as CHR$ values stored at character positions 17 and 18 of the corresponding row in a$. The raw demand is computed at line 590:

LET n=RND*CODE(a$(d,17))+RND*CODE(a$(d,18))

This sums two independent uniform random values, each scaled by a weather-specific constant, producing a roughly triangular distribution. The effective demand parameter pairs are:

Weather	Param 17	Param 18	Max raw demand
Cloudy	60	40	100
Sunny	80	90	170
Rainy	15	15	30
Stormy	7	10	17
Hot	105	130	235
Snowy	2	8	10

Sales Calculation and Price Sensitivity

Line 600 applies a price penalty to the raw demand:

LET a=INT(n-(1/(10-(l-p)))*n)

This reduces demand proportionally based on how far the sale price l exceeds the wholesale cost p. When l-p approaches 10, the denominator approaches zero and the formula produces a near-total wipeout of sales. The sale price is capped at 40 cents (line 450), so with p starting at 3, the maximum spread is 37, making the denominator negative and actually reversing the sign — a mathematical anomaly that rewards extreme overpricing with boosted (not penalized) demand when l-p > 10. This is a bug in the economic model.

Variable Reuse Conflict

The variable a is used both as the FOR loop counter in the graphics subroutine (lines 810, 860, 870, 890) and as the computed cups-sold value (line 600 onward). Since the graphics subroutine at line 780 is called before a is used for sales (line 590), this does not cause an in-game conflict, but it is a fragile design. The subroutine variable a in the graphics section also shadows the outer a, since BASIC uses a single flat variable namespace.

String Array as Data Store

Rather than storing demand parameters in a numeric array, the author stores them as single characters inside a string array a$ and retrieves their values with CODE(). This is an unconventional but memory-compact technique, embedding numeric data within a structure primarily used for text. Positions 1–16 of each a$ row are left as spaces (the default fill for DIM’d string arrays), and only positions 17 and 18 carry meaningful data.

Graphics Subroutine

The shop display subroutine (lines 780–1100) draws a storefront using block graphic characters (█ rendered as \:: escapes) to create walls, a counter, and a sign. Two animated lemon jugs are drawn using PLOT/DRAW sequences with a short PAUSE inside the loop to create a filling animation effect. The shop sign at line 930 uses CHR$ 8 (cursor left) combined with OVER 1 and OVER 0 to overlay a forward slash over the price display, simulating a cents notation (e.g., “3¢/cup”) without a dedicated character.

Clock Animation

Lines 510–560 animate a clock advancing from 9 o’clock through the business day. The hour variable t increments and wraps at 13 back to 1 (line 550), cycling until it reaches 8 (line 560), at which point the shop closes. Each tick uses PAUSE 30, making one simulated “hour” last about 0.6 seconds of real time.

Randomized Wholesale Price Creep

Line 730 increments the wholesale cost p by 1 cent with 40% probability each day (IF RND>.6 THEN LET p=p+1), creating a gradual cost-of-goods inflation that adds economic pressure over the week without requiring player input.

Vandalism Event

Line 90 fires a random vandalism event with approximately 3% probability, but only after day 2. This branches to the police report section (lines 1320–1400), which deducts $20 (2000 cents) from m and gives the player the option to quit (INKEY$="q") or absorb the loss and continue. Quitting leads to a separate “broke” ending at line 1490.

Key BASIC Idioms

• Busy-wait input loops: IF INKEY$="" THEN GO TO n used at multiple points
• Inline screen clearing via PRINT AT r,c;"...spaces..." rather than full CLS
• All monetary values stored internally as integer cents to avoid floating-point rounding, divided by 100 only at display time
• DIM of w$ and a$ inside the main loop (line 130, 200) — these are re-dimensioned each day, which is functionally harmless but wasteful

Notable Anomalies

• Re-dimensioning w$ and a$ with DIM on every pass through the day loop (lines 130, 200) resets the arrays and forces all values to be re-assigned each time — an inefficiency that works correctly but wastes time
• The demand formula breaks down when l-p >= 10, producing negative or zero denominators; no guard is present
• Line 1150 contains a missing space: "...make as much money as possible" and similar strings are split across lines in a way that can cause words to run together in the printed output (e.g., "youfailed")
• The unused variable z$ captures the ENTER keypress at line 30 as a string INPUT, which is functional but unconventional — a keypress loop would be more idiomatic