I really hate to say it because I was very much looking forward to Guitar Hero III – unfortunately I was taken in by marketing. Yes, the game has over 70 songs. Only 42 are on the set list, the other 30+ are bonus songs, which is a polite way of saying “You weren’t a good enough song to make it into the set list”. That’s exactly how good the bonus songs are: not really worth it.
Overall, this game has been a vast disappointment. The most glaring difference is the graphics. They’re horrible compared to Guitar Hero II. Xavier Stone now looks like a cartoony pimp from the 70s instead of the cool, guitar god look he had previously.
Here’s some tips on making Guitar Hero the game it should be.
I subscribe to a lot of development feeds, one of which is the Model-Glue Google list. I’ve seen requests from time to time for a step by step tutorial, or demo, on using Model-Glue. Obviously, the place to start is the documentation (which I believe is admittedly in need of an update). However, during the past few months, I’ve had to give a few co-workers here a crash course in how to navigate my latest MG application.
Because of this experience, I believe I can put together a fairly well done set of blog posts, and perhaps some videos, of how I set up my application, and even go into some of the features upon which I rely heavily. Of course, it would by no means be an official review of all features; I believe only Joe Rinehart could do that.
Nonetheless, one of my strengths is being able to take “complex” processes or ideas and break them down into simple to follow steps that a beginner can follow. If you read some of my past posts, I vent often about the disease I call “Doculitis” (lite documentation). This afflicts many software people and causes them write documentation from their perspective and gloss over, or even ignore, important content because it’s been internalized and they just don’t think about it like an outsider.
So, this post is mostly a reminder, or kick in the butt, to myself to make sure I make the time to help some people out there.
As I was explaining my latest application to another developer this morning, I realized that I was a serious framework junky on this one. I like frameworks, but I also like to scatter in my own personal touches to them based on the needs of the application. In this latest app, I am using the following.
I was actually amazed at myself when I realized this. I also found myself thinking that the saying “standing on the shoulders of giants” is appropriate in this situation. I created an absolutely amazing application, in less time than was anticipated, and with an slick, easy-to-use interface. If it wasn’t for the hard work of the Rineharts, Resigs, Corfields, Gondas, Mandels, and others of the world, my applications would still be grinding along on my homegrown frameworks that, while they work well, don’t have near the feature set of these libraries.
I’ll add voice to the thousands who say thank you for your hard work.
Powered by ScribeFire.
When I start developing a new app that uses the Ext library, I first just include everything because it allows for rapid development in the initial stages. I never have to worry about if I’m including the right features. However, as the app matures – queries are added, UI is strengthened, configuration is complexified (yes, I said it) – the pages start to bog down from the massive 500k include.
Splitting the Ext features into individual files allows for two things:
Here’s an example of my Ext libraries for a particularly heavy page:
<script type="text/javascript" src="js/ext-core.js"></script>
<script type="text/javascript" src="js/ext-buttons.js"></script>
<script type="text/javascript" src="js/ext-data.js"></script>
<script type="text/javascript" src="js/ext-dialogs.js"></script>
<script type="text/javascript" src="js/ext-form.js"></script>
<script type="text/javascript" src="js/ext-form-combo.js"></script>
<script type="text/javascript" src="js/ext-layout.js"></script>
<script type="text/javascript" src="js/ext-quicktips.js"></script>
<script type="text/javascript" src="js/Ext.ux.InfoPanel.js"></script>
<script type="text/javascript" src="js/Ext.ux.Accordion.js"></script>This is stripped from the most feature-rich Ext page I’ve developed to date, and by splitting things out, the JS is down to 380k from 550k. Still large, but significantly smaller than just including everything.
This is easily done by using the Build Your Own Ext page. When you want to add a specific piece of functionality, simply use that page to download it, strip out the core code so you’re left with only the objects you need, and include it in your page.
My favorite idiom by which I live as a developer is, “It’s always the small things.” By which I mean that when there’s some catastrophic problem with my web page or software, I always scan for the little things first – missing semi-colons, syntax errors, reserved words as variables, etc. I’ve learned this from years and years of fruitlessly debugging an application for endless hours only to, in the end, find I didn’t close a tag, or left out a double quote.
Today I can add another “little thing” to the mental library.
I’m populating some Ext ComboBoxes with an array which is created by looping over a query.
Ext.mappingData.payers = [
<cfloop query="allPayersQuery"><cfoutput>['#pr_seq_no#', '#identifier#'],</cfoutput></cfloop>
];This worked perfectly fine in Firefox, as usual. However, a user who was testing my app in IE found that the ComboBoxes weren’t working. I spent my usual hours trying to figure out why it wouldn’t work in IE. I even spent another few hours recoding one page with a band-aid workaround. I ran across the problem tonight in another page, and it just popped into my head…. the trailing comma.
I rewrote my code to build the array and trim off the last comma and it finally worked in IE.
Hopefully this post will save someone hours of work in the future.
Powered by ScribeFire.