Group 1 Game Overview

 Group Number: 11

Summary: You and your opponent compete for the throne by going through a dungeon. You travel through the dungeon (the game) in a visual novel style. Your opponent has the map to your player route, and you must rely on them to help you (or hinder you).


Audience: Can be for all ages, but mainly teens and young adults would play it


Player Interaction Pattern: Player vs. Player


For the most part, we didn’t really have any problems that affected gameplay. We wanted playtesters to suggest anything else we could add, but no one really said anything. The hardest part was merely thinking up the content that would make up the events in the game. This idea was a combination of our pitch ideas, but mostly my partner’s. My pitch idea was used as the premise, and my partner’s was the main gameplay. Unfortunately, she didn’t really think up any content so we had to rack our brains on that part. It was difficult thinking up anything. The game ended up being pretty short because of that, but it’s a pretty good length for playtesting purposes.


I feel like my partner ended up doing a lot of the thinking for this one. Since I suggested we use RenPy to make this game, she did a lot of the other tasks like typing up the rule sheet while I coded it in RenPy. It’s made to be easy to learn! I had a really rigid view of what the game was supposed to be when we first started, which prevented me from progressing further into my code. I wanted to put in a bunch of stuff and make it more complicated than it really needed to be. As a result, I got really scared of doing it, and put it off for a long time. But after my partner made our game in Inklewriter (which is basically an online text adventure maker), I softened my view, and used it as a reference to what I would code. Instead of being scary and difficult, it merely became a tedious task.


(Player 1 program code)

Our game is extremely simple in coding. It’s basically just a bunch of menus and dialogue. There is definitely space to add in some graphics (RenPy is a visual novel engine after all!), but there are none in our game because I took far too long in getting all the options working correctly. Technically it does look nicer because there are no spelling mistakes in any of the dialogue. One thing that differentiates it from the Inklewriter version is that there isn’t exactly a “continue” button with some events. The text just keeps going until the player needs to make another choice. I suppose I technically could have tried to add one, but it wouldn’t really make sense because it’s basically making a menu with only one option. There were a few bugs when it came to making the programs, which were because I somehow indented a little too much or not enough. The sucky thing about RenPy is that it doesn’t like tab spaces in the script, so you have to press space 3 times. You probably don’t have to press it that many times, but I wanted to keep consistency. (The spaces in my code aren’t exactly like that, though.) It took me a very long time to learn how to code and debug the Player 1 program, since I made it first. I did a lot of revising. I was able to use the knowledge I gained from that to code the Player 2 program, and the code is a lot cleaner. Now that I’ve figured that out, I can use it for future projects! It won’t be such a bother next time.

Comments

Post a Comment

Popular posts from this blog

Aftershock Simulator - Sprint 16

Image
  On sprint 16 in Aftershock Simulator, I assigned the team 87 points and 51 points were finished. We’re beginning to pick up now that we have a plan on what to do. In this sprint, our team started on the tutorial levels and the objectives system. And of course, there was some extra work to do for the UI in the game as well.   As a producer, I still find it difficult to gauge the difficulty of a task, especially when it comes to programming. I still end up needing to change the point values of some cards because they end up more difficult than expected. For example, I had figured that creating the basis for the objectives system wouldn’t have been too difficult, but not necessarily. A few of the objectives require you to click certain UI elements on the screen, and the things that would “listen” to those UI elements are all each in their own separate scripts, so now there’s the added work of finding them and knowing where to put the code. I always end up asking people if t...
Read more

2D MegaMan Level 2 Feedback (10/27/21)

     Making a late-game type level is incredibly difficult. I had my idea of making the player climb up, but I wasn’t really able to implement that. I couldn’t really think of a layout for a room that wasn’t having the player zigzag up the room. Although, according to my playtesters, what was in the level was pretty good. At least I was able to avoid the “no clear way to the exit” problem I had with my tutorial level. It was a simple “gather the keys to unlock the exit” type level, and unlike my tutorial level, there was actually a point to it.      Players generally praised the way I set up my keys, as you need two keys to unlock the exit, but there are 3 in total. You can get the first key through an easy or hard route, and then you have to get the second key by passing through some enemies. When getting the second key, I put in a weapon deleter that takes out the Nado so you have to jump through a bunch of enemies to get to the top of the room. There’s a...
Read more

Chicken Scramble - Sprint 1

Image
  To start off, this first sprint was kind of disorderly. Since we’re using a completely new project management tool with no prior experience, it took some time to get used to (and still getting used to it). I suppose for my other teammates it wasn’t a big deal but it was an added pound of stress to my shoulders as the producer. To add to that, there was some confusion between me and the designer as to what the whole game idea and aesthetic was. My original idea for the game was a multiplayer maze in which the goal was for two players to compete to get to the other side of the maze. We could have ways for the players to mess around with each other, like using door switches to open and close doors. To clear up the confusion on what we were building, we set up a meeting to talk about it. To prepare, I made a design map of what I thought it should look like. (In the picture, the blue dots are door switches, yellow dots are checkpoints, and the red dot is where the enemy spawns. Bl...
Read more