The Grouch's Trash Pile [Baldur's Gate 3]

Ugh, well. I managed to mostly fix that assignment, but the autograder gave me an error that I looked at and was like, not only do I not know how to fix that, what you say should happen isn't what I expect to happen and what you say happens is not happening so I give up, I can live without those seventeen points when I've 100%ed the rest of the course. Too late anyway! The weekly deadline was seven minutes ago!

I'm going to have to go back over all the material about streams and Options again, slowly and carefully, and see if I can make more of it stick.......... later.

In general I need to plan out my time better and find... idk what to call it. Defined breakpoints? where I stop and go ask for help on the forum, instead of waiting until I feel like I absolutely cannot figure it out myself. Like, if I haven't progressed on an assignment after X amount of time working on it, I go ask for help and either move ahead for a while or go do something else until I've gotten a response. Not sure how long of a time period I should make it though. An hour?

Whatever I do, I need to not eat up 75% of a day again if I can avoid it. The last two days I've mostly lived in Eclipse, to the point that night before last I was dreaming about coding and my brain was so hyperactive I kept waking up constantly and then trying to get back to sleep because I'd almost figured it out!!! Exhausting, and also boring. (I slept much better last night, fortunately.)

 

I think an hour seems reasonable. Fwiw that's what my first boss always suggested, bang your head against it [with Google, bc this was work and not graded] and if you're still stuck after an hour go ask a colleague for help.

(not that I stopped at the hour mark, bc I am stubborn, but I can recognize good advice even when I don't follow it : p)

 

One of the reasons I really like this course is that it has weekly bulletins where the instructors go over the material in the previous chapter, explaining things that were difficult, showing some of the variety of solutions, addressing concerns raised in the feedback forms, and generally responding to what we've told them. They also sometimes respond to our feedback individually; I got reassured that this will get easier with practice (since I agonized a bit about how it felt like everything I knew fell out of my head and it took me forever). It's all very kind and friendly, which is a stark contrast to how cold and distant the Java course was. I mean, I wasn't doing the Java course 'on schedule' but on my own time, but there was still zero feedback, whereas with the Scala course even students who are working on their own schedule can ask questions on the forums and send and receive feedback.

They also have a sense of humor; a recent chapter introduced the concept of rubber duck debugging and ever since the feedback forms have had the background image of a rubber duck. :3

This week started off with improving a very simple text adventure game; next week starts a two-week project where we make our own text adventure. I'm both excited and filled with trepidation, because I know just how out of hand I can get with something like this. :'D

 

On that note, a little story I related in the feedback form about my very first experience with making a text adventure:

I don't know exactly why it wouldn't compile, since this was 25 years ago and my memories are hazy at best, but I do remember how frustrated I was that I couldn't do anything else with it anymore - and how envious I was of the classmate who had also chosen to blow off the coursework in favor of making a text adventure, but made one that (mostly) worked and was complete because it wasn't so completely overambitious.

 

I strongly considered putting a rubber duck on the shelf over my new computer desk as a nod to rubber duck debugging. I've got one over on my bookshelf. I haven't ever explained my code aloud to an inanimate object that I recall, as I tend to go for the whiteboards first and have pretty good success. But if I did want to switch it up, I decided I'd probably prefer to explain it to my little squishy plastic Snort pig. (Snort makes network intrusion detection and prevention software for network security, and the pig is their mascot.) It has an expression suggestive of intense, suspicious inspection. It seems like a good companion for finding a problem. Also it looks very funny peeking out from behind a picture frame.

 

My primary email attached to most official stuff is, unfortunately, the one that contains a (gender neutral, at least) diminutive of my deadname. I have another email I also use a lot that's attached to the same google account, but it's using... my unwieldy and fandom-y tumblr handle (mercurial malcontent). I'm not sure if using it for more 'official' stuff would be a faux pas, but I reaaaaaally want to stop using stuff with my deadname on it and don't particularly want to create yet another email address, although I suppose I might need to once the legal name change finally happens...?

BAH. *kicks rocks* :T

 

I thought I didn't have any interest in Death Stranding, then a friend got it and has been talking about it on Discord and suddenly I'm all

I wanna be a post-apocalyptic postman with a pod baby!!! *SITS AND WAITS SADLY FOR PC PORT* T_T

 

S A M E i want to play it badly.........

 

Got it finished a day late because it's a long 'un (for me anyway) - Week Four of Between!

This one is a very upsetting horror story 8)

 

Finally actually... working... on my text adventure project...

The requirements are:

• 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.

The areas thing is a no-brainer. Puzzles is a bit more challenging since I only have experience solving them, and a lot of that experience is getting mad and finding a walkthrough. >_>; It's also a potential rabbit hole to fall down and that would be Bad.

New text commands won't be too bad - I'm going to have a 'use' command, and an 'on' modifier (so like 'use key on door'); not sure what else to put in right now.

Victory condition - I want it to have two things: one, finding the key to open the last area after a small series of puzzles, but the ending you get is determined by what objects you picked up and chose to keep. I want to try to have a limited inventory so a player can't just stuff their pockets; then the items will have certain hidden to the user stats, and what stat ends up being highest determines what ending the player gets - but if they're all below a certain threshold, they get the unsatisfying ending. The point of this is that my idea is that the game is something of an experience, and the objects one chooses to keep represent a certain emotion or mental state or something; not committing to any one experience gets you a very mundane ending. I'll have to be careful, though; this is something that could way too easily get very large. I have a feeling my planning is going to envision something sprawling I'll have to pare down to a model version for the purposes of the assignment, and expand later if I want to make this a personal project.

Welcome message and help command are also no-brainers.

Spoiler: So I'm basically using this thread as my rubber duck

In keeping with my whole liminality thing I want this game to go along that theme. The player starts at the gate to the yard of a mysterious house; it's one they often saw in their youth walking to and from school. It's a once-beautiful two story house, painted seafoam green with white trim, but it's always looked run down with peeling paint and stained trim, the yard patchy. The windows are clouded over, with only dim shapes seen beyond, and the player has never seen anyone go in or out of the house, or in the yard.

Now they've returned to this town as an adult, and something has drawn them to the house. The gate stands open, and the front door seems to be open just a crack. They can't help but go inside.

There's no one in the house (but maybe the insinuation of ghosts, or the ghosts of memories), and while the inside is house-shaped with things one would expect in a house in it, there's something faintly unreal -- but familiar -- about it. The initial rooms that can be explored seem relatively normal, but as the player unlocks additional rooms, they're more surreal and representative of states of mind or memories.

The final room contains the key to the attic - which is metaphorically representing some final state of mind or something like that - and the last step is to unlock it. If their hidden stats are too low, they find nothing up there but a dusty, empty attic and leave in disappointment; other endings depend on other hidden stats.

My DREAM features are:

• both player stats and stats on the items that have effects
• a lot of rooms that go from real to very dreamlike as the player goes further into the house, with a gradual shift
  
• some rooms that shift permanently based on what the hidden stats are at the time the rooms are opened
• a 'curiosity' stat that increases based on how many optional things the player does; a higher curiosity stat gets a more interesting ending
• a variety of objects to pick up and examine
• a variety of things to interact with - simple interactions that increase some hidden stat as well as for solving puzzles. Some interactions have an effect in another room that doesn't solve a puzzle, just adds to the experience
  
• an inability to max out all stats - doing certain things decreases some stat while increasing another
• rooms that close off permanently when certain things are done; to prevent the game being unwinnable, any puzzle-necessary items still in the room teleport to a 'lost and found' room (the most 'solid' - i.e. connected to reality - room in the house, like the kitchen)
  
• a variety of endings, each based off of some mood or state of mind - for example, you get a high curiosity score but enter the attic with an empty inventory, you gain the Detachment (in the Buddhist sense) ending
• the *really* starry-eyed feature - a static pixel art image for each room

Obviously, this is a Lot, and more to do that I can really get done in 9 days. More realistic is:

• a few hidden stats - like, maybe three
• a normal amount of rooms for a small two-story house
• a variety of objects, some of which are necessary for puzzles
• puzzle-necessary objects, once used with the puzzle objects, are removed from player inventory and can't be picked back up
  
• a few puzzle objects to interact with that belong to the room they're in and can't be taken
• have... puzzles...

My vague idea for puzzles is to have one of those switch puzzles with three switches. Flipping different pairs of them opens up different rooms, and to get to the room that has the final key they need to be flipped in the right order so they open up all the rooms at once, but two of the switches are missing a component - so the player has to flip the first switch, search for a component, install, flip the second switch, search, install...

Thinking about how to design this puzzle is making me anxious. >_>;

Anyway, I'm going to try to make the structure of this game so that I can add on more features (and additional rooms) more easily later -- which is one of the big things that this course has emphasized anyway. Once I figure out how I want this game to work, exactly, I can start figuring out how I want to structure the code.

Any suggestions or commentary welcome!

 

In traditional text games, a popular goal was to collect treasure by finding valuable items and putting them in a trophy case or something. A puzzle was often as simple as figuring out what item to use to solve any particular problem.

You find a cursed-looking weapon and indeed, attempting to use it to fight a hostile npc who keeps taking all your stuff results in you using the weapon on yourself and dying. Hmmmm perhaps if you weren’t the one using the cursed weapon? A course of action seems to suggest itself.

Or more simply, you have a rope. Be on the lookout for any situation where a rope might be useful.

Your concept sounds super cool! I think it would be a really interesting game.

I also think that in so few days, it might be more useful to write a very simple backbone that would be a functional basic game that’s not what you really want, but would give you something working you could modify and expand into something not generic later. Like you said, but way more. Cut the scope to the bare minimum and plan to add more later. Generic is good now, this is way more the game engine and basic prototype as proof of concept than a real and excellent final game.

Maybe just for now, a very basic haunted house with some rooms, objects and basic commands? Simple puzzles like figuring out that the repeated prompts about how distractingly cold it is in this room mean you need to light a fire in the fireplace before the game will let you do anything else in that room? I don’t see why an npc couldn’t be an animal or an apparition if you like? Ghost you need to get cryptic information from (that is itself a puzzle in that it’s vague enough to require a bit of thinking even if it’s not hard) by satisfying a particular condition for the ghost to talk at all? Cat you need to lure from one place to another to be able to accomplish something? I don’t think the assignment would need you to do more than a few problems to solve to show you got the basic concept. I would go for very simple, easy puzzles unless the assignment says otherwise. This is not a game design class unless your schedule changed dramatically since last I heard.

I’d definitely focus on the most important functionality that’s part of the requirements, get those working first, preferably adding the features one at a time and making sure they each work before moving on. Functional is more important than cool. Cool can totally be added to functional, but that does not work nearly as well the other way. After you have finished the basic requirements, written the simplest victory condition and it works (and simple objects and they work), then you can start adding hidden attributes and multiple endings. Just save the boring version separately first.

 

Thank you for the suggestions, and saving me from my own ambitions X)

I'm going to skip the NPC thing since they aren't strictly required. Implementing a use itemname function is something that feels less onerous to me than making NPCs that move around. I can think of ways to make NPCs that wander but I absolutely do not want to deal with it at this time. (The robots assignment stressed me out too much.) However, I'll save the cat idea for any future implementation; a friendly animal would be a good way to handwave why puzzle-important items mysteriously appear in the kitchen instead of being lost forever.

 

Also, I don't have to do this 100% from scratch; we did an assignment last chapter where we edited an existing game to work. (Well, it was only very loosely a game, but the bones are there, is the important part.) So I don't have to totally reinvent the wheel to create the basic structure.

 

More thinking 'out loud'--

I think the text parser might be a pain in my ass if I try to get too interesting with it. The former assignment shows one way of making a simple text parser, but it expects commands that are only two words long -- so I know how to do use itemname simply, but something like use itemname with otheritem or even just use itemname otheritem might be very annoying for me to work out. :|c

Items... I'll divide them into Furniture and Items, where Furniture are Items that 'belong' to a Room and can't be taken. They'll have on and off states, which won't be relevant for all items but can be relevant for some. I may try making regular Items have 'charges' so, for example, a player has to turn the flashlight on only when they want to use it, else they'll drain the battery as they move from room to room. (I want to avoid anything that makes the game unwinnable, though, so I'll have to figure out a way to make it merely annoying if the batteries die.)

Rooms will have a locked state, and perhaps a darkness state that needs an item to be in inventory and on so you can see (and thus, interact with anything).

Actions - go, get, drop, examine, use, inventory, help, quit. I want to keep this simple so if I want the player to be able to sit in a chair for example, they can just 'use chair'. The sample game has examine only work on held Items; I want it to work on held Items, Furniture, and Items in the world.

Hidden Player stats - not sure what they'll be for this iteration, but certain things will give or take away from them, frex trying to use anything but a flashlight in a dark room adds to a 'fear' stat.

So... I'm thinking I should make the Room, Player, Action, and Game classes, arrange the Rooms in the Game, place the Player in the first Room (the yard), and then wander around to make sure all the Rooms are connected up like I want. From there, place a few Items and test the get, drop, examine, inventory, and use commands. Then go from there.

 

That sounds exceedingly reasonable.

 

@Verily thank you for keeping my overly ambitious bullshit in check because even making it possible so a room can have a darkness state that can be changed by a player's inventory item, while it's in the inventory, is looking to be a little bit much for me right now. I guess this is just a little reminder to keep to the KISS principle and rather than trying to get clever with a bunch of different stats and states and things, think of ways to do interesting things with very simple ideas.

 

What I described are some of the basic principles of the agile method, or iterative software development, just without a client or set times for iterations.

Pretty much you would sit down with the client for a software project, discuss their needs and wants, narrow it down to the most important one or two things, set a timeframe, and show up at the end of that time with a working prototype. (Even if you can’t do everything after all, it must work. Software that doesn’t run at all is impossible to judge.) That’s one iteration. You’d then take feedback from the client and talk about the next one or two items for the next cycle if you’re on track, otherwise if you’ve misunderstood each other completely or they don’t actually like what they asked for, you can work to clarify that and fix it sooner rather than later. Whatever the case, you set another very limited goal for the next iteration. The iterations are short, a couple weeks at a time.

As I was writing the thing, it occurred to me that it’s fucking stupid that we make students wait until they get to a software engineering course before describing how to solve a software problem? I can’t imagine that organizing anything reasonably complex is not a major point of failure for new programmers. We know how to do this. Why aren’t we telling people sooner?

 

Trying to think of the simplest way possible to make items 'useable'. Right now they're a name, a description, and a boolean that determines whether or not they can be picked up. I should not still be awake pondering this.

I kind of envy the person who asked if they could do a 'multiple choice' style of game -- that could be like, a narrative with some slightly branching paths and some counter helper variables to determine an ending. Might not exactly meet the requirements of the assignment, though. :p

 

If this is object oriented, perhaps they need some methods as well as attributes? But honestly the possible solutions vary heavily by language and what you want to do. So maybe not.

 

Sleeping enough a very important and often overlooked part of software development imo.

Spoiler: way too much rambling about text games

Anyway, there are different ways to deal with objects and player actions in text games. The joy of a branching path game is that it can be a very procedural program. (A program starts at the beginning and advances in a basically linear manner until it gets to the end, though it may skip back during loops or other decisions, or forward over code for a decision that wasn’t picked.) You don’t have to make different parts of the code able to happen in independent ways. Variables are global until you get to functional programming because there’s no smaller subsection of code for them to inhabit.

It’s possible to do procedural programming on a full feature text game. It gets complicated because then you start having to skip around between blocks of code associated with rooms. (If the player goes north from here, goto line 42. If they go east, goto line 130. Hope you never have to insert code in a way that would mean changing these numbers or you will cry.)

As you start entering more object oriented territory, programmers may begin to think about games more like collections of objects of different types than paths through the code towards the end. Room objects with attributes such as descriptions and exits. Interactive item objects with attributes such as description and value and maybe weight or something.

One pretty good way to start thinking about how an object might interact is to look at what technique you’re using to put an object in a room in the first place. Can you use the same technique in the abstract to create an inventory as a location and put items there the same way you put them in a room?

If it’s highly object oriented, the code for the interactions may belong to the items themselves. They may have methods defining what actions they respond to and how. They can probably inherent a lot of their behavior from larger classes so that you don’t have to write the “you cannot do that to a [small bird/vase/dining chair]” message over and over.

Rooms might also be objects. They may be responsible for keeping track of items that are in them, and they’d need someplace to store that data as well as methods for adding and removing items from it. The inventory might work a lot like a room except that it’s always accessible, you can’t enter it, and it probably doesn’t have a description of itself.

It would get complicated when you need to decide who is responsible for things like putting objects in the correct place at the beginning of a playthrough, and performing movement of objects from one place to another. Is the item in an accessible location, such as the current room or the player’s inventory? Who owns the method to check that? Who is responsible for checking if an item has the attribute indicating it can be moved, if the room/inventory can hold that item, then asking one location to relinquish it and another to add it?

The big question with object orientation is “who should this belong to?” for both variables and functions. Global variables are so last paradigm, now our data has to belong to something and we have to use its interface for changing it. The answers don’t necessarily have to make a lot of sense, but you’ll often get better results, especially as things get more complex, if they basically do. If a trophy cabinet that isn’t called The One Cabinet Of Win owns the actual code for winning the game, rather than triggering it by calling somewhere else, that might get weird if the game evolves and becomes something more but you still have to have your code consult with the cabinet to access winning.

(If the game itself or the game engine or this instance of the game does not qualify as a valid object, one that can have attributes and methods that have to do with the state of the game and interactions between parts of it that shouldn’t belong to or be under the control of those parts, I have a complaint to file with programming.)

If your code is less object oriented, you can not worry about a lot of that. But it doesn’t necessarily get easier. Some people deal with items by creating a data structure containing all of the items in the game and a variable for their location. When the game needs to print what items are in a room, it looks through the entire data structure and prints all the ones with the matching location data. If it needs to know about a specific item, it can just look that one up. This is not the most elegant solution ever invented, but it basically works.

Rooms might also be housed in a data structure. (For either of these, if your language isn’t friendly about storing collections of different data types including strings of various lengths in one place, the name and description might be index information that the game can use to look those up in a different data structure. Game programming: isn’t it fun?!) The popular ways of making room data structures work for navigation are very much better left alone if you’ve already got something working. Doubly linked lists! Pointers! Yay!

You would still do pretty much the same things to check if you could do a thing with an item, but from a more centralized viewpoint: testing to see whether basic conditions such as accessibility of the item were met, and whether that was a valid thing to do with that item. This entire style of programming is gonna rely heavily on conditionals. The player enters the kitchen. If the cellar is unlocked, print this part of the description for it, otherwise print that one. The player tried to use the cellar key? Well since this is the kitchen there’s code for that. Do they have the key? If not, tell them they can’t. If they do and the door is unlocked, tell them they already did that... and the lock is stuck now if you feel the need to explain why they can’t use the key to lock the door again. If the door is locked, print that it’s unlocked now and change the cellar variable to unlocked. If they try to enter the cellar, check if the door is unlocked and then either print a message about the locked door or move the player to the cellar.

The big thing with non-object oriented code is scalability. This code will not organize itself, so you better create something that you can add five more items and three rooms to without breaking everything or yourself. Data structures are gonna be incredibly important because you will want similar data to be in one place that you can find, and you want to be able to add onto it. It’s very easy to add special items or events or effects to this type of program by just adding an if branch and some extra code. The tradeoff is that the less imposed structure you have, the more you need to create, or your code will be completely unmanageable and probably summon demons or something before you have even a five room prototype of a text game. (Also your teacher will probably think ill of you if you write a procedural or even functional game in an object oriented class, because people are just so picky like that.)