This is Stephen Nichols's Typepad Profile.
Join Typepad and start following Stephen Nichols's activity
Join Now!
Already a member? Sign In
Stephen Nichols
Pflugerville, TX
Your code stinks.
Interests: Programming
Recent Activity
You realize that your comment doesn't make much sense. About all I got from it was something about not fixing stupid... which you definitely seem to know something about. Reference counting is just about the worst way to manage memory, hands down. There are some very small edge cases where it makes sense. If you use it then you're likely retarded. Yes, reference cycles are a LOGIC FLAW, as is your comment. The very method of reference counting objects begs for cycles to occur. And those cycles are damned hard to detect. That's a DESIGN FLAW in the technique. I don't recall saying that memory management has zero overhead. Of course it has overhead of some sort. But to make every object responsible for its own lifetime and thread safety is pure unadulterated shit. What a terrible approach. One fraught with regular deadlocks and bloated implementations. If you want to manage memory, manage it. If not, use a garbage collector. But to fall back on reference counted smart pointers is just retarded. Don't do it.
A few things: 1. You can't spell "premise." Thus your argument is invalid. 2. Richard didn't design "Ultima Online." Raph Koster was the main man there to my knowledge. Shame on you for being so ignorant. 3. You obviously can't read. Richard clearly said that most game designers were lazy. Here's the quote again for you: "every designer that I work with -- all throughout life -- I think, frankly, is lazy." Richard is entitled to say whatever he wants. But that doesn't make him right! Most designers aren't lazy. He's not the best designer in the world. And he didn't invent the computer RPG. He's a great creative director and front man. But, in my experience, he's not a designer. He should be ashamed of himself for shitting on all the developers that have worked with him over the years like that.
Your comment made me LOL! :D
Toggle Commented Mar 27, 2013 on NEW RESEARCH: Women and Coding at Coding Wisdom
So, I've done a little research on you tonight. You seem to be "Andrew Darovich." I get this idea from your cross-posting of this info on Facebook and here. Please correct me if I'm wrong. I checked out your games at Aetherbyte. Not too shabby. I'm digging the retro look. Definitely not state of the art, or all that complicated, but not too shabby either. Kudos for that work! :) So, what puzzles me even more is that someone who has developed a game would make the determination that design is the most valuable skill. Methinks that you're a Garriott fanboy. But, let's go with your argument for a moment. This'll be fun! You say that non-lazy designers break the mold. You go on to say that if the mold isn't broken then people are being lazy. This amazes me coming from someone who is rehashing old game ideas from the 80s. Cool as that is, it's certainly not "breaking the mold." Would you call your team lazy? Just wondering. If so, I wonder how they'd feel about that. You said: "As far as I am concerned, without a game design, you have nothing to program." That's obvious. Bravo for making an obvious point. Without a game idea you can't make a game. So, since you've mastered that obvious fact, why can't you also understand that without programming the design wouldn't advance beyond the idea stage? Ideas aren't video games. Please show me a video game that exists without coding. I'm guessing that you won't come up with much. Surely this dependency is clear to you. As is the dependency on testing, marketing, art and sound. If not, please help me see why that is. I'll also take a moment and respond to your assertion that I'm doing the same thing that Garriott is with my blog here. My, oh my, I can't disagree more. Saying "your code sucks" isn't the same as "you suck." Take a moment and reflect on why that is. It may be hard, but try to. One can be a good programmer that writes suck-ass code. I know I've written plenty of suck-ass code. I'm somewhat of an authority on code suckage. That doesn't make me a sucky coder. It just means that my code sucks on occasion. Consider this link to my first post here: My favorite part is where I explain the point of this blog: "I started this blog to impart my coding wisdom to you. My code has sucked in every way possible. Learn from my mistakes and leapfrog your way to better coding habits. Or don't. Hell if I care. Just think of me (and this blog) as your own personal Master Kan. Use it to master your craft." My code sucks just like yours does. Don't take it as an insult, it's just a fact. Realizing that your code sucks is the first step to constant improvement. Ignore that at your peril! Looking at that same post, you might take this quote and throw it back at me: "It's a rare day when I meet a coder with similar levels of skill. Maybe I just need to get out more. I don't know. But, for whatever reason, there's just not that many coders out there that can match wits with me. Hey, I'm okay with that because it makes finding work that much easier for me." Yeah, that sure sounds like a similar statement to Richard's. Can't disagree too much there. Except I'm actually a coder where Richard isn't a game designer. So, I take exception to his claims outright. The biggest difference though is that I'm generally targeting the work and not the person. That's the distinction. Yeah, your code sucks but you're probably a good coder. I'd never say "I'm the best coder in the world" or "My code is perfect" or "You're a lazy person because you don't push the code architecture envelope." Richard isn't a game designer in my opinion. He's a creative director that works at a very high level. That's an important job but it's not game design. Anyway, I could prattle on and on about this. I'll stop now because I'd rather play a Dota game with my kids. Take care and good job on your games!
"Hey, I play lots of games so I know game design!" If you've been in the game industry long enough you'll come across the dreaded "armchair" game designer. This nasty bit of work doesn't make games, of course. They play them. A lot. Even though they don't know a thing... Continue reading
Posted Mar 23, 2013 at Coding Wisdom
Thanks! Yeah, I'm a high school dropout actually. It really makes telling my kids to stick with school difficult. We homeschool though so it's not too hard to stick with it. :)
Thanks for the kind words. :) Yeah, I'm concerned that Portalarium may not be able to meet their 1 year 7 month delivery date. Controlling scope is a huge problem. If they can do that then they have a good chance of pulling it off. I'm rooting for them! Even though Richard's comments were shitty, I'm rooting for them. The project is much bigger than Richard.
Ahh, yes, that's "Heroes of Evermore." It's an MMO we've been working off and on for a while now. Took a break working on it to poop out Udder Destruction. Hopefully we can get back to it one day.
Thanks for your post, Arkhan. Although you may find me to be less polite here on my own blog rather on Facebook. Let the poster beware! First off, Richard didn't invent computer RPGs. Computer RPGs existed nearly 10 years before Akalabeth. Learn your history: But put that aside for now. I've been making computer games professionally for 22 years. Don't presume to tell me what you think the importance of game design is. I design games. I program them. I know the relative value of the various disciplines. They are pretty much equivalent. If you disagree with me, you're wrong. RG is a creative director. A damn good one too. Not a game designer as I define it. But, hey, what do I know? Part of being a professional is to make mistakes and learn from them. Agreed! It's not to verbally disparage virtually all other game developers in the world. That's not cool. Then to blame it on context. It's a dick move. Players are the most important. I agree! I learned that lesson over 15 years ago when I was making The Realm Online. Yes, yes. All well and good to keep your customers happy. Any business owner understands this! Unless you've actually worked on a video game and shipped it you have no clue what you're talking about when it comes to innovation. Companies make what customers will buy. End of story. Indie games break the mold. Most are dismal failures commercially. Some are awesome and start a new commercial exploitation cycle. That's business. Not lazy designers. Please check your facts and learn something about game development before posting here. You're embarrassing yourself.
I'm excited to see what happens with Shroud of the Avatar too. Just because I think Richard was way out of line on his game designer comments doesn't preclude me from loving his work and wanting to see his next game. I hope it's amazingly successful! Glad to see that you like our old school games. You clearly have a soft spot for gaming antiquity. :) I could write a bunch about what happened to Dungeon Runners. The short story is that it wasn't profitable enough for NCsoft to keep alive. So it was shot in the head.
All valid points, Dr. Cat. I think statements like "I think most designers really just suck" aren't being taken out of context. The comment stands alone, regardless of context. Unless, of course, the context was something like: "This is something I'd never say." It's a shitty attitude in my opinion. Sure, "great" designers are hard to find. So are great programmers or great audio guys. Superstars are rare, thus making them superstars. Great games come from average developers and superstars alike. And by great I mean profitable games that lots of people enjoy. This high horsing is just bullshit. I'm also betting that his retraction was posted under pressure from others. But that's just my guess.
"I think most game designers really just suck." -- Richard Garriott If you've landed here you're probably already aware of Richard Garriott's recent "unfortunate" comments about the state of game design today. But just in case you've been living under a rock, let's review them together now. A couple of... Continue reading
Posted Mar 21, 2013 at Coding Wisdom
Oh, I'll keep it going. Been really busy the past two weeks. Generally speaking, ebp is called the "base pointer." And for good reason. We use it as the pointer to the base of the stack frame in our functions. We do this because each time you push a value onto the stack esp is modified (decreased by the size of the thing you're pushing). Using esp to find other values on the stack makes things really annoying. The only real exception to this is when you're doing things relative to the current stack pointer on purpose. I hope that helps!
This comes as no surprise to those following the trends in technology staffing; but there is an alarming dearth of women in coding positions throughout the industry. Consider these sources for more details on this disturbing trend:,, and No matter how you slice it, there just... Continue reading
Posted Nov 2, 2012 at Coding Wisdom
These are all good questions. Let me answer each one in turn: You're right to point out that there are differences between the registers. ESI, EDI, ESP and EBP do not have the byte-sized aliases. They do, however, have the word-sized aliases (i.e. SI, DI SP and BP). I've updated the tutorial text to clarify this. ESI and EDI are generally used as indexers, although there's no requirement that they're used that way. Just habit on my part. All of the instructions that I laid out in this tutorial are single instructions (single opcode) and not macros. You're right about ccall (and stdcall for that matter). Those are macros for the two calling conventions provided by Flatasm. I'll be going into more detail on calling conventions soon. The main differences are: 1. ccall supports variable numbers of arguments. This makes it the responsibility of the caller to clean up the stack after making a call. 2. stdcall supports a fixed number of arguments. This makes it the responsibility of the callee to cean up the stack at the end of the function. The ReverseString function in this tutorial is an example of stdcall. By way of example: ccall Function,arg1,arg2,... becomes push arg1 push arg2 ... call Function add esp, (size of all args pushed) stdcall Function,arg1,arg2,... becomes push arg1 push arg2 ... call Function Whenever you call a function in x86, the EIP of the return address is pushed onto the stack. When you return from a function (using RET), that saved EIP is restored and execution continues. As you pointed out, it's critical that you clean up your stack before exiting the function (depending on your calling convention). If you don't then your code will crash. This is one of the reasons that buffer overruns on the stack can be so troublesome to debug. Imagine a buffer overrun that stomps on the return address for your function. When your function returns in that case, it returns to a bogus pointer. Nasty.
Welcome to Part 2 of my tutorial on coding. This time, we'll be focusing on registers, memory and the stack. This tutorial is quite a bit more involved than the first one. Pay close attention and follow along as these are critical skills if you hope to master coding. Let's... Continue reading
Posted Oct 20, 2012 at Coding Wisdom
Admit it? Are you high? It was obviously a sexist joke and not a statement of fact. Was it a joke about penguins? Perhaps it was a joke about genitals. Please extract your head from your ass.
Toggle Commented Oct 18, 2012 on Programming for morons? at Coding Wisdom
Please, cry more. I like it! The answer to your question? Both. The best part is when you made an anti-Semitic joke while you were trying to make a point about my sexist joke. Why do you hate Jews so much? By the way, did you see how I made fun of retards on another post? Enjoy!
Toggle Commented Oct 18, 2012 on Programming for morons? at Coding Wisdom
Thanks for the kind words. Let me answer your questions: 1) I can only think of one reason for making non-readable sections. Imagine you're making a program that has some extra "meta data" associated with it. You might only want that data to be readable by some external loading program, and not your own code. In that case, it might be useful, but it's a stretch... 2) Good observation on the "import data." You can actually drop the "data" option there and use "import readable." I just included the "data" option out of habit. I'll be posting the next tutorial in a couple of days, so stay tuned!
I guess not! Pleased to meet you! I assume you're a lady programmer. At least you got the joke. Some ass hat's can't see that I'm kidding. :)
Toggle Commented Oct 18, 2012 on Programming for morons? at Coding Wisdom
You know how retarded that sounds, right BZ? 1. You say "you use a memory manager?" 2. You then proceed to describe what a correct memory manager looks like. If your argument is that static allocation of all data is the way to go, I can agree with that on some level. But, clearly, static allocation is NOT the correct choice in all cases. For example, would you like your web browser to preallocate all the RAM it needs to service the largest web pages possible? Clearly that's a bad choice. Sounds like you just write simple programs that rely on fixed memory footprints. One day you'll graduate to writing real code! Keep at it...
I love coding. I mean, I really really love it. Some might argue that I love it a bit too much. Fuck them. :) This love of coding I have has fueled a certain level of passion about coding that has led me to a high degree of mastery of... Continue reading
Posted Oct 13, 2012 at Coding Wisdom
I love you too, "Jesters." ;)
Toggle Commented Oct 2, 2012 on Programming for morons? at Coding Wisdom
Fair enough!
Toggle Commented Sep 29, 2012 on Programming for morons? at Coding Wisdom
So, just to make sure I understand you, are you saying that everyone has the ability to learn mapping desired outcome to computer instructions? If so, I see no reason to believe this is true. Perhaps we disagree on what abstraction is. Human beings are abstraction machines. That's how we accomplish almost everything in our daily lives. We all abstract concrete reality into a personal conceptual model. That's what we do all day every day. The problem is that the computer is just somewhere else "mentally." Adapting your thinking so that it overlaps with the computer is the central issue in programming. Meaningful communication requires a shared model of the world between the communicators. Computers have no shared model of reality. The computer has no concepts at all. This puts the budding computer programmer in the difficult situation of learning how to think like a machine (as you pointed out). Hell, most people have problems talking to each other clearly. Let alone to a foreign mind that has no shared model of reality. There's just no meeting the programmer half way here. Abstraction isn't the issue. We all abstract every day. Communicating with the computer IS the issue. Speaking "computer" is the issue. That's what programming is.
Toggle Commented Sep 28, 2012 on Programming for morons? at Coding Wisdom