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.
Sunday, March 2, 2014
Week 1 Idea:
For this week I want to create a clone of a puzzle game I used to play in my younger days. The game was called Yahoo! Towers and was produced as part of Yahoo!'s games initiative way back in the day. The game itself is actually a clone+modification of a tetris-like game called Columns. The game board consists of a 6X13 board of blocks. A new block that falls down is a column of 3 blocks of different colors. There are 6 different colors overall. A block begins falling like tetris and once it fits into place, any blocks which are in the same color in a row/column/diagonal are broken and the blocks above them shift down. Once blocks shift down, blocks can still be broken/shifted down until there are no more blocks to be broken. Then, a new block will spawn and start falling again. In the original Yahoo! towers, there was a multiplayer element where there were power-ups, players could use those power-ups against each other, and the winner was the last man standing. I highly suggest anyone interested in these types of games to check out the now-almost-defunct Yahoo! Towers (although it requires a login, you could also look at Youtube for Columns or Yahoo towers).
For this week, I want to create a simple clone of the Columns/Yahoo! Towers game. There will be 6 colored blocks, and they will come down and the user will need to rotate the colors around and move the piece to put it into a place which will break colors and/or cause all other colors to break. There will be a simple score system for the player and a simple menu. The point of this challenge is to get me back into the SDL library. I've been an OpenGL programmer for 10+ years, and I've used mainly GLUT in the beginning, then the GLFW library for GL context management and for setting up the main event loop. SDL seems to be a much fuller-featured library for this type of thing and also contains functionality for all other aspects of programming which game programming requires (audio, controller input, etc), so I want to get into this and use it so I'll have experience with future projects. I will also be using code that I come out with to be used on future GaW projects (not the game, just utility functions such as sprite blitting or menu functionality).
Goals:
1. Create a simple columns clone. Piece of three blocks falling with 3 random colors from the 6 color pool. Once a piece is landed, pieces will break if the colors are in order in a 3-or-more like color succession. Pieces will continue to break if they are in color succession when other pieces break.
2. Simple menu system, score identifyer, and next piece viewer.
Stretch Goals:
1. Power-ups
Language used:
C++
Libraries used:
SDL, OpenGL (version XX, I might be using newer OpenGL version. I'll make sure to edit this once I post the game).
After the game, I will post which libraries I used, which ones I had to create which could be used in future games, and other stuff. See you next Sunday.
-Billy
For this week I want to create a clone of a puzzle game I used to play in my younger days. The game was called Yahoo! Towers and was produced as part of Yahoo!'s games initiative way back in the day. The game itself is actually a clone+modification of a tetris-like game called Columns. The game board consists of a 6X13 board of blocks. A new block that falls down is a column of 3 blocks of different colors. There are 6 different colors overall. A block begins falling like tetris and once it fits into place, any blocks which are in the same color in a row/column/diagonal are broken and the blocks above them shift down. Once blocks shift down, blocks can still be broken/shifted down until there are no more blocks to be broken. Then, a new block will spawn and start falling again. In the original Yahoo! towers, there was a multiplayer element where there were power-ups, players could use those power-ups against each other, and the winner was the last man standing. I highly suggest anyone interested in these types of games to check out the now-almost-defunct Yahoo! Towers (although it requires a login, you could also look at Youtube for Columns or Yahoo towers).
For this week, I want to create a simple clone of the Columns/Yahoo! Towers game. There will be 6 colored blocks, and they will come down and the user will need to rotate the colors around and move the piece to put it into a place which will break colors and/or cause all other colors to break. There will be a simple score system for the player and a simple menu. The point of this challenge is to get me back into the SDL library. I've been an OpenGL programmer for 10+ years, and I've used mainly GLUT in the beginning, then the GLFW library for GL context management and for setting up the main event loop. SDL seems to be a much fuller-featured library for this type of thing and also contains functionality for all other aspects of programming which game programming requires (audio, controller input, etc), so I want to get into this and use it so I'll have experience with future projects. I will also be using code that I come out with to be used on future GaW projects (not the game, just utility functions such as sprite blitting or menu functionality).
Goals:
1. Create a simple columns clone. Piece of three blocks falling with 3 random colors from the 6 color pool. Once a piece is landed, pieces will break if the colors are in order in a 3-or-more like color succession. Pieces will continue to break if they are in color succession when other pieces break.
2. Simple menu system, score identifyer, and next piece viewer.
Stretch Goals:
1. Power-ups
Language used:
C++
Libraries used:
SDL, OpenGL (version XX, I might be using newer OpenGL version. I'll make sure to edit this once I post the game).
After the game, I will post which libraries I used, which ones I had to create which could be used in future games, and other stuff. See you next Sunday.
-Billy
Saturday, March 1, 2014
First Post
This is a blog I'm creating inspired by some one game-a-week blogs going on (Rami Ismail's article at http://www.gamasutra.com/blogs/RamiIsmail/20140226/211807/Game_A_Week_Getting_Experienced_At_Failure.php, and Adriel Wallick's blog http://www.adrielwallick.com/blog/). So the point is for us to create some games quickly, with short iteration times and quick prototyping. The point is not to make full-fledged games, but instead to come up with an idea which can be prototyped in a week using tools we may/may not be used to. This will allow me to explore my coding process even more (outside of work/academia) as well as explore new technologies (such as HTML5) to learn from. Some of these ideas may be fleshed out later, but for this blog each game will end after a week, meaning that no new game will come out that is a direct iteration off a previous game (now exploring ideas from previous game ideas is permissible). Since my schedule is pretty busy, Sunday will be the deadline day. This means that if something ends early, we could start on the next week's game a bit early. We'll see if that actually happens! I would like to present the game idea the week before, and if I have more ideas I will sketch them down in a to-be-completed-later log. Before the start of each game's week, I will post the idea, and the next weekend a game should come from that. This is a challenge to me, my management of time, team structure (if someone else is working on it with me), and my programming skills. The main use for this challenge is for me/us/the community to learn, make mistakes, learn from those mistakes, and to see the simple joy in completing projects, no matter how shitty simple they are :-)
-Scyfris
-Scyfris
Subscribe to:
Posts (Atom)