tag:blogger.com,1999:blog-18982700874258010342024-03-13T02:09:25.671-07:00The WandererThe journey of a young Computer Science student as he goes from rags to riches or something. Follow our hero Bender as he sets out to design and program his first video game project which he has so lovingly titled "The Wanderer".Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-1898270087425801034.post-7606776592885501732015-02-17T13:19:00.001-08:002015-02-17T13:22:45.134-08:00Release!... Sort of.<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.automatedbusinesslogic.com/_/rsrc/1314368587982/Getting-Started/downloads/release-summary/Bird%20release%20big%20copy%20575.jpeg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://www.automatedbusinesslogic.com/_/rsrc/1314368587982/Getting-Started/downloads/release-summary/Bird%20release%20big%20copy%20575.jpeg" height="266" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Be free my child!</td></tr>
</tbody></table>
It's been nearly two years since I last contributed to this blog. Two years! My oh my, how things have changed. I can't say I've given this pet project the attention I wish I could. I still love this game the way I did on day one and there are still features I hope to implement. There's a major problem with that plan though. In the last two years I've formally learned many interesting and useful new skills.<br />
<br />
(Un)fortunately I learned software architecture.<br />
<br />
<a name='more'></a><br />
Holy crap is the architecture behind <i>The Wanderer</i> bad. There are certain good practices I manged to stumble into by accident. I managed to reinvent the observer and factory programming patterns by pure intuition, I can't say I'm not proud of that feat. The rest of it? Yikes! Discovering modularization has ruined me!<br />
<br />
<br />
Unfortunately like a two week old curry, I just can't stomach the structure of my source code. I still tinker he and there and maybe someday I'll wade through the gooey core and implement some new features and fixes however I'm tempted to simply start over.<br />
<br />
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBnXSPkUFWFteY5BKlWqwAV_opyoMttB9R9IbjC1N6QfCLV380-GZBxj__ctVFCMj711z4IgHGyldiSwXur-WSZrg6SD8EqnYS4_ZeuYQiChXfdujaC5RrUSoNnN8e8vB1tWMxUFothRtK/s1600/Wandererbanner.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBnXSPkUFWFteY5BKlWqwAV_opyoMttB9R9IbjC1N6QfCLV380-GZBxj__ctVFCMj711z4IgHGyldiSwXur-WSZrg6SD8EqnYS4_ZeuYQiChXfdujaC5RrUSoNnN8e8vB1tWMxUFothRtK/s1600/Wandererbanner.png" height="120" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Pretty spiffy banner in my opinion</td></tr>
</tbody></table>
So what happens now? Well, recently web retailer itch.io put out the
call for developers to submit their unfinished projects to be hosted on
the site. It might not have a menu, it might not run well, it might be
missing sounds and features but it's now up there and you can play it.<br />
<br />
Click <a href="http://itch.io/jam/unfinishedweek/rate/19148">Here</a> and follow the instructions to download the game.<br />
<br />
<br />
I think I'll come back to this blog. I have a history here after all. I really enjoy writing about making games and I still make games. The Wanderer is the closest I've come to release but I'm hoping to change that. Maybe stay tuned?Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com0tag:blogger.com,1999:blog-1898270087425801034.post-41978759831189552232013-08-14T13:23:00.000-07:002013-08-14T13:24:38.437-07:00Mobius Blog<div class="separator" style="clear: both; text-align: center;">
<a href="http://ayoungscientist.com/wp-content/uploads/2010/06/Mobius-Strip.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://ayoungscientist.com/wp-content/uploads/2010/06/Mobius-Strip.jpg" /></a></div>
<br />
<br />
It's been a while. A long while. First off, the good news: I plan on continuing regular updates. Not yet, but soon.<br />
<br />
As for my explanation? I want you all to know that although I said I would update my story, this bump in the continuum is not my fault. Too bad it is.<br />
<br />
<a name='more'></a><h1>
What The Dealio Is</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6LnNIgCKZhS2QotJlSlP8fOYBHnVM5e1YdEuWPUbN8cPwXx7U3DzCWBySHi4W4JeMWtxSJjU2QJVGnLPYeDTOqDQ2ngZ1CW1_tPslIC6nplPL-aDmpyIKZ41wkHxIWzpFKyyKFx6nEqM/s1600/whats+the+deal.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6LnNIgCKZhS2QotJlSlP8fOYBHnVM5e1YdEuWPUbN8cPwXx7U3DzCWBySHi4W4JeMWtxSJjU2QJVGnLPYeDTOqDQ2ngZ1CW1_tPslIC6nplPL-aDmpyIKZ41wkHxIWzpFKyyKFx6nEqM/s1600/whats+the+deal.jpg" /></a></div>
<br />
There are two main reasons for my previous and continuing inactivity. The truth is that it's difficult to find motivation to work on your own when you work at a desk for eight hours a day. This is my biggest flaw. This past summer I've been employed at a company that has me programming or otherwise using a computer for most of the working week. I love making The Wanderer, but it's not the most relaxing of activities. It's actually fairly frustrating. At times at least.<br />
<br />
That's the reason I have not been updating.<br />
<br />
Why will my absence continue? Well, this one is actually out of my hands. My development (and personal) computer is currently having hardware issues diagnosed at my local computer shop. When will it be back in service? Good question. One I'd like to answer with another question:<br />
<br />
When will my computer be back in service?<br />
<br />
I'm glad we're on the same page.<br />
<br />
<h1>
I'll Be Back</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.blastr.com/sites/blastr/files/styles/blog_post_media/public/images/arnoldterminator.jpg?itok=5IyrJgGG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="192" src="http://www.blastr.com/sites/blastr/files/styles/blog_post_media/public/images/arnoldterminator.jpg?itok=5IyrJgGG" width="320" /></a></div>
<br />
I already have some plans for new articles, not just about Wanderer. Maybe I'll start a second project from which I can learn different lessons. I mean, I don't learn much about level design from a procedural generated world. That's also an area I'm very interested in, so don't be surprised if something pops up on some topics that aren't necessarily about C++ game development.<br />
<br />
One things for certain, It's been a while. A long while.
Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com0tag:blogger.com,1999:blog-1898270087425801034.post-47751268692140718252013-06-03T22:53:00.003-07:002013-08-14T13:24:12.657-07:00The Common (Re-)Factor<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://openclipart.org/people/bogdanco/2011-02-14_Red_Green_Refactor_.svg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="236" src="http://openclipart.org/people/bogdanco/2011-02-14_Red_Green_Refactor_.svg" width="320" /></a></div>
<br />
Have I submitted to this blog before? It must have been some forgotten time because the sense of familiarity is but fleeting.<br />
<div>
<br /></div>
<div>
I kid.</div>
<div>
<br /></div>
<div>
In one of my earlier posts, I mentioned that a lesson I had learned was to never implement flexibility for the sake of being flexible. In retrospect, I would like to modify that statement. Flexibility for the sake of flexibility still bogs down the development process with needless problem solving but flexibility for the sake of impending future addition is still important. A lesson that is becoming all to clear as I revise not only my wisdom but my code as well.</div>
<div>
<br />
<a name='more'></a><br />
<br />
<div>
<h1>
Breadth Over Depth</h1>
</div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGaWfUSqJsj0Pr031HM5I-zMDbHi9GoxBILssMc4PAfhjYWNltG5vaeEkzY_UTrHXkWr6n7feYQmlmbbbhy4RQBB4CwkTSj9r31576wKcXq4ElTDraALc0c14ax4xkUEqd5J1_-B2ZVw/s1600/deepWater1.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGaWfUSqJsj0Pr031HM5I-zMDbHi9GoxBILssMc4PAfhjYWNltG5vaeEkzY_UTrHXkWr6n7feYQmlmbbbhy4RQBB4CwkTSj9r31576wKcXq4ElTDraALc0c14ax4xkUEqd5J1_-B2ZVw/s320/deepWater1.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">This is a poorly planned metaphor.</td></tr>
</tbody></table>
</div>
<div>
While writing The Wanderer over the last month, my first task was to get as much of my code functional as possible. I wanted to have something to show off and be proud of but alas my arrogance was my folly.</div>
<div>
<br /></div>
<div>
By ignoring the need to account for future features in my code, I quickly found my code messy, improvised and incredibly rigidly structured. In order to get the basic game elements out quickly, I sacrificed future development. Hey, didn't I mention previously that was something I wanted to avoid?</div>
<div>
<br /></div>
<div>
The past couple weeks, while containing the introduction of new features, included a whole lot of refactoring. Refactoring? [Refactoring is] The process of modifying existing code to improve efficiency, functionality or simply for sport. It's an important process and a common one. Unfortunately, more common for me than I'd like.<br />
<br />
A great example of this is my map generation algorithm.<br />
<br />
Originally, all my map generation did was place blocks in vaguely building-like shapes in order to generate vaguely town-like maps. Although still fairly abstract in it's resemblance to real world architecture, the current algorithm accounts for item placement, trader placement, stair placement (Oh yeah, I added dungeons.) and a multitude of other factors.<br />
<br />
Although it doesn't seem like much, when you don't build your code originally to account for the introduction of new features, you end up redesigning large portions to make it all fit together. Adding tilesets into the game meant that I needed to generate new ground textures. This led me to needing to store the textures. I did this by placing them in the same grid used by the wall blocks. This led to me needing to redesign the movement system. This led to me needing to redesign the ghoul ai.<br />
<br />
See where I'm going with this?<br />
<br />
<h1>
My Second Rodeo</h1>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcS4FW-_80Y6jKMa7Y9KOsiNY42Yh6Hu7-orl6ttzXf8XklP2UuC4Q" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcS4FW-_80Y6jKMa7Y9KOsiNY42Yh6Hu7-orl6ttzXf8XklP2UuC4Q" /></a></div>
<br />
<br />
What should I do next time? I wouldn't advocate building each part of the game to 100% completion at once. That's a fantastic way to get burnt out. One of the biggest successes of this project was to instead break the game down into small tasks that were easy to complete. It allowed me a sense of progress which helped keep me on task and motivated.<br />
<br />
Next time I think I need to plan out my systems better. Plan them out with future features in mind. Features I know I'm going to add. Like I said in one of my first posts, I won't focus on making things work that I will never need to use nor account for but planning for impending expansion is a necessity of good code. Plan systems that work now but will also work without too much grief.<br />
<br />
One of the easiest methods to achieve this is organizing and segmenting code cleanly. Organize functions properly into functions. Use helper functions. Find anyways to make your code more flexible without actually changing the system. This helps a great deal when modifying it later and modify it later you will.<br />
<br />
<h1>
Get to it.</h1>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.nvtc.ee/e-oppe/Marina/joogid/Beer.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="320" src="http://www.nvtc.ee/e-oppe/Marina/joogid/Beer.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The reason this post is gradually getting less coherent.</td></tr>
</tbody></table>
<br /></div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
</div>
<div>
Just keep your code cleanly organized and you'll be okay. Keeping your code as modular as possible with your functions and classes helps a great deal too. It's far easier to modify one feature than a dozen interlocking features.</div>
<div>
<br /></div>
<div>
All in all, the big takeaway is to build your code with the understanding that even when it works, it won't be finished. Even when you release your game, it won't be finished. You should always act as if you will need to modify a piece of code later. If you keep that in mind, your refactoring will go a hell of a lot smoother than mine.</div>
Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com0tag:blogger.com,1999:blog-1898270087425801034.post-79415767041014650932013-05-17T09:39:00.000-07:002013-05-17T16:41:41.625-07:00The Solution To All Your Problems<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.behavioradvisor.com/sbPuzzled.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="295" src="http://www.behavioradvisor.com/sbPuzzled.jpg" width="320" /></a></div>
<br />
<br />
Modern video games are easier than their retro counter parts. The Brainy Gamer posted an <a href="http://www.brainygamer.com/the_brainy_gamer/2010/09/unplayable.html">article </a>some time ago on the topic of problem solving in modern versus classic video games. He concluded that games today coddle and instruct far more than the games he grew up on, showcased by a modern generations inability to use their intuition to solve certain aspects of the game. Now, I don't want to drop the player into my game with no instruction, no understanding and expect them to have fun, but in a game about survival, exploration, and discovery, I want to leave some features a surprise.<br />
<br />
<a name='more'></a><h1>
Building Solutions</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://img.ehowcdn.com/article-new/ehow/images/a07/8u/5h/mount-jigsaw-puzzles-800x800.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="http://img.ehowcdn.com/article-new/ehow/images/a07/8u/5h/mount-jigsaw-puzzles-800x800.jpg" width="320" /></a></div>
<div>
<br /></div>
At the risk of this becoming a theme in my writing, <a href="http://www.bay12games.com/dwarves/">Dwarf Fortress</a> takes this approach to the extreme. Tarn Adams drops you into a complex world with complex rules and expects you to figure the game out by yourself using the manual. Although an incredibly frustrating experience, once you learn how to carve out a plot in the side of a mountain, the fruits of your frustration will bear.<br />
<br />
This isn't quite the approach I want to take with The Wanderer. By the nature of the game, Wanderer is far more intuitive than Dwarf Fortress. The WASD key movement and mouse aiming abides by the standard set by decades of game development and innovation. In contrast, there has been decidedly less innovation in the genre of "dwarf colony simulator".<br />
<br />
No, I want to leave certain aspects of the game world a surprise, not the basic rules of game flow. A more appropriate example from Dwarf Fortress would be the ability to construct complex mechanisms and how to apply this to other game mechanics such as agriculture.<br />
<br />
When I first started playing the game, I quickly realised that farming would be a necessary task in order to sustain a thriving, healthy (Ha!) fortress. I had a problem, the crops I wanted to grow in my farm plot could only be grown under ground, where it doesn't rain. In order to irrigate my crops, I needed to channel a pond into my underground plantation without drowning the crops. I did this by constructing levers and applying their function to opening and closing doors in order to allow and halt the flow of water.<br />
<br />
This example showcases the sort of application of abstract game mechanics to practical problems I want to encourage in the Wanderer.<br />
<br />
<h1>
Predicting Risks</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifKKM_ih6BEBQ7D5J29ndywvnUgsp6AvYHKpW0JRlP6oEqo79diYZRE2AwITqfa4DPQ7DIz2uvXB5Wyebe09k8QkMBl1CbHbVdaNK9-v-M0NhIrjEHuB6mGQSHrux7hEAl1xRfP8xIBKLg/s1600/found-puzzle-5-675x506.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="239" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifKKM_ih6BEBQ7D5J29ndywvnUgsp6AvYHKpW0JRlP6oEqo79diYZRE2AwITqfa4DPQ7DIz2uvXB5Wyebe09k8QkMBl1CbHbVdaNK9-v-M0NhIrjEHuB6mGQSHrux7hEAl1xRfP8xIBKLg/s320/found-puzzle-5-675x506.jpg" width="320" /></a></div>
<div>
<br /></div>
A second problem I encountered with my irrigation system was drainage. I channeled a tunnel out of the side of the mountain in order for excess water to be expelled. I figured that this was a genius solution and soon my fortress was producing cave mushroom meals, liquor and goods. Cave mushrooms might as well have been subsidized.<br />
<br />
Unfortunately, my problem solving skills did not account for the risks of an ambitious farming project. My fortress was laid siege to by a vast army of goblins. I felt safe in my impenetrable fortress filled with traps, mazes and a capable military. Well, impenetrable except for one irrigation tunnel.<br />
<br />
This is an example of how game mechanics are not explained but follow intuitive thinking. Of course creating an exit from my fortress also created a second entrance. Of course I put myself at risk by not weighing the risks. The game wasn't at fault for improperly preparing me for this issue, I had only myself to blame.<br />
<br />
Perhaps with The Wanderer, shooting a trader will allow free access to far more powerful weapons. Maybe trying to sell this new, powerful weapon at another trader will alert them to your crime. I want the player to learn this mistake for himself instead of needing to walk the player through each possible outcome of their actions. Consequences should follow logically from actions.<br />
<br />
<h1>
Logical Flow</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.thebeattieblog.com/wp-content/uploads/2013/02/2-puzzle.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://www.thebeattieblog.com/wp-content/uploads/2013/02/2-puzzle.jpg" width="216" /></a></div>
<div>
<br /></div>
Another example of consistent game logic can be found in Fallout: A Post Nuclear Role Playing Game. One can prime explosives and set timed delays for their detonation. This leads to the conclusion that the timer carries over when the explosive is dropped from inventory onto the ground. Once the item is dropped and the delay expires, the explosive detonates. An unrelated game feature includes pick pocketing Non playable characters. Once you discover that you can take items from other characters you realise that you can place items in their inventories as well. These two conclusions lead to a third conclusion, if you place a primed explosive in a non playable character's inventory, they will explode (With a brief instant of shock, surprise and an understanding that "you got them good this time.")<br />
<br />
Never is this taught in the game tutorial, manual or suggested during game play. This is a game mechanic entirely discovered through intuition, problem solving and logical conclusions.<br />
<br />
I want the same logic to carry over to The Wanderer. Perhaps instead of being caught when selling the fallen Trader's weapon, you can instead give it to a second trader to equip. Once equipped, the other, non playable characters believe this second trader is the real culprit of the murder. This would be the logical conclusion of the trading and murder game mechanics (Assuming the second trader knows how to keep his damn mouth shut!)<br />
<br />
<h1>
The Yang</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.usask.ca/wcvm/herdmed/specialstock/images/yingyang.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://www.usask.ca/wcvm/herdmed/specialstock/images/yingyang.gif" width="320" /></a></div>
<div>
<br /></div>
The most important aspect of this mechanic design is keeping conclusions logical. There are numerous adventure game puzzles featuring the combination of cat hair with a nail file and a comb to make a lock pick and equally absurd logic.<br />
<br />
These puzzles need to be intuitive. The player has to be able to come to these conclusions by themselves without any explicit instructions. Not every player needs to be able to discover this feature but every player needs to be able to accept it as a realistic ability in the game world.<br />
<br />
If the player is shaking their head or their neighbours can make out the expletives shouted violently after discovering your game mechanic, you've done something wrong.<br />
<br />
<h1>
Golly Gee Williger</h1>
Game mechanics like the ones described above have lead to the most interesting discoveries in my experience with games. Discovering new ways to exploit the game universe is an interesting way to add depth to the game but keeping things realistic and logical can be difficult.<br />
<br />
These are the experiences I want to create and hopefully it will help make The Wanderer a unique and entertaining journey.<br />
<!--more-->Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com0tag:blogger.com,1999:blog-1898270087425801034.post-60838301308697915072013-05-12T13:55:00.000-07:002013-05-12T22:11:20.690-07:00Hanging the Floor<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.zontikgames.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/b/a/backgammon-precision-dice-dark-red_primary.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="197" src="http://www.zontikgames.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/b/a/backgammon-precision-dice-dark-red_primary.jpg" width="320" /></a></div>
<br />
One of my favourite games and big inspirations for this project is a game by Tarn Adams called <a href="http://www.bay12games.com/dwarves/">Dwarf Fortress</a>. The game includes procedurally generated worlds that are so detailed and rich that there's a game mode specifically dedicated to reading through the historical events of the kingdoms. This is the game that enlightened me to procedural generation (from here on called PG) which has quickly become one of my favourite aspects of game design and programming.<br />
<br />
How much do I like it?<br />
<br />
I used a random title generator for this entry.<br />
<br />
<br />
<a name='more'></a><h1>
A Grand Design</h1>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://theyandoitproject.files.wordpress.com/2011/10/canvas.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://theyandoitproject.files.wordpress.com/2011/10/canvas.jpg" width="284" /></a></div>
<br />
In a game like Wanderer, exploration is key to the premise. Procedural generation allows the player to explore a new world each time they play the game which is obviously integral to a game about exploration and survival. This is the primary strength of PG, it keeps things fresh and, in the appropriate genre, is almost required.<br />
<br />
Procedurally generated worlds have drawbacks though. It's impossible to reach the level of intimacy that a handcraft world possesses. The landscapes of the Half-Life franchise wouldn't be nearly as memorable if designed by a computer. On the contrary, Half-Life 2's big strengths were it's memorable set pieces and attention to detail. No algorithm could possibly recreate Half-Life's Ravenholm.<br />
<br />
In regard to The Wanderer, I plan to and already use PG for certain aspects of the game. I don't think I'll ever manage the level of detail exhibited in Dwarf Fortress but I don't think I'll ever be a playboy billionaire either. I keep my expectations grounded.<br />
<br />
<h1>
The Here And Now</h1>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://thefalloutgirl.files.wordpress.com/2011/10/escher-big.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="297" src="http://thefalloutgirl.files.wordpress.com/2011/10/escher-big.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Pictured: A screen shot from The Wanderer.</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
Right now, I use PG to generate the game spaces available for the player to explore. I do this by splitting each map into a grid of 8x8 blocks. Each space in the block is a 16x16 pixel spaces. Each block then checks if there should be a building in that position or if it should be blank. Once the generating function decides there should be a building, the game fills in the 64 spaces appropriately.<br />
<br />
Each space has a different probability of being taken by a wall. For example, spaces next to filled spaces have a higher chance of being filled and edge spaces have the highest chance of being filled. This is done to give each building a more distinct man-made (irony...) shape while still creating a damaged, post-apocalyptic level.<br />
<br />
While filling in the building with walls, empty spaces can be filled with ghouls and caches of food and ammunition. This is the final step in generating a building. Once this is completed the generator moves on to the next block.<br />
<br />
When transitioning between levels, the maps have to be stored in the game folder so that the player can return to areas already explored. This is done by storing the grid information in a ".wap" file (a portmanteu of "Wanderer" and "map". I'm super creative.) The title of each .wap file is a designation used to keep track of that level's position on the meta-map. "0_0.wap" indicates the starting space while "-999999_0.wap" indicates the map generated if the player is masochistic. The game keeps track of the player's position on the meta-map to save and load files appropriately.<br />
<br />
All of the above processes unite in the elegant (yeah right) system currently in place to generate Wanderer's game world. The game world size as it stands is only limited by the hard drive space of the user. Beat that, Skyrim!<br />
<br />
<h1>
Into the future</h1>
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.bowmanvilleveterinaryclinic.com/sites/site-4003/slides/Mick%20looking%20down%20microscope.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="212" src="http://www.bowmanvilleveterinaryclinic.com/sites/site-4003/slides/Mick%20looking%20down%20microscope.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><br /></td></tr>
</tbody></table>
<br />
In the future, I plan on using random numbers for far more than simply map generation. The next step is to add an inventory and weapons system to the game and I can assure you that I'm not going to design any of the weapons personally. Beyond that, survivor camps, different structures, enemies and beyond all look attractive to my hunger for surprises (Maybe I should just design a random game generator?)<br />
<br />
Inventory is definitely the next step in adding depth to the game. Right now, playing Wanderer feels very shallow. Not totally unexpected of a game developed in a week and a half but something I definitely want to fix. Whether people play this game or not, I want it to be a game someone would want to play. <br />
<br />
Overall, procedural generation is going to be one of the fundamental features of The Wanderer. It's going to allow the player to explore new spaces and experiences in order to keep the game fresh each play through. The PG currently featured in The Wanderer isn't exactly as sophisticated as it gets but it works and can be expanded upon in the future.<br />
<br />
<h1>
On Frequency</h1>
<br />
After my initial torrent of blog posts I've slowed down my contributions quite a bit. That's probably a trend that is going to continue. I don't want to force these posts which means I only contribute when something has inspired me to write. This post was inspired by finishing the map saver and loader.<br />
<br />
What I'm trying to say is, if I ever get tired of this I'll make sure it's known.<br />
<br />
<h1>
One Last Note</h1>
<br />
You know, the more I think about it, the more fitting the generated title seems. Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com1tag:blogger.com,1999:blog-1898270087425801034.post-91261227230228476552013-05-09T12:38:00.001-07:002013-05-09T13:16:01.624-07:00If it looks stupid and it works...<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://topfunnythings.com/images/uploads/1352872276duct_tape_wont_fix_it_03.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://topfunnythings.com/images/uploads/1352872276duct_tape_wont_fix_it_03.jpg" width="250" /></a></div>
<br />
It doesn't seem to matter how much planning I do, I always end up needing to improvise at some point. When I started this project I promised myself a few things, one of which was that I would have very neat, organized, readable code with a very rigid design. Well, it's less than a week in and I'm already breaking promises.<br />
<br />
<a name='more'></a><br />
While I was building my collision detection for the zombie objects. I realized a couple things:<br />
<br />
1. My Controller class was referencing my Zombie class a whole lot.<br />
<br />
2. In order to make use of the same collision detection I was using for my player, my Zombie class was going to need to reference my Controller class.<br />
<br />
Crap.<br />
<br />
Unfortunately, this isn't really good design. It's called <a href="http://en.wikipedia.org/wiki/Circular_reference#In_computer_programming">circular referencing</a> and is the result of poor planning. The problem I had was that C++ only allows the code to reference other parts of the code that have already been declared. That means that if I declare class a before class b, then I can only reference class a from b, not vice versa. I searched message boards for hours in order to make this work. I found what I thought was a solution in <a href="http://www.learncpp.com/cpp-tutorial/17-forward-declarations/">forward declaration</a>.<br />
<br />
The idea behind forward declaration is that the code can reference what is essentially a hollow declaration of a class at the very beginning so that it can later be called to at any point. It's sort of like giving out a fake phone number at a bar. The guy can tell all his friends he has your number without technically lying, but he probably won't ever be able to talk to you (Sandra).<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://ak9.picdn.net/shutterstock/videos/1638973/preview/stock-footage-happy-and-joyful-young-man-wearing-a-grey-jumper-is-laughing-whilst-using-mobile-phone-isolated-on.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="179" src="http://ak9.picdn.net/shutterstock/videos/1638973/preview/stock-footage-happy-and-joyful-young-man-wearing-a-grey-jumper-is-laughing-whilst-using-mobile-phone-isolated-on.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Pictured: Not me.</td></tr>
</tbody></table>
<br />
This has a couple restrictions.<br />
<br />
The first restriction is that you can only initialize a pointer to a class that you've forward declared. If you don't know what a pointer is, it's basically directions to what you want. Instead of storing "Bender's House." you're storing "Turn left of main street."<br />
<br />
The second restriction is you can only pass the Class objects that you've forward declared by reference. This is a little more complex to explain. When you call a function, it has something called scope. Scope is basically the part of the code that the function can manipulate. Think of the function like a king. A king's scope is his kingdom. When you call to a function and give it a variable or class to work with ("pass" a variable) you are taking something outside it's scope and creating a copy of it inside it's scope. That means that if you modify the variable passed in the function it has no effect on the variable outside a function. One way to get around that is to pass the variable by reference. This basically means any changes made to a variable passed into the function are permanent.<br />
<br />
The third restriction is that you can't actually manipulate a class you've forward declared. You can only make reference to it. The last three paragraphs were basically a very roundabout way of saying that this third restriction sunk me. That was kind of unnecessary eh? But hey, you learned something I bet so 'sall good.<br />
<br />
For the first time, I had to break my first promise. I ended up coding the zombie movement entirely in one function. When a target location was passed into the "move" function, it does all direction calculation, speed calculation and collision detection. (Boo!)<br />
<br />
Luckily it sort of works. Zombies don't go through walls anymore! (Yay!)<br />
<br />
Just like I said about two week before the dog show, I'll probably get it fixed and make it prettier. For now though? I'm just happy it works.<br />
<br />
<br />
<h1>
Another thing I did </h1>
<br />
is get a basic line of site system working. You can only see zombie that you have a clear line of vision too. Or sometimes you don't. I don't know, there are still some bugs. I'm pretty proud of it though. You can see it (and the bugs I'm talking about around frame 4-ish) below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/VajShXB.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="http://i.imgur.com/VajShXB.gif" width="320" /></a></div>
<br />
The way it works is very similar to zombie movement in general. It turns the distance between the player and the zombie into a triangle where the x and y differences are the edges. It then adds certain ratios to x and y so that x + y = 1, the idea being that it moves along the hypotenuse of the triangle. If it detects a wall at any step, it decides that the player can't see the zombie. It's Pretty simple and kind of buggy but it's serviceable. If I need to do an overhaul then I'll do it further along into development.<br />
<br />
Oh yeah, I also added some basic graphics to make the game look fancier. <br />
<br />
Actually, it's changed a lot since my last screenshots.<br />
<br />Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com2tag:blogger.com,1999:blog-1898270087425801034.post-5406916788411359432013-05-07T13:32:00.002-07:002013-05-07T13:55:49.819-07:00The Nitty Gritty<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://rookery.s3.amazonaws.com/714000/714195_cbc8_625x1000.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="183" src="http://rookery.s3.amazonaws.com/714000/714195_cbc8_625x1000.jpg" width="320" /></a></div>
<br />
I realize that I may have skipped some valuable explanation with my last post. Here I am blabbering on about my performance issues like a senior at his annual checkup and you have no idea how my code works! If you're going to read these articles then understanding the architecture of my code is going to be important. Luckily for you, I'm here to set things straight.<br />
<br />
<a name='more'></a><br />
<h1>
The Initialization</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://designwebkit.com/wp-content/uploads/2011/11/1-Project-Initialization1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="http://designwebkit.com/wp-content/uploads/2011/11/1-Project-Initialization1.jpg" width="320" /></a></div>
<br />
These are the first lines of code that are executed in the game. This comes before the game loop and any other process. Here I load files from my computer in order to make the game work and set up variables that I may need to use later on. For example, the clock I use for my FPS counter is initialized in this step.<br />
<br />
<h1>
The Game Loop</h1>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://knitfreedom.com/wp-content/uploads/2010/10/loopy-plane.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="250" src="http://knitfreedom.com/wp-content/uploads/2010/10/loopy-plane.gif" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Maybe I'm too literal.</td></tr>
</tbody></table>
<br />
Here's where the fun part starts. Unless you find loading fonts fun and assuming "Wanderer" resembles something enjoyable in it's finished product.<br />
<br />
This is where the "game" part of the game comes in. This is the point where I register your keystrokes, mouse clicks, etc., use your input to manipulate variables and render images to the screen. This done through a series of classes.<br />
<br />
Quick lesson - If you know what a class is, skip this part. - A class is a collection of variables and functions... wait...<br />
<br />
Okay, quicker lesson - If you know what a function is, skip this part. - functions are very self explanatory. They are grouped lines of code that can be used at any time to do a specific task. Sort of like the chorus of a song. When you need the function called "chorus" you use chorus() and the chorus of the song gets played.<br />
<br />
...Back to classes. A class is a collection of variables and functions that are all associated with each other under a name. The idea is generally that it creates the properties and actions of a specific object in your code. For example, you can have the class "car" which has the function "start_ignition" and the variable "paint_colour" You can create many unique instances of the class which will all have the same variables and functions but will have different values assigned. For example, if I want a red Mazda (sponsors?) I can create the instance of the class referred to as "Mazda" and assign "red" to "Mazda.paint_colour"<br />
<br />
<h1>
The Major Players</h1>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEheuVoMwhJcW7KfGocNdeHMJ-5pJrq531o_OXmrZPrYJ_-7hXyng8BEleCrBkVidW4BIK5JQ6Fy9J56HO6OzEetqEG2oTQfnDDsVkfjAU9b8cCT9D4oHYSFF6R74NK5Ik9J0KdwhUBecv/s1600/afriendinneed.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEheuVoMwhJcW7KfGocNdeHMJ-5pJrq531o_OXmrZPrYJ_-7hXyng8BEleCrBkVidW4BIK5JQ6Fy9J56HO6OzEetqEG2oTQfnDDsVkfjAU9b8cCT9D4oHYSFF6R74NK5Ik9J0KdwhUBecv/s320/afriendinneed.jpg" width="320" /></a></div>
<br />
These are the main classes that are used (as of right now) and how they interact with each other.<br />
<br />
a) The Player class.<br />
<br />
This is the class that contains all of the information for the player. As of right now, that's primarily x and y positions as well as the image (sprite) but in the future the stored information will include health points, hunger, etc. This class contains an "act" function which, when called, checks what the player is doing and changed the variables accordingly. For example, if the player is pressing the "a" key, the act function checks if it's about to collide with a wall (more on this later) and if not, subtracts one from the x coordinate. This moves the player left.<br />
<br />
b) The Block class.<br />
<br />
This is the class that contains all of the information for the wall segments. Mostly just x and y but also the sprite. Maybe more in the future?<br />
<br />
c) The Zombie class (future)<br />
<br />
This contains all of the information for the zombies. It will mostly be similar to the Block class but will also contain brain craving subroutines.<br />
<br />
d) The controller class.<br />
<br />
This class contains all of the game state information. It contains all of the wall positions, player positions, eventually zombie positions. Every time any object wants to interact with any other object, it's going to go through this class.<br />
<br />
When the player class checks for collisions, it sends it's coordinates to the controller class and the controller class checks the position it wants to move to for an obstructing object. If the check returns false, that means there is no object in the way and the Player is free to move. If the check returns true, that means that the Player can not move to where it wanted to.<br />
<br />
In the future, this class will contain all information not directly related to the Player, Zombie, Wall or whatever class. This includes score, and level generation.<br />
<br />
So there you have it. That's the basic architecture of the game as it stands right now. I might do a bit of an update and make this a sort of map to the code.<br />
<br />
My current plans are to get the collision detection working for more than just stationary objects, then add some zombies to be collision detected!Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com3tag:blogger.com,1999:blog-1898270087425801034.post-48738759864558289732013-05-07T01:27:00.000-07:002013-05-07T02:35:31.765-07:00The Funny Thing About Coding...<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i2.ytimg.com/i/uiuU6-RCKmSYyHj9DmRMmg/1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="221" src="http://i2.ytimg.com/i/uiuU6-RCKmSYyHj9DmRMmg/1.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
I've spent the last two days on my project. Being a rookie game developer, I get hung up on what are probably incredibly simple tasks to more experienced veterans. The following is the account of my first major issue with performance (only two days in!)<br />
<br />
<a name='more'></a>Besides the player, Wanderer is going to contain two other types of entities. Those you can interact with (enemies and "chests" for now.) and those you can't (just stationary obstacles like wall sections which will from here-in be referred to as "blocks"). Because everything is a 16x16 block, many aspects of larger maps can be scaled down and stored on smaller grids. For example, current map sizes are going to be approximately 3200x3200 pixels large (subject to change), the grid used to store blocks will only be 200x200 elements large.<br />
<br />
My first big issue had to do with the way I'm storing this data. Each wall section is actually it's own entity with it's own sprite and position. Each of these entities was stored in a linked list. I wanted to store each item in a linked list because I didn't want to set an arbitrary maximum number of entities and linked list can be dynamically sized. The problem came from the fact that each block's position needs to be checked in order to draw it to the screen. This involved n semi-traversals of the linked list per step where n is the size of the linked list.<br />
<br />
If you're a a little bit lost, this basically means that I'm storing the blocks in a never ending address book where each block has an address. The first block has the address 0, the second block has the address 1, the third block has the address 2 and so on until the last block. Unfortunately, each time I wanted to reach block 3 I also had to access block 0, 1, and 2. After accessing block 3, if I wanted to access block 4, I had to go back to the beginning and access block 0, 1, 2, and 3.<br />
<br />
I was foolhardy. I figured "This is 2013, we have powerful computers! I can have 100 blocks in a linked list! So what if we have to traverse a linked list 100 times a step?" Well as it turned out, 100 times a step isn't actually so bad. In fact you can see what 100 blocks looks like at this point in time.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/Pf7o8Wq.png?1" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="269" src="http://i.imgur.com/Pf7o8Wq.png?1" width="480" /></a></div>
<br />
Not too shabby!<br />
<br />
My hard cap of 59.whatever frames per second (FPS) isn't even phased by these puny blocks. However, each game space is supposed to be a 200 x 200 grid or 40,000 total spaces. What are the chances I'm only going to use 100 of those bad boys? Let's kick it up a notch to 3,600 blocks which is a little less than 10% of the available grid spaces.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/vfiVbQ0.png?1" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="269" src="http://i.imgur.com/vfiVbQ0.png?1" width="480" /></a></div>
<br />
Yikes!<br />
<br />
Not the sort of FPS I was hoping for. The problem came from how many traversals the game was doing each time it rendered the scene and by extension how many times it was accessing each block (accessions?). I'm not a mathematician but I estimate that each step of the game loop, Wanderer was doing (give or take a few ) approximately around exactly 3600! accessions.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://i.imgur.com/r0Uje2J.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="269" src="http://i.imgur.com/r0Uje2J.png" width="480" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Uh oh.</td></tr>
</tbody></table>
In layman's terms, every time I wanted to draw the scene to the screen (approximately 60 times per second) the game needed to make 3600! comparisons to determine the locations of 3600 blocks. <br />
<br />
This was not okay. I was stubborn however. I had spent nearly two days wrestling with pointers to get my current system to work, an area in which I am not yet an expert.<br />
<br />
I began brainstorming solutions, from storing blocks in separate linked lists to simply accepting my fate and making The. Slowest. Game. Ever.<br />
<br />
Fortunately, the solution came quickly. I began to reason: "If the maximum game space is 40,000 grid spaces, then why shouldn't I have a cap on the number of blocks in the game space at any one time?" From this stance I quickly surmised that an array of blocks would suit my purposes nicely.<br />
<br />
Now, since arrays are statically sized (you give them a size which can not change) in order to get everything working exactly right I had to create a class called "block array" which has functions for adding blocks to the first unused element, getting the size of the used space, etc.<br />
<br />
Now, if you're once again lost what I'm doing now is subbing out my never ending, inefficient address book for a far more efficient far more believable address book that, while containing a specified beginning and end, does not require me to access every address successively. If I want to access block 7, I do not have to run past blocks 1-6 first.<br />
<br />
You can see how much better this works.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/gaXDECI.png?1" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="269" src="http://i.imgur.com/gaXDECI.png?1" width="480" /></a></div>
<br />
That's a far more pleasing sight...<br />
<br />
...but I crave more!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/ymAW3zN.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="269" src="http://i.imgur.com/ymAW3zN.png" width="480" /></a></div>
<br />
<br />
MORE!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/FuN4bos.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="269" src="http://i.imgur.com/FuN4bos.png" width="480" /></a></div>
<br />
In conclusion, there are two lessons to be taken from this:<br />
<br />
1. Screw flexibility for flexibility's sake, just do things the simple way the first time if you have no real reason otherwise.<br />
<br />
2. As soon as days and days of frustration and tooth grinding have culminated in a functioning solution held together with (proverbial) duct tape, glue sticks and sheer power of will, you WILL think of a simpler, easier method. (Has this law been taken already? If not, I dub it "Bender's law". If so I didn't want it anyways.)<br />
<br />
Hopefully I can get the collision detection and enemies up and running soon so that I can have something a little more impressive to excitedly show my parents.Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com4tag:blogger.com,1999:blog-1898270087425801034.post-28149556393479157932013-05-04T20:25:00.000-07:002013-05-07T02:32:18.200-07:00Introduction and/or Prologue<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjl_673y7txuK5Ob2uVkpA0d4y1aCYct5qwX-IYU9qoizY5CLG-PrSgUwbzTYj4P-S2WkcUG1pk7dnvJ_boCjVdtEwLI4lLM-FPMN9dSeEfQ_sAEIHsk69OQyga-sogXSbPgYxJ7O8gZuPQ/s1600/odyssey.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjl_673y7txuK5Ob2uVkpA0d4y1aCYct5qwX-IYU9qoizY5CLG-PrSgUwbzTYj4P-S2WkcUG1pk7dnvJ_boCjVdtEwLI4lLM-FPMN9dSeEfQ_sAEIHsk69OQyga-sogXSbPgYxJ7O8gZuPQ/s320/odyssey.jpg" width="227" /></a></div>
<br />
What we are about to embark on is a journey. A journey filled with
struggle, trials, tribulations and constant teeth grinding. My goal with
this blog is to chronicle the development of a computer game from it's
first lines of code all the way to release. More specifically, I intend
to keep track of the ideas, methods and solutions I develop as I work my
way through this task. For the less technically inclined, I would also
like to share interesting or funny stories and pictures somehow related
to my odyssey.<br />
<br />
<a name='more'></a>Now, a little about me:<br />
As of this post, I am a
2nd/3rd year inbetween-er Computer Science student. I've always had an interest in games (video or otherwise), from a play and design perspective. Something about game design is incredibly attractive to me, far more so than any other creative medium. I've never programmed
a full game before and am ready to have my incredibly arrogant attitude
firmly put in it's place.<br />
<br />
What I will be developing in:<br />
While I'm conversational in a multitude of programming languages including Python, Java and C, <br />
I will be
using the C++ language and the SFML multimedia library. My environment
of choice will be Microsoft Visual Studio 2012 Professional edition.<br />
<br />
Now,
finally, what is this game I'm designing and developing? Well, you
might be disappointed in it's simplicity, at least initially. My game,
"Wanderer" (working title) will be a survival game based entirely around
searching for food, discovering treasure and avoiding death (by zombies
and not finding food) The player will start off with a projectile
weapon (shooting a gun, throwing rocks I'll leave that up to your
imagination) with which to repel the zombie hoards and an open level to
find the treasure.<br />
<br />
I can already tell you're not impressed. Luckily, I don't need to impress you! The game's simplicity is part of my strategy. I get very easily distracted with projects like this. If a project is far too complex, I'll get overwhelmed with the notion that I will never see it completed. If it's too simple or uninteresting, I find myself getting incredibly bored. To keep myself both interested and grounded I'll be developing this game in stages.<br />
<br />
Stage 1 has already been described above.<br />
<br />
Stage 2/3 will involve adding in procedurally generated, infinitely reaching maps for the player to navigate<br />
<br />
Stage 2/3 will involve adding more depth to the core game play. Most likely in
the form of varying tools for the player and varying enemy types an
behaviors.<br />
<br />
Stage ?<br />
<br />
Stage ?+1 will involve profit.<br />
<br />
This is where I stand right now. how long will I stand here? Will I reach my destination? Will my destination change? Right now I don't know. All I know is that I'm inspired and I'm hoping I can use that inspiration to create something I'm proud of.<br />
<br />
Come at me world.Benderhttp://www.blogger.com/profile/03260905121724671744noreply@blogger.com2