Final Project Update #2

I've done some more polishing on my game, this time mostly with the start screen and other screens that more clearly explain the game.

The first image is the screen seen when booted up. It's a lot simpler and less busy than the start screen on the previous version of the game, and I think it works much better. The second image is the screen you see after selecting the number of players, in this case 2 players were selected. It's in between the start screen and the actual gameplay to allow players to ready themselves.

Final Project Update #1

I've made some significant progress on my final project updates. I have the gravity working, so now bullets curve towards the center and edges of the screen, depending on where the player is shooting from. This helps prevent players from "trapping" each other in corners:

I've decided to scrap the idea of turning the ship. It seems like more trouble than it's worth, especially since the black hole exists which prevents much vertical movement. There's just one problem, which I've come up with a solution to. For the 3 player game, two players are on one side of the hole. This could cause problems if they manage to kill the player on the other side, since they won't be able to attack each other. To combat this I've decided to make the 3 and 4-player games a team match. When the players on one side of the hole are eliminated the game is over. For the 3 player game, the solo player will be given double heath.

Dev Blog Entry #6 - Networking Questions

Wrapping my head around the whole idea of networks, servers, and clients has been pretty tough for me. I understand peer-to-peer connections, where the users just send the data back and forth. I also understand the concept of a server on a theoretical level, where both users are 'clients' and send data to a server that then pushes only the required data back to the clients. I also get that it's smart to only send absolutely required data back and forth, since the more data you have to parse the more likely it is there will be unclean data.

I just don't really understand it on a practical level. I'm having trouble forming my thoughts into actual questions, but putting the whole thing together seems to be eluding. I think I just need to read up a lot more on servers and how everything works and really seem some code in action that can break everything down.

For my game, it wouldn't be hard to scale it for more players. I would just have to change the variable that restricts the maximum number of players to a higher number. That many players would have trouble fitting on the screen, but they would be there. The game itself would be unplayable, but the server can already theoretically handle that many players.

Dev Blog Entry #5 - Making Changes

I plan on making three major changes to my local multiplayer game. They are:

1. Add support for 3 or 4 players
2. Add support for turning your ship to allow 360-degree shooting
3. Force bullets to curve toward the middle of the black hole to discourage "trapping"

Adding support for more players is incredibly simple. I need to simply make two more player objects, and add in the built-in logic for collisions that the other players already contain. I'll also need to make two more "rooms" - Gamemaker's levels, one for three players and one for four. Then on the main startup room I'll need to add some logic for allowing players to choose if they want a 2, 3, or 4-player game. It's as simple as the user pressing the corresponding number key. Controller support for the two additional players is easy as well. When each player is created, it is assigned a 'pad_num' variable. Player 1 is 0, player 2 is 1, and so on. Players 3 and 4 will just need to be assigned that variable.

The logic for turning the ship is slightly more complicated. I already have the logic written for turning with the right analog stick, but the sticks are too loose for it to work correctly. I'll have to look into using the bumper buttons, and having each press turn the ship 90 degrees instead of having true free movement. I'll have to look into this more.

The third change is making bullets have a weight and angle to them. This will be achieve by using the built-in gravity and gravity_direction functions in GameMaker. I'll add the gravity to the bullets to make them gravitate towards the middle of the screen.

Game #3 Final Update

The last thing I added into my game was a score tracker to make it more of a game. There's still no real ending, but players can now keep track of score and make their own rule. They can also spawn multiple balls with the S key (but I don't recommend that because too many on screen at once will slow the game down). The score tracking works pretty well, but the game occasionally lags for one player which causes the scores to sometimes not match up. Here's what the game looks like with two players and the score:

I also added in a few sounds. The general background cheer noise comes from SoundBible: http://soundbible.com/1881-Sports-Crowd.html and the "GOOOOOL" noise comes from this Youtube video: https://www.youtube.com/watch?v=eSnWOWEXyVg

Final Project Plans

I plan on polishing my second game, the local multiplayer one, for the final project. I want to add in support for 3 and 4 players. I also want to add in the ability to turn your ship to allow attacking in 360 degrees. The added number of players will make the game more hectic and fun. I'm also going to add some new functionality to the "black hole" I used in the two player game. I'm going to try and make the bullets curve around the black hole to add some strategy and make it less easy for the players to "trap" one another. I'm going to add some more polish and tighten up the delay on being able to shoot so that players can't fire bullets so quickly.

Game #3 Update 4

I've continued working on my game, changing the art a bit and I managed to get the ball synced up on both clients, so I've got a fully playable game. The art is primitive, but I think it's cute and kind of endearing. All I need to do now is add in some sound effects and some logic for when a player scores. Maybe some sort of variable to keep track of goals. I don't really have a plan for ending the game, instead letting players end when they choose. Here's what the game looks like right now with one player in the game.

Game #3 Update 3

I've changed my game into a sort of soccer game, where the players must bounce a ball into the opposing player's goal. I have the networking stuff set up, and the player instances are synced. All I need to do now is set up the logic for synchronizing the ball instance, the logic for when a player wins, and I need to clean up the art a bit.

Game #3 Update 2

I've finally figured out all the networking issues with Gamemaker, and have an internet server running. I'm using a tool called GameMaker Server, which is really just a server a guy provides free to use, along with some built-in networking functions, like accounts, high scores, and achievements.

I don't really have much of a 'game' at this point, everybody can connect and their sprite is a random color, so players don't get confused. I'm still thinking of exactly what kind of game I'd like to make. I was planning on just making a 2 player capture the flag, and I think I'm still going to do that.

More updates to come as I continue working.

Game #3 Update and Networking

After initially struggling to wrap my head around networking in Gamemaker, I eventually found a tool that helps do most of the networking for you. It's called GMNet Engine and it works by having the master game server running on a platform like Digital Ocean. The documentation for the tool was pretty extensive and I worked through the tutorial pretty quickly to get it up and running. The only thing I need is the Digital Ocean server, or to see if I can run a Java server on my A Small Orange hosting.

A little clarification of my game concept too. It's capture the flag type game where players have to retrieve an item from the middle of the screen and return it to their base. There will be obstacles and hazards to make retrieving the item a bit less trivial, and players will have a special attack that forces the opposing player to drop the ball.

More updates to come.

Game #3 Concept

For my third game I’m thinking of using Gamemaker again. I’m thinking of making a 2-player game where both players start at opposite sides of the screen and have to retrieve a ball that sits in the middle of the screen, and then take it back to their home ‘base’. The first player to win 3 games will win the match, and each of the levels will have different features that the players will have to navigate around. Going along with the theme of ‘animal energy’, I’m thinking of making the players be animals, and then each player will get a certain number of special attacks that will make the opposing player drop the ball. For example, the lion will roar, causing the ball to drop and the other player to be pushed backwards. I think having a system like this will make the game more fun and add some strategy.

Since I’m using Gamemaker, all of my network stuff will have to be through Gamemaker as well. I’ve never done anything with networking and Gamemaker before, so I’m not sure exactly how it should. They have lots of documentation and tutorials, so I’m definitely going to look into things like these blog posts (https://www.yoyogames.com/blog/6), (http://help.yoyogames.com/hc/en-us/articles/216754698-Networking-Overview), the documentation -(https://docs.yoyogames.com/source/dadiospice/002_reference/networking/index.html) , tutorial videos (https://www.youtube.com/watch?v=MbUsHVak_yA), and things like the GMnet Engine (https://gmnet-engine.org/engine/). 

Entry #4 - Some Code

I was really happy with how this game, Space Fight, turned out. Since I had already worked with GameMaker in the past I didn't really have to waste any time learning how it works, and was able to jump right in designing and building my game. Gamemaker does a lot of functions using a drag-and-drop GUI, but a lot of the stuff I added in had to be hand-coded. One piece of code I liked was the healthbars I added in. GameMaker has a function built in that draws healthbars for an object, and I followed this tutorial to help me, but I was really happy how they turned out. This is the code for them:

This code takes arguments for location and bar size, the variable that the ship object uses for health, in this case health1 and health 2, and then the various colors used in the bar.
And this is what they look like in-game:

The second thing I really liked was the addition of gamepad support. When played on the keyboard my game feels a little cramped and players seemed to focus more on fighting the controls than on the game itself. Gamepads removed that probably and allowed players to just focus on playing. The controls felt natural to me. I used information from this blog post, and some of the code for gamepad support is below:

The first block is code that fires when the system detects a controller is plugged in. It defines the deadzones for the triggers and buttons, and then creates a player object and assigns the controller to the player object.

The second block is the logic for doing 'normal shots'. Pressing the trigger creates the instance and the specified location - the front center of the ship - and then gives it a speed of 15 and a direction of 90, which will make it shoot straight up. It then plays a sound and sets the can_shoot variable to false, which sets a cooldown timer until the player can shoot again.

One other thing that I liked, and something that changed as I worked, was the title screen I made for the game. The original title screen was made before I had gamepad support, and I wasn't a big fan of it. This is the original:

Then, as I worked and added more concepts and depth, I ended up with this:

So as I worked, the main thing I added was the gamepad support. Then I realized that gamepads had 8-directional movement with the analog stick, but keyboard users could only move in 4 directions. So I implemented a velocity variable that allows the player to move in all 8 directions with the keyboard. During playtesting I noticed that players were intentionally moving towards each other to be on the same horizontal level which made the game a stalemate. To combat this I added the black hole, which wounds players if they go near the center of the screen.

There's a few things I'd still like to add. I'd like the players to be able to rotate so they could shoot in any direction. This would make the black hole unnecessary, since players could just turn and shoot. Barring that, I'd like to make the bullets slightly curve towards the black hole to kind of simulate the gravity. I'd also like to add more players to create teams, which I feel would add some more strategy to the game. More levels and ship colors/types are also on the list of changes I'd like to make.

Entry #3 - My Game's Design

My game has a similar design to other space shooters like Galaga and Raiden. Those games, however, are mostly vertical scrolling single-player games, whereas mine is a stationary two player fight. I think my game, while not unique in any way, puts a nice little twist on that genre. The multiplayer components of most space shooter games function exactly the same as the single player portion. The second player just takes control of another ship on the screen. My game's a little different because it is competitive instead of cooperative.

The design itself doesn't really add much to the genre - it's just a simple shooter. I did like the black hole concept I added in to keep people from getting on the same horizontal level and thus being unable to shoot each other. One piece of feedback I got was to make the bullets gravitate towards the black hole in the middle of the screen. I think that would make the game a lot more interesting and strategic since players would be able to curve shots. It adds another level to the game, since right now players can just remain across from each other and block shots indefinitely.

Another piece of feedback I received was to add a cooldown between normal shots. As it is now, the player that shots first and gets the jump will always win. Adding a second between shots will slow it down a bit and create some strategy.

Game Project 2 Update

Since my first update I've made a bunch of progress on my game. I've updated the title screen, changed how movement works to make it fully 8-directional, and also added gamepad support, among other things.
This is the new title screen, where I've only made subtle changes, but I think it looks much nicer than the previous.

The new movement system is much smoother than the previous one that only allowed for 4 directions. The new system allows players to move diagonally. I figured this out by making the movement keys affect a 'velocity' variable instead of the x and y variables directly. 

I also made it so bullets can collide with each other instead of just passing through, which gives players a method of defending themselves.

One of the issues I had with the game was not knowing how much health each player had, besides the sprite changing to an "injured" version when health got below 50. I added in healthbars for the player using this tutorial.

The biggest update I made was the addition of gamepad support. It makes for a much better experience than having both players crammed together on the keyboard. The only thing that didn't work correctly was using the right stick to make the ship turn. I implemented it, but it was far too finicky and sensitive, even with the deadzone set as high as Gamemaker will allow. For this, I used this excellent blog post.

Since the players can't turn, there is a potential problem with players getting on an even level horizontally which would make it impossible for them to shoot each other. To combat this, I added a 'black hole' across the middle of the screen that blocks the user from crossing it and also hurts them. It should make it so that players are always able to shoot at each other.

The only thing left for me to do is implement my own art for the player ships and bullets.

Game Project 2 Progress

After some deliberation I decided to make a multiplayer space shooter for my next project. I also decided to work in GameMaker since I already have some experience with it. So far the process has been pretty smooth. I have all of the basic gameplay functions added in, with both players shooting, damaging each other, and being destroyed with health reaches 0. I also have a start screen that displays controls.

The few things I have left to add in are:

• Game over screens
• Try to tighten up the controls a bit
• limit the fire rate for shooting

Potentially I'd like to add gamepad support and other stages, as well as user defined number of lives. 

Questions about Games in Class 3/7/16

The game I enjoyed most was Astro Duel. It was the easiest to pick up and play, and the simple game mechanics were really enjoyable. Even though it was simple it was really competitive. Everybody could pick up on it really quickly so there wasn't a period where we had to fiddle around with the controls.

A screenshot from Astro Duel

The game with the most novel concept was Filo Filo Disco. I didn't really understand the objective at first, but after a few rounds I picked up on it and found it really fun. I thought the swinging and throwing mechanic was really cool and added some strategy to an otherwise really simple game. It was pretty cool how such a simple concept could be so competitive and require strategy.

Single Screen Multiplayer Game Idea

Our next project is to make a multiplayer game that uses one or no screens. I'm thinking of making a 2 player shooter game in GameMaker. I have a little bit of experience with GameMaker, so with the time we have I think I'll be able to create a game with a couple levels. Since the theme is "grit", I think a shooter is appropriate. The players will have to shoot all of the enemies to advance to the next level. After a couple of levels they will fight a boss. After defeating the boss the game is over.

Finished Game

So my game is finished, and I've got mixed feelings about it. On the one hand, I'm glad that it works and is pretty stable. I came into this project only wanting to make a simple game of tag with some special features, like obstacles. As I worked I had to remove some of the features I wanted, like obstacles and a restart button, for the sake of having a working networked prototype at the deadline. If I had more time I would have added things like:

• Obstacles with collision detection
• Make players switch colors when they touch (switch who is "it")
• A restart button

I'm also a little disappointed that I didn't get to add in any data checking during the grace period that would have let me run the game at a higher framerate. I just didn't have time with work and class.

The finished project is pretty simple. I took some screenshots to show the progression of the game:

The start location for the players

The red player, who is "it" gets closer to the target.

When the red player touches blue, both players see the game over screen.

There were a few code snippets that I think exemplify some of the effort I put into the project, even if the end result wasn't very flashy. First, there's the logic I built for the collision detection. 


boolean isInsideRect(float x, float y, float rectX, float rectY, float rectW, float rectH)
{
boolean answer = x > rectX && y > rectY && x < rectX+rectW && y < rectY+rectH; return answer; }

This function was used in my IMM120 class (I can't find the original github repo) and I had to tweak it for my implementation:


if ((isInsideRect(player1.x, player1.y, player2.x, player2.y, size, size)) ||
(isInsideRect(player1.x, player1.y+size, player2.x, player2.y, size, size))||
(isInsideRect(player1.x, player1.y, player2.x+size, player2.y, size, size))||
(isInsideRect(player1.x, player1.y, player2.x, player2.y+size, size, size))||
(isInsideRect(player1.x+size, player1.y, player2.x, player2.y, size, size))||
(isInsideRect(player1.x+size, player1.y+size, player2.x, player2.y, size, size))||
(isInsideRect(player1.x+size, player1.y+size, player2.x+size, player2.y+size, size, size))||
(isInsideRect(player1.x+size, player1.y, player2.x, player2.y+size, size, size))||
(isInsideRect(player1.x+size, player1.y, player2.x+size, player2.y, size, size))||
(isInsideRect(player1.x+size, player1.y+size, player2.x+size, player2.y, size, size))||
(isInsideRect(player1.x+size, player1.y+size, player2.x, player2.y+size, size, size))||
(isInsideRect(player1.x+size, player1.y, player2.x, player2.y+size, size, size))||
(isInsideRect(player1.x, player1.y, player2.x+size, player2.y, size, size))||
(isInsideRect(player1.x, player1.y, player2.x, player2.y+size, size, size))||
(isInsideRect(player1.x, player1.y, player2.x+size, player2.y+size, size, size))||
(isInsideRect(player1.x, player1.y+size, player2.x+size, player2.y+size, size, size))
== true) {
gameOver = true;
}


As you can see, it's a bit tedious and sloppy. But it's the way I know how to do collision detection, so I used it. It seems to work.

I also like the way I did movement for the player who is "it". I used processing's second() function to count time, and after 30 seconds have passed the player moves faster. It isn't really anything special, but I liked the functionality of it.

void update(){
if(keyPressed == true && keyCode == UP){
y -= speed;
}
if(keyPressed == true && keyCode == DOWN){
y += speed;
}
if(keyPressed == true && keyCode == RIGHT){
x += speed;
}
if(keyPressed == true && keyCode == LEFT){
x -= speed;
}
if (x > width - 100){
x = width - 100;
}
if (x < 0){ x = 0; } if (y > height - 100){
y = height - 100;
}
if (y < 0){ y = 0; } if (time > 30){
speed = 15;
}
}


All in all, there were a couple takeaways from this project for me.

1. Collision detection is hard
2. Everything will always take longer and be harder than you think it will.

I wish I had had more time/skill to implement the features I wanted to. I'm a little disappointed with the outcome of this project, but I'm glad it at least works on some level.

Project Update - Almost Done

So I've made lots of progress on my game. It's pretty much completed with very few bugs, and no game-breaking bugs. Crashes are very rare and are fixed with a simple restart. There are two things I'd like to go into in this post: the way I used collision detection, and the audio I used for this project.

There were a couple resources for collision detection posted in Piazza (I even posted one of them) but in the end I decided to go with a method I have used in the past. In my IMM 120 class, I was taught a method to check if a point is inside of a rectangle. This is useful, in most cases, for checking to see if the cursor is inside of a shape, but I changed it to work for my use case, It resulted in this gigantic, poorly-coded, bad practice if statement:

It's not pretty, but it works. I haven't found a case yet where the squares touch without triggering the gameOver variable. I'm sure there's a better way to do this, in fact I'm positive there is, but this method worked for me.

My game's a little bare, graphics wise. I felt that I didn't really need too many distractions, since the game is all about the two players. I did however want to add in some audio. I found a pretty cherry playground-y song that I thought works well for tag (in fact, the song is called Tag Game Song). It fits the game perfectly in my opinion. 

Give it a listen: https://musescore.com/user/912161/scores/1498441

Networked Games - Project #1 Programming Outline

So I've decided to go with Tag for my first project. I haven't started actually coding (will start that after this post and throughout the week), but I've laid out the roadmap for how my code will be organized.

I'll have the main class where setup() and draw() are called, which will contain the networking logic and the logic for players colliding with each other and with stationary objects.

My program will have two classes outside of the main class: Player and Obstacle. Player will contain the logic for player movement and starting location, and Obstacle will generate objects at random points.

I hope that planning out my programming ahead of time will help make the process smoother. More updates to come as I start coding.