Frame this around the idea that games are a controlled testbed for general intelligence, not an end in themselves. Researchers justify game-playing AI on several grounds: • Well-defined benchmarks: Games have clear rules, states, legal actions and an unambiguous score, so progress is measurable and reproducible. This makes them ideal for comparing algorithms (e.g. the Atari Learning Environment as a standard benchmark for deep RL). • Controlled complexity: A game can be simple (Tic-Tac-Toe) or astronomically complex (Go has more legal positions than atoms in the observable universe), letting researchers scale difficulty while keeping the environment closed and cheap to simulate. • Transferable techniques: Methods proven on games transfer to real problems. The DQN and AlphaGo/AlphaZero line led directly to AlphaFold-style search + learning systems, datacentre cooling control, and robotics. The game is the proving ground; the algorithm is the product. • Safe, fast, cheap experimentation: Millions of self-play episodes can be run in simulation with no physical risk or cost, which is impossible in robotics or medicine. • Public milestones: Beating human champions (Deep Blue 1997, AlphaGo 2016, OpenAI Five, AlphaStar) are headline demonstrations that drive funding, attract talent and communicate capability to a wide audience. Support each point with a direct quote from a paper in the AI game-player case study reading list (e.g. Mnih et al. 2015 on DQN, or Silver et al. on AlphaGo) and add your own commentary on whether the justification holds.

Pick three distinct areas and, for each, name the games-research technique it draws on: 1. Robotics & autonomous control: The same RL pipeline that learns to play from pixels (state → action → reward) is used for robot locomotion, grasping and self-driving policies. Sim-to-real training is the direct descendant of game self-play. 2. Operations research & resource optimisation: Tree search and RL trained on game-like abstractions are applied to logistics, scheduling, traffic-signal control, datacentre cooling (DeepMind reported ~40% cooling-energy reduction) and energy-grid balancing. 3. Scientific discovery & design: AlphaZero-style search + learning generalised into AlphaFold (protein folding) and AlphaTensor (discovering faster matrix-multiplication algorithms). Game search becomes search over scientific hypotheses or designs. Other valid choices you could substitute: education/training simulators, automated game testing and balancing in the games industry, finance/portfolio strategy, and military/defence planning (worth mentioning as it links to the ethics question A3). Cite a paper for at least one area and comment on how strong the analogy to games is.

Discuss several strands and attribute views to researchers you have read: • Dual-use / militarisation: Techniques for super-human strategic play (StarCraft, Dota) transfer to autonomous weapons and battlefield planning. Many researchers call for restraint and oversight. • Compute & environmental cost: Training systems like AlphaStar/OpenAI Five consumes enormous compute, energy and money, concentrating capability in a few well-funded labs and raising fairness and sustainability concerns. • Reproducibility & hype: Headline results are hard to reproduce without industrial resources, and press coverage can overstate generality ('the AI is creative/strategic') beyond what the system actually does. • Addiction, manipulation & fairness in the games industry itself: Game-playing/player-modelling AI can be used to optimise engagement, microtransactions and matchmaking in ways that exploit players; bots also enable cheating. • Job displacement and deskilling in QA, design and professional e-sports. • Reward hacking / specification gaming: Agents exploit loopholes in the reward function (a recurring research finding) — a safety concern that scales badly to real-world deployment. This links nicely to your own Part B fitness function, where a creature might 'cheat' by flying rather than climbing. Quote at least one source and give your own reasoned position rather than just listing.

Avoid a simple yes/no — argue 'it depends, and the strongest systems are hybrids': • Where neural nets dominate: high-dimensional perceptual input (Atari from raw pixels — Mnih et al. 2015) and games too large to search exhaustively, where a network must generalise across states. • But pure neural nets are rarely the whole story: AlphaGo / AlphaZero combine a neural network (policy + value) WITH Monte Carlo Tree Search. The search does the lookahead; the network supplies priors and position evaluation. Neither component alone is as strong as the combination. • Classic strong players use little or no learning: Deep Blue beat Kasparov with alpha-beta search, massive parallel hardware and hand-crafted evaluation — no neural network. For solved or small games, exact search / minimax is optimal and beats any network. • Other paradigms compete: evolutionary methods and even simple heuristics can match neural approaches on some tasks, and tabular Q-learning is provably optimal on small discrete problems. Conclusion to argue: neural networks are the best tool for perception and generalisation in vast state spaces, but 'best game player' is usually a neural network embedded in a search algorithm with significant compute — so the honest answer is that architecture and search matter as much as the network. Back every claim with a cited example.

For each of three references, evaluate it against consistent criteria rather than just summarising it. Useful criteria: • Authority — who wrote it and where are they based? (e.g. a DeepMind paper by Mnih/Silver et al. carries weight from the authors' track record.) • Venue & peer review — published in Nature / NeurIPS / a top venue (high reliability) vs. arXiv preprint (useful but not yet peer-reviewed) vs. a blog post or press release (lowest, may be promotional). • Evidence & reproducibility — does it report methods, hyper-parameters and results others can reproduce? Is code/data released? • Citations & corroboration — is it widely cited and corroborated by independent work? • Recency & bias — is it current, and does the source have a commercial interest in the result (a company publicising its own product)? Worked example: 'Mnih et al. (2015), Human-level control through deep reinforcement learning, Nature 518 — highly reliable: peer-reviewed in a top journal, authored by domain experts, thousands of citations, methods reproducible and code subsequently released. Mild caveat: authored by the company (DeepMind) that benefits from the result, so corroboration by independent reproductions strengthens trust.' Do the same for two more, ideally choosing references of differing reliability so the evaluation has contrast. End with a one-paragraph reflection on the formatted reference list.

Goal: get a clean, reproducible environment before touching any logic. 1. Create an isolated environment, e.g. python -m venv venv and activate it (venv\Scripts\activate on Windows). 2. Install the dependencies the case-study code needs — at minimum pybullet and numpy (pip install pybullet numpy). Pin versions in a requirements.txt so the marker can reproduce your run. 3. Run python cw-envt.py. You should see the PyBullet GUI open with the yellow sandbox, the dark mountain mesh in the middle, and a randomly generated creature dropped into the arena (matching Figure 1 of the brief). 4. Common gotchas: if the mountain doesn't load, check the path to the generated mountain mesh/URDF that prepare_shapes.py produces; if PyBullet's GUI won't open over a remote/headless session, fall back to p.DIRECT for batch runs and only use p.GUI locally. Take a screenshot of the working environment — it is good evidence for the report and the start of your video demo.

This is the central integration task — connect your existing GA pipeline (genome, creature, population, fitness, main evolution loop) to the new environment. Key steps: • Loading: In your simulation/run loop, load the mountain (and the sandbox floor/walls) via p.loadURDF exactly as cw-envt.py does, instead of the flat plane you used in the course. Keep the mountain static (base fixed) so creatures climb a fixed obstacle. • Spawning: Generate a creature from its genome (the URDF your Creature/genome code emits), save it to a temp .urdf, and load it at a sensible drop point — typically at the foot of the mountain, slightly above the floor so it settles under gravity. • Stepping: Run the physics for a fixed number of steps per individual with p.stepSimulation(), applying your motor controls each step, then record the outcome used by the fitness function. • Population loop: Reuse your Population class — evaluate every creature in the generation, compute fitness, then selection → crossover → mutation → next generation, as in the course code. Only the environment and the fitness measure change. • Headless vs GUI: evolve in p.DIRECT for speed; render the best creature of a generation in p.GUI for your video. In the report, clearly highlight (per the brief) the blocks of integration code you wrote yourself versus the provided template.

This is where most marks are won or lost. Design a fitness that rewards real climbing. Baseline measure: track the creature's height (z) or, better, its straight-line distance to the mountain peak, and use the BEST value achieved across the whole simulation, not the final value — otherwise a creature that climbs then slides back is unfairly punished: fitness = max over all steps of ( peak_z − distance_to_peak ) (or simply max z). Anti-cheat (the explicit requirement): a naive 'reward height' lets a creature launch itself into the air. Counter this with one or more of: • Require ground/mountain contact — only count height while at least one body part is in contact with the terrain (use p.getContactPoints); ignore airborne frames. • Penalise vertical velocity / ballistic motion, or cap the reward when the creature is not touching the surface. • Reward horizontal-then-vertical progress toward the peak (closeness in x,y,z) rather than raw altitude, so jumping straight up gains little. Also consider penalising flips/instability and rewarding sustained contact, so solutions actually grip and climb. In the report, state the exact fitness formula, justify each term, and show a failure case (a 'flying' creature) that motivated the anti-cheat term — examiners love seeing the reasoning, not just the final function.

Treat this as a small empirical study. Change ONE factor at a time and measure its effect on climbing performance. Factors worth sweeping: • Population size (e.g. 10 / 25 / 50 / 100) • Number of generations • Mutation rate and mutation amount • Selection pressure (elitism count, tournament size) • Genome limits (max number of parts / links) Method: • Because GAs are stochastic, run each setting several times (e.g. 3–5 seeds) and report mean ± spread, not a single run. • Log best and mean fitness per generation to a CSV. Presentation (the brief explicitly asks for graphs AND tables): • Line plot: best/mean fitness vs generation, one line per setting — shows convergence. • Bar chart or table: final best fitness vs population size (or whatever you varied). • A summary table of every configuration and its result. Then interpret: e.g. 'larger populations reached higher fitness but with diminishing returns beyond N=50 and far higher runtime; mutation rate X gave the best exploration/exploitation balance.' Analysis earns more than raw plots.

The advanced part changes HOW genomes map to creatures, expanding or constraining the design space. Pick one or two clear experiments and compare against your baseline. Ideas (from the brief): • Motor controls: change how genome values drive the joint motors — e.g. different waveform/control parameters, frequency/amplitude ranges, or a different control function — and see how it affects gaits for climbing. • Part shapes: extend the decoder so parts can be different shapes/sizes (not just the default), changing how creatures grip and balance on the slope. • Partial evolvability: fix some parts of the robot and evolve only others. Two concrete experiments named in the brief: (a) start from a FIXED body design and evolve only the motor-control parameters; (b) fix some parts (e.g. the torso) and evolve only the legs. • Different connection settings: change how parts attach (joint types, symmetry rules). For each experiment: describe the change to the encoding, why you expected it to help, run it under the same fitness/measurement as B4, and present graphs/tables comparing it to the baseline encoding. Conclude whether the richer/narrower design space actually produced better climbers.

Exceptional work shows genuine independent investigation beyond the basic + advanced criteria. Two strong, well-scoped directions from the brief: 1. Different landscapes: use prepare_shapes.py to generate several mountain/terrain shapes (different heights, slopes, multi-peak or rough terrain) and study how the evolved creatures and the best strategies differ per landscape. Do creatures specialise? Does a creature evolved on one mountain generalise to another? This is a clean, novel experiment. 2. Sensory input / closed-loop control: at present the creatures are open-loop — motors ignore the world. Add a sensor (e.g. the direction/angle to the peak, or a contact/orientation sensor) and let motor activation depend on it — for example motors that only turn on when the creature is facing uphill. This turns the controller into a reactive agent and is a meaningful step up in complexity. Whichever you choose: motivate it, implement it cleanly, run controlled experiments with graphs/tables, and critically discuss the results (including what didn't work). The brief also asks for a short 'Why my work is exceptional' statement — write it explicitly, mapping your extensions to the marking criteria.

Follow the brief's mechanical instructions exactly — marks depend on it: • Concatenate: on Windows PowerShell the equivalent of `cat *.py > mycode.txt` is `Get-Content *.py | Set-Content mycode.txt` (or `gc *.py > mycode.txt`). Make sure every source file is included. • Highlight YOUR code: paste into Word/Docs and apply a clear colour highlight to the blocks you wrote unaided (your integration code, fitness function, encoding changes, experiment harness). Leave provided template code un-highlighted. This is how the 'code you personally wrote' criterion is assessed. • Convert to PDF and submit as a single file. Tip: keep your own code in clearly named functions/files so highlighting is easy and the marker can see the boundary between template and your work at a glance. Good formatting and comments are explicitly part of the code marks.

The video is marked on structure and explanation, not just footage. Plan it like a short talk: • Intro slide: the task and your fitness function. • Show evolution working: footage of early random creatures vs. a late-generation climber, with a sentence on what changed. • Basic experiments: a couple of result graphs (population size, mutation rate) with commentary on what they show. • Advanced section: explain your encoding-scheme experiment and show the resulting creatures. • Exceptional section (if attempted): landscapes or sensory input, with results. • Wrap-up: what worked, what you'd do next. Practical: render the best creature per condition in PyBullet's GUI and screen-record it; narrate over slides rather than showing a silent montage (the brief warns against a pure montage). Keep it close to 5 minutes and export as MP4. Final deliverables checklist: Report (1,500–2,000 words, PDF, word count on page 1), all code as a highlighted PDF, the ~5 min MP4, and the 'Why my work is exceptional' statement if you attempted the extensions.

Structure the report against the Part B marking criteria so a marker can tick each line: 1. Title + word count on page 1 (explicit requirement). 2. Introduction: the task (evolve creatures to climb the mountain) and your approach. 3. Integration & fitness: how you connected the GA to the environment and the exact fitness function, including the anti-cheat (no-flying) design and why. 4. Basic experiments: method (multiple seeds), then results as graphs AND tables, with interpretation — not just figures. 5. Encoding-scheme experiments (advanced): what you changed, hypotheses, results vs baseline. 6. Exceptional work (if attempted): landscapes / sensory input, results and critical discussion. 7. Conclusion: what worked, limitations, future work. You may include short code fragments where they aid explanation. Keep within 1,500–2,000 words by being concise in prose and letting the graphs/tables carry the data. Reference any sources properly, as in Part A.