OGUR is finally in phase two of the three phase development plan I came up with many months ago. To recap:

  • Phase 1: Build an engine that supports the type of game I want OGUR to be
  • Phase 2: Leverage that engine to create the actual game
  • Phase 3: Spruce up the graphic and audio component of OGUR to best fit the theme of the game

There are still a number of bugs to squash and enhancements to make, but all and all the core engine is complete.

So what is the state of things after three months? Well, post-graduation from RPI and immediately getting married, OGUR was put on the back burner. To make things even more challenging, my primary hard drive decided to die the night before I was moving seven hours away from college.

Thankfully I have always been dogmatic about pushing to a remote backup repo for OGUR. Unfortunately, I had gotten so busy with schoolwork that I never got around to pushing over a week or two and lost around seven hours of critical work I’d done in the engine. In order for me to start working on OGUR again I would both need to get into a weekly routine that allowed time for my favorite side project as well as enough motivation to redo the work I’d lost extending the engine’s functionality.

Here in Virginia, I still haven’t hit a healthy stride week by week. Surprise errands continue to pop up, but random hours here and there do come around from time to time. I’m excited to say that enough of those random moments were aggregated and the engine is back to its full glory.

In all honesty, that was the case a week or so ago. Since then, I’ve been doing work on implementing the skills for each of the seven playable classes in OGUR. The release plan is to build out the first five skills for each class and use that as the basis for an alpha release of the game. From there I will build out the game in whatever area needs expansion.

I won’t be taking much time to write up progress until the Alpha is ready. When that will be, I really have no clue as of yet. Additionally, I will be putting off any updates to SPX until OGUR is at least in alpha.

Here’s to an exciting future :) .

 

 

SPX has been built by taking code from OGUR and refactoring portions of it to be more useful for general game development with the XNA framework. One week ago I loaded OGUR onto my XBox 360 to see how it performed compared to the PC version. That test was intended as a way for me to see if the first of two graphical overhauls looked as good blown up on a big screen as it does on my laptop.

Boy oh boy did I underestimate how important that test turned out to be.

Starting out, I couldn’t even get the console specific project copy to build. Thanks to multiple blog postings I was able to find out that the Xbox runs a different version of the .NET runtime than what runs on the PC. This meant that I first would need to implement some features from .NET 4.0 in .NET 3.5 which OGUR needed to run. Only after I completed this task did I realize that the target runtime could be changed in the Xbox project without adverse effect. DOH!

As soon as the game launched on the console, I knew something was horribly wrong. OGUR had run on the Xbox in its early stages, but I hadn’t taken any time over the past two months or so to test on the console. I didn’t think there would be any major differences between the two platforms, especially since OGUR (and subsequently SPX) are built to dynamically handle both PC and the Xbox.

By leaps and bounds the most dramatic problem was lag. A button on the controller needed to be held down for literally seconds before any movement would occur. Don’t even get me started on the lack of response shown by the HUD for each player. This was a crippling blow to my momentum on the project.

Sitting on my couch, I knew there was no chance of me backing away from OGUR. With the engine nearing completion I couldn’t cut my losses and either build from scratch on another platform or simply pursue a different game altogether. There was certainly a temptation to quit in the back of my mind, but in hindsight my obsessive nature over this project wouldn’t have possibly let me stop.

What could have been a trainwreck for OGUR turned into an amazing bound forward for both the game and SPX. Over the past seven days, I’ve run countless memory and processing performance tests for OGUR both on PC and the console. I’m happy to say that after many hours and an entire weekend spent, OGUR is once again playable in the Xbox. In the process, I’ve added a number of useful helper utilities to SPX which I plan on pushing to the repo once I can grab another spare handful of hours.

 

 

Creating the framework needed to make OGUR is a task that is nearing completion. In the likely event that the initial foundation is ready to go this weekend I am taking some time to step back and refresh my understanding of the best way to design games.

Practically speaking, the past month or so has been an exercise in wearing my software engineering hat. Late nights drawing up diagrams to ensure that the framework for the game makes sense and will scale as I extend it to new heights. Refactoring chunky portions of the code base to ease development later on. So on and so forth.

However, phase two is predominantly about two things:

  1. Make a lot of content for the game
  2. Test all of that functionality to ensure that it is fun and balanced at the same time
This doesn’t take nearly as much forethought as it does feedback. Hours and hours of playing by myself and with friends as new content gets added, and then talking about the gameplay experience. To help this transition, I’m stepping away from C# to spend some quality time with some of my favorite games. Today will be Roller Coaster Tycoon.
Mind you, this isn’t so much a vacation away from developing OGUR, not in the least. This is a concrete way for me to change the way I perceive the project from here on out. Of course there will be times when I need to tweak the game’s underlying framework, but more importantly now is to gauge the fun factor. Engineers are boring people that think “fun” means organizing their stamp collection. Gamers on the other hand…
 

A little over a week is a looong time in terms of feature development on a single game. Within that time period I traveled to Virginia to visit my wonderful better half, brought my sister to visit me for this week, and worked full time at my day job.

Did I forget to mention the twenty tasks completed in the Wedoist backlog? There were many minor changes as well as completely new features. These included:

  • A completely functional inventory and equipment system with items that influence every creature in the game
  • A major tweak of the HUD to improve usability
  • Made creatures have the ability to progress through levels of advancement in character
  • Building a framework for creatures to have a class that influences growth over time
  • Twelve major bug fixes
  • Moving into a testing stage with multiple players participating locally at one time.

The flight from Virginia back to home in Albany was an hour long, just enough time to crush the final two known bugs in the game.

With every distraction removed from the backlog, its time to move into the final leg of constructing the first version of the game for play testing. Only three major features remain for the game, and they are the most exciting for me to work on…so I’m glad they’ve been reserved until last.

Time will be harder to grab while my sister is in the area, but next week should be the perfect opportunity for me to nab up some free time and put the final pieces into place.

A major thought that I keep reconsidering throughout development is the idea of porting this game to multiple platforms after completion. A lot of work has been done to cram a huge amount of dynamic game play into a minimal control set that maximizes a user’s overall experience with the game. This should translate well should I decide to port the game to, say, mobile platforms.

There might be an entire post devoted to examples of how I approached this problem, and what system I’m using to keep game play exciting in multiplayer while providing flexibility for each player regardless of the actions being performed by any respective person.

 

Five hours is a long time to sit silently and ponder. It’s just enough time so that you are guaranteed to be both hungry and losing the appeal of driving within a single day. Additionally, one might contemplate long enough to have some lifestyle breakthroughs.

Today’s drive to Connecticut in the AM and back to New York in the late PM helped me understand that past focuses aren’t satisfying neither my desires as a developer nor as a human being. Time now past would find me flinging to an extreme position or direction to take life, but that amount of shifting doesn’t feel necessary anymore. On the contrary, the major recurrence in thought throughout the day was balance.

I’ve never been good at balance, but its usefulness is growing on me. Waking up this morning brought me into a state of being wound to the point of snapping. A sense of cosmic scales tipping off center weighed heavily on my morning routine. It took two and a half hours locked inside a Chevy thought cage to slowly release the tension placed on my life.

Long story short, I simply cannot focus on business-centric development full time. I can do it as my primary source of income, but on my own time I cannot be working on similar projects. The work is monotonous and provides very little motivation to better oneself.

My solution to this newly understood problem is straight forward, its time once again to continue game development.

 

I need to catch my breath. I’m currently in my home town without any need to remote back to the office for the first time in a long time. Looking back over the past seven days is a breath taking experience throughout this rainy day.

For starters, yesterday was my younger sister’s birthday. As a surprise I helped her learn the basics of building a website. Within a few short hours I saw someone move from not caring about programming to truly appreciating the power granted by learning to program a computer. Her funny little site is by no means the next killer app of the Internet, but I’m excited to see my passion for software engineering rubbing off on a family member. This opens a new channel of discussion between us, as well as a new path for affirmation. Both of her intelligence, and my role as an older brother.

At the same time, research is being conducted about the appropriate platform on which to build a potentially massive web application for a friend. It appears as though Ruby on Rails will be the best bet after reading many stack overflow posts on the debate of RoR vs. other languages and frameworks. Rails does a great job of pulling me into the beautiful design philosophies it embodies, the coming weeks will tell whether or not beauty can tame the beast of an application that needs construction.

However, RoR really exposes the weaknesses of Windows’ terminal support. The Console in which I run Git Bash is atrocious for reading longer outputs, but Powershell is slower than death. This meant a cleanup of my Ubuntu partition to make space for full-time RoR development under Linux. Setting up the latest ruby with the latest gem package manager was as simple as configure/make being called on ruby’s source snapshot and then  running the setup.rb script for the gem package manager. Once rails was installed from gem, everything started moving along smoothly. Over the next handful of days I look forward to continuing progress through the tryruby.org site and reading books on Rails.

Another interesting development is that of the direction my plans for an Xbox 360 Indie game are heading. The plan on paper is a platformer with a handful of unique gameplay mechanics driving puzzles and exploration. However, tonight I made a return to some rougelike games and have started to plan a second game. This second game is far more interesting to me personally, so there’s a chance that I’ll back burner the platformer for now until I make some headway on planning this second game.

I am more motivated to work on this new project because I’ve always wanted to build my own rougelike game. Ancient Domain of Mystery by Thomas Biskup has always been my favorite rougelike,  but I have many ideas beyond the styling of that game’s core play mechanics. Building this for Xbox will present an interesting challenge and I look forward to solving the problems that arise. There’s still much planning to do if I seriously want to build this, so its not the highest priority at the moment.

Then there’s AMIWAM. I’m fighting a battle at the moment with the Views of AMIWAM to overcome some awful flickering that occurs when I redraw the screen. There are numerous solutions available for this problem across the Internet, but so far none of them has proven useful. Every day I’ll tackle the problem with new ambition, only to break the effort an hour or two later to make progress on other projects. Once the rendering works perfectly the amount of work to rebuild Eucalyptus will be trivial.

 

 

The basic functionality of Bombard360 is finished to the point of what is due for my coursework. Now that I basically need to freeze the repo until classes are over (for grading purposes) I used the free time available to abstract out a lot of the code from Bombard360 into an easy to use framework for other 2D games.

This new framework can be found at this GitHub repo.

To get a feel for how the framework is used, try the following to add a new element to the game.

  1. Draw a new sprite in the next open open row of “SimplePathXna\SimplePathXnaContent\GameplaySheet.png”
  2. In the VS2010 solution, add a new element to the SpriteType (\Sprites\SpriteType.cs) enum that described the object you want to add to the game
  3. Add a new dictionary entry defining the contents of the sprite to SpriteSheetManager (\Sprites\SpriteSheetManager.cs)
  4. Create a new class that inherits GameplayObject (\GameObjects\GameplayObject.cs). In the constructor, pass the location and SpriteType into the protected Initialize method. This will handle most of the graphical setup for the class.
  5. Create a method within your new class with the following signature: public override void Update();, and define the object’s game logic here.
  6. In GameplayObjectFactory (\Factory\GameplayObjectFactory.cs), add a new case to the switch statement that defines the way your new object shall be created
  7. In GameplayState (\States\GameplayState.cs), call the function Add(GameplayObjectFactory.Create(400,400,SpriteType.YOUR_NEW_SPRITE_TYPE)); in the constructor
  8. Run the application, and an instance of your new object should show up on screen at 400,400. If not, then there’s a good chance that a null exception will be thrown before the game can launch, showing you what step you missed in setting the object up.

The benefits I’m finding from using this growing framework is the topic of a future post, but feel free to shoot me an e-mail if there are any problems encountered in getting setup with the project.

 

As I look back over my past few posts I can see that many of them were made at the wee hours of the morning. That time of night is my most productive, but apparently not so much for my writing. In a similar mindset of looking over my recently made mistakes, I’ve taken on Bombard360 as my final project in Software Design and Documentation, the computer science capstone course at RPI. Within an hour of looking over the changes required to fit in a level editor I realized that there were a good many poor decisions made in construction.

First of all, the classes don’t follow anything resembling MVC. This means the views are actually the parents of every game play object. This makes display very easy, but it lead to some problems when I wanted to show each sprite without its currently coupled game logic. Working on Eucalyptus is what brought about this revelation in the first place, so I’m glad that project isn’t going towards a useless assignment that I need to churn out.

Secondly, Bombard360 still has one major technical flaw that I have yet to address. The massive 20×20 grid for play works great on the PC but displays improperly on the XBox 360. I was expecting the view to scale to the TV’s height, but it doesn’t. Not sure yet about a work around.

Lastly, resource (content) references are still something I don’t have a great way of managing. They are currently mapped to an enumerable within a class that manages how many frames each sprites has for an animation. More research is needed on the best way to handle this.

 

I’ve been trying to spend more time playing games lately. Although I develop all kinds of software, making games is my favorite pastime. In an effort to better understand the games all of my friends talk about I’m setting aside time during each week to play through them. As I work through each game I try to pick it apart and understand both the gameplay mechanic designs and the psychological shaping enforced by each game.

I’m not a big FPS person. Once I purchased my XBox 360 I knew it was only a matter of time before friends berated me for not playing MW2 and Halo. In my opinion, these latest franchise iterations appeared to lack any depth. However, I didn’t give them a fair chance and wrote them off because I didn’t hear any valid reason from people to play them, in my opinion.

That changed about a month or two back. I had been in full-on hermit mode for a whole and decided it was time to hang out with people more frequently. I was given a free copy of Halo Reach and used that opportunity to invite a friend over once a week to play some online multiplayer. As the gaming session rolled by I became more acquainted with each map and started to develop strategies that would favor me as the victor in battle.

I’ve played the first and third Halo game and found myself very, very dissapointed with the strategic depth both in single player and especially with online play. I’m accustomed to a game where there are many variables, which have been finely balanced, that a winning strategy takes days of trial, error, and well-thought out practice to develop. Halo seemed to be 100% about learning the map and mastering each weapon respectively. Once you had that down, there was nothing else to worry about.

Halo Reach changed that for me. As my familiarity with the maps increased my strategies still needed to be changed on a steady basis. This is due entirely to the class system in Reach. No longer does it matter entirely that power weapons are being controlled; if an opponent is properly using a class skill that overpowers your own then you are forced to change strategy.

Reach accomplishes this in a way that offers a low barrier of entry for players to have fun. Getting shot a few times while investigating a map doesn’t deal a lot of punishment, since everyone can stand several blows before death and your shield regenerates rapidly. Reach is the kind of games where I can hold a conversation with the people sitting in the same room, but still dominate in game.

In stark contrast to both of those points stands Modern Warfare 2. This was a game I purchased for the sake of a friend of mine. He claimed it was the end-all-be-all FPS of our time. With that purchase I played through the short but enjoyable campaign. I never even thought about touching the online mode until a month later. At that point, said friend visited my apartment for non-gaming reasons and while I was assisting him in computer related issues he booted up MW2.

He was baffled that I hadn’t even started multiplayer, and informed me that it was 75% of the game’s worth. I watched him play a few rounds and didn’t really see anything different about this game. Later that night I tried it for myself.

Two hours later I was ready to trade this game in for Katamari Damacy on PS2, or something else I’m searching for to add to the collection. It was the least fun experience I’ve had in gaming in quite some time. What was frustrating was that I had a solid handle on the controls, yet was still getting destroyed in game. My worst record was 0-18 in a single game. At the end of two hours I wasn’t doing much better.

One rule I have is that a game that doesn’t give you any direction to progress is poorly designed (see the No Twinkie Database for many, many more quips). MW2 fit this unfortunate bill. Two hours in and nothing seemed to tell me how I could get around my constant failure. I am also a firm believer that one should never watch online videos or read WIKI/forums in order to enjoy a game. If that’s a requirement, then the game is poorly designed.

Sitting on the couch pondering the distance an XBox 360 disc could be hurled, I had a breakthrough. I flipped through the classes available  as a starting player and saw that one carried a device similar to a rocket launcher. In many other games from my past, that wonderful n00b tube had been my entry into victory. Rocket launchers tend to give players that are bad at a game enough of a random victory to provide incentive to continue playing, MW2 was no exception to this.

As I got a handle on blasting away enemies I found myself more naturally crawling around the game maps. No longer did I dash nonchalantly around and get picked off by snipers, but I blitzed through hectic firefights and cleared rooms one by one, dashing across small gaps to avoid stray rounds taking me down.

Around hour four the largest difference in this gameplay experience hit me. Reach is much more about having a light-hearted good time. MW2 is largely a battle of thought. You need to choose the very customizable loadout of your class very carefully depending on both the map and the loadouts of the opposing team. Being able to adjust quickly in a battle also hooks a higher victory rate. This experience was much harder to break into than Reach was, but as time went on I found it far more rewarding. Reach was a nice repetitive time sink, MW2 felt like a compelling and fun mental workout.

Both games serve a purpose in my collection, but they are very different experiences. Reach is for times when I need to gives other people I’m with some quality attention, and MW2 is a game for my own pleasure and game time. This post talks a lot more about the non-gameplay element specific thought that went into my gameplay experiences, but that’s because I’ve seen enough MW2 vs. Reach posts to last a lifetime that cover the technical differences. If Reach is a quick pickup game, like playing cards, then MW2 is a battle of Settlers of Catan.

 

Work on Bombard360 has been a blast this evening. I started with chasing down some baffling performance issues in the board management system. My initial thinking was that the sprite resource files weren’t being cached in a way that allowed for low overhead when each instance needed to be displayed.

However, thanks to the great tool SlimTune I was able to discover the true culprit. The board management class was having issues handling the number of explosions generated by each bomb. Slimtune showed that over 50% of the application calls were to functions within the board manager which added new tiles to draw after a bomb exploded. This caused some memory issues by attempting to add tiles to non-existant coordinates on the grid. What exactly caused the slow-down I am unsure, but adding some logic which prevents this behavior increased performance back to optimal levels.

© 2012 Simple Path Studios Suffusion theme by Sayontan Sinha