I’m not abandoning this blog, not by a long-shot. Still, my current work eats up my life these days.
If you wanna follow what we’re doing at Will Pwn 4 Food (and you know you do, because you like videogames just like I do), then come our first game, DodgeBots, and subscribe to our blog.
It’s 45 minutes late, but the map loader now properly imports a level (converted from a Google Docs spreadsheet) into a Javascript array, then selects the proper tile in the tilemaps image to make the level.
Here’s an image.
Now onto actually designing the level and making the game.
NetHack – Plane of Fire (Photo credit: ludios)
Guelph Game Jam #4 just started. I’ll be liveblogging here, tracking our progress on our Rogue-like. It’s Michael Hoyle and Me, along with a touch of art asset assistance from Amy.
The theme of this game jam is Growth.
We’re still trying to figure out how that will be implemented in our idea for a Rogue-like, but our first few ideas are pretty promising.
It’s going to be a tight schedule because we’re breaking my first rule of game jams: don’t build your own engine. Hoyle and I have been building a small Javascript Rogue-like engine for the past week in preparation but there are still a few things left to do. I’ve come up with the idea of taking the first two hours of the jam to complete the features of the engine that we need today then taking the remaining 6 hours to make the game.
If we’re going to do this, we’ve got to be ruthless and pull the plug after those two hours and switch to the game. If we let it slip and say “we’ll do one extra hour on the engine” we’ve lost.
Wish us luck!
I’m using the Wiki that’s built into the GitHub service for the BitBuilder Game Platform documentation. GitHub’s Wiki is full-featured, easy to use, and plugged right in next to the source downloads and commit history.
For any open source project to succeed, it needs serious and quality documentation. This is where most open source projects fail and it’s an area that I want to put a lot of focus on with BitBuilder. Since it’s a wiki, anyone can help out, and you don’t need to be a programmer to do so. In fact, it might even be better if you’re not as you’ll have a unique perspective trying to get things running.
My goals for the wiki are to have serious technical specifications for each facet of BitBuilder, but more importantly a series of great, simple walkthroughs to get you up and running, building your game quickly no matter what type of game it is (platformer, puzzle, rpg, adventure, shooter, etc.)
When it comes to documentation, what do you look for? What do you need from documentation? What do you hate about documentation? What makes one project’s documentation better than another?
It’s compiling, so I thought I’d take a second to update the blog on my progress!
The other day, I blogged about the difference between char and char * in C and how I spent a good deal of time wrapping my head around how concatenations and string comparisons work in C and C++. It turns out that in my initial search…replace I mistakenly forgot to switch some of them back to the way they were written beforehand.
Since BitBuilder uses ELIX and the erroneous concatenations and comparisons were in the ELIX files, I may have solved it by reverting it back to the way they were. Programming is great like that. You learn a lot but it takes time and patience.
Here goes.
BitBuilder Game Platform Logo
I’m building games today with @hoylemd at Red Brick Cafe and, once we’re done our coffees, back in my apartment living room. Actually, to be truthful, I’m not working on my game BastardBlaster, I’m working on the BitBuilder Game Platform, which is my fork of the Mokoi Game Engine.
It’s a great exercise for me since it exposes me to C, C++, GTK, and git, which I love.
Hoyle is really good at C and C++ so he’s always great at bouncing errors off of and helping out. Will post more as I make progress.
I’m fresh off the boat when it comes to C++. I learned C in high school and enjoyed it very much, but it’s been so long since I’ve done anything with it, I’ve become really rusty.
Partway through my fork of MokoiGaming’s Game Engine, I ran into a strange condition in an if-block that was comparing the last character of a string to ELIX_DIR_SSEPARATOR. Why would there be two Ss? Did I do something wrong while renaming functions and code blocks with search/replace?
Investigating further, I found this double definition in a header file:
#define ELIX_DIR_SEPARATOR "/"
#define ELIX_DIR_SSEPARATOR '/'
I looked at this, completely puzzled why something would be defined twice. I figured it had to do with the difference between the quotes, so I removed one of the definitions and replaced the few instances there were of the DIR_SS version in the code to the DIR_S version to see what it would do (gotta love that.)
After an hour or so getting into the intricacies of C++’s string comparison, char comparison, and char* comparison, I figured it was just better to have two definitions in my header like what was originally there instead of dynamically trying to cast depending on the situation.
Is that right, or wrong? I like to live by DRY programming if I can avoid it, but in this case, casting to char from char* and vise-versa just seemed like so much more work than one more line in my header.
What do you guys and gals think?
This post is about sharing my ‘Programming Notes and Code Snippets’ document, which I’ve been building on-and-off for a while in the hopes that it might help some of you solve a programming question you have or save you time while you’re building your code project.
I’ve also found this document to be very handy for coming up with new app ideas to get me started using new languages or tool chains. It’s how I got started on Quoats.
Google Wave used to offer this really awesome document embedding feature that doesn’t appear to be available with Google Docs (am I wrong? Correct me, please!), so I’ll just include a link to my code snippets document and an iframe version below.
Note that on all of the code snippets I include a link back to the source that I’m referencing. If these are in error or you’re the owner of the content and want it removed, be sure to drop me a line and I’ll correct the problem. As it is, these code snippets were found scattered across the Internet and this work-in-progress document merely hopes to compile them into something useful.
Enjoy and happy coding.
Placeholder Kitten :}
Sean Yo from last night’s Guelph Web Maker Meetup shared a few awesome web tools I’d never heard of and I thought they were so neat I resolved to share them (and a few extras) today with everyone here.
Every web designer and developer under the sun has used (or at least heard of) the default ‘lorem ispum‘ text that is used as a filler for unfinished text copy on websites that are a work in progress. Well, now us web developers and designers have an option to use something similar for our images as well.
The image on the right should give you some sort of indication where is going… check it:
Let me be straight with you: Every WordPress blog on the web should have this plugin installed.
And, no, I’m also not being paid to say that. :)
W3 Total Cache is exactly what its name suggests: A total caching solution for WordPress blogs. WordPress is a good publishing platform and content management system (CMS) but runs into problems quickly when more than a few visitors hit your site. Even moderately busy websites can buckle under the strain of the database connection pools, stylesheets, Javascript, and HTML that WordPress uses.
Some of the neat features that W3 Total Cache includes:
Before W3 Total Cache I was a fan of WP Super Cache. And before that, I used WP Cache. Neither of the latter two can hold a candle to the capabilities and caching power of W3 Total Cache.
For more information on how this plugin can increase your website’s performance, take a look at W3 Total Cache on the WordPress Extend website.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_c.png?x-id=5bdfe4b0-29ef-4743-9252-c4a076a9f70c)