Saturday, May 3, 2014
Update
I've decided to work full time on a game right now for IndieCade as well as for release on mobile (Android, iOS), so all my time will be devoted to that for the next few weeks. I will return to this once I feel I have sufficient development time invested in the other game.
Saturday, April 26, 2014
Week 6: Gravity Ball
Well, it looks like the Game a Week is turning into the Game Every Ten Days. Well, that's okay, because I'm proud of this week. I delved into the mobile development tool Moai (http://getmoai.com/). It's a very nice open source solution to writing games in Lua and publishing for multiple platforms. The backbone of the system is C++, and there are multiple hosts that can be used (Windows, Android, IOS, etc). I used the Windows host which uses GLUT is a back-end (not my first choice, but I see that the newest version uses SDL).
When I initially downloaded from the Git repository and tried to build it, I got nothing but erros in Cmake. After scrounging around a while, I managed to get an older stable version which only uses the Glut host for Windows. I quickly learned Lua, and also wrote a simple parser using Tiled map editor (http://www.mapeditor.org/).
The player can move a ball around and can jump. Also, the player can rotate gravity to the right, left, or up. The ball will fall in that direction, and when it lands the camera will rotate to orient the up direction. The goal is to get to the yellow. Red squares will reset the character. I'm actually looking to ramp this up a bit, polish it, add a few more features.
When I initially downloaded from the Git repository and tried to build it, I got nothing but erros in Cmake. After scrounging around a while, I managed to get an older stable version which only uses the Glut host for Windows. I quickly learned Lua, and also wrote a simple parser using Tiled map editor (http://www.mapeditor.org/).
The player can move a ball around and can jump. Also, the player can rotate gravity to the right, left, or up. The ball will fall in that direction, and when it lands the camera will rotate to orient the up direction. The goal is to get to the yellow. Red squares will reset the character. I'm actually looking to ramp this up a bit, polish it, add a few more features.
Monday, April 21, 2014
Gamedev post
Just wanted to let any readers know, I have collected a few links from the web and forum posters on various resources relating to game a week/2weeks. The original Gamedev.net post is here http://www.gamedev.net/topic/655333-game-a-week/
Here are the links from the post, in no particular order.
Here are the links from the post, in no particular order.
Adriel Wallick's blog: http://adrielwallick.com/
LessMilk: http://www.lessmilk.com/
Jayenkai's website: http://jayenkai.socoder.net/
Mondongorongo's blog: http://mondongorongo.wordpress.com/
Jonathan Gaiser's blog: http://gameaweekchallenge.tumblr.com/
Some articles about GaW.
Other contributions from forum posters:
One game a month -- http://onegameamonth.com (Thanks BHXSpecter )
ManTis' Gamedev Journal -- http://www.gamedev.net/blog/704-crawling-with-ideas/ (Thanks slicer4ever)
11 day level design process overview -- https://www.youtube.com/watch?v=pj8cbC2YnwU (Thanks Tutorial Doctor)
Thursday, April 17, 2014
Week 6: Preview
Okay, so I haven't really gotten a lot of time with my previous games. The first few were created using low-level C++ and OpenGL. The next few were with GameMaker: Studio. I think this time I'll be trying the Moai API (http://getmoai.com/). It seems to offer a solid framework for mobile, AND it's opensource. The competitor, Corona SDK (http://coronalabs.com/products/corona-sdk/faqs/) offers a fulle bundled solution (everything is in the SDK, physics, in-app purchasing options, graphics, etc), whereas Moai lets you use other tools to get the job done for development.
The idea for this game is to play with gravity. It will be a little platformer jumper, where the player must jump from box to box, but only a subset of the sides of the box will be land-able, the other sides will cause the player to die. The player must manipulate gravity during jumps in order to land on the correct side.
The idea for this game is to play with gravity. It will be a little platformer jumper, where the player must jump from box to box, but only a subset of the sides of the box will be land-able, the other sides will cause the player to die. The player must manipulate gravity during jumps in order to land on the correct side.
Week 5: Mole Messiah
Wow, this week was crazy. I had a paper deadline for a conference I was submitting to and didn't get but 4 hours to work on the game this week :-S Despite that, I managed to build something (thanks to the fast prototyping capabilities of Gamemaker) and I learned a little more about Gamemaker Studio as well. I wouldn't really want to use it for production games, but it's great for fast prototyping. The reason I wouldn't use it in production is that I would like more control over things, such as object hierarchies, being able to use other tools in the pipeline, more control over the logic of the game. I think I'll end up purchasing it in the long run since I can make some decent 2D games from it, but I for production games I'll probably require something a little more heavyweight (or lightweight depending on how you look at it. I mean heavyweight in the sense of control). Next week I'll be examining the Moai API for building (http://getmoai.com/). I'll probably return to Gamemaker and test out some more advanced features later.
Anyways, this week was a Whack-a-Mole game where the moles appear and disappear very fast. Additionally, there is a "Messiah" mole that , when hit, will end the game. Also, when the timer runs out the game is over. You will notice the lack of graphics and user interface :-) But, fun little experiment with GM:S.
Anyways, this week was a Whack-a-Mole game where the moles appear and disappear very fast. Additionally, there is a "Messiah" mole that , when hit, will end the game. Also, when the timer runs out the game is over. You will notice the lack of graphics and user interface :-) But, fun little experiment with GM:S.
Tuesday, April 8, 2014
Week 5: Preview
Whack-a-mole -- This is a simple idea I had that I might eventually port to other devices. I want to make a whack-a-mole style game, where you gain points by whacking the moles the fastest. Most moles are good, but every now and then a special mole type pops up that, if hit, will end the game.
Week 4: Powerup Inverse
This week, instead of using my own tools, I'm tested out Gamemaker: Studio to test out its prototyping abilities. This week I wanted to experiment with a modified handicap system. I created a space shooter where the player is rewarded for killing by NOT giving him powerups. Powerups will decrease the player's score if they get a kill, so when the player is doing well, it means he has no powerups and is getting the maximum score. When the player dies, he receives a powerup making it easier to kill the enemy, but decreasing his score each kill. When he gets a kill, the powerup level is decreased.It's basic, and I'm sorry for the random mouse cursor in the way!! I made a really simple and horrible AI for the enemy ship. I might extend this game later. This is the first time I have used GameMaker: Studio free edition, and after the video I will talk about it a bit.
Ship and nebula image were found with Google image search. The ship came from someone on Stackoverflow: http://stackoverflow.com/questions/15342083/algorithm-to-make-a-polygon-from-transparent-png-sprite and
I used Gamemaker this week to make the game because I wanted to experiment with something different. I've found that Gamemaker is amazing at allowing somoone to quickly create a prototype, but it definitely has some deficiencies which make it harder to use for full-scale games. Perhaps some of those deficiencies arrose because I wanted more control, more power, or more programming language expressive power (I am a programming). But all-in-all, I will probably end up purchasing the pro version of Gamemaker in the future for fast prototyping and iterating. Once I use Gamemaker a bit more, I'll post a full review, but here are some things I've noticed that are lacking in it.
1. Organization
This is a primary concern. I wish it would let you see relationships among objects and variables assigned to them, or let you quickly see which objects have what scripts attached to thim.
2. GML
The Gamemaker programming language is a fusion of scripting languages such as Javascript and C++. While the syntax is mostly C++, the types and variable system are dynamic. The biggest issue I have with the GML so far is organization.
The GML is a fusion between Javascript and C++. While it does have the concept of objects, there is no way to create object methods or private obj data, or anything like that. Also, there is no way to easily craft polymorphic objects (even though there is a parent-child component that can be used). I wanted to create a gun class, then subclass this for the individual powerups and give it one virtual function: shoot. This would have allowed me to encapsulate all my gun variables in the gun object and also prevent any powerup logic other than swapping out a new gun from being in my ship objects' code. Well, this isn't quite possible. In fact, if you do want to have object methods, you need to use the provided userevents instead and somehow trigger them. I'll have to look into using the parent/child relationships a bit more.
Variables are a bit hectic. First, if you were to assign a variable like this:
This code will actually create a variable named shipSpeed (if it doesn't exist) and attach it to whatever object instance the current script is running on. As far as I can tell, there is no way to see the variables on an object, so if you declare some variable in another script, you will have to remember where you declared it, what it is named, which script it was named in, etc. I kind of like more organization, like being able to see variables on an object or having some method to add variables to an object outside of the scripts so I can keep it organized, then if a variable is referenced in the script that doesn't exist, it throws an error. Anyways, this is kind of like what Javascript does (and I don't like it there either).
To make a variable local to the current execution of the script, use the var keyword. This will create a local variable that will be destroyed once the current script is done executing. And finally, globalvar is used for global variables.
What would make the variable system a bit better? Use this to explicitly say that you are accessing an instance variable. That way I don't accidentally create one by leaving off the var keyword for a variable in a script execution.
The with keyword is a way to switch contextsand allow you to operate on another item's data structures. The problem is it can get confusing if you are just reading somone's code. For example:
The second assignment to x and y is done on the objShip object (or the instance that it finds), whereas the first x and y assignments are done on whatever object instance is executing the script. You can see, this can get a bit confusing if you just want to read the code and you forget that the current block you are in is in some giant with statement. This is a better way to do it:
Also, you can't really define pure programmatic structurs, such as classes or the like. In fact, there isn't even a simple object that encapsulates a point (x, y variables). All functions are essentially C-style in that they operate on one piece of data and return some output.
Built-in variables -- The color coding of built-in variables in the code is nice, but I would like to make sure I'm not accidentally assigning something to a built-in variable which is going to modify some substate of my game (such as the speed variable).
Again, I wish GM was a bit more organized in code structure and variables, and would at least have some GUI allowing my to view objects and their properties, but I guess it's not really too advanced (maybe later versions). Gamemaker does a lot of things well though: 1. Fast prototyping: It automates many of the subsystem routines you would have to manually create, such as effect loading, timestepping, etc. 2. Visual interface: The visual interface is fine for 2D games and I kind of like how easy it is to add rooms and such to correspond to levels. 3. Very very easy scripting and world building manipulation.
Takeaways: Use tools like GameMaker or Unity 2D for quick prototyping. I have been a programmer and have resisted the urge to use these tools because I wanted to do everything myself, but when you are the only programmer in a game team, building everything yourself, no matter how simple some of the things are, is very time consuming. I would rather focus my time on designing and iterating on a game design to show the other developer instead of focusing on hours programming boilerplate code without anything to show for it. Again, use tools like GameMaker for quick prototyping, even if you don't want to use them in the end.
Wednesday, April 2, 2014
Week 4: Preview
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.
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.
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)