{"id":20707484,"url":"https://github.com/code-help-tutor/cs3110-a2","last_synced_at":"2025-07-03T12:03:52.765Z","repository":{"id":234136352,"uuid":"784580231","full_name":"code-help-tutor/cs3110-a2","owner":"code-help-tutor","description":"cs3110 a2 代写代做 编程辅导, code help, CS tutor, WeChat: cstutorcs Email: tutorcs@163.com","archived":false,"fork":false,"pushed_at":"2024-04-10T06:09:47.000Z","size":17,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-11T05:23:18.670Z","etag":null,"topics":["a2","cs3110"],"latest_commit_sha":null,"homepage":null,"language":"OCaml","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/code-help-tutor.png","metadata":{"files":{"readme":"Readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2024-04-10T06:09:41.000Z","updated_at":"2024-04-10T06:09:50.000Z","dependencies_parsed_at":"2024-04-18T09:29:49.450Z","dependency_job_id":null,"html_url":"https://github.com/code-help-tutor/cs3110-a2","commit_stats":null,"previous_names":["code-help-tutor/cs3110-a2"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/code-help-tutor/cs3110-a2","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/code-help-tutor%2Fcs3110-a2","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/code-help-tutor%2Fcs3110-a2/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/code-help-tutor%2Fcs3110-a2/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/code-help-tutor%2Fcs3110-a2/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/code-help-tutor","download_url":"https://codeload.github.com/code-help-tutor/cs3110-a2/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/code-help-tutor%2Fcs3110-a2/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":263322786,"owners_count":23448712,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["a2","cs3110"],"created_at":"2024-11-17T01:26:25.282Z","updated_at":"2025-07-03T12:03:52.734Z","avatar_url":"https://github.com/code-help-tutor.png","language":"OCaml","readme":"# A2: Adventure\n\n**Deadline:** Monday, 10/23/23, 3:00 pm\n\n*This assignment is to be done as individuals, not with partners nor with teams.*\n\nIn this assignment, you will develop a *text adventure game* (TAG), also\nknown as *interactive fiction*. The characteristic elements of TAGs\ninclude gameplay driven by exploration and puzzle-solving, and a\ntext-based interface in which users type natural-language commands and\nthe game responds with text. The seminal work in this genre is the\n[Colossal Cave Adventure][adventure].\n\n**Exercise:** An interactive example is worth a thousand words. So\nbefore reading any further in this writeup, spend just a few minutes\nplaying this [online version of Colossal Cave Adventure][playcave].  And\ndon't worry; that game is far bigger than what you will build in this\nassignment.\n\n**How to get started:**\nBegin by reading this entire writeup and making sure you have a good\nunderstanding of it. The next thing you should do is spend a good bit of\ntime, maybe a whole day, sketching out on paper how you're going to\nsolve this assignment. Your focus should be on identifying what features\nyou need to implement, what data structures and functions you'll need\nfor those features, and how you'll go about testing those data\nstructures and functions during the process of implementing them.\nWaiting until the very end to test is a recipe for disaster!\n\n[adventure]: https://en.wikipedia.org/wiki/Colossal_Cave_Adventure\n[playcave]: https://rickadams.org/adventure/advent/\n\n**Table of Contents:**\n\n* [Introduction](#intro)\n* [Assignment information](#assignment-info)\n* [Part 1: Game engine](#part-1-game-engine)\n* [Part 2: Testing](#part-2-testing)\n* [Part 3: Your own adventure](#part-3-your-own-adventure)\n* [What to turn in](#what-to-turn-in)\n* [Assessment](#assessment)\n* [Karma](#karma)\n\n## Introduction\n\nYou are to implement a *game engine* that\ncould be used to play many *adventures*.  Here, the game\nengine is an OCaml program that implements the gameplay and\nuser interface.  An adventure is a data file that is\ninput by the game engine and describes a particular gaming\nexperience:  exploring a cave, hitchhiking on a spaceship,\nfinding the missing pages of a powerful magical book, etc.\nThis factoring of responsibility between the engine and\ninput file is known as *data driven design* in games.\n\nThe gameplay of TAGs is based on an *adventurer* moving between *rooms*.\nRooms might represent actual rooms, or they might be more\nabstract\u0026mdash;for example, a room might be an interesting location in a\nforest. Each room also has a text description associated with it.  Some\nrooms have *items* in them.  These items can be taken by the adventurer\nand carried to another location, where they can then be dropped.  The\nadventurer begins the game in a predetermined *starting* room, possibly\nwith some predetermined items.\n\nThe *player* does not so much win a TAG as *complete* the TAG by\naccomplishing various tasks:  exploring the entire *map* of rooms and\ncorridors, finding items, moving items to specified locations, etc.  To\nindicate the player's progress toward completion, a TAG gives a player a\nnumeric *score*.  The TAG also tracks the number of *turns* taken by the\nplayer.  Savvy players attempt to achieve the highest score with the\nlowest number of turns.\n\nYour task is to develop a game engine and to write a small adventure of your own.\n\n## Assignment information \n\n**Objectives.**\n\n* Design and use data types, especially records and variants.\n* Write code that uses pattern matching and higher-order functions on lists and\n  on trees.\n* Interact with the environment outside the program by reading and writing\n  information from files and the user.\n* Use JSON, a standard data format.\n* Practice writing programs in the functional style using immutable data.\n\n**Recommended reading.**\n\n* The front page of the [JSON website][json]\n\n*Caution: There is a chapter on JSON in [RWO][rwojson], but you are\nprobably better off ignoring it.  The features used in that chapter are\nmore advanced than what you need, hence might be more confusing than\nhelpful for this assignment. The ATDgen library and tool at the end of\nthat chapter are not permitted for use on this assignment, because using\nthem would preclude some of the list and tree processing that we want\nyou to learn from this assignment. Note that the Core library used in\nthat book is not supported in this course.\n\n[rwojson]: https://dev.realworldocaml.org/json.html\n\n**Requirements.**\n\n1. Your engine must satisfy the requirements stated below.\n\n2. You must submit your own, original small adventure file.\n\n3. You must submit an OUnit test suite, as described below.\n\n4. Your code must be written with good style and be well documented.\n\n**What we provide.**\nIn the release code on the course website you will find these files:\n\n* Several `.ml` and `.mli` files:  `command.ml(i)`, `state.ml(i)`, and `main.ml`.\n  You are permitted to change the `.ml` files (i.e., the implementations) \n  but not the `.mli` files (i.e., the interfaces), unless otherwise specified.\n  You are permitted to add new compilation units of your own design.\n* A couple small adventure files, `one_room.json` and `two_rooms.json`, that you could\n  use as a basis for writing new adventures.\n* A larger adventure file, `small_circle.json`.  When you finish your engine, you\n  can play this file.\n* A JSON schema `schema.json` for adventure files that defines\n  the format of such files.  It is not an adventure file itself,\n  so your engine will not be able to load it.\n  Most people will want to ignore this file, but we provide it for those\n  who want an exact description of the JSON format for adventures.\n* A dune setup for compiling your code.\n\n**Grading issues.**\n\n* **Late submissions:** Carefully review the course policies on\n  submission and late assignments.  Verify before the deadline\n  that you have submitted the correct version.\n* **Environment, names, and types:**  You are required to adhere to the names and\n  types of the functions and modules specified in the release code. \n  Otherwise, your solution will receive minimal credit.\n\n**Prohibited OCaml features.**\nYou may not use imperative data structures, including refs, arrays,\nmutable fields, and the `Bytes` and `Hashtbl` modules.  Strings are\nallowed, but the deprecated functions on them in the [`String`\nmodule][string] are not, because those functions provide imperative\nfeatures. The `Map` module is not imperative, hence is permitted. Your\nsolutions may not require linking any additional libraries/packages\nbeyond OUnit, Yojson, Str, and ANSITerminal.\nYou may and in fact must use I/O functions provided by the\n`Pervasives` module, even though they cause side effects,\nto implement your user interface.\n\n[string]: https://caml.inria.fr/pub/docs/manual-ocaml/libref/String.html\n\n## Part 1: Game engine \n\nImplement a game engine that provides the following functionality.\nThe release code provides the following files to get you started:\n\n* `Command`:  a compilation unit (`.ml` + `mli`) for player commands.\n* `State`: a compilation unit for the state of the game.\n* `main.ml`: the user interface to the game.\n\nYou are permitted to change the `.ml` files.  The existing code\nin the `.mli` files may not be changed, unless otherwise specified,\nbecause those files declare the names and types against which the course\nstaff will test your engine.  You are permitted to add new\ndeclarations to the `.mli` files, because additional names and types\nthe course staff is unaware of will not impair our testing.\nIn fact, you will almost certainly want to declare new names and types\nin `state.mli`.  \n\n**Interface.**\nThe interface to a TAG is based on the player issuing text *commands* to\na *prompt*; the game replies with more text and a new prompt, and so on.\nThus, the interface is a kind of read-eval-print-loop (REPL), much like\n`utop`. For this assignment, commands will generally be two-word phrases\nof the form \"VERB OBJECT\".  We leave the design of the user interface up\nto your own creativity. In grading, we will not be strictly comparing\nyour user interface's text output against expected output, so you have\nfreedom in designing the interface.\n\nAll the console I/O functions you need are in the [`Pervasives`\nmodule][pervasives]. Some people might want to investigate the [`Printf`\nmodule][printf] for output, but it's not necessary. The `Scanf` module\nis overkill for input in this assignment; in fact the `read_line`\nfunction in `Pervasives` is probably all you need. For parsing player\ncommands, you are welcome to use the OCaml [Str library][str], but\nit's not necessary; the standard library `String` module suffices.\n\nYour user interface must be implemented entirely within `main.ml`\nor any supporting modules you design yourself.  It may not\nbe implemented in `state.ml`.   There are a couple reasons for \nthis restriction.  First, we want you to think of `State` as being \npurely functional.  Second, games are often designed using the\n[Model-View-Controller][mvc] design pattern.  Here, `State` \nis the model, hence it should not be implementing any of the \nuser interface.  Indeed, you should imagine your `State` module \nbeing usable equally well by other programmers implementing \ngraphical user interfaces, which have no need for printing of text \nresponses. So instead of printing inside `State`, you can add \nfunctions to the `State` interface to help  `Main` figure out \nwhat to print.\n\n[mvc]: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller\n\n**Commands.**\nYour engine is required to support the following commands:\n\n* **Movement** is performed by using the verb \"go\" followed by the\ndirection.  The room itself determines what the allowed directions \nare, for example, \"go north\", \"go up\", \"go clock tower\", etc.\nIf such movement is possible, the adventurer transitions to a\nnew room, and the description of the new room is displayed.  The\ndescription of the room may vary depending on the items in the\nplayer's inventory or located in the room itself.  If the\nmovement is impossible, an error message is displayed.  As a\n*shorthand*, the player may simply type the direction itself without the\nverb \"go\".  For example, \"go north\" and \"north\" are equivalent. For\nmovement to be possible, certain *keys* may be necessary, and it suffices\nfor those keys to be either in the player's inventory or located\nin the room from which movement originates.\n\n* **Items** can be manipulated by the verbs \"take\" and \"drop\" followed\nby the name of the item, for example, \"take hat\", \"take bronze key\", etc.\nThe command \"take\" transfers an item from the current room\nto the adventurer's *inventory*, and \"drop\" transfers an item from the\ninventory to the current room.  The items present in the current room\nare displayed whenever the room description is displayed.\n\n* **Other commands** include \"quit\", which ends the game, \"look\", which\nre-displays the description of the current room, \"inventory\" (shorthand:\n\"inv\"), which gives a list of what the adventurer is currently carrying,\n\"score\", which displays the current score, and \"turns\", which displays\nthe current number of turns.\n\nInput from the player must be handled as case-insensitive. \nFor example, \"go north\" and \"gO NoRtH\" should be recognized and\ntreated as the same.  Nonetheless, the room descriptions, directions\nand item names in the adventure file are case sensitive and should be\ndisplayed by the engine with their proper case.  For example, if the\nadventure file defines an item named \"Lambda\", then when that name is\ndisplayed it should be \"Lambda\" and not \"lambda\". But the player is\npermitted to enter \"take lambda\" to pick it up. \n\nA *turn* is any successfully completed issue of the commands\n\"go\" (or any of its shorthand forms), \"take\", or \"drop\".  For example,\n\"go north\" counts as a turn only if the current room permits exit to the\nnorth. At the beginning of play, the current number of turns is zero.\n   \n**Scoring.**\nThe player's score is determined by these rules:\n\n* The player starts with zero points, but might automatically receive\n  more as described below.\n\n* Every room is worth a certain number of points, which are earned simply\n  for having entered the room at least once.  The player automatically\n  gets whatever points are associated with the starting room at the\n  beginning of play.\n\n* Every item is worth a certain number of points.  The points for an\n  item are earned if the item is currently located in a *treasure room*.\n  Different items may have different treasure rooms, and a single item\n  might have multiple possible treasure rooms. Dropping an item\n  in the item's treasure room(s) earns points, and taking the item away\n  loses points.  The player automatically gets whatever points\n  are associated with items already located in their treasure room(s) at\n  the beginning of play.  Taking or dropping an item in a room\n  other than its treasure room(s) is permitted but has no effect on the score.\n  Items in the adventurer's inventory are not located in any room;\n  they must be dropped to be considered as located in a room.\n  \n* The points that a room or item is worth might be positive, zero, or \n  negative.\n\nThe *winning score* for a game is sum of all the item points plus the\nsum of all the room points, regardless of whether it's actually possible\nto earn those points (i.e., maybe a room is unreachable), or whether the\npoints are negative (hence decrease the sum).  If the player does earn\nthe winning score possible for the adventure, the game engine informs\nthe player that they have completed the adventure using a message\nspecified in the adventure file, but the player is\nstill allowed to interact with the game afterwards\u0026mdash;the game\ndoesn't automatically quit.  So the player's score might go down or up\nagain.  After the completion message has been displayed once, the engine\ndoes not have to display it again.\n\n**Robustness.**\nWe want you to imagine that you are writing the game engine as a product\nthat you ship to customers.  The customers then additionally acquire\nadventure files that they want to play, and those files could be authored by\nsomeone other than you.  In that scenario, you want to make sure that\nthe customers do not blame you for errors that are not your own.  That\nis, the game engine itself should not exhibit any errors, but if it\ndetects an error in an adventure file, it should correctly blame that\nfile (and by association its developer rather than you).\n\nSo your game engine may not terminate abnormally, meaning it may not \nraise an unhandled exception, nor may it go into an infinite loop\nthat would prevent the player from entering a command. But if the\nadventure file itself contains errors, your engine is permitted to\nprint an error message blaming the adventure file, then terminate\nnormally.\n\n**Adventure files.**\nAdventure files are formatted in [JSON][json].  We provide a couple\nexample adventure files in the release code. Note that the JSON property\nnames in that file may not be changed. Also note that many of the\nproperty values are strings, which are case sensitive and can contain\narbitrary characters (including whitespace). An adventure file contains\nsix main entries:\n\n* The rooms.  Each room contains five entries:\n  - an id,\n  - a list of descriptions (a description itself contains two entries:\n    the set of items that must be collectively present in the adventurer's inventory\n    or in the room in order for that description to be displayed,\n    and the description text itself; the first description in the list\n    for which all the items are present is the one that must be displayed),\n  - the number of points exploring the room is worth,\n  - the exits from the room (an exit itself contains three entries:  the\n    direction of the exit, and the room to which it leads, and the items\n    that the adventurer must have in their inventory or must be present in\n    the room for the exit to be unlocked), and\n  - the treasures that should be dropped in the room.\n* The items.  Each item contains three entries:\n  - an id (which is the item's name by which it can be taken and dropped),\n  - a description, and\n  - the number of points the item is worth when it is dropped in its treasure room,\n    or any one of its treasure rooms if there are multiple.\n* The starting room (where the adventurer begins).\n* The starting items (which are initially in the inventory).\n* The starting locations of all items not in the inventory.  Each location contains\n  two entries:\n  - the id of the item\n  - the room id where the item starts\n* The message to display when the player wins\n  \nAdventure files will never have huge maps in them; as a rough estimate\nthere might be on the order of 100 rooms and 100 items.\n\nFor those who desire additional precision, we provide a JSON schema for\nadventure files in `schema.json`.  Your game engine is required to be\ncompatible with this schema, which defines the required elements of the\nfile and their names.  It is possible for you to extend this schema\nto add more functionality to your engine, but you must make sure that\nyou don't remove any properties or objects and that you maintain support\nfor adventures that don't have your additional features.  Otherwise,\nthe course staff will be unable to grade your submission using our test suite\nof adventures.  Using a JSON [schema validator][validator], you can check the\nwell-formedness of an adventure file again the schema.\n\n[json]: http://json.org/\n[schema]: schema.json\n[validator]: http://www.jsonschemavalidator.net/\n\nThere are many errors that could exist in an adventure file, however,\nthat cannot be detected by a schema validator.  For example, a room\ncould have an exit to a non-existent room, or two items could have the\nsame name, or a non-existent item could be given in the starting\ninventory, or there could be two exits with the same name,\netc.  For these and other such errors that are the fault of\nthe adventure file creator (as discussed above under the heading\n\"Robustness\") your game engine may not itself exhibit any errors, but it\nmay blame the adventure file and terminate normally. \n\nYour engine is not responsible for detecting adventure file errors or \nfor attempting to continue gameplay beyond the point it happens to \ndetect an error, although your engine may not raise unhandled exceptions \nor go into an infinite loop, as discussed above under \"Robustness.\"\n\n**JSON.**\nWe recommend using the [Yojson library's Basic module][yojsonbasic] for parsing JSON\nadventure files.  Although you are welcome to use any functionality\nprovided by the library, we suggest concentrating your attention\nas follows:\n\n* Use `Yojson.Basic.from_file` to read the contents\n  of a JSON file and construct a `Yojson.Basic.json` tree.\n  `Yojson.Basic.from_string` might also be helpful for test cases.\n* Use the `Yojson.Basic.Util` module to extract information\n  from that tree.  That module might seem intimidating at first,\n  but there are really a very small number of functions that you\n  need.  In fact, you can implement your entire parser with just\n  these:  `member`, `to_list`, `to_string`, and `to_int`.\n  \n[str]: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Str.html\n[yojsonbasic]: https://mjambon.github.io/mjambon2016/yojson-doc/Yojson.Basic.html\n[pervasives]: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html\n[printf]: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Printf.html\n\n**Plan of attack.**\nHere's one way you might approach implementation of your game engine.\n\n1. Implement the loading of an adventure file into a `json`-typed value.\n\n2. Implement converting that JSON into OCaml types, including designing\n   the types.  Do some interactive testing in `utop` to check whether it looks\n   like the conversion is being done right.  \n\n3. Implement the game state, including producing the initial state,\n   and all the required functions except `run_command`.  Write an OUnit test suite\n   using those required functions to make sure the initial state is correct for\n   some small adventure files.\n\n4. Implement parsing of a string into a verb and object (if any),\n   including designing a type to represent commands.  Do interactive\n   testing in `utop` to make sure all the commands that need to be supported\n   are being correctly parsed.\n\n5. Implement `run_command` and write a OUnit test suite for some test adventure files.\n\n\nTasks 2 and 5 are probably the hardest, but YMMV.\n\n## Part 2: Testing\n\nThere are two aspects to testing this assignment.\nThe first is to create an OUnit test suite in `test_state.ml`.\nThe second is to playtest your REPL.\n\n* *Unit testing*:  Write black-box unit tests against the\n`State` interface.  Determine whether the initial state computed by your\nJSON parser is correct.  Determine whether the state is updated\ncorrectly based on commands. Your unit tests should use the interface\nprovided by `state.mli`. You are not required to submit unit tests for\nany functions beyond those in the interface (e.g., helper functions you\ndesign yourself), though of course you are permitted to do so.\n\n\n\n## Part 3:  Your own adventure \n\nWrite and submit your own adventure that a grader will play using your\nown engine. Your adventure must have at least 5 rooms and 3 items. If\nyour engine is somehow non-operable, the grader will attempt to play it\nusing the staff's own engine.\n\nWe ask you to do this for two reasons.  First, it will help you\nunderstand the adventure file format and implement your game engine. (So\nyou need not do this part last!)  Second, it provides you with an\nopportunity for some creativity, which we encourage but will not assess\nas part of your grade. If there are some really great adventures\nsubmitted, we will consider making them available for other students to\nplay.\n\n\n\n## Assessment \n\nThe course staff will assess the following aspects of your solution.\nThe percentages shown are the approximate weight we expect each to receive.\n\n* **Correctness.** [50%] Does your solution compile against and correctly pass\n  the course staff's test cases? Only Part 1 is relevant to Correctness.\n  As a rough guide, here is a further breakdown of the approximate weight we expect \n  to assign to the parts of our test suite: `init_state`: 20%; unit tests for `run_command` and \n  `parse`: 60%; integration tests on new adventure files of our own creation: 20%.\n  Note that these tests are necessarily somewhat cumulative:  if your solution\n  cannot read in a simple adventure file (e.g., `one_room.json`) or parse at least\n  simple player commands, then it has no chance of passing unit tests for `run_command`.\n  Partial credit is based on the test cases your submission passes, not on\n  code you write per se.  So to optimize your partial credit, make sure your submission\n  can read `.json` files and parse player commands before spending a lot of time\n  implementing `run_command` or a fancy REPL.\n\n* **Testing.** [15-20%] Does your test suite for `State` adequately \n  provide black-box tests against the specification?\n\n* **Code quality.** [15-20%] How readable and elegant is your source code?  How\n  readable and informative are your specification comments?  All functions,\n  including helper functions, must have specification comments.\n\n* **Gameplay.** [10-15%] How usable is your REPL?  Does it ever\n  terminate abnormally?  Does it print the messages it is\n  supposed to print?\n\n* **Your own adventure.** [5%] Did you submit an adventure meeting the \n  minimum requirements?\n\n## Karma \n\nYou are highly encouraged to go beyond the minimal requirements for this\nassignment as described above. But, no matter what you implement, be\nsure to maintain compatibility with the basic adventure file format and\nrequired commands.  Note that it should be possible to add additional\ninformation (e.g., properties and objects) to the JSON file and still\nremain compatible with the required schema.  Your karma\nimplementation must not cause you to change or violate the\nspecifications of any of the functions in the provided interfaces.  It's\ntrue that might rule out some cool features that you have in mind, but\nwe hope you understand that the course staff must be able to run \nyour solution through our autograder with those interfaces.\n\n**Experienced Adventurer:**\n\n* item sizes and weights, and inventory limits on those\n* game save and restore\n* consumable items (e.g., money, which could be earned and spent)\n* time passing as adventurer explores, with effects occurring as a result\n  (e.g., the sun rises and sets, and what is possible changes as a result)\n* other in-game characters (which could be stationary or could themselves\n  wander around) with which the adventurer can have conversations\n* the adventurer getting lost in a maze\n\n**Seasoned Adventurer:**\n\n* an automated bot that completes adventures without human assistance  \n* flexible command parsing so that users can type in interesting natural\n  language instead of two-word commands\n* a larger vocabulary of commands that enables designers to create puzzles\n  and players to solve them (e.g., manipulating items and rooms\u0026mdash;locks and\n  keys are a good place to start)\n  \n**Master Adventurer:**\n\n* text-based graphics to display images of rooms, a map of the area\n  explored so far, etc.\n* a level editor that makes it easy for designers to create adventure files\n  without having to write JSON themselves\n\n* * *\n\n**Acknowledgement:** \nAdapted from Prof. Michael Clarkson (Cornell University),\nwho in turn adapted it from Prof. John Estell (Ohio Northern University).\n# cs3110 a2\n\n# 程序代做代写 CS编程辅导\n\n# WeChat: cstutorcs\n\n# Email: tutorcs@163.com\n\n# CS Tutor\n\n# Code Help\n\n# Programming Help\n\n# Computer Science Tutor\n\n# QQ: 749389476\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcode-help-tutor%2Fcs3110-a2","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcode-help-tutor%2Fcs3110-a2","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcode-help-tutor%2Fcs3110-a2/lists"}