Taggame

2018 Fall Game Project – Cards

Fall semester of my Junior year at Virginia Tech was more a laid-back one when compared to my earlier semesters – mainly due to the fact that I was a year ahead of schedule and most, if not all, of my hard classes were behind me. I took the solid amount of free time that I had to start researching new and interesting computer science topics, while building on the skills I had learned previously either at my internship with Cox, or through the work I had done by myself. After coming up with a couple of different ideas, I settled on a basic card game, twisted in such a way as to challenge what I knew and force me to learn some new and interesting concepts.

Essentially, my goal was to create a multiplayer standard 52 card game that was able to support any rules the players decided to enforce. The idea was to create a simple backend so that I could have the liberty on focusing on the more challenging and new concepts like communicating with a central game server. I also wanted to test my abilities in making a backend in C, as it is well known that lower level languages, like C and C++, are great for games due to their relatively fast execution times. However, making all other aspects of a game in C (i.e. rendering) can be rather frustrating and time consuming, so I also decided to code the frontend in another language. As such, I settled on python/pygame. Finally, as I wanted to make the game multiplayer, I needed to include a server framework that was able to communicate with n many clients at a time, while still being able to interface with the backend C code. After doing some research, I decided on ASP.NET, as I am generally unfamiliar with C# and the .NET framework, and wanted to use the opportunity to learn something new instead of falling back on a framework I’m more comfortable with. Using C# also allowed me to interface with the backend incredibly easily (detailed later). I decided to upload the server on AWS/EC2, as I’m always looking for an excuse to learn more about the Cloud/AWS and practice using it.

The final architecture of the card game project.

Coding the C backend was the easiest part of the project – mainly due to my comfort level with the language (thanks to the many difficult low-level programming courses taught by Virginia Tech), but also due to the nature of the project. The game is fairly simple; there exists only a couple of noteworthy objects/data structures. The main deck, the cards on the table, and the cards in each of the player’s hands. All of these objects can be represented as a Deck, each containing Cards. I created the Deck data structure as a hybrid between a stack and an array list. It supports popping and pushing, as drawing from a deck usually entails popping from one deck and pushing it onto another, but the need for placing or picking cards from specific indices was also necessary, as a player picks and chooses specific cards to move onto or into their hand from the table. As of right now, the backend supports 4 basic functions – drawing from the main deck to the table, drawing from the main deck to a player’s hand, picking a card up from the table and placing it into a player’s hand, and placing a card from a player’s hand onto the table. Keeping it relatively simple, at least for the time being, allowed me to write up this portion of the project quickly and move on to the newer and more challenging parts of this project. I definitely plan on revisiting this section and fleshing it out to add more functionality later down the line.

Next came creating the server and wrapper for the backend. Like I stated before, however, this was relatively easy, as the choice for C# made interfacing the C backend easy (through DllImport) and the .NET framework allowed for a speedy standing-up of a basic RESTful web API (through MVC). Essentially, the client makes requests on various endpoints depending on the method they want to invoke. All I really had to do was create endpoints for each of the 4 functions described in the paragraph above. Other than that, I created register/unregister endpoints for when a player joins or leaves the session (mainly to ensure that the number of players didn’t exceed the maximum of 4, and to assign each player a specific player id), and basic start/terminate endpoints. After creating the C# server, all that was left was to publish it on an AWS EC2 instance, which admittedly took some time as I was unfamiliar with how to do so, but was achievable in the end after some time and googling.

Finally came creating the frontend in Python. Thankfully, interfacing the server was relatively easy due to the urllib library. As a result, I really just needed to focus on getting the correct information from the server and translating it into something that could be easily understood and rendered using pygame. I achieved this by adding an endpoint to the server that retrieved a JSON object of the entire table (including the main deck, the cards on the table, and each of the hands). The python code regularly makes checks to this endpoint and references it against a stored version. If they differ, the local versions of these decks are changed to reflect the differences. All I really needed to do at that point was render the cards and come up with an intuitive way to activate the backend functions. I took inspiration from the popular online card game Hearthstone and implemented a dragging feature, where players can click and drag cards from their hand to the table or visa-versa.

The current status of the python client, with 4 players connected to the central server. You can see the main deck represented in the middle of the screen as the stack of non-visible cards, and the on table cards represented as the stack of visible cards. Each of the hands are also present, with only the current player’s hand being visible.

I still have much I want to achieve with this project. After an initial play test with friends we discussed a couple of features that would be good to include later down the line. For instance, the ability to show cards from one’s hand without having to place it on the table, being able to discretely trade cards between players, and the inclusion of a discard pile. I’m eager to continue optimizing and working on this to see where I am able to take the final product. If you’d like to see the code for this project, you can view it on github here.

Thanks for reading! If you have any questions or comments, feel free to write them below or email me at [email protected].

 

2016 Spring Game Project (In Progress) – Adventures of Mark

A lot has happened since my previous update nearly a month ago. The main area of my focus has been switching from a top down view to something more isometric (think games like Earthbound), and the perspective challenges that are associated with that. I’ve also added a lot of new objects, tiles, and items (including various shops). Making this game has really opened my eyes to just how many assets and things of the like are required for not just indie-games like this, but professionally done AAA titles as well, and how difficult and tedious asset creation can be at times.

One of my more recent undertakings has been overhauling the way I create levels in the game. Before, I used a system of images where each pixel was a tile in the level, which was tedious and inefficient for a variety of reasons. Memory wise, it required a relatively large amount of effort to load each level. Making the levels themselves was also difficult because I had to use a specific set of colors with precise R, G, and B values to get the desired outcome, and didn’t get to see what the final outcome would look like until I loaded it into the game. Now, I use a level editor that I made myself that really facilitates level making because you can actually see the tiles you’re placing instead of just solid colored pixels.

Screen Shot 2016-03-15 at 12.47.26 PM

Although it is a simple editor, it has everything I need to make levels quickly and efficiently. The lighter tiles are floor tiles while the darker tiles are walls. The blank spaces are place holders while I create more tiles to be input into the game.

Screen Shot 2016-03-15 at 12.48.14 PM

The map I created inside the level editor loaded into game.

It did take a little while to complete the map editor, and I still have to add objects, but the benefits definitely outweigh the costs. Now, the tile IDs are saved to a text file that can be easily read and made into a tile map that’s loaded pretty quickly.

Screen Shot 2016-03-15 at 5.06.39 PM

The text file created by the editor to be loaded into the game. This particular text file creates the level shown above.

When I first thought of making a level editor, I thought the idea was a good one, but backed away because I wasn’t familiar with a lot of the window components needed to make one (for instance JButtons and JToolBars). However, I’m glad I worked through and figured out how everything meshes together because making it was fun and interesting, and I can make levels more efficiently from now on.

If you want to see the game as it progresses in detail, you can visit the github repo here: https://github.com/VolitionDevelopment/The-Adventures-of-Mark

2016 Spring Game Project – Plane Challenge

As my senior year of high school began to slow down, I began to look at more relaxing and laid-back  projects. Games, to me, are fairly low stress as there isn’t that much problem solving (at least at the early stages), so I decided to make a couple of games during my final semester of High School.

On my spring break trip to Grand Cayman, I decided I wanted to see how much of a game I could make on the plane ride down. This resulted in a fairly simple game that was completed in roughly 2 hours (give or take 10 minutes). Granted, I did start laying the ground work while I was waiting to board, but most of the work was done on the plane itself.

The game itself ended up being about planes. As I didn’t have too much time to work on it, I decided to make a simple endless runner in which the player dodged obstacles while trying to get as far as they could get without dying. The player, in my game, controls a plane that can move left and right, dodging debris while also picking up health packs.

Screen Shot 2016-03-06 at 11.38.42 AM

As you can see, I really whipped out my AP Drawing art skills on this one. In reality, I wanted to spend more time coding than on asset creation (which definitely shows in the final product).

One of the challenges of making this game was creating an endlessly looping background. The way I ended up doing it was having one image that was the size of the window (500 x 500 pixels) that was stacked on top of itself 3 times. The resulting picture scrolls down and when it hits a specific point (close to the end), it jumps back up exactly 1 image height and continues to scroll down, resulting in the illusion of an endlessly scrolling image.

If I had a bit more time to work on this project, I’d first add a menu, then a scoring system that went up the longer the player was alive.

I’m now going to start uploading all of my projects to Github, so exploring the code is a little bit easier. If you want to see the code for this project, you can see it here: https://github.com/mccloskeybr/PlaneProject

2016 Spring Game Project (In Progress) – The Adventures of Mark

Screen Shot 2016-02-10 at 11.51.36 PM

I’m currently working on a 2D Java game with inspiration coming from games like Final Fantasy and Undertale called The Adventures of Mark. It features a typical too-tired-for-this-shit college pizza delivery boy who must embark on an adventure down the block to earn his pay. Will his Tolerance and Brain Power hold true? Find out, nightly, on the GitHub repository featuring this project located here. This is definitely one of the larger games I’ve worked on and is filling me with more and more determination each day.

Screen Shot 2016-02-10 at 11.57.54 PM

Current state of the battle system. All of the assets (except the fonts) are drawn digitally and animated by myself.

I’m collaborating on the game with a friend of mine, Jackson Yeager (his portfolio). Although Jackson may have more knowledge than myself when it comes to various data structures, he has less experience with game making. Regardless, I’m sure both of us will learn something from this project, and I would definitely recommend you take a look at it if you’re at all interested.

I’ll be updating this post/making new ones as the game progresses.

2015 Winter Game/AI Project – Chess

The 2015 school year was when I began dabbling around AI. The idea always amazed me. Everything from movie depictions of them to the real practical uses they have in modern day life was interesting, and I wanted to know more about it.

I had been wanting to make chess for a while, as I’ve been a fan of the sport. What better way to make it than to explore simple self learning artificial intelligence at the same time? However, before getting to the AI, I first had to make the game. The idea of generating a list of possible moves was was simple enough, but the real challenge was implementing more complex moves like castling, checks, stalemates, etc.

Screen Shot 2015-12-11 at 6.49.45 PM

Final game showing all possible moves.

After spending a while messing around with the game itself, time came to begin working on artificial intelligence. Having known nothing about the subject (I started learning about concepts like neural networks and genetic algorithms shortly after), I decided on a simple concept. The artificial intelligence would save all the games it had previously played and look back on them, determine the statistical probability that it would win if it did that move (based on the outcome of the games that had the same move), and decide whether or not to proceed from there. If it decided that the move was bad, it would instead do a random move and add that to the database.

There were a few errors in my method, however, that presented themselves as I neared the end of writing the program. Mainly, it would take ages before the AI became even decent at the game, because, no matter how fast it played the game, it would almost always play a new game every single iteration (Hardy’s estimate of possible chess games is roundabout 10^(10^(50)), more on the subject here), causing the file that contained all of the previous games it had played to become unbelievably massive before it became good at the game.

Screen Shot 2015-12-11 at 8.26.02 PM

A fraction of a single game stored in a .txt file.

Despite all short comings, this project was still a simple and a fun introduction into the world of self-learning artificial intelligence.

2015 Fall Game Project – Ludum Dare 33

The Ludum Dare Game Creation competition, if you’re unfamiliar with it, is a competition in which entrants are given a central theme and are required to make an entire game – code, art, sound, etc. – in two days.

The theme of the 33rd Ludum Dare competition was ‘You are the Monster’. Other games I first thought of were games similar to that of Rampage for the Nintendo Gamecube, a game where you are a giant monster destroying cities and causing chaos just for the hell of it. Thus, Colossus Guard was born.

Screen Shot 2015-12-10 at 12.12.52 PM

Main menu.

I took the idea from Rampage and combined it with an endless runner; the player can only move right, but can destroy houses and step on civilians as they run away.

Screen Shot 2015-12-10 at 12.13.32 PM

Final product.

It was the first game in which I implemented more complex animations, as well as any sort of sound in my games. I expected that process to take a very long time, but was pleased to find that it was shorter than I had expected. This game is also the first game in which I used a delta time to try and increase frame rate, of which increased playability on other machines.

I very heavily enjoyed this process and learned a surprising amount in those two days.

The source code can be found here (Java, 201mb): https://drive.google.com/file/d/0Bz_0wgRmDpKqckpUTnNXVFdTclU/view?usp=sharing

 

2014 Winter Game Project – Lunar Lander

2014 was when I really got interested in game development. Throughout the winter and into 2015 summer, I was interested in all aspects of game creation– everything from the code to the art.

Lunar Lander really appealed to my obsession with space at the time and brought everything together that I had previously worked on in one single project. Angles, horizontal and vertical velocities, and simple world generation are just a few examples of the components that define the programming side of Lunar Lander.

Screen Shot 2015-12-10 at 11.09.23 AM

Finished product.

I had worked with horizontal and vertical velocities before in games like Asteroid, but I hadn’t explored anything with a constant downward vector (gravity) before Lunar Lander. This downward force really defines this game from other space games, as it’s a rare component that other games usually don’t have.

I also explored simple level generation while making this game. Normally it would be fairly easy to make a random sequence of lines to represent hills and valleys, but Lunar Lander requires little spots where the ship can land with ease. Thus, it took a bit of thinking to be able to implement landing strips into normal world generation.

The preliminary work on level generation would prove invaluable in my future projects because it built a foundation for the general logic required for building simple worlds.

The code can be found here (Java, 37 kb) : https://drive.google.com/file/d/0Bz_0wgRmDpKqS2xSMjNuekJQbTA/view?usp=sharing

2014 Winter Game Project – Asteroid

2014 was when I really got interested in game development. Throughout the winter and into 2015 summer, I was interested in all aspects of game creation– everything from the code to the art.

One of the first projects that propelled me into my obsession with game creation was the classic arcade game Asteroid. Prior to this, I dabbled in basic 2D side scrollers. Asteroid was a lot different than before because I had to worry about special polygons as well as turning the polygon a full 360 degrees instead of having rigid up-down-left-right movements.

Screen Shot 2015-12-10 at 9.32.53 AM

Ship and one asteroid.

Learning how to make polygons was simple enough, and it looked wonderful. It was a breath of fresh air from my previous games in which almost 95% of the objects were filled rectangles. The hard part came when I had to figure out how to rotate the ship and propel it in the way is was angled. Thankfully, I had payed attention in my pre-calculus classes so I knew it had something to do with sine and cosine. After a lot of googling and thinking, I figured out the basic equations needed to rotate. It was difficult for me to grasp at first because the ship needed to essentially be at the origin at all time, in order to be rotated, but also at its correct position on the board. Thanks to pre-calculus again, I knew how graph transformations worked, and figured it out after a short period of time.

An unexpected challenge while creating this game was figuring out how the logic for asteroids was going to work. It was fun figuring out how to break asteroids into smaller pieces and how to spawn them randomly without interfering with the player.

Screen Shot 2015-12-10 at 9.36.50 AM

Ship blowing up an asteroid.

This was a great introduction to polygon games, teaching me a lot about the process as a whole.

The source code can be found here (Java, 36kb): https://drive.google.com/file/d/0Bz_0wgRmDpKqNUFhak80V1dxdFU/view?usp=sharing

© 2024 Brendan McCloskey

Theme by Anders NorénUp ↑