Luet oppimateriaalin englanninkielistä versiota. Mainitsit kuitenkin taustakyselyssä osaavasi suomea. Siksi suosittelemme, että käytät suomenkielistä versiota, joka on testatumpi ja hieman laajempi ja muutenkin mukava.

Suomenkielinen materiaali kyllä esittelee englanninkielisetkin termit.

Kieli vaihtuu A+:n sivujen yläreunan painikkeesta. Tai tästä: Vaihda suomeksi.

Chapter 11.1: Your Text Adventure

About This Page

Questions Answered: What will my own text adventure be like?

Topics: Practice on designing a program independently. Explore other programming topics as you choose. You can practice on pretty much any topic covered so far in O1 or even something we haven’t covered.

What Will I Do? Program. Make design decisions about which sort of program to create and how.

Rough Estimate of Workload:? Even though you can work from the given starter code, deciding on your goals, refining them, and coming up with the needed solutions can be very difficult for a beginner. Even if you happen to be a seasoned programmer already, you can turn up the difficulty for a greater challenge. The length of the assignment depends on your own ambitions, but for nearly all students, this is O1’s most time-consuming project. We recommend that you reserve an absolute minimum of 10 hours, and preferably at least 15. There’s no upper limit — you can sink weeks into this if you’re so inclined.

Points Available: C200.

Related Modules: Adventure.

Task Description

Forget about the forest, the remote, the batteries, and the other elements of the given game world and write a new text adventure game. Use any elements you like. Let your hair down and create!

Here are some ideas that you can develop further if you like. But feel free to ignore this list and come up with something entirely of your own instead.

Classic adventure. The player could explore an ancient pyramid, for instance, or venture into a ruined castle. The game world consists of rooms, passages, and the like.
Modern adventure. For instance, the player could be a first-year student at university who needs to accomplish one thing or another. The game world consists of buildings and rooms on campus.
Mystery adventure. The player has to recover a lost item, find out whodunnit, or something of the sort.
Action adventure. For instance, the player might need to escape from somewhere.
Literary adventure. The player takes the role of Alice, Captain Ahab, Clarice Starling, Marjane Satrapi, Randle McMurphy, Dolores Abernathy, or someone else.
Inhuman adventure. The player character is a dog, an insect, a robot, a microbe, a planet-eating space creature, a sentient kumquat, or anything you like.
Something completely different. Anything that makes a game. For instance, the areas of the game aren’t spatial locations but states of mind, stages of life, or something else.

Task requirements in more detail

The game should have:

Areas that the player can enter.
Challenges or puzzles that player needs to deal with in order to win the game.
At least a few new textual commands that the player can use for doing something meaningful.
A new victory condition that the player must reach to win the game. It needs to be something other than simply walking over to another location. You can also include loss conditions (e.g., the player character dying), but that’s optional.
A welcome message that indicates what the game is about and what the player should try to accomplish. If you prefer that the goal of the game is revealed only while the game is in full swing, that’s okay, too, as long as it doesn’t take a disproportionate effort to discover the goal.
A help command that prints out instructions for playing. Include any commands you added that the player should know about.
One or both of:
1. A command of the form use itemname, which makes the player character use an item. What happens as a consequence should depend on the item.
2. Non-player characters — human or non-human — that move about in the game world and are somehow useful, dangerous, or otherwise meaningful.

Within the module that you submit, you should also include:

A file that contains a “cheater’s map” of the game world (cf. the given forest_map.gif).
- This map should be in PNG, GIF, or PDF format or (failing that) as a character-based diagram in a plain text file.
- Name it map.png or something similar.
- Place it in the module’s root folder.
A walkthrough that describes, step by step, how to win the game.
- Write the walkthrough in the same file as the map or in a separate walkthrough.txt (or similar) at the module root.
- The teaching assistants may use the walkthrough as they assess your game. A less frustrated TA may go easier on the marking. :-)

On non-game projects

In case you are absolutely dead set against programming a game of any sort, you may suggest a personal topic for a project of the same size. Send your detailed suggestion to the head assistants (Chapter 1.1) well in advance of the deadline. You will be entirely responsible for picking a topic and a schedule that are realistic for you; we also cannot fully guarantee that grading will be exactly comparable. In any case, your program must be written in Scala, and it must be comprehensible to the course’s teaching assistants. Do not suggest a topic that is substantially more complex than the game topic described on this page.

This is not a good option for beginners, and we do not recommend this to other students either. There are other courses that follow O1 and enable you to do a completely personal project on a free topic.

On Marking

O1’s teaching assistants will manually assign a mark to your game.

The marking won’t be very strict. If your game fulfills the above requirements, you can expect to get at least half the available points. Indeed, you can expect to get more than that unless the assistants discover serious flaws such as game-breaking bugs or completely illegible source code.

The game does not need to be a mind-blowing spectacle for you to the full points. For that, it’s enough that you submit a reasonably high-quality program that works and fulfills the listed requirements.

Your code will be read by a human, so write clearly. Remember O1’s style guide. You don’t need to obey that guide or any other specific set of guidelines slavishly; the important thing is that you get the basics right so that an unknown person can read your code with reasonable effort. Indent your code, pick sensible names for variables, and so forth. If your code is very hard to read, you’re unlikely to score full marks.

You aren’t required to write comments in your code, but you may do so at your own discretion.

The size of the game is not a significant factor in grading. Although a larger game world may result in a more interesting game, adding more areas merely in the hopes getting more points is not worth it. You can very well score full marks with a small game of just a few well-functioning areas.

The assistants may award additional points at their discretion. You can score them for technical quality but also for interesting and fun details in your game.

We’ll publish the scores two weeks after the deadline, at the latest.

Each of the assistants picks their own favorite among the games in their packet. In making that decision, the assistant may use any criteria, such as entertainment value, originality, or technical merits. We’ll reward the assistants’ favorite games with movie vouchers and make those games available for other O1 students to see in A+, unless you specifically request that we don’t do that.

Further Instructions and Hints

Have fun.
We accept games in English, Finnish, and Swedish.
You can build on the given Adventure module. You’ll need to edit some or all of the classes. The class Adventure, especially, needs a complete makeover or could even be replaced by a different class altogether.
You may very well focus on building the game logic and leave the user interface(s) untouched.
- You are allowed to change the user interfaces if you want to. Indeed, you are completely free to change anything in the given code and add whatever you wish.
- The game does not need to be compatible with both the given AdventureTextUI and AdventureGUI. One user interface is enough (and you can even create your own if you choose). In any case, it’s good to follow the principle of keeping the game’s inner logic independent of the user interface.
Hopefully, inspiration will hit you and you’ll create something fun. But don’t bite more than you can chew: there’s only a limited amount of time until the deadline.
- You can ask the teaching assistants to help you estimate how time-consuming it might be to implement a feature that you have envisioned. Ultimately, though, you are personally responsible for your own schedule.
- Try to work on one feature of the game at a time, finishing it before moving on to additional features. That way, you’ll have something submissible even if you run out of time before you can implement every feature that you had planned.
Additions to the game mechanics are welcome but optional. For instance, you may wish to consider: new directions to move in; vehicles; attributes or abilities for the player character; weights for items that limit what the player can carry; complex commands that consist of multiple words; etc. etc.
Don’t keep the generic module name “Adventure”. Instead, please follow the instructions below to rename the IntelliJ module. Renaming not only makes sense, it also helps the teaching assistants distinguish between modules written by different students.
1. Right-click the module in the Project view and select Refactor → Rename.
2. IntelliJ asks if you’d like to rename the module, or the folder (directory) on disk where the module is located, or both. Usually, it’s a good idea for a module and its folder to have the same name. Pick Rename module and directory and type in a descriptive name. (You might see only separate options for the module and the directory. If so, pick one after the other and type in the same name in each case.)
Since your game will be played by an actual human, don’t forget the help command or the walkthrough. Try to ensure that your game is understandable. For instance, if the game has a bug that unexpectedly and imperceptibly teleports the player to a different location, the game may be a pain to play and assess.
- If you wish to write additional comments or instructions for the teaching assistant, you can also include a readme.txt or readme.pdf file.
In Aalto IT’s Linux labs, you can use Inkscape, Dia, or GIMP to draw the game map. There are many alternative graphics programs, too; use whatever is available in your environment.
If you want to use O1Library’s tools in your game, go ahead and do so but read the box below first. In fact, you may want to read the box in any case.

Dependencies between IntelliJ modules

If an IntelliJ module depends on the classes in another module, you need to indicate the dependency. If you don’t, your imports from the other module won’t find their target.

Most O1 modules already define such a dependency to O1Library. You can see this in the settings: select File → Project Structure in the menu, then pick one of the earlier modules and open the Dependencies tab on the right. (On a Mac, the menu item is IntelliJ IDEA → Preferences.)

As given, Adventure is an independent module. If you want to use O1Library in your game, find the above setting and click the plus icon on the very right and select Module Dependency when prompted.

Using files in your project

Some ambitious students might want their game to make use of external files. For example, you might want to load some information about the game world from a file or enable the player to save their game.

Using files is definitely not a requirement! If you’d like to pursue it nevertheless, you’ll find some basic information about file handling in Chapter 11.3 and can expand on that with a web search or through our resources page.

Submitting the Assignment

This assignment cannot be submitted for auto-grading via IntelliJ’s A+ Courses plugin. Instead, package your program as per the instructions below and submit it via the browser.

Preparations

Make doubly sure that you’re looking at the exact version of your program that you intend to submit and that all the files are saved. Then make triply sure.
Make sure that you’ve renamed your module according to the instructions above. That is, the module should no longer be named simply Adventure.
In IntelliJ’s menu, select A+ → Export Module. Select your game module. Press OK.
IntelliJ will create a zip package of your game. It prompts you for a location and a name. Pick some suitable folder on your computer and a descriptive name such as 654321_TitleOfMyGame.zip. Please start the name with the student ID(s) or surname(s) of the author(s).
Locate the .zip file on your computer, in the folder you chose earlier. Examine its contents to make sure it contains everything you want it to. It should contain the entire module, source code and all.

Submitting your program for marking

Your attention, please!

If you did the assignment with a pair, please make sure you’ve selected a pair submission in A+. Only one member of the pair should submit the assignment!

A+ presents the exercise submission form here.

Great work! Because this message is prerecorded, any observations regarding your performance are speculation on our part. Please disregard any undeserved compliments.

—Aperture Announcer

Feedback

Please note that this section must be completed individually. Even if you worked on this chapter with a pair, each of you should submit the form separately.

Credits

Thousands of students have given feedback and so contributed to this ebook’s design. Thank you!

The ebook’s chapters, programming assignments, and weekly bulletins have been written in Finnish and translated into English by Juha Sorva.

The appendices (glossary, Scala reference, FAQ, etc.) are by Juha Sorva unless otherwise specified on the page.

The automatic assessment of the assignments has been developed by: (in alphabetical order) Riku Autio, Nikolas Drosdek, Joonatan Honkamaa, Antti Immonen, Jaakko Kantojärvi, Niklas Kröger, Kalle Laitinen, Teemu Lehtinen, Jaakko Nakaza, Strasdosky Otewa, Timi Seppälä, Teemu Sirkiä, Anna Valldeoriola Cardó, and Aleksi Vartiainen.

The illustrations at the top of each chapter, and the similar drawings elsewhere in the ebook, are the work of Christina Lassheikki.

The animations that detail the execution Scala programs have been designed by Juha Sorva and Teemu Sirkiä. Teemu Sirkiä and Riku Autio did the technical implementation, relying on Teemu’s Jsvee and Kelmu toolkits.

The other diagrams and interactive presentations in the ebook are by Juha Sorva.

The O1Library software has been developed by Aleksi Lukkarinen and Juha Sorva. Several of its key components are built upon Aleksi’s SMCL library.

The pedagogy of using O1Library for simple graphical programming (such as Pic) is inspired by the textbooks How to Design Programs by Flatt, Felleisen, Findler, and Krishnamurthi and Picturing Programs by Stephen Bloch.

The course platform A+ was originally created at Aalto’s LeTech research group as a student project. The open-source project is now shepherded by the Computer Science department’s edu-tech team and hosted by the department’s IT services. Markku Riekkinen is the current lead developer; dozens of Aalto students and others have also contributed.

The A+ Courses plugin, which supports A+ and O1 in IntelliJ IDEA, is another open-source project. It has been designed and implemented by various students in collaboration with O1’s teachers.

For O1’s current teaching staff, please see Chapter 1.1.

Additional credits for this page

This chapter draws inspiration from classic adventure games by Infocom and the work of David Barnes and Michael Kölling.