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.

 

Throughout the years I’ve used a growing list of development platforms. ActionScript, Java, C, C++, Python, C# (.NET). In an effort to ease development of AMIWAM and improve extendability, the language chosen was C# within the Mono platform. The only graphics library that appears to be useful within Mono is GTK-sharp. Tao SDL hasn’t been updated for six years and nothing else appears to get the job done.

This choice has proven much more costly than first estimated. The documentation on GDK-sharp doesn’t have any examples so far as I can tell of this type of application being built in GTK-sharp, but GTK is the framework on top of which the GIMP is constructed. Therefore, I know there’s a way to achieve my goal of rebuilding a C++ application powered by SFML in C# under Mono and GTK-sharp. At this point I’m considering giving this another two or three tries. If no solution can be found within those attempts, then I’ll move onto rebuilding Eucalyptus in a different language.

 

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.

 

 

As the gears shift into more framework development  for the next Xbox 360 game, I wanted to write a quick note about a new project on the Projects page.

Eucalyptus was a great proof of concept into the idea of a keyboard driven image mocker, but it has two major flaws in my opinion. Firstly, it is built in C++. This means the application has great low-level power, but rapidly building new infrastructure is difficult and often blocked by barriers in memory management. Secondly, RPI could claim total control of the project should it ever develop into a serious tool.

In an effort to overcome both of these shortfalls, I am taking the time to rebuild the entire application from scratch in C#, without referencing any of the code in Eucalyptus. Many of the same ideas will carry over, with a small numbers of improvements. Predominantly, I want this application to be geared towards image mocking that ranges from hideous and blocky in a way that fits immediate develop needs, as well as allows for mocks that might carry the same elegance as the 8-bit Nintendo era games.

Programmatically speaking, this will involve a new system wherein a user can switch contexts after finishing the vector body of an image. At this point, it can be exported and used in whatever code is being developed, or a raster editing context can be entered where a slight amount of refinement tools will be made available. The goal is still to keep out as much bloat as possible while still providing the most convenient means of mocking graphics without the impediment of a mouse.

In spirit, the program’s name will embody this principle. Amiwam Makes Images Without A Mouse, AMIWAM. AMIWAM currently has both the keyboard input sub-system and rendering capabilities needed to start the principle development, so I just need to table the work to be done and accomplish it. This summer will be a great experience both at Apprenda, and working on these new and exciting projects. Looking over the fruit of my labors from the semester is a sweet taste indeed, and I look forward to more in the coming weeks.

 

RPI’s term is coming to a close which means I will soon have time to jump back into some project ideas for the summer. Over the past two weeks, there was an application that had to be built as a final assignment. After thirteen days of building it in C++ it began turning into spaghetti. Over a thousand lines of code to convert between different data structures used by other parts of the application. Gross.

Why was this code so bad? It turned foul because I had no idea what I was building from the get go. In a general sense, a simplified SSL client was being fashioned. Technically speaking, I had no clue.

This lack of knowledge lead to me jumping into programming as a means of learning what I had to make. That sounds backwards, but it is a trend I find myself in all the time when learning about new things. Sometimes I am better able to visualize and comprehend a subject by programming it instead of researching and planning the architecture ahead of time.

With that said,  as my knowledge increased about the workings of SSL my code was growing more and more fragile. Closer and closer it got to the edge of usability until it fell and broke a hip. A few conversion function changes lead to all encryption breaking.

The project was due in three days from that time. I had already invested dozens of hours into this project. A tough call needed to be made. Should I continue wrestling with memory error ridden C++ that was near completion, or was the wiser choice to start over from scratch in Java?

Start over from scratch? Two thousand lines of C++ for nothing?

No, not for nothing. Writing that awful code was an exciting experience filled with twists and turns that I didn’t see coming. That’s the thrill of gaining understanding on a new subject. I don’t think programming as a task should be that way. Its too easy to be overjoyed with accomplishing a job that the time isn’t taken to do it well.

Yes, re-writing the entire application from scratch sounds like a grand undertaking. On the contrary, knowing exactly what I needed to build meant better planning before even touching the keyboard. By the time I was coding the application was well designed on paper, so writing the code itself wasn’t as thrilling.

Such if life, that we can get excited about the wrong things. Perhaps if people spent more time brainstorming and less time pounding out rushed code then we’d have a few more Linus Torvalds rising from the ranks of my peers.

 

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.

 

While working on Eucalyptus I came across an interesting solution to a potentially painful problem. I wanted to allow a user to provide input through the console while tracking the keys pressed elsewhere in the application. This required a way to remove characters from the buffer and the console once BACKSPACE was pressed. A neat trick a discovered through a few attempts was to print “\b”, or the backspace character to the buffer. By printing this, a space, and then another backspace the character was erased from output. Useful tip.

 

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.

 

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.

 

A capstone course required for CompSci majors at RPI is Software Design and Documentation. Throughout the semester students engage in the process of building a piece of software that has little to no limitations. This provides a foundation where computer scientists can let their minds unwind and imagine exciting new applications to construct.

Group focused software development is at the core of this class. In my group we decided to make an image editor that doesn’t use a mouse. This little project started as my brain child, but was quickly taken in a different direction than what I’d envisioned.

In  my mind, there existed a program where I could execute a short number of keystrokes and quickly generate decent looking graphical mocks for my 2D game projects and edit images pixel by pixel. Since starting documentation and development, we are instead working on an application that doesn’t even support raster graphics anymore.

I’m working with a group of very bright students, but this semester is teaching me a lot about project management. At Apprenda, we are all allowed to some extent the opportunity to be cowboy coders. Anyone with an interesting idea can dive into their project and show off how useful it is. Due to this development lifestyle, I was not prepared to properly cast the vision of the application I’d imagined and will now be left to develop it on my own time.

In other news, the input management system is developed for Bombard360. I will shortly be moving forward to tests on the XBox now that the meat and potatoes of the underlying game framework is complete.

© 2012 Simple Path Studios Suffusion theme by Sayontan Sinha