DON'T FORGET to check out ReShelved Overview Video.mp4 and PLAY THE GAME in ReShelved Project folder!!
So I currently work at Charles Library, and I've found that a lot of people can't fully wrap their head around (including me) how the library call number system works. Even for me -- who regularly organizes books -- can accidently place books in the wrong order because for some reason the first set of numbers on a book is in standard numerical order, but the second set is based by decimal (refer to this link to see a full explanation of the Library of Congress system: https://www.angelo.edu/library/handouts/lcnumber.php).
So, when thinking about projects for this course, I was inspired by typing accuracy tests and other basic educational games and wanted to make one of my own that could teach people the basics of reading call numbers. From this, RESHELVED was born! I hope that this simple little program can help improve people's understanding of how these library books are rather unintuitively sorted and, if I am able to further work on the project on my own time, become a fully-fledge arcade-style game that can still teach people to read these call numbers faster and more efficiently!
Working on this game through Python was actually very fulfilling, as I could combine/test my general programming knowledge of the language along with learn to experiment with a bunch of new kinds of code of new thanks to the features brought by the Pygame library.
Naturally, designing a video game as my first project had me run into a lot of new challenges that seemed to come out of nowhere -- a staple in game development. The greatest struggles I faced throughout this project was with the system of graphics that pygame uses, which I had no experience in and had intended to have my book images be easy to move around as well as clearly visualize what order a given list of call numbers was in. Since the position of any surface is normally static, they can more easily be adjusted by placing rectangles over the surface and moving them around specific points on it. I spent a good period of the project timeframe just tinkering around with my book graphics' rectangles trying to find an intuitive way of moving the books around and would constantly run into different roadblocks involving these rectangles, often causing me to change how I wanted the primary gameplay to work.
Initially, I planned for any given book that the player interacted with to be able to move follow the mouse anywhere, and when the player let go of their MOUSE 1 button, the book would automatically be organized into the closest position on the shelf it was let go from. However, because I used a series of if statements that went in a set order (book 1, then book 2, etc.) to check if a player was interacting with each book on the shelve, any overlapping books would prioritize moving whichever book was observed to be "picked up first" instead of which book was already being grabbed. In addition to this problem, because each surface is placed onto the display one at a time in a given frame, I found early on that books that were loaded later in the code would always cover ones loaded before if they were overlapped, making it much harder to come up with a moving mechanic where whatever book the player picked up could be moved around freely and show above all other images.
To solve the visual glitch, I had to create a seperate list that marked whether a book was currently being interacted with by the mouse, and ensure that this book was loaded onto the screen after all the others. At the same time, making a seperate "grabbed" variable actually solved my overlap problem when moving a book, as I could now write an if statement that first checks if a grabbed book was still being interacted and continue moving that book, only using the predetermined list of books if no book was currrently being grabbed.
This design choice also came in handy to easily implement a couple other features in my game, such as switching the position of a grabbed book and an adjacent one if the player lets go of the grabbed book as it collides with another book, which I found to be a much more consistent way of moving the book sprites around compared to my original idea of automatically correcting a book's desired position. Through these experiences of working around strange and alien-like problems, I learned that being flexible and creative with my code could actually lead to solutions that are much easier to implement than what I had initially planned and fix a variety of unexpected obstacles along the way!
Even with no prior skills in making games with Python, I've been able to further a lot of my general coding skills and the problem-solving process I use to try to bring my concepts to life in my program. Throughout the past few weeks of development as I went through many alterations of my book-moving mechanic, I constantly revisted previous code with a newfound perspective and would end up adding new variables or editing out redundant lines. As my overall program became much bigger, I strived to make a habit of labeling different sections of my code with what they did and organizing chunks of code carefully so that future editing wouldn't become needlessly complex. Making my own fuctions played a big part in this, and I hope that I can revist my program more and add more easily add/improve features by replacing patterned lines of code with functions. Over time, as I overcame different issues involving similar lines of code, I also ended up adapting my standard procedures of "debugging" code and looking for errors in my logic within the context of my game; I especially had to remember to pay attention to what certain variables were equal in a given FRAME of my game, as this is what caused a variety of problems from graphics appearing and disappearing as well to books moving in the wrong directions when grabbed.
At the same time, I've also found that giving myself time to methodically look over lines of code when things don't work as intended, or simply take a break from programming can help return to a problem with newfound unerstanding -- and more times than not, allow you to notice glaring flaws in your previous code that caused them! As one example, I spent hours wondering why my editable list that marked how the player organized the books and could be checked to the right order did not update, and only by taking a day off from my code did I realize that I had put the initial list in a loop that would always reset the player's list back to its original contents regardless of how much it was updated. Having my program not work the ways I intended them to became a natural part of my game development, and identifying instances or kinks that caused specific problems were crucial to having such features effectively add to my overall program.
Plus, I was able to get familiar with a bunch of cool modules that can easily create other kinds of games I'm interesting in thanks the tutorials that have taught me pygame! The process of making games as a whole was actually really fun; designing basic states of my program like a 'check answers' or 'replay' option, although rather involved coding-wise, were extremely satisfying to watch be implemented into my program and make it run a lot more like a game! I particularly enjoyed making my own custom art for the sprites and playing around with the "physics" I made for the game to see what sliding motions of the books felt the most fluid. I intend to come back to this program more often to perhaps add more mechanics to my game as I become more well-versed in Python and other programming languages, such as different difficulties or a score system based on the speed to which books are sorted. Overall, I would love to make more games in the future to just to get the chance to personalize my program like this, and really valued this project as a chance to explore this specific medium of game development through the technicalities of Python that I have learned over the course of this class!