Posts Tagged ‘Programming’

Yoink! – an Addon for WoW

So my doodad-a-week project hasn’t been going as I’d hoped.  Too many things going on, and I have several toons to support in WoW.  One thing that has been going well is Yoink, my first addon for WoW.

Yoink is a pickpocketing stats addon that tells you all sorts of nifty info, including gold-per-minute, total gold, number of mobs pickpocketed, and how many healing potions and junkboxes you’ve pilfered from unsuspecting NPCs.

I have to say that programming in Lua is a blast.  My only complaint about it is the same beef I have with PHP, which is that there is no consistent naming convention for functions.  Other than that, it’s really slick and easy to pick up.

To learn the basics, I started out with the ShowMeTheMoney addon demo.  I like learning a new language/platform by typing in everything by hand first, then messing around with the IDE.  After I got the general gist of what was going on, I downloaded the WoW Addon Studio.  It’s built using the Visual Studio shell, so it was nice to have a familiar environment to work in.  While it’s very handy, it does have several quirks.  I’ve come to use it mostly for its syntax highlighting and intellisense, mostly.  I no longer use the visual editor except to browse through the various backgrounds, buttons and bling that you can use in your widgets.

One of the frustrating things I ran into while making Yoink was that events aren’t reported in the order they occur.  Anybody building Flash/Flex apps should be familiar with that happening.  Come to think of it, fellow Second Life scripters deal with the same thing.  It’s a big ol’ world of asynchronous event handlin’.

Yoink is in testing right now.  I’m publishing it via CurseForge, which is really nice since they act as your code repository (supporting git, svn, cvs, etc.) and have a very active addon developer community.

So yeah, that was fun and all, but I don’t see myself making a lot of addons for WoW.  I might make some class-specific utilities but I’m not getting involved in anything big.   Back to thinking about web games!  So there.

Cocoa/Objective C development tips for .Net Folks: Part I

No, this isn’t about using .Net to make iPhone apps!  It’s just a set of observations that might make it easier for people like me who currently use .Net (specifically, ASP.Net) at work, but want to start fiddling around with some Objective C, Cocoa, etc.

Keep in mind that this is from the perspective of someone who got into web development without traveling down the formal education route (when some of my buddies were learning C, COBOL and PASCAL in CompSci 101, I was sucking sand through a gasmask, patrolling some godforsaken ammo dump or airfield in the middle of nowhere).  I have no pure C language knowledge or insight, so all of this stuff is new to me.  I know many web developers in the same situation, so maybe this will help some people make the connections between Obj C and the types of languages they’re used to.

– “Actions” are event handlers.
– “Outlets” are properties that can be bound to your user interface widgets.  They are objects of the same type as the given widget. So if you have a RoundedButton on your UI, you’ll probably have a RoundedButton in your .h/.m code if you want it to actually do something.

From what I can tell, you don’t need to name the specific buttons in the UI part…you associate the button with its corresponding outlet via a drag-and-drop in the UI editor (“Interface Builder”).  I’m pretty sure you can do it manually/dynamically via code, too.  In the .Net world, you’d set the name of the button in the UI editor or in your HTML code, and Visual Studio would automatically make the corresponding code additions.  I haven’t seen that ability in XCode/Interface Builder, but I’m totally new to this so don’t take it to mean that it doesn’t happen.

You can think of the .xib file (known as a “nib” file by Cocoa vets to honor the former file extension) as needing a code-behind page.  The nib is your UI, and the .h and .m files need to be told “Hey, I have these do-dads on the UI.”  After all, if you dig through the code that ASP.Net automatically generates, you’ll find the same kind of definitions for each UI item in the code-behinds.  Same-same.  Don’t let the EXTREMELY WEIRD BRACKET-HEAVY SYNTAX scare you.

Speaking of which, here’s a brief bit of learnin’ about the syntax.  Let’s take apart this function…

-(IBAction) openThing: (id) sender
{
// code that does stuff
}

The hyphen is there on purpose.  (Don’t ask me why.)  (IBAction) is the return type, openThing is the name of the function.  (id) is the type of the argument and sender is the argument itself.  To call a function, use brackets like this:
[myObject doSomething:5];
myObject being the object, doSomething is the function being called, and 5 is the argument.

By the way, the “id” type in Obj C corresponds to Object in our world.  It could be anything.  You’ll need to cast it to whatever type actually sent the event if you want to use it.

If you ask me, the brackets clutter up things, and dot notation isn’t supported enough in Objective C.  They added it to 2.0, but I think it could be used more than it is.  You still need to use brackets for functions if I’m not mistaken.  Of course, you can’t just change the entire syntax of a language without peeving your developer base!

On a side note, I’ve found XCode to be a sweet IDE to work in.  At first I found it a little annoying to have to switch between two completely separate programs to do coding vs. UI work, but then I realized some benefits to it.  Unlike Visual Studio, you can open up just the stuff you want to work on.  VS gets more bloated and resource-hoggy with every iteration, and it would be nice if you could completely rip out the Design mode when you’re working on ASP stuff.  You know it’s lurking in memory somewhere, ready to reformat your clean, hand-written tags the moment that you accidentally summon it.

Another advantage to having two separate programs is that it reinforces the separation of concerns between code and UI.  This premise lies at the very heart of how iPhone programming works – it uses the Model-View-Controller pattern!  I have used this pattern extensively, and although I’m not a design patterns guy, I have to say that it makes for fairly clean distinctions between the various pieces in an app.  If you haven’t used it yet and you’re an ASP.Net developer, you’re in luck.  ASP.Net has an official MVC implementation!  Grab it, build some stuff with it.  Understand it. It’ll help you see how things work in the iPhone (“Cocoa Touch”) world.

The books I’m reading on the subject are Beginning iPhone 3 Development by Dave Mark and Jeff LaMarche, and Programming in Objective C 2.0 (2nd Ed.) by Stephen G. Kochan.  I’ve found both of them to be very, very good books.  I will say that getting about halfway through the Objective C book first will make your life a lot easier.  I’m currently switching back and forth between them.

I’ll be posting more stuff as I wrap my head around this.

Excellent indy game dev post – Asterope by Niklas Wahrman

http://www.gamedev.net/reference/articles/article2570.asp

This guy hits the nail on the head so many times in this article.  He refers to a lot of development ideas that I tend to agree with, such as the “Ready, Fire, Aim” approach…just build it and stop overthinking!

ActiveX weirdness will make you pull your hair out.

Note: Non-developers can skip this post completely.

If you’ve ever had to make an ActiveX application run within a web page, then you know how frustrating it can be to get it working, much less try to debug the $!&@# thing. If you’re building it with .Net, it’s even more of a pain.

What do you do in this situation: You’ve read through the available online tutorials (which I will not list, since they’re all somewhat incorrect in one aspect or another) and have had the app working at one time or another, you may still have the “missing/broken” section appearing on your web page instead of your nice new application after you’ve made a change. You’ve cleared your IE cache, restarted IE and may have even rebooted your computer trying to get your app to re-appear. You’ve done just about everything and it’s still broken.

Well, the simple answer is that there’s an error in the app itself. Apparently everything has to run super-smooth in order for IE to even display the app. Comment-out the stuff you’ve changed or throw some try-catch blocks in there. Rebuild the app, clear your IE cache, restart IE, and see if your app appears.