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. Myös suomenkielisessä materiaalissa käytetään ohjelmaprojektien koodissa englanninkielisiä nimiä kurssin alkupään johdantoesimerkkejä lukuunottamatta.

Voit vaihtaa kieltä A+:n valikon yläreunassa olevasta painikkeesta. Tai tästä: Vaihda suomeksi.

Chapter 10.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 this will be the most time-consuming project in O1 for nearly all students. We recommend that you reserve an absolute minimum of 10 hours for it, 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 Projects: 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 Who Dunnit, 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, Travis Bickle, Dolores Abernathy, or whoever.
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 Adventure project you submit, you should also include:

A file that contains a “creater’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 root folder of the project.
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 project root.
- The teaching assistants may use the walkthrough as they assess your game. A less frustrated TA may go easier on the marking. :-)

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 it clearly. You don’t need to obey any specific style 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, etc. 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 aspects. 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 project. You’ll need to edit some or all of the classes. The class Adventure, in particular, needs a complete reworking or could even be replaced by a different class altogether.
- Unless you have a particular reason to change the two user interfaces, don’t change them. However, you may change them if you want to. You are completely free to change anything in the given code and add whatever you wish.
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.
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.
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.
In Aalto IT’s Linux labs, you can use Inkscape, Dia, or GIMP for drawing the game map. There are many alternative graphics programs, too; use whatever is available in your environment.
If you want to use tools from O1Library in your project, 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 Eclipse projects

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

Most O1 projects already define such a dependency to O1Library. You can see this in the project settings: select one of the earlier projects and go to the menu Project ‣ Properties ‣ Java Build Path ‣ Projects.

As given, Adventure is an independent project. If you want to use O1Library in your game, find the above setting and click Add...

Submitting the Assignment

Preparations

Before submitting your project, you need to package it in a zip file. Here’s how to do that in Eclipse:

Make doubly sure you’re looking at the exact version of your program that you intend to submit and that you’ve saved all the files. Then make triply sure.
In the menu, select File ‣ Export...
In the little dialog that pops up, select General ‣ Archive File.
Press Next.
Tick your adventure game in the project list on the left.
Choose a folder and a name for the .zip file under To archive file. Use a name such as 654321_TitleOfMyGame.zip. Start the name with the student ID(s) or surname(s) of the author(s).
Press Finish.
Examine the file you just created to make sure it contains everything you want it to. It should contain the entire project, source code and all.

Sending your project 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 that has contributed to this ebook’s design. Thank you!

Weeks 1 to 13 of the ebook, including the assignments and weekly bulletins, have been written in Finnish and translated into English by Juha Sorva.

Weeks 14 to 20 are by Otto Seppälä. That part of the ebook isn’t available during the fall term, but we’ll publish it when it’s time.

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 programmed by Riku Autio, Jaakko Kantojärvi, Teemu Lehtinen, Timi Seppälä, Teemu Sirkiä, 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 have done 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 tools from O1Library (such as Pic) for simple graphical programming 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+ has been created by Aalto’s LeTech research group and is largely developed by students. The current lead developer is Jaakko Kantojärvi; many other students of computer science and information networks are also active on the project.

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.