So, week 3 is finished. Since it has a networking component, I'm waiting to test it out with another developer before writing up a report on it (and I will have quite a bit to write about it). But, I wanted to go ahead and give a preview for week 4! I will be testing out some game development tools in the coming weeks to get a sense of the tools and what operations I should employ in my own engine. This week, I'll be using GameMaker Studio (https://www.yoyogames.com/studio). I haven't really taken this seriously in the past, but I've decided to give it another shot as I've heard it's become a serious contender for professional indie game devs writing 2D games. That, and there was an announcement they were partnering with Sony on the PS4 (https://www.yoyogames.com/news/210). So far I've been using it for a few days, and I really like it for its fast prototyping capabilities.
This week will be a space versus shooter. The components of the game will feature a modified handicap system which will reward players with powerups if they die. It will punish players by taking away a powerup if they get a kill. Kills with lower power ups score more points, kills with higher powerups score less points. The game is a two player multiplayer game, much like the clown game, where each side has a ship and will shoot across the board to kill the other player. The game will be a time limit long, and the player with the most points at the end of the time limit is the winner. I will be using Gamemaker this time to get a feel for the tool and see how easy it is to put together a prototype.
Wednesday, April 2, 2014
Tuesday, March 25, 2014
Week 3: Update
Ahh, the joy of seeing your first networked game...it's awesome :-) I just got Week 3's clowns to connect to a server and move around, updating each other's screens. This is freaking sweet :-) I'm trying to finish by tonight, but a quick update on things. I'm using Boost::asio to do the network functionality, and I hijacked their chat client example and modified it so I can plug my game instances into it. Essentially, the games are connected via messages to the chat server via TCP/IP to each other. More updates to come, and I'll have a longer post on this. This week has really given me a sense of how essential game development tools such as Unity and Gamemaker really are for fast prototyping :-/
Monday, March 17, 2014
Week 2, Game 2: 3D Maze!
This week was pretty hectic with I3D among other things. I managed to slip together a simple (and quite ugly) prototype of a 3D maze. The idea is this: in a 2D maze, the player can move left, right, up, down, and the movement is constricted by a set of boundaries. An example maze generated is shown below:
While this is great, I wanted to experiment with a 3D maze. So I thought it would be cool if the maze is generated the same way, except the player has the option of going down or up. How this would be displayed on the board is that the current layer the player is at will be displayed (looking like above), and cells will be marked (with textures or colors) whether there is a pathway to the layer below or above. An example is the bottom, where red means there is a pathway down, blue is a pathway up, and green is a corridor leading both up and down.
So how to navigate this? Well, I thought it would be nice for the player to rotate the maze cube, then the layer that is facing UP will be the layer the player sees. So above, if the player is on a red square, then when rotated, the down pathway will now be on the top layer as a pathway leading left (or right depending on rotation direction). Then the player can move. Well, this was fine, but it makes the game so complicated! I'll have to experiment with a different maze generation algorithm in the future which minimizes down/up pathways, but the problem is that the player sees a slice of the maze cube at an arbitrary rotation, so down/up/left/right/ etc. are all relative to the slice. Anyways, I finished a simple prototype using C++ and SDL again. I didn't have time to put any textures in it as I would have liked, but I think this prototype could have potential. Perhaps I will go back in a post-mortem update and make it look better.
The video below shows an example run. Red is down, blue is up, and cyan is both ways. The player can rotate the cube, and the slice that needs to be shown is show. I think making the player a 3D object such as a sphere could add a little bit to the UI. Currently, there is a lot of room for improvement in the UI, and if this is extended to a project the UI would probably be the hardest thing to get right. This is an example of "it looks great in my head" but when it comes down to it, a lot of experimentation and player testing would be needed to get just the right view, colors, textures, shading, etc. to make it feel "intuitive" to the player.
So how to navigate this? Well, I thought it would be nice for the player to rotate the maze cube, then the layer that is facing UP will be the layer the player sees. So above, if the player is on a red square, then when rotated, the down pathway will now be on the top layer as a pathway leading left (or right depending on rotation direction). Then the player can move. Well, this was fine, but it makes the game so complicated! I'll have to experiment with a different maze generation algorithm in the future which minimizes down/up pathways, but the problem is that the player sees a slice of the maze cube at an arbitrary rotation, so down/up/left/right/ etc. are all relative to the slice. Anyways, I finished a simple prototype using C++ and SDL again. I didn't have time to put any textures in it as I would have liked, but I think this prototype could have potential. Perhaps I will go back in a post-mortem update and make it look better.
The video below shows an example run. Red is down, blue is up, and cyan is both ways. The player can rotate the cube, and the slice that needs to be shown is show. I think making the player a 3D object such as a sphere could add a little bit to the UI. Currently, there is a lot of room for improvement in the UI, and if this is extended to a project the UI would probably be the hardest thing to get right. This is an example of "it looks great in my head" but when it comes down to it, a lot of experimentation and player testing would be needed to get just the right view, colors, textures, shading, etc. to make it feel "intuitive" to the player.
Preview: Week 3
Clown fun! This GaW idea comes from Dipdac. The game will involve a multiplayer component, so I'll get to play around with sockets and such in C++ (I could do it in Python or some other , and I may in the end, but for now I want to target C++ for a few more GaWs).
The idea is that each player controls a clown on opposite sides of the screen. The player can shoot water (from a water gun I think) towards the other clown. If it hits the other clown, a set of balloons tied to the clown will expand. Once they expand to the max, they pop and the clown isdead sad. I'll have to figure out a good design for the balloons when they get close to popping, I am thinking currently they could start oscillating rapidly to show they are nearly about to burst. Additionally, coins will flow on each side of the screen (or in the middle) where the clown could retrieve it to reduce the water in his balloons. This opens up some interesting multiplayer competition possibilities as the other player will want to shoot towards the coin to prevent the other player from picking it up, kind of like clown dodge ball.
Again, I'll be using C++ and SDL, and I will be making use of a lot more textures than I have in my previous two entries. Hopefully I'll have developed a nifty sprite library after this week is complete for use in later games.
Thanks to Dipdac for the idea.
Happy coding!
-Scyfris
The idea is that each player controls a clown on opposite sides of the screen. The player can shoot water (from a water gun I think) towards the other clown. If it hits the other clown, a set of balloons tied to the clown will expand. Once they expand to the max, they pop and the clown is
Again, I'll be using C++ and SDL, and I will be making use of a lot more textures than I have in my previous two entries. Hopefully I'll have developed a nifty sprite library after this week is complete for use in later games.
Thanks to Dipdac for the idea.
Happy coding!
-Scyfris
Friday, March 14, 2014
Update: Week 2
First maze (only one layer, so all cells lead to neighboring cells in 2d:
A different maze with 10 layers using same maze generation algorithm. The first image shows the first layer where red cells lead to the layer below.
This image shows the cells leading down as red, and the layers leading up as green. The blue cells have both layers (tunnels) though.
I will need to minimize this. I'll experiment more tomorrow. I'll detail my maze generation algorithm (although it's super simple) during the final post.
Monday, March 10, 2014
Preview: Week 2
This week is a little hectic, I will be leaving for a conference on Thursday and won't be back until Monday, so I will have to code on the road!
The idea for this week is to create a 3D maze. The player will enter one side of the maze and must work their way through a 3D cube of tunnels until they find the exit. The player will always see from "above" the cube and can rotate it left, right, up, down. The player inside the maze will also rotate with the cube, but the layer that the player is in w.r.t. the "down" direction will always be the visible slice, so the player will always be able to look from above. Hopefully once this is implemented it will be clearer :-D
I wanted to use HTML5 for this one as I'm particularly excited about it, but due to my time constraints, I will be using C++/OpenGL/SDL again (same as last week).
Goals
The idea for this week is to create a 3D maze. The player will enter one side of the maze and must work their way through a 3D cube of tunnels until they find the exit. The player will always see from "above" the cube and can rotate it left, right, up, down. The player inside the maze will also rotate with the cube, but the layer that the player is in w.r.t. the "down" direction will always be the visible slice, so the player will always be able to look from above. Hopefully once this is implemented it will be clearer :-D
I wanted to use HTML5 for this one as I'm particularly excited about it, but due to my time constraints, I will be using C++/OpenGL/SDL again (same as last week).
Goals
- 3D maze generation inside a cubical area. One exit, one output.
- Player navigation and input to manipulate cube
- Maze cube rotates around different directions, displays topmost layer at all times to player, modify directions the player navigates w.r.t the current rotation (always looking from same direction on cube, but cube will rotate).
- Use 3D texture for the generated maze, use OGL to slice the cube to view inside the texture.
- Multiple maze cubes within a larger maze cube. Each smaller cube can be rotated independently if the player is inside it.
Happy coding everyone, see you next Sunday (or Monday, I may be on a plane :-S )
-Scyfris
Game 1, Week 1
Well, I finished the game. I need to do a better job with my deadlines since I targetted last night a midnight, but I just got it done. This is in part due to 3 deadlines I had for work/school this last week, but it's all good!
The first game is finished. As mentioned previously, I wanted to start out simple. I created a Columns clone. Columns was a game like Tetris where a block of 3 colors falls down from the top of the board. The player can rotate the colors as they fall and move them to place them where they want. Colors that line up in 3+ succession in vertical, diagonal, or horizontal will be broken. Then the blocks above those are shifted down, and any new blocks that line up will be broken again. This is the simplest possible configuration. For my stretch goal, I wanted to add power-ups much like in Yahoo! Towers, but I never reached that point.
The game currently has a board, pieces that fall, a high score, a current score, and a game over component. The entire game was completed using SDL, OpenGL, and the SDL_ttf (for text display) libraries. Everything else was done from scratch. It was great to get into SDL, and since I haven't done much with text + OpenGL combinations, it was nice to refresh myself and see how tricky these things can truly be.
Issues
Even with a simple project like this, a number of issues came up which I'll need to be weary of in the future. The foremost being text display. I used SDL_ttf which is a wrapper to a TrueType Font library. You can write text directly into an SDL surface (which you can think of as an image buffer with formatting, etc. Much like a GL/D3D texture in software, and in fact I use surfaces as intermediaries to hardware textures). I think upload this texture to a GL hardware texture and display it as a quad on the screen. There are a number of other ways to do it which I'll look into in the future (http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenGL_Tutorial_Text_Rendering_01), (http://www.opengl.org/archives/resources/features/fontsurvey/).
Another issue I will need to code for is animations. I'll have to survey different game engines to see how they handle animations (seperate thread, how to block other components, etc). I wanted to have a simple animation of the blocks breaking when they are eliminated, but I didn't have the time. For now, everything happens instantaneously.
Menus will also need to be added. I will need to create a library myself for this or resort to using something like QT ( but I'd rather do it myself at this point since I'm building on previous work each week).
I also had some issues with uploading SDL surface textures to hardware textures. Primarily the issues were due to format conversion and flipping the SDL surface around for the hardware texture.
Postmortem
Although I didn't meat the stretch goals of power-ups and I didn't get any animations in there, I feel this succeeded in my first goal and is a good first GaW project. I would have liked to have menus in there and I would have liked to have animations, but I do have the basic Columns functionality and a high-score system in place. I'm looking forward to using SDL some more in the future. For my OGL/C++ projects.
The scoring system just takes the number of blocks broken at once (including succession of breaks if a block shifts other blocks into a breaking patter) and squares the number and adds it to the score.
Summation:
Languages used: C++
Libraries used: SDL2, OpenGL, SDL_ttf (True type font library).
Code obtained for future projects: Working with SDL surfaces, uploading to GPU, game loop.
Code to clean for future projects:
The first game is finished. As mentioned previously, I wanted to start out simple. I created a Columns clone. Columns was a game like Tetris where a block of 3 colors falls down from the top of the board. The player can rotate the colors as they fall and move them to place them where they want. Colors that line up in 3+ succession in vertical, diagonal, or horizontal will be broken. Then the blocks above those are shifted down, and any new blocks that line up will be broken again. This is the simplest possible configuration. For my stretch goal, I wanted to add power-ups much like in Yahoo! Towers, but I never reached that point.
The game currently has a board, pieces that fall, a high score, a current score, and a game over component. The entire game was completed using SDL, OpenGL, and the SDL_ttf (for text display) libraries. Everything else was done from scratch. It was great to get into SDL, and since I haven't done much with text + OpenGL combinations, it was nice to refresh myself and see how tricky these things can truly be.
Issues
Even with a simple project like this, a number of issues came up which I'll need to be weary of in the future. The foremost being text display. I used SDL_ttf which is a wrapper to a TrueType Font library. You can write text directly into an SDL surface (which you can think of as an image buffer with formatting, etc. Much like a GL/D3D texture in software, and in fact I use surfaces as intermediaries to hardware textures). I think upload this texture to a GL hardware texture and display it as a quad on the screen. There are a number of other ways to do it which I'll look into in the future (http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenGL_Tutorial_Text_Rendering_01), (http://www.opengl.org/archives/resources/features/fontsurvey/).
Another issue I will need to code for is animations. I'll have to survey different game engines to see how they handle animations (seperate thread, how to block other components, etc). I wanted to have a simple animation of the blocks breaking when they are eliminated, but I didn't have the time. For now, everything happens instantaneously.
Menus will also need to be added. I will need to create a library myself for this or resort to using something like QT ( but I'd rather do it myself at this point since I'm building on previous work each week).
I also had some issues with uploading SDL surface textures to hardware textures. Primarily the issues were due to format conversion and flipping the SDL surface around for the hardware texture.
Postmortem
Although I didn't meat the stretch goals of power-ups and I didn't get any animations in there, I feel this succeeded in my first goal and is a good first GaW project. I would have liked to have menus in there and I would have liked to have animations, but I do have the basic Columns functionality and a high-score system in place. I'm looking forward to using SDL some more in the future. For my OGL/C++ projects.
The scoring system just takes the number of blocks broken at once (including succession of breaks if a block shifts other blocks into a breaking patter) and squares the number and adds it to the score.
Summation:
Languages used: C++
Libraries used: SDL2, OpenGL, SDL_ttf (True type font library).
Code obtained for future projects: Working with SDL surfaces, uploading to GPU, game loop.
Code to clean for future projects:
- Create a more generic game class for using in future projects. Currently the game loop is kind of hard coded.
- Create a more generic text-to-texture class to help with drawing text to the screen.
- Clean up some of the utility functions for manipulating textures.
Subscribe to:
Posts (Atom)