Hex: Summer 2010
During the school year one of my friends from
Game Creation Society and I started talking about our summer plans and decided that
we would make a game together over the summer. My friend had a few ideas floating around, so
before the semester ended we sat down and discussed his ideas to try to figure out which one
would be both feasible and fun for us to work on over the summer. We eventually decided on a
puzzle game which is based around tile manipulation on a hexagonal grid. The project is not
yet finished, but we now have a stable version up and running that includes all of the minimum
requirements we wanted from the start of the project.
Thoughts
One of the most important things I learned from this project was the power of black boxing components of
the engine. I had just finished reading much of
Game Coding Complete by Mike McShaffrey et al. when I started working, and I was trying
to implement some of what I had learned in my new game. One big part of this was isolating
components of the engine from the game logic. I ended up creating two completely separate systems,
one for game logic and one for the systems which required the hardware, like rendering and sound.
About a month into development, once I had a good chunk of the engine done and was working on the logic, I ran into a few issues with the rendering engine. I was originally using Direct2D, but was running into some issues with its capabilities. I also greatly disliked how much code was required for what should have been some simple operations. Eventually, I decided to switch over to using SLD as my main rendering engine. Within a few hours, I had not only switched over my entire rendering engine, I had also implemented multiple new features that I had not yet implemented using Direct2D because of the time it would have required. A large part of why this switch was so fast was because my game logic couldn't see what was happening inside the rendering code, and thus as long as I made new functions that matched the same interface, everything just worked.
One other interesting experience I had on this project was working for a designer. My first priority was getting the game running and in a playable state. A few weeks in, once I had reached this point, I wanted to move onto programming all the bells and whistles I had left handles for, like say the option to change resolutions and toggle other various options. However, my friend, who knows very little about coding, wanted to design the levels for us, and kept requesting features so that he could work more easily or efficiently. Thus, once I finished getting the engine playable, I spent my time trying to implement the features he kept requesting instead of the ones on my todo list. This resulted in us having a fairly good level editor and a few extra gameplay features that were lower on my list, but the options and credits screens still are non-existent.
Having someone waiting for the various features like this was a very different experience for me, but I actually enjoyed working for someone else like this. Having someone who did not necessarily know how to program requesting features resulted in multiple interesting discussions on the importance and feasibility of different ideas. This process also resulted in me attacking the most important item on the todo list first instead of the most interesting to implement, and also forced me to tackle some programming issues which I had not originally thought I would need to face, providing lots of interesting new challenges I would not have faced on my own.
While Hex is now in a perfectly playable state, neither of us feels the project is done. We still need lots of art for the project, at least for the main menu. We also have a sound engine but no sounds for it to play, and a puzzle mode with no puzzle levels. There are also multiple lose ends in the game, like the options screen and the fact that neither gameplay mode currently has a state that the game recognizes as an end state. We both plan to continue work on the project, but since we both are now in the middle of busy school semesters, the project may have to wait for a bit.
About a month into development, once I had a good chunk of the engine done and was working on the logic, I ran into a few issues with the rendering engine. I was originally using Direct2D, but was running into some issues with its capabilities. I also greatly disliked how much code was required for what should have been some simple operations. Eventually, I decided to switch over to using SLD as my main rendering engine. Within a few hours, I had not only switched over my entire rendering engine, I had also implemented multiple new features that I had not yet implemented using Direct2D because of the time it would have required. A large part of why this switch was so fast was because my game logic couldn't see what was happening inside the rendering code, and thus as long as I made new functions that matched the same interface, everything just worked.
One other interesting experience I had on this project was working for a designer. My first priority was getting the game running and in a playable state. A few weeks in, once I had reached this point, I wanted to move onto programming all the bells and whistles I had left handles for, like say the option to change resolutions and toggle other various options. However, my friend, who knows very little about coding, wanted to design the levels for us, and kept requesting features so that he could work more easily or efficiently. Thus, once I finished getting the engine playable, I spent my time trying to implement the features he kept requesting instead of the ones on my todo list. This resulted in us having a fairly good level editor and a few extra gameplay features that were lower on my list, but the options and credits screens still are non-existent.
Having someone waiting for the various features like this was a very different experience for me, but I actually enjoyed working for someone else like this. Having someone who did not necessarily know how to program requesting features resulted in multiple interesting discussions on the importance and feasibility of different ideas. This process also resulted in me attacking the most important item on the todo list first instead of the most interesting to implement, and also forced me to tackle some programming issues which I had not originally thought I would need to face, providing lots of interesting new challenges I would not have faced on my own.
While Hex is now in a perfectly playable state, neither of us feels the project is done. We still need lots of art for the project, at least for the main menu. We also have a sound engine but no sounds for it to play, and a puzzle mode with no puzzle levels. There are also multiple lose ends in the game, like the options screen and the fact that neither gameplay mode currently has a state that the game recognizes as an end state. We both plan to continue work on the project, but since we both are now in the middle of busy school semesters, the project may have to wait for a bit.
Language
C++
Requirements
Windows XP with service pack 3, Windows Vista, or Windows 7
Downloads
Credits
| Andrew Friedland | Programmer |
| Connor Fallon | Designer |