No Software

Things people like to do in games.

2012-01-03T11:45:00.001-08:00

Things people like to do in video games:
- Create stuff
- Destroy stuff
- Collect stuff
- Click stuff
- Get better stuff
- Wait (People think they don't want to do this, but in reality they do) (Examples: Everquest, Ultima Online, Dragon Warrior, Cow Clicker, Farmville, Tamagotchi)

However, creating a game that people actually want to play involving any of the above is nearly impossible. It's really easy to say what people like, but it's really hard to give people what they like.

Here's a game that involves all of these: you go around destroying buildings to get money to build your own castle to house all the awesome plants and animals you collect that get better every time you click on them provided that you've waited long enough after the last time you clicked, and the more you upgrade through clicking the stuff in your castle the better stuff you can find outside your castle.

I have no doubt that such a game would fail miserably.

Noobs, roguelikes, selling games.

2011-12-25T22:05:00.001-08:00

Recently there was quite a debate over at Ascii Dreams about the list of potential roguelikes of the year. Several things stand out to me about this debate. Let me preface this by saying that I'm quite a fan of Ascii Dreams and have been for some time.

That said, it seems like suddenly tons of people have come out of the woodwork to complain about omissions from (or inclusions to) this year's "Roguelike of the Year" poll. These people don't seem to be regulars on the site. Most have never commented there before about any other post. Instead, they seem absolutely obsessed with this "Roguelike of the Year" business specifically, and don't really seem to care about much else. This seems disingenuous to me. These people aren't really a part of the larger roguelike community, but they're very upset about percieved problems with this single poll. I don't know what to say about this, except that it seems very disingenuous to be totally inactive in the RL community except to complain about a once a year poll. It comes down to the fact that all these noobs want their favorite roguelikes to win, and they want their most hated roguelikes to be removed from the list. That's just childish.

A few people made comments about how roguebasin is a "fringe site" that can't compare to other sites like "planet roguelike." Now, I would bet that most people who've been in the roguelike community for more than a year know Roguebasin very well, and have absolutely no idea what "planet roguelike" is. In fact, "planet roguelike" is not even a site, but a feed of news items about rogue likes that's hidden under a small section of a much larger site. Calling roguebasin a "fringe site" while advocating "planet roguelike" is just crazy.

There are also several comments about how roguelikes have "gone commercial." There is no such thing. Roguelikes have always been sold. The original Rogue was sold at one point in time, and so were many other roguelikes (ADOM comes to mind). Just because a few roguelikes are on Steam does not mean that the roguelike community as a whole has changed at all. Some roguelikes have always been sold, and some have always been free. Nothing has changed.

I like these new commercial roguelikes. My only problem with them is that many of them (but certainly not all of them) were made by people who were completely inactive in the roguelike community until they released their commercial games. These people weren't really roguelike developers. They were random people who decided to cash in by making commercial roguelikes. That part bothers me, but everything else about the recent commercial success of some roguelikes I'm fine with.

So, please support REAL roguelike developers by buying Cardinal Quest.

Mario's jumping.

2011-12-21T19:59:00.001-08:00

Been reading a lot about jumping physics in sidescrollers, particularly analysis of Mario's jumping from SMB 1. A lot of people give complicated mathematical formulas involving all kinds of things like gravity, time squared, velocity, even mass. I constantly read things like "then gravity is subtracted" and lines like these disappoint me the most. You see, the NES didn't have floating point numbers, and didn't do any kind of complicated calculations for Mario's jumping. Simply put, Mario 1 doesn't simulate any kind of physics. How does Mario jump then?

Tables. Mario's height is added to and subtracted from based on information in a table. His jump is calculated by hand, then entered into a table, which during runtime adds or subtracts from Mario's location. The simulation of physics happens on paper before the program is even compiled. This is important because of the nature of Mario's jump. In SMB 1, Mario's jump has "less gravity" when he's rising than when he's falling. That is, the first (rising) half of Mario's jump lasts longer and happens slower than the second (falling) half of his jump. At first it may appear that some "gravity" variable is being adjusted on paper, but this interpretation is incorrect.

What really happens is that the developers calculated two completely seperate parabolas (curves): one for rising, and one for falling. They used half of the rising parabola for the first half of Mario's jump, and half of the falling parabola for the second half of Mario's jump. This makes it easier to control mario in the air while still providing a quick fall once the jump is over.

This is a signifigant advancement if you've ever tried programming jumping using only one parabola. With only one parabola, the character rises equally as quickly as the character falls, which creates either a jump that seems too fast, or a fall that seems too slow. Mario solves this by using two seperate parabolas, held in two seperate tables.

Nothing is calculated in game. Mario's position is only added to or subtracted from based on these two tables.

Programming.

2011-12-20T17:10:00.001-08:00

I have a love/hate relationship with programming that over the years has become a hate/hate relationship. Over the years, I've learned a lot about really obscure things that most people will never know or care about. For example, most people don't know how to write a matrix multiplication based software rendering 3d engine from scratch with lighting. But the other side to that is that even most programmers don't need to know how to write software 3d rendering engine. That knowledge, like so much of the other knowledge I have, is essentially useless these days. It's become obsolete.

So, you want to be a great programmer? Well, here's how you do it: you need to be fast. The core difference between great programmers and medeocre programmers is the speed at which they code. John Carmack, for example, wrote Commander Keen inside of a month. I still can't write a complete 2d sidescroller in that kind of time, and yet Carmack when he was younger than I am was able to complete one of the most popular shareware sidescrollers in 1/12th of a year. That works out to 12 games a year, when I produce at a rate of roughly 1 game every 2 years. He works at 24x my speed.

Take Notch, of minecraft fame. Apparently, he wrote a raytracing adventure RPG for a contest inside of 2 days. He did so essentially by never stopping even for a moment. Now, I happen to know a thing or two about coding after all these years, and let me tell you that never having to use the internet to look anything up comes down to one thing and one thing only: memorizing libraries. I'm always looking up what the correct proceedure even for standard library functions. Not Notch. This guy never looked at the internet, and ate seemingly only once in two days. That means that he had every function he was going to use memorized beforehand.

Memorizing libraries is harder than it seems, for various reasons. The hardest part is the fact that libraries change faster than just about anything else in life. Oh, you just memorized that library? Well it's going to be obsolete next week, so I hope you like memorizing new libraries, because you're going to be doing it for the rest of your life. That's the first reason memorizing libraries is hard. The second is the fact that it's far too tempting to just never memorize them. Why memorize something that you can look up in ten seconds on the internet? The reason to memorize libraries is that it cuts down on development time and difficulty. Looking something up once takes ten seconds, but over the course of a week you're going to end up looking things up hundreds of times, and that quickly adds up to hours of wasted time.

Another important part of coding very quickly is to move onto the next thing you need to implement immediately, no matter how hard it seems. This is the thing I'm probably worst at. If something seems hard, I end up procrastinating about it for days, even if when all is said and done it only takes five minutes to implement. The key to coding fast is to never stop, for any reason, ever. If you're having problems implementing something, throw it away, rewrite it, or leave it out. But don't take a break. Don't think about it. Don't try to plan what should replace it. Just act now and get it over with. Good programmers never stop or take break before implementing large or difficult sections of code. They approach the biggest feature of their program the exact same way they would approach the smallest.

Then there's that whole "having to release stuff" thing. That part scares the shit out of me, but it's absolutely crucial to developing games. At some point, you have to release your steaming pile of shit (and you know that when you do lots of people will call it a steaming pile of shit) so that people can do nothing but complain about something that you've poured your heart and soul into. That's just how it works. Ask any writer, or artist, or musician. Eventually, you have to release your stuff so that everyone can tell you how much it sucks and then ignore it. But that's the game. If you can't release things and stand the criticism, then you'll never make it.

Take this game I'm developing right now. It's done. 100% done, but I haven't released it. I've invested so much time, and energy, and even love into it that I don't want to see it crushed and ignored. If I'd written it faster, that wouldn't be an issue. But I've written it so painfully slowly, that now years of my life are tied up with this game. I just can't bear to see it complained about, ignored, and otherwise hated, so I haven't released it. Maybe I'll never release it.

And so, this is why programmers like me are not great programmers:
- We are slow
- We don't memorize libraries
- We procrastinate before implementing big features
- We don't want to release our finished products

And this is what makes a great programmer:
- They are blindingly fast
- They quickly memorize any new library that they need to use
- They treat big features the same way they would small features, and never procrastinate
- They never hesitate to release a steaming pile of shit, and aren't afraid to see it promptly hated

Something big.

2011-08-27T07:54:00.000-07:00

Coming soon...

Photographic PROOF Nintendo's new console will FAIL.

2011-06-08T18:23:00.001-07:00

I rest my case.

A system for stats.

2011-06-05T23:47:00.000-07:00

I've started another side project, but Tower of Madness work will continue eventually. Right now I'm trying to come up with a system for describing the relationships between player and monsters stats. For instance, strength and damage are both types of stats that have a definite relationship: strength modifies damage. I want to be able to represent this relationship in a generic sense, and I'm working on a system to do just that.

Stephen Hawking, I respectfully disagree.

2011-05-17T15:51:00.000-07:00

If you don't know, Stephen Hawking just said he believes that the afterlife is just a myth. To justify his position, he used the example of a computer. He said that computers eventually break, and there is no computer afterlife, so since we're just computers there is no afterlife. As a software engineer, I am highly offended.

So, I've decided to offer a different computer based analogy to argue that there is life after death. Specifically, I'm going to describe life as a form of finite state machine. Life in your current living state is something like this:

void LifeState(int input)
{
switch(input)
{
case STILL_ALIVE:
CurrentState=CurrentState;
break;
case JUST_KILLED:
CurrentState=DeadState;
break;
default:
/*Who the fuck knows?*/
break;
}
}

This is life represented as the simplest type of state machine, featuring only two known states: life and death. The default choice at the end allows for unknown states. Since I'm only interested in discussing life and death, default covers every other state of life that exists. This state machine switches depending on input, like all state machines, to a variety of other states. In this example, either life continues to be the current state, or life ends and death becomes the current state.

Obviously, death is a state which is switched to from the state of life. What might not be obvious is that life is a state that had to be switched to, as well. The default state is not life, because obviously you weren't born at the beginning of the universe. You were born on some random day some random amount of years ago, with billions and billions of years between your birthday and the start of the universe. The default state was non-existence: the default state was death. This means that death as a finite state machine can be represented as the following:

void DeadState(int input)
{
switch(input)
{
case STILL_DEAD:
CurrentState=CurrentState;
break;
case BORN:
CurrentState=LifeState;
break;
case default:
/*Who the fuck knows?*/
break;
}
}

From the state of death came the state of life in order for you to be born. Therefore, once returned to the state of death, there is nothing to prevent a return to the state of life, or to other unknown states. See diagram above.

Non-trivial.

2011-05-01T17:01:00.000-07:00

"Non-trivial" is an engineering term meaning "completely fucking impossible."

Binary compatibility.

2011-04-13T16:47:00.000-07:00

Users want binary compatibility. Linux was originally designed to prevent binary compatibility, to encourage people to distribute source code instead of binaries. But this, I think, was horribly wrong. At the end of the day, normal users, every day users want binary compatibility. Programmers like to think of themselves as engineers, and from an engineering standpoint not listening to the demands of normal users is pretty awful.

The default copy constructor is your friend.

2011-03-12T21:52:00.000-08:00

The default copy constructor loves you. It is your friend. Use it.

For all it's downfalls, the default copy constructor is really quite useful.

7DRL fail: FarmCraft.

2011-03-11T21:49:00.001-08:00

So I'm not going to be completing FarmCraft for the 7DRL. I've just lacked the motivation and desire to complete it this year. So, good luck to all the other contestants, particularly Slashie who is working on an amazing crime fighting action game! Good luck to all!

In the future software will write software for us.

2011-03-09T03:08:00.001-08:00

Don't worry: we'll still write the software that writes software for us.

And now for something completely different.

2011-03-04T00:19:00.001-08:00

I hope that phrase isn't copyrighted. Anyway, here's the reason (aside from the obvious) that I'll never be a massive internet success millionare ala Mark Zuccer-how-ever-you-spell-his-name-berg . I will absolutely never, ever understand why people prefer some products with less functionality when the products they're competing against have vastly more functionality. Not sure what I'm talking about? Let me give you an example, the example really: Twitter.

Blogs have been around for FUCKING EVER. Oh sure, the word blog is somewhat recent, but the basic idea has been around forever. And they've never been very popular, except for that brief moment when LiveJournal first opened. But what happens the moment someone comes out with a vastly worse product that specifically contains less features? Everyone fucking loves it! Twitter limits people to 140 (or something like that) characters. It's a blog, but with a character limit. And people are all over it like it's the greatest thing since Facebook. I simply do not understand. I'm sorry, I just don't get it. Why would you want to limit yourself to 140 character? That seems kind of dumb, when every other product online (including e-mail and even fucking USENET) offers vastly more characters. It seems to me, in every way, that this limit is a disadvantage. Yet people love it. I do not understand.

Here's another example: Facebook. Facebook is myspace, except you can't customize fucking anything. Thanks facebook, what an upgrade. This is bad enough on it's own, but here's the worst part: I hated myspace when it debuted for the SAME REASON. Myspace was a shitty personal webpage that you could barely customize compared to every other personal website on the internet. And yet people LOVED it. It was way worse for communication than e-mail, and yet people almost immediately started preferring it over e-mail. To this day, I am baffled. Why do we exchange Facebooks instead of e-mail addresses and personal websites? It makes no sense to me.

Finally, the grand triumph of my confusion: Amazon.com. A long time ago (this is a true story) a few months after Amazon.com went onto the stock market, an old friend of mine told me he was going to be rich. Why? Because he bought an absolutely ridicules amount of shares in Amazon and it was about to take off. When he said this, I laughed in his face and told him that Amazon would never succeed because it was an awful website with a horrible layout that no one will ever use. Amazon to this day has an awful layout. But I'm certain that he's sitting somewhere right now, sipping wine, rolling around in piles of thousand dollar bills, and laughing in my general direction.

Sometimes, people prefer less features. I don't know why. I can't explain it. I don't understand it. It just is. And that's how all these Mark whats-his-names do it. They somehow magically divine which features people prefer to have less of, and which features people prefer to be annoyed by. How they do that, is beyond me. This is a drastic over simplification of course, but it illustrates that I have no idea why so many people prefer less features over more features.

7DRL Soon!

2011-03-03T20:27:00.000-08:00

This Saturday (3/5) is the 2011 7 day roguelike competition! If last year is any indication, it should be a fantastic competition with an incredible amount of sophisticated game entries this year. There have been several 3d roguelikes created recently in very short periods of time, so there will probably even be a number of graphically impressive roguelikes. Over all, it should be a fantastic time, and of course, I plan on competing.

I decided on a game plan fairly late in the process. Here are some of my early ideas:
- A science fiction action game taking place on Venus
- A zombie defense game
- A castle building game
- A slightly warcraft-ish strategy game
- A wolfenstein like game

There is one problem with these ideas: they all take too long. Except maybe the zombie defense game, but come on, there are tons of zombie defense games out there. That would be booooooooring. Anyway, my new game plan is fairly original, easy, quick, and fun. Plus, I've been wanting to do a game like this for a while. What is it? You'll see :)

I'm going to sell it, too. It's price will be somewhere between $1-7 dollars. I'd really like to price it at 7.77, but that's a bit too much for a 7 day roguelike IMO. So, I'll probably price it at 1 or maybe 1.77 or something. Maybe 0.77. Don't worry, there will be a shareware version.

What will it's graphics be like? Frankly, I haven't entirely decided. I like the direction Slashie has been heading in his development philosophy. Recently, he's been advocating that a major advantage of roguelikes is that you don't need to be an expert in advanced graphical programming to create them. That is a pretty big advantage of roguelikes. In the past, I've gone in the opposite direction by trying to make a 3d roguelike. But I think there's something very true about what Slashie is saying. There is something special about being able to build a video game and not having to worry about advanced graphics. Even if we suffer from a lack of players, perhaps this is a feature that's worth sacrificing players for. Maybe simple graphics are a core feature of roguelikes.

What counts as simple graphics? That's the biggest question of all. When I made Underhall (my 3d roguelike), I was trying to create a roguelike with simple 3d graphics. However, an ironic thing happened. I feel like Underhall has 3d graphics that are too good, but most of the comments about Underhall's graphics were that they needed to be better. Over all, Underhall having good graphics didn't pay off very much compared to Dreamhack having bad graphics. In the end, I'm not sure it's worth the trouble to put 3d graphics in roguelikes. I'm still going to try to create a 3d roguelike several more times, but not for the 7DRL, and not in the way I went about it before.

For my 7DRL, I'll be using the fantastic libtcod. If you haven't heard about it, it's one of the best libraries for roguelike development ever made. In the future, I'd like to try working on more tile based roguelike games. The tile based roguelike I particularly admire for it's graphics is CastlevaniaRL. I'd like to develop a roguelike that looks something like that some time in the future.

Jeff Vogel (Of exile/avernum fame) on Difficulty.

2011-02-10T19:45:00.000-08:00

As I just posted my recent thoughts on video game difficulty, I was surprised to see that the legendary Jeff Vogel did the same on his blog. He's way more experienced/real programmer/hardcore than I am, so you should go and read his article here.

On a side note, I once tried beta testing for Jeff Vogel, but school caught up with me and I just sort of disappeared. I'm apparently a much bigger fan of Geneforge than Avernum these days (I was testing Avernum 6). I feel quite guilty about it, but there's really nothing I can do about it now.

No One Wants to Play an Easy Game.

2011-02-09T16:37:00.001-08:00

We might think that we want to play easy games, but the truth is, we don't. As counter intuitive as it is, many of the features that we find difficult or dislike in games are the exact features that make those games fun. If you were invincible in Doom and had unlimited ammo, no one would want to play it. The same features that make games difficult or even irritating are really the only things that keep us playing.

Don't just take my word for it, try to play Nethack on Wizard mode, or Doom with invulnerability. It quickly becomes very boring. Even if you don't like dying in Nethack after drinking from a fountain, you still return to that fountain over and over. Further, you return to Nethack itself over and over. We think that we don't want to be killed in Nethack after drinking from a fountain, and yet this outcome is exactly what keeps us coming back. In a way, we really do want to die after drinking from a fountain in Nethack.

For a personal example, I hate that Doom's Nightmare mode causes the enemies to shoot faster than the player can physically shoot. I just think it's unfair, and it annoys the hell out of me. But if the enemies were just as easy on Nightmare as they are on the easiest difficulty, then I would promptly stop playing all together. This feature that I hate is the exact feature that makes me continue playing this game.

Players secretly love the features that they hate. They don't want an easy game, they want a game that they lose at, over and over and over. They want not just a difficult game, but a steady increase in difficulty to make up for the increase of skill in the game. It's no fun playing one easy level after another with no increase in difficulty, even if we are frustrated by a game's later difficulty. Counter intuitive, but true. A game which is not difficult becomes an automatic, mechanical, and boring repetitive process.

Google Phone's Useless Features.

2011-02-08T01:33:00.000-08:00

I'm picking on Google phone here, but only because it's such a great example. The following is from their marketing material, where it tells the potential customer all about the AWESOME and AMAZING features of a Google phone that are so unbelievably cool that you have to buy one RIGHT NOW. The problem is, all the things they list are completely useless stereotypical things that sound good to someone who doesn't know anything.

Product Features

* Android 2.3 <--- [This number is totally meaningless]
Packed with the latest Google features.

Oh. My. God. You mean it comes with the latest software, and not that crap from last year? I am SHOCKED. The problem is, stuff we buy is always expected to come with the latest software. That's why it's the latest software, because it's the stuff from, you know, right now. Also, 2.3 is a totally meaningless number to everyone except really obsessive people who track what the latest features of Android 2.3 are over 2.2. Was there a 2.2? I don't even know, which just shows how even most technologically skilled people don't even know what this means.

2.3 tells me nothing, and the "latest features" is exactly what I expect everything I buy to have. This might as well have said "* Android." But that's worthless too, because I know that Google MAKES ANDROID. Of course it's Android, what else is it going to be? Microsoft Windows 7?

* 16GB of built-in memory
Lets you store contact information, phone numbers and more.

16 GBs! Wow, I have never seen a number that big, ever. I can't even count that with my hands, so it must be pretty huge. Come on, my flash drive is half this size, and I got it for $20. I can barely remember when hard drives were less than 16GB. Oh, I can remember, I remember when hard drives were 500mb, but that's exactly my point. This number, like the "latest features," is tied to the time when the product came out. Outside of that context, this number has no meaning. Next year, it'll be different, and last year it was equally as meaningless. Yes, you can hold stuff on it, probably about as much stuff as most other phones allow. That's what anyone buying a phone expects, that it has about as much storage as the other phones.

And, how the hell is "lets you store contact information" a product feature? DOS could store contact information. I'm sure that microsoft marketed DOS at some point as a great way to store phone numbers and contact information. Computers have been storing phone and contact information since the beginning. This is not a feature, unless you've never used a computer before. Ever.

* Contour display
With a comfortable, smooth grip provides maximized visibility and usability.

Comfortable is completely arbitrary. What one person thinks is comfortable can be totally painful to someone else. Equally, smooth and usability are both totally arbitrary and person. What this should say is "Contour display: Maximized visibility." Except that I'm not sure anyone has ever been concerned with a phone's visibility. Usually, the screen size is a fairly good indicator of visibility, and if you don't like the size you get a bigger screen. And what is maximized visibility in comparison to normal visibility, anyway? How much larger than normal visibility is it? And how much visibility are you really expecting from a phone that fits in your pocket, anyway?

* Built-in hotspot capability
Share an Internet connection with others.

Okay, that's pretty cool, but it doesn't actually tell me anything about it. How fast is this connection? How much does it cost? Can I use it too, or just other people? Can my phone just be my entire neighborhood's internet connection from now on, or are there some details being left out here? What this really says is "* May sometimes provide crappy internet connections to computers for a fee." Now does that sound like something you want?

* The latest Google features
Including YouTube 2.0, Gmail and more.

The LATEST features! OMG!

* Built-in Wi-Fi 802.11b/g/n network
For Internet capability (additional fees may apply).

Who came up with 802.11b, anyway? That's a totally arbitrary number if ever there was one. Where is 802.3a? Where is 799.6b? These do not exist, this number is worthless marketing crap. What this says is "* Built-in wifi." Yay. Because that's what I always wanted out of my phone, the ability to access my network. Oh, and thanks for letting me know that this is for internet capability. I would have never figured that one else. Of course wifi is for the internet, what else is it going to be for?

* Virtual QWERTY keyboard
For quick and easy text messaging.

As compared to slow and painful text messaging I suppose. More importantly, who is deciding the definition of quick and easy, here? A number pad might be "quick and painless" compared to someone using morse code! By Virtual QWERTY keyboard, they mean "* Program we wrote that emulates a keyboard." Amazing, I don't know how they've managed this incredible feat of software engineering. Must have taken them years.

* 4" WVGA display with 480 x 800 resolution
For clear viewing of your text messages, photos and videos.

Now that whole "maximized visibility" thing just seems insane. 480x800? That's very close to 640x480, which my old 486 used to run at. Impressive technology here, guys, impressive, it's almost 20 years old.

Also, clear viewing? Really? That's what glasses are for, not your phone. And it'd better have clear viewing. Who would buy a phone with completely unclear viewing? There are no phones without "clear viewing of text." I wasn't even alive the last time they manufactured a computer that didn't have "clear viewing of text."

* 5.0MP digital camera with autofocus and flash
Lets you snap photos to share with friends and family.

Megapixels. Don't even get me started. Another worthless arbitrary number, and it has autofocus! WOW! Why, that's the awesome feature that no camera has been made without in the past 30 years! AMAZING. And this ad is kind enough to let me know that cameras allow me to take photos, which I would have never thought up on my own. Further, I really doubt that any cell phone camera ever has come with manual focus. I just don't think it's happened.

* Google Maps and Google Mobile services
For improved phone functionality and navigation.

Google maps, there's a valid point. I can now look at Google maps on my phone. Which will allow me to... Well, here's ye old typical joke chart:

1. Get out my phone.
2. Access Google maps on my phone.
3. ???
4. PROFIT!

Also, how does Google maps improve my phone's functionality? Does it make the volume louder? Does it make people's voices clearer? And navigation. Yeah, that would be great. If driving while on your cellphone were a good thing, that would be awesome. Does Google really want everyone to be driving around staring at their cell phone? While driving? Really?

* Built-in MP3 player
Lets you enjoy your favorite tunes.

It has an MP3 player. Which would have been great, in the 1990s, when people still used mp3s instead of other formats like FLAC. Sure, I've got some MP3s still, but come on. Every phone from 2000 onward has had an MP3 player. This isn't a feature. It would be a bigger deal not to have one than to have one. And yes good, I do know that an MP3 player allows me to listen to music. Thanks.

* Built-in video player
Lets you watch movies, TV shows and home videos.

IN 480x800? ON A SCREEN THAT FITS IN MY POCKET? That's just not going to work. It's just not. Either my hands are going to get tired of holding my phone, or my eyes are going to get tired of staring at that tiny screen, or my ears are going to get tired of the headphones, or I'm just not going to be able to see a damn thing because the screen is the size of my palm.

* Easy scroll
Makes Web browsing simple.

What the fuck is easy scroll? This tells me NOTHING. NOTHING. Apparently, there is this magical, incredible thing, called easy scroll, that magically makes web browsing simpler. First, I want to know how web browsing is not simple. It seems pretty straight forward to me. You click on stuff, and that takes you to other stuff. Seems just about as simple as can be. And how will "easy scroll" (Whatever it is, and however it works, which I don't know since Google hasn't told me), how will "easy scroll" magically make web browsing simple? It won't. It doesn't.

I'd like to say something to sum up here, but it's late and I'm tired, so I'll leave with this: these useless, worthless, horrible bullet points are awful and say nothing, but Google spends a lot of money to come up with them and sell them to us. Do they work? Would Google use them if they didn't? Maybe.

There's an old business saying, half of your marketing doesn't work, the problem is you never know which half. Which half is this? I think it's the worthless half, but Google disagrees. Who am I to question them?

Bug... Or Feature?

2011-02-06T01:37:00.000-08:00

Leather Javelin. Cloth Crossbow. Glass Cape.

I'm not sure whether to remove these fantastic items, or allow them to exist. But I'm so amused by them that I'm leaning toward acceptance. Well, maybe not the cloth bow, but the others could work. Here's another: Wool Rocks. As in, rocks made from wool, not wool is awesome.

Added some stuff to Underhall.

2011-02-01T22:46:00.001-08:00

Just a few graphical updates. I'm preparing to add a few more, but nothing major. Actually, I've done a lot more work on my libtcod game, but I haven't worked on it as recently as I've worked on Underhall.

For my libtcod game, I added a lot of interesting items, and started work on an editor for the monster data. Ultimately, I don't think I'm going to end up using the editor. Creating and using a crappy editor is much more painful than just hard coding all the enemy and item data. Which is sad, because I don't like that solution either, but at least it works fairly well. I'll probably just create a few unique files specifically to hold all the hard coded data. It's not an ideal solution, but nothing is.

Eventually, I'm going to combine my Underhall engine and my libtcod engine into a single engine. This will mostly involve the cannibalization of Underhall, and the preservation of my libtcod engine. But there are a few things I'm going to change in the libtcod engine, too. The general goal will be to preserve both modes of operation: ascii and 3d. Adding a tiled version is trivial, since libtcod is awesome enough to use SDL. Then, it should have 3 modes: ascii, tiles, and 3d.

And it'll probably still have hard coded enemy and item data.

Libtcod Roguelike First Screenshot Ever!

2011-01-19T13:10:00.000-08:00

Here's the first screenshot ever of my commercial libtcod game:

Also, at the extended requests of Ido, I plan on enabling commenting on my blog. Enjoy! :D

AMAZING graphics!

2011-01-03T22:15:00.000-08:00

This article from the NY times is written by someone with about as much knowledge about computers as my great grandmother. What really makes me laugh is when the journalist says "the accompanying technology meant that amazing graphics would be commonplace in a couple of years." AMAZING graphics you say?! In only a couple of years?! This sounds just like:

Yes, the NES. Every generation of graphics is called amazing, and the old generation is called horrible. This happens every year, year after year, and yet not even the New York Times seems to have caught on yet. The Commodore 64 didn't have good graphics when it came out, and neither will the graphics cards that come out in 2012. That's just not how the industry works. Better graphics will be released, sure, but in a year or two those graphics will be just as horrible as the NES.

Sidetracked by the NES

2011-01-02T18:22:00.000-08:00

I had planned to do a lot of work on my new libtcod game, but ultimately I've done very little. Instead, I've been playing around with programming on the NES. I've always wanted to program something for the NES, but the task of learning NES assembly always seemed daunting. Well, not anymore. I've been doing a lot of NES programming lately, and it's a lot of fun. I've even bought one of the legendary NES Power Paks, to allow me to develop software on an actual NES. Of course, NES development has some downsides.

The game I want to make is a castlevania clone. Unfortunately, this means I'll have to learn how to do a lot of different things on the NES all at once. So, I've given thought to making something smaller, such as a Super Meat Boy clone. Ultimately, I've come to the decisions that easier games would be just as much work to develop while being vastly less satisfying. Even if a castlevania clone is hard to make, it would ultimately be more fun and more satisfying in the process. Why develop something easy if it isn't what you want to develop?

If I complete this castlevania game, I plan to submit it to retrousb.com for publication. If you haven't heard of them, they're the same people who make the power pak. They've also published quite a few independent NES games, such as Battle Kid.

Work and Underhall 2.

2010-12-10T02:15:00.000-08:00

I've worked on my libtcod roguelike some. There are now some nice effects and various nice menus under certain circumstances. My to-do list grows shorter seemingly every week, or at least every other week. Finals are next week, so I'm not sure how much time I can devote this weekend. However, after finals I'll have tons of time, so I might be able to actually release this roguelike around January. Maybe, maybe not, we'll see :)

After I've released this roguelike, I'm going to completely rewrite Underhall's engine. The game will remain essentially the same, just with a much better engine, better dungeon generation, and more items. Then I'll release it and begin work on Underhall 2.

Underhall 2 will be a traditional Elder Scrolls: Arena-like game, except that it will also be a roguelike. It'll use the same engine as Underhall, but it's scope will be much larger. There'll be an overworld to run around on, different towns to visit, better plot, that sort of thing. The setting is going to be really fantastic. It'll involve dungeon diving, castle raiding, all sorts of great Elder Scrolls series like things.

For graphics, I have two options. Either I try to model everything in 3d myself, or I admit defeat and use high quality 2d graphics. Of the two, I still don't know which one I'm going to use. I may actually end up trying to model everything. That will require restricting the number of enemies, or at least the number of enemy models, which is not necessarily the same thing. Still, I'm conflicted.

C++ libraries.

2010-12-02T04:11:00.000-08:00

I've been programming in C++ for a long, long time now. Due to this, I've abandoned many conventions used for safety. Things like checking input in a function for validity before using it. I can get away with this, because I know not to pass a function something that it can't use. And believe it or not, I really don't suffer any problems due to this. I've been using C++ for so long that I just know what a function can and can't accept and act accordingly. For this reason, I hate private variables more than any other part of C++.

Yes, I understand their use perfectly well. It's to keep me from unknowingly breaking things, causing bugs, causing structural havoc, using things in inappropriate times and in inappropriate ways, and so on, and so on. But jesus christ, I know what I'm doing. If I want to access one of your libraries' variables, just let me do it. I'm not going to break anything, I've already read the functions in your library that use these variables and I know how they use these variables. If I want access to them, it's for a specific and concrete reason, usually related to functionality that your library is lacking.

In the current library I'm playing around with, I want to bypass a lot of slow and useless functions by accessing some private variables directly. I know what I want to do will work, and it will work just fine, but the variables are private so I can't. I'm essentially trying to work around the slowly written functions of the library, but I am prevented from doing so, just in case I'm an amateur.

Library writers: if someone wants to access an obscure variable in your library, just let them. Anything they break is only going to harm themselves anyway, and if they want to use some of your obscure variables, it's probably because they know what they're doing.

More work on my new roguelike, and thoughts on marketing.

2010-11-28T16:49:00.000-08:00

I've added an absolutely ridicules amount to my new libtcod based roguelike. I've begun maintaining a list of additions, so that I can view my progress in a more straightforward way than trying to remember exactly what it is I added. Preferably, I'd like to track the hours involved too, much like Slashie does his for his projects, but I haven't looked for any good program to track development hours and such yet. Now, I should be working on school work, but what do I find myself working on? The following:

+ Skills
+ Stairs
+ Links between maps
+ Better dungeon generation
+ Better graphics
+ Drinking potions, reading scrolls, casting spells
+ Fake names for unidentified items
+ Character classes with skills and spells
+ Better titlescreen
+ Better menus
+ Random player names
+ Ranged weapons
+ Better main menu and better character generation
+ Special effects
+ Shops
+ SAVING AND LOADING

I put that last one in bold because it's an important one. Saving and loading is not a feature I implement in games often, partially because I hate dealing with file io. It's a fairly serious and complicated thing to add, too. But I've done it, saving and loading is implemented. It took me the better part of a day that should have gone to school work, but it's done.

Why have I worked so hard on this roguelike? Well, it'll be my first commercial video game. Yes, that's right, I'm going to charge hard cash for it. And it won't be cheap, either. I plan on charging almost as much as a brand new in store video game. Don't worry though, there'll be a shareware version, naturally. Although I hate to give away "My Secrets," I'm charging this much for the following reasons:

1. I don't plan on selling many copies. This is economics 101: If you know you're only going to sell 10 of something, it'd better be expensive if you hope to make any money.
2. I believe the people who do buy it will buy it regardless of if the price is $1 or $60, not that I'm going to charge either of those.
3. Price is a real reflection of value that the consumer recognizes. A product priced at $10 is valued less by the consumer than a product priced at $100, regardless of what the product actually is.
4. People are used to paying a certain price for new video games. If I price my product below this price, it appears that my product is somehow inferior to games available in stores.

This brings me to another recently released commercial roguelike: Hypersilence. I have some doubts as to how many copies this game has actually sold. It's creator claims over 6 within the first day, which to me seems impossibly high, especially given the numerous negative comments the game has received in various forums. However, assuming for the moment that this game has sold well, I'd like to give a reason why: marketing. What the creator of Hypersilence has been very good at is marketing his game's every release on every major video game forum. Hypersilence not only markets itself very well, but it is sitting on a somewhat valuable domain name. Apparently, Hypersilence.net at one point hosted open source PHP scripts, and according to Google used to receive fairly heavy traffic.

Marketing is a fundamental part of business that we roguelike developers often overlook. We overlook it probably because most roguelike developers do not think of themselves as in business, since most of their games are free. Still, it is a tried and true business principal that you can have the best product on earth and without marketing it will not sell. Products do not sell themselves, especially in a market which is flooded with competitors all offering essentially the same product with few genuinely distinguishing features. The video game industry is such a market. Every game has many competitors which are essentially identical, in such perfect competition the only way to distinguish yourself from your competitors is through marketing.

After this game is released as a commercial game, I'm going to update and release Underhall as a commercial game as well. Then, I plan on upgrading the Underhall engine and producing a sort of "Underhall 2." It too will be released commercially, of course.

More work.

2010-10-23T14:14:00.001-07:00

Here's some new stuff I've added: spells, scrolls, wands, staves, rings, effects, classes, autoget, and various user interface improvements. Next up: ranged weapons, stairs, stores, help, the tutorial, and saving/loading.

The work done this weekend.

2010-10-17T22:27:00.001-07:00

Well, the weekend is over, and I've accomplished quite a bit. To my new libtcod game I've added food, hunger, eating, armor, wearing armor, weapons, wielding weapons, enemies attacking, enemies dying, and various user interface improvements. Also, I've started on magic items, which has taken more time to get going than I thought it would. Over all, it was a highly productive weekend.

The magic system ran into some problems, but they were fairly minor. They centered around one thing. Specifically, that a magic item has to know 3 things to work: the character using the magic item, the target of the item's effects, and the item itself. To put it simply: the source, target, and item. Previously, I was only handling magic effects that required a source and a target. But most effects also need to know the item in question. So, I had to change everything to specify what the source, target AND item involved in magic effects is. I tried to find a way around this, which probably lost me far more time than it was worth.

Currently all my text is in past tense. I thought this would be nice, because generally in books past tense is very nice. But in roguelikes it sucks, and I'll very shortly be converting all my text to the present tense.

Along with this, I've also got to expand the message log. Currently, the message log is 3 lines. It'll be expanding to 8 or so, which corresponds to the amount of enemies that would surround the player under a worst case scenario. Of course, ranged attacks can cause the player to receive more than 8 attacks in a single turn. But if you take into account ranged attacks then I suppose there's no upper limit on the amount of attacks a player might suffer in a single turn. I suppose what's really needed is a scrollbar, which I might actually put in.

Addendum: I tried to change everything to present tense, but that turned out to have problems of it's own. So, I'm sticking with past tense.

Unified items.

2010-10-14T23:56:00.001-07:00

I'm currently working on exactly 3 long term programming projects. Specifically: Dreamhack, Underhall, and my new libtcod based game (Tower of Madness, I might rename it again soon though). All of these are roguelikes, and fairly similar roguelikes too. So, I've been thinking about creating a single item system that would be portable between all three. Not sure how I'd go about it, exactly, but it sounds nice. That way if I add items to one, I could add those items potentially to all three.

Underhall is the project I've most been meaning to work on, and unfortunately it has a horrible item system. It also has a horrible dungeon generation system, compared to my new libtcod based game. Essentially, I want to port my libtcod game's item system and dungeon generation to all my other roguelikes. It's much easier said than done, though.

By far, the hardest part is that I have no time. I've been spending an absolutely ridiculous amount of time reading for college. Practically all my spare time is used up reading. It's not so bad, really. I just never have any time for programming.

Tomorrow, I've got some time off finally. So, I might try working on Underhall. Who knows what I'll add to it, but definitely something :)

Added: Panning.

2010-07-30T01:35:00.000-07:00

You can now pan the camera around the map in Tower of Madness by holding down the right mouse button. It's a bit cooler than it sounds, I'm having fun playing with it. It was fairly quick to add today, too. Took almost no time, and almost no code. Not a lot else got done today, unfortunately. I did add a bit to the random dungeon generator. Now mazes might occasionally pop up, among other things. I'm excited to show this dungeon generator off, I think people will like it.

Next I might start working on enemies and combat, probably implementing wearing objects while I'm at it. Things are coming along very nicely, I've decided that the hack I disliked yesterday is not as bad of a solution as it first seemed. It works, and it seems to run fairly fast. What more can I ask for?

There's still a ton to be done. The menu system needs finishing, more menus need to be added... Also, I'm planning on displaying the names of items and enemies on the map when your cursor is over them. So much to do. I'm going to go pan the camera on the map around for a while.

Work on Tower of Madness continues.

2010-07-28T21:40:00.001-07:00

I've been working a lot on my fantasy roguelike Tower of Madness today. Although the project was nearly abandoned, I decided I'd like to keep working on it. I did a ton of work on it today, to say the least. I added a player inventory screen, picking up items, stacking items, doors, a message log, and the beginning of more advanced items and enemies. When I list it like that, it doesn't sound like a lot, but it's still quite a bit of work.

The only thing I'm upset about in terms of the code is the way I'm handling doors and enemies with libtcod's pathfinding and visibility. The map in my game doesn't change a lot, practically never, so ideally libtcod's internal map should almost never be updated. However, since I want libtcod's pathfinding to take into account enemies and doors, this internal map has to be updated every frame. Not only that, but in order to path find onto enemies and doors, I had to implement a rather strange hack. This is because doors and enemies should be counted as walls, unless you're pathing directly to them. It all works, but I'm not terribly happy with the solution.

I currently loop over every object on the map 6 times per frame. That isn't so bad for a roguelike, especially considering I'd need to do it probably at least twice (once for updating and again for drawing). But it's still annoying that I'm looping over a large linked list 6 times every frame. All this looping could probably be condensed into a single loop, but that presents technical challenges of it's own. It's a conversion I may eventually make, but since performance hasn't tanked yet, I'm holding off on an overhaul for now.

The object system I'm using is a bit unique. Absolutely everything in the game aside from the map is represented by a single class called Object. Everything from enemies to items to the player are all Objects. This works very well since everything that all objects need is contained in a single place inside a single class. This allows functions that copy all objects, or that save all objects to be written with ease. The only downside is that the base object class occasionally suffers from variable bloat. That is, a lot of variables get added to the class that apply to a single type of object (such as doors). But this is a fairly minor downside.

Over all, I like the direction that the engine is heading as a whole, but this hack to implement pathfinding to doors and enemies is really annoying me. It's a fairly small part of the code, but it just bugs me that it's there at all. I feel like there is an easier solution staring me in the face, and I just don't see it. But work will continue, the engine will press forward, hacks or not.

Writing entertainment for 100 people.

2010-07-21T04:21:00.001-07:00

Every game I've released has had roughly 140 downloads. I estimate that this probably translates into roughly 100 real players. For a long time now, I've been pretty depressed by this, but recently I've started to look at things differently. Even though I'm never going to reach thousands of people, or tens of thousands, I can still produce something fun for the 100 people who actually play my game. So what if my games have an audience of 100? I still get to try to entertain them with my game. Really, I should be grateful that I have an audience at all.

100 people isn't so bad. Some might even say that's a lot. Sure, it's not an enormous amount, but it's a good number of players. If I can make some of them have a good time for a couple of hours, then 100 is probably as good as 1000, or 10,000. Plus, this particular 100 is not very picky. Dreamhack was highly experimental, yet roughly 100 people played it semi-happily. Over time, I'm sure I can improve my games in ways that matter to these 100 people.

Having a small audience is not so bad, actually. I could probably physically talk with every person who played my game, if I knew who they were of course. What that means is that I can realistically respond to their preferences. If I had an audience of several thousand, I would likely have to ignore many of their requests. Instead, I can heavily customize my game for 100 people.

Over all, having a small audience isn't so bad. It might be hard on the ego at first, but 100 people is still a lot of people.

Rogue Survivor.

2010-07-17T22:11:00.000-07:00

I've become absolutely addicted to Rogue Survivor, recently. It's like Left 4 Dead, but with more complex gameplay. Amazing game, over all, and every time I play it I want to write a game just like it. But I could never do quite as good of a job as it's creator has already done. But what game do I want to make?

I don't know. I don't really want to make a fantasy game, and I don't want to make a zombie game. Science fiction doesn't sound fun either. In fact, nothing sounds particularly fun to write. I feel drained of ideas completely. Well, almost...

I'd like to do a harvest moon clone. Unfortunately, I'd also like it to have decent graphics, and I don't feel like making as many graphics as it would require. Let alone writing all that annoying display code. So, since that's out, there's really nothing I'd like to work on.

I've done quite a bit of work for this fantasy game, and part of me wants to finish it. It's a nice engine, good graphics, nice dungeon generator, but I just don't care about finishing it. So, if I do work on something else, I'll end up converting the engine to a different game. But what type of game? I'm thinking maybe post-apocalyptic. Not like Rogue Survivor, more like Fallout or specifically Alphaman. I've wanted to work on an Alphaman clone for some time, and I never have. So it seems pretty suitable. But it's very close to Rogue Survivor, in a sense, and I don't want to compete with it.

Dreamhack is another option. There are a lot of things I could add to and improve about Dreamhack. I just hate Dreamhack's codebase. I'd really like to overhaul a lot of the code, but it's much too late for that. The engine is essentially done, so I might as well work with it rather than trying to rewrite it. Still, Dreamhack never seemed to catch anyone's attention, much. I'm not overly excited about working on it again.

All of this leaves me in a creative rut. I don't want to work on anything, really, but I still want to work on something. But what?

Motivation (or lack thereof)

2010-07-05T21:20:00.000-07:00

I've had no real motivation to program recently. Underhall was released for this years 7DRL, but it's downloads were highly disappointing. I worked pretty hard on it, so it's always disappointing when the number of downloads don't match my expectations. I suppose it would be much healthier to not look at the download count at all. But that would just be willful ignorance.

I started work on a new game, using libtcod. The new game's name has changed a couple of times, and it liable to change again before I release it. If I release it. It was originally called Tower of the Dragon, now it's called Tower of Madness. It's your typical roguelike dungeon crawl, nothing particularly special about it. Perhaps that's why I'm having such a hard time finding motivation to work on it. There is nothing particularly unique or special about it, which makes it a bit boring to work on. I feel like "oh now gold is implemented, who cares?"

Recently, I've been playing some roguelikes with "unusual" themes. I'm particularly impressed by Rogue Survivor and Privateer: Ascii Sector. I suppose I just don't want to develop a fantasy themed roguelike right now. I feel like doing something along these lines. Either science fiction, or post-apocalyptic or at least something different. I want to write something with a tileset, involving guns and cities. Something Left 4 Dead like, but without the zombies.

The problem is, I don't know if that's what I'll want to do in a week or two. Maybe I'll want to develop this fantasy themed roguelike again. Maybe I'll want to develop something completely different. Right now, I really have little motivation to develop anything at all.

I actually have a slightly more recent version of Dreamhack and Underhall just sitting around on my hard drive gather dust. I don't really want to work on either, and the few features I've added are incomplete and rather minor. There are bugs that need fixing in Underhall and Dreamhack, but I really don't want to work on them. Why bother when they will only ever have a hundred some odd downloads at the most? The one I most want to fix is Dreamhack, because it's so incomplete. But it's code is also the most annoying to work with between the two of them. Eventually I suspect I'll release a new version of both, not that anyone will notice.

I'm becoming quite jaded about download count, obviously. It all started with Dreamhack, which had fairly poor downloads. I assumed that it was because Dreamhack was unusual and had bad graphics. So with Underhall, I tried to fix both of those problems by having a traditional fantasy theme with a nice 3d engine. Despite my best efforts, Underhall turned out almost identical to Dreamhack in terms of downloads. It is as if my efforts were totally worthless. This has made me become quite jaded about things, and I don't hold out much hope for any other games that I release to do any better in terms of downloads. It's sad, really.

But, I'm still proud of my minor contributions to gaming. So I've been thinking about creating a better website for No Software. It's probably the project that I'm the most motivated to complete. I'd like something like Slashie's website, such that it prominently showcases each of my games. But even that I'm not very motivated to do...

Rendering optimization, and why Java is the future.

2009-11-21T13:42:00.000-08:00

Man, I wish I'd stuck with math when I was in high school and middle school. It would have helped me a lot in the end. So let this be a lesson to you, kiddies: stick with math. It gets better. By now, I am only starting to have a grasp of algebra, and I will never be able to take trig or calculus, or even geometry. But algebra I have quite the beginning of a handle on. And believe me, it's helpful.

My new favorite function is atan2, as it has been for some time. Atan2 will calculate the angle of any line. I know of no other way to do this, probably because I have never taken and will never take geometry. The important part is, knowing the angle of any line is quite useful.

I've been working on this 3d engine, the first good one in a while. I've already made some pretty impressive progress. Using atan2, I can quickly and easily weed out anything from displaying that is +-45 degrees from the view direction. This means, I'm only ever rendering 1/4 of the total possible polygons I could be rendering. Additionally, I've added sprites that automatically rotate to face the player using atan2.

This is a very strange engine I'm developing. It's a tile based 3d engine. The map is composed of equally sized cubes arranged on a grid. This should be fairly fast to render, but initially I was having difficulties. I had tried to use a C++ map for the textures. This way, I could refer to textures by name. But of course, this requires one string comparison for every texture per frame.

The overhead of the map structure itself is not so bad, but 60 string comparisons per second as a minimum is quite the overhead. Since there were four textures, that's 240 string comparisons per second. This was however easily reduced by using numbers to refer to textures instead of strings.

Here's the thing; these optimizations can as easily be made in Java as in C++. Currently, if you want to write an amazing 3d FPS, C++ is practically the only option. But even in C++, there are all sorts of awful things I can do terribly wrong to ruin my framerate, even when rendering something simple. The same can be said about Java. The consistent criticism of Java is one of speed, and I admit that it is currently much easier to write a high end FPS in C++ than in Java. But this is only because of our current limit of processing power.

Need I remind anyone of Moore's law? Specifically, the thing that I see as a developer of 3d applications is that practically no high end processing is done on the processor anymore. The real high end stuff is done on the graphics card, including more and more of the high end programming. C++ is used for the programs structure these days, things like lists and object management and AI. All these things that will never be offloaded to the graphics card can be done in Java as easily and quickly as they can be done in C++.

When Quake 2 came out, no one could have imagined that Java would have eventually had the capacity to run a game like Quake at full speed. Yet, Jake 2 does just that. But what really gets me about Jake 2 is that rendering technology has not changed so much since Quake 2. The critical difference between Quake 2 and Doom 3 visually is the use of per pixel lighting through shaders. It is not a matter of polycount or geometric complexity. It is only a matter of shaders.

Jake 2 could look as good as Doom 3 with the right shaders, and it would run EQUALLY as fast as it does now. Why? Because shaders are entirely offloaded onto the graphics card. It doesn't affect the speed of the program to alter the shader. Unless it's a complex shader, it doesn't even affect the speed of rendering. So thusly, you could already create a first person shooter with completely modern shader based graphics in Java and have it run at a realistic speed.

Java is the answer to Microsoft and to Linux. Slow as it may be now, it is already so infinitely faster than it was before in all the ways that matter. And in ten years, it will only be faster and better. Java allows binary compatibility across platforms, allowing the modern programmer to target a single virtual system and be assured that his program will run anywhere.

I have used Java in Linux sometimes more reliably than I have used native applications in Linux. And then I've turned around and run the same application with all the same features in Windows. In ten or twenty years, this effect will only be amplified. And then, why would anyone want to develop in a language like C++?

Java would be just as fast at all the things that matter, particularly with the offloading of graphics processing and even physics processing onto the graphics card. Java will allow developers to target every available platform rather than one platform at a time. Not to even mention that with Java webstart, applications can be run from online sources quickly and easily on all machines that support Java.

I simply see there being no reason in the future to use C++. Sad as it may be for me, I'm not sure I'll ever learn Java as well as I already have C++. But, Java is a good language, and it'll be very nice to see it take over as the dominant language of the future.

Open Source program market place?

2009-09-18T21:56:00.000-07:00

So, Steam, Gametap and the XBox live are all excellent ideas for game distribution. They're essentially an Internet based paid software distribution method. The problem with this is that they operate like traditional publishers: Only letting in the best known companies that produce the most money. This isn't healthy for the independent game developer. What we need is an open source paid software management system. This would ensure that no one could discriminate against the size or recognition of the developer.

It would have to be written in Java, because everything good is anyway these days. It would probably work by downloading encrypted files and unencrypting them if the user has the right password, etc. and deleting them when finished. It doesn't need to be overly sophisticated to start with. Open source software could even be charged for, since the GPL allows charging for distribution. The source would naturally be included. Public domain games could be charged for too!

Parts of it may have to be closed source to prevent piracy, though.

Paper data.

2009-09-15T22:41:00.001-07:00

There is a virtually infinite amount of paper. Which is almost equal to the virtually infinite amount of data that all the hard drives on earth could contain. I can copy a book, though it might be hard. I could even open a whole factory making copies of books. But this is illegal if I don't own the copyrights to the book I'm producing. Why is this?

Because the book is copyrighted, of course. Many people accept books being copyrighted and those copyrights being important without a second though. It would be awful to open a factory to produce someone else's books without their permission. But when the material is changed from books to data, there's an entirely different response. Suddenly copying is acceptable, probably mostly because it's so much easier to copy data than books.

Often, the excuse that data can be copied infinitely virtually for free is used to justify piracy. This is completely incorrect, because copyrights do not exist because of the price of printing books. Copyrights exist to protect the authors of theirs works, and to allow them to properly profit from their works. That has nothing to do with the price of books or the ease of copying books.

Equally, although it is very easy to download pirated songs from the Internet, it is just as wrong as photocopying a book. And if you then share that song with others, it is equally as wrong as running your own factory printing someone else's books without their permission. So why is this so socially acceptable? Because it's easy?

Piracy has to be handled somehow.

Money from software.

2009-09-13T16:19:00.000-07:00

I've been thinking recently about how to make money from software. Some of these ways are awful, but worth at least discussing.

First, money can be charged for source code, and for binaries. Further money can be made from disallowing modification of the source without a license. You could say the same for distribution, that way you controlled the entire distribution of the source. I suppose this is "closed source", because no one can distribute a modified version without a paid license. But it's a good way to make money from software. And people would still be able to see and learn from the source, just not to distribute it. And isn't that what this is all about?

But there's an even better way to make money from software. That's this brilliant scheme that cell phones came up; software as a service. Here, someone subscribes to your software, and only has access as long as they have the subscription. This is how World of Warcraft makes so much money. You can also charge access to documentation for the source code or binaries, which can be held online.

You can further charge for access to content. The binary, while paid for, might still ask for money for additional levels, weapons, etc. You could sell players all sorts of things in your game for real money. You could sell access to a god mode, access to special items, access to new levels, access to a level editor, almost anything. Again, these would be best suited to a software as a service model, charging people per month for additional content.

And of course, upselling can be done. You can and should have multiple levels of subscriptions that provide different levels of content. You could heavily advertise and reward the higher levels of subscription as a way of upselling. Finally, you can charge for technical support if you want to, as well as for access to and features on your forum.

So, the most money you could make from a single person would be:
- Monthly access to the binary (Let's say $10)
- Monthly access to the source (Let's say $50)
- Monthly access to the documentation of the binary (Lets say $5)
- Monthly access to the documentation of the source (Let's say $100)
- Monthly access to the "platinum" content (Let's say $15)
- Monthly access to any additional content (Let's say $3)
- Monthly access to the forums (Let's say $5)
- Technical support for the binary (Let's say $5)
- Technical support for the source (Let's say $100)
- Any possible licensing fees (?)

= $293

Of course, this is an astronomical figure from one person every month, but not everyone will want all levels of access. Some just want the binary with "bronze" content. Some just want the source, no documentation. The main thing is that all can upsell the others. And since these are mostly monthly charges, it could potentially add up to quite a sum of money, if anyone liked your game. The key there would be to release a very short shareware version for free, without source.

The main problem is still getting anyone to pay for your game at all. Especially with Diablo 2 selling for $20 on Amazon.com. And of course piracy drives down sales quite a bit, as does plain old competition. Video games traditionally sell somewhat low volume, except for those few rare multi-million dollar sellers. And even then, there's still competition from open source. The only platform this model would be viable on is one that was built for it. If the only way to buy software was as a service, we'd all be rich. But we'd also be paying a lot of money to use our own computers in inferior ways.

I'm not advocating these techniques, just saying that they exist. The problem with selling games is that occasionally no one buys. And that's not what any developer I know wants. That's why a strong but short shareware version of any software for sale is needed.

Special thanks

2009-08-29T22:42:00.000-07:00

Special thanks to my friend Justin.

What is a roguelike?

2009-08-27T18:26:00.001-07:00

I'm going to offer here my attempt at a definition for the roguelike genre. Many people have tried before me, including the authors of the Berlin roguelike interpretation. The inherent problem of defining roguelikes is not a new one. It has been discussed endlessly on IRC on #rgrd and on the r.g.r.d newsgroup. I've found that many interpretations tend to be much more strict than my interpretation, which is why I offer it here. A roguelike is any game which contains mainly randomly generated maps.

Roguelikes predate Rogue, by quite a bit. First, there's Beneath Apple Manor, which was two years before Rogue but very Roguelike. However, none of these games gained the fame or wide spread use which Rogue did. Roguelikes as a genre have not traditionally defined a specific set of looks. For instance, even Rogue used the extended DOS character set for enhanced graphics. Nethack has had a graphical version for well over a decade. Further, Beneath Apple Manor does not contain the "typical" roguelike graphics either.

Roguelikes do not share a universal graphical look, nor do they share universal game play. This should be obvious for anyone who has played Angband and Nethack back to back. DoomRL has the word Roguelike in it's name, yet it doesn't have many traditional features of roguelikes. For these reasons, the term Roguelike has been traditionally hard to define.

The reason I define Roguelikes as any game with mainly random maps is that any other definition is too restrictive. Clearly, a game with predominantly static maps is not a roguelike, even if it throws in a few random maps. However, every other quality of a Roguelike is not necessary for it to be easily defined as Roguelike. There have been graphical roguelikes such as Nethack, and 3d roguelikes such as Egoboo. There have been action based Roguelikes such as DoomRL and strategy Roguelikes such as Dwarf Fortress. There have been non-scrolling maps like Nethack, and scrolling maps like Angband. The status display has been on the bottom in Nethack, on the left in Angband, on the right in Crawl, and on the top in the DS port of Nethack. None of these qualities are even remotely roguelike. A roguelike could exist with or without any of them. There is only one quality that all Roguelikes must have to be Roguelike: randomly generated maps.

This is the single uniqueness that even Glenn Wichman acknowledged: "Rogue's biggest contribution, and one that still stands out to this day, is that the computer itself generated the adventure in Rogue. Every time you played, you got a new adventure. That's really what made it so popular for all those years in the early eighties." This was then and is now the single unique feature of the Roguelike genre. For as much as we'd like to talk about identification of items or ascii graphics, it comes down to random maps.

The argument against my position says that defining roguelikes this loosely is watering down the entire genre. This argument would say that Diablo is not a roguelike, because it does not look like a roguelike. Or that Dwarf Fortress is not a Roguelike, because it does not play like a roguelike. However, there have been graphical roguelikes before Diablo, including the PC port of Rogue. There have even been isometric version of Nethack and Angband that utilize graphics at least similar in principal to those in Diablo. Equally, the argument that Dwarf Fortress is not a roguelike is invalid because there have been many other Roguelikes that played nothing like a "typical" roguelike. DoomRL is only one exaple. MegamanRL features a sidescrolling action adventure based gameplay, yet it is easily identifiable as a roguelike. A closer example would be Slashie's Expedition. This game features extensive strategy gameplay inside of a roguelike environment. Therefore, defining Roguelikes this loosely is not watering down the Roguelike genre, but simply making sure that the term is applied consistently. My definition is the only one which can be applied consistently to all Roguelikes.

If the term roguelike is to be applied consistently, "mainly random maps" must be it's only definition. This definition will not water down the roguelike genre, but will instead allow consistent identification of games as Roguelikes or non-roguelikes. In conclusion I'd like to note that no single definition will ever be fully adequate. If you have never heard of the argument over "What is art?" I highly recommend you read up on the subject. "What is a Roguelike?" is a similar question. What I mean by this is that it is wholly unanswerable by anyone. My definition is no more or less valid than any other, they are all equally invalid. Roguelikes are ultimately what we continue to make them to be. For the time being, however, my definition fits nicely.

Money from open source.

2009-08-26T00:21:00.000-07:00

I am not qualified to talk about this. First, I have no degree or other qualifications in economics. Or business. Or even computer science. Nor do I develop or support a large open source project. That having been said, I'd like to write about the possibilities of making money with open source. The two are not mutually exclusive, but in my opinion, the main problem is no one has found the right model for it yet.

First, there's the classic route preferred by Ubuntu and other large open source projects: Through tech support. Tech support is an endless well of free cash for stuff like "how do I change my password". However, tech support is not particularly well paid, and it's very high stress. Further, it's constantly being outsourced, even from countries it was previously outsourced into. Also, I don't know many programmers who want to spend their time doing tech support. We're programmers, not tech support. So this route, while it may suite many large companies, completely fails to provide the average programmer with any meaningful pay.

Then there's donation-ware. A seemingly new concept, but it's been around for years. There was lots of old freeware that begged for money at the end. Oh, we're better at getting people to donate now, we have fancy buttons asking for instant pay-pal donations. But it's still donating. Now it just works, for some people. It does provide a meaningful source of income to Dwarf Fortress, in the range of $2000+ a month. But this is largely a singular success story, bordered by so many failures it is hard to properly count them all. The paypal button on Roguebasin has received sadly little use. So, for most programmers, asking for donations is not a reliable source of income.

There's shareware, which has worked for quite a few old companies. Id software comes to mind. But there were many shareware products even in those days that did not monetarily succeed. Megazeux comes to mind here. The games that did succeed were those on the bleeding edge of modern graphical technology like Doom. Today, there is also a glut of independent games using the shareware model. Jeff Vogel is just one of your many competitors, including developers for the iPhone (like the dev of 100 rogues), and for the XBox. Many competitors, not much chance for success, even if you do sell a copy or two it won't be enough to live on. This certainly isn't enough to provide the average programmer with any money.

The GPL allows you to charge for the distribution of source. This means that you could charge for access to the official version of the source. You could make people shell out for physical CDs if you wanted to, and you could pretty much ask whatever amount of money you felt appropriate. However, I've never seen this tried, and I doubt it works. Maybe for an extremely popular large software project, but some jerk would put up a copy on sourceforge before the first copy was sold. I don't think this is a reliable source of income for programmers.

There are more creative answers, too. In game advertising, like all advertising, does not provide as much money as you might think. Meaning it provides very little, and even less since so few people have heard of in game advertising. Not to mention that selling advertising is not fun. Micro charges for some kind of MMO is pointless to consider, due to the incredible difficulty, staff and time required to both develop and run an MMO successfully. For the average programmer, making money from micro charges is simply impossible.

Finally there is some un-thought-of other idea. The main problem with this idea is that all the ideas preceding it have failed to offer average programmers even a reasonable prospect at real money. Even if some new method is found, how much can it possibly improve on these methods by?

The main problem I see with all the previous ideas is that they lack real organization. Even NORML, the National Organization for the Reform of Marijuana Law makes a considerable amount more money than Dwarf Fortress, largely due to the power and capabilities of the organization itself. It is no one person in NORML responsible for it's success, failure or funds. Organizations are very powerful, in any form. Take the NAACP, without which civil rights in America would undoubtedly be much different than they are today. We need organizations of people: we need institutions. There must be some way for programmers to band together in some kind of organization for mutual monetary interest and gain. A single open source developer in and of himself can never be as powerful as a well organized company of open source developers.

But how exactly an organization or company of open source developers would make money is another matter entirely. It simply seems to me that all the previous examples leave out the formation of any kind of actual business organization. Even non-profit organization is left out. Surely, there must be some beneficial way we can organize ourselves.

But making money from software is tricky to begin with. Should we be doing it at all? If software is an art, which I think many programmers believe, and I do too, then why do we expect to make any money from it at all? Microsoft has not benefited programmers despite their massive size and profits from software. I am not sure that commercial software benefits the end programmers any more than non-commercial software. Perhaps there is no future in selling software, and maybe there shouldn't be. We would all write software, I don't think any "real" programmer would stop programming just because it didn't pay. Many of us don't get paid for it now, but we do it any way. Would we really be so much worse off if there was no money in software at all?

Linux would still be here..

Dreamhack Screwdriver.

2009-08-22T21:38:00.000-07:00

I added a screw driver to dreamhack today that you can press 'u' to use to unscrew things. This was much more difficult to add than it sounds. Mostly because half of my code is old, and half is new. Eventually, I want to convert all the old code to the new style, but there's no reason not to leave the old stuff for now until it becomes unusable.

I'm not sure what the first thing I want to do next is. I keep putting off the town, I don't want to do the NPC part, and I don't know what the town should look like. I want it to look like a small town, maybe a gas station, and a super market with other smaller stores attached. Something like that, but I want it to look realisticish. It's very hard to make something look realistic in text. I might just do something simple like Angband. Not sure..

I don't want to do the closet, because that involves objects containing objects, which is an annoying overhaul. For that reason, I don't want to do the fridge either. I could work on the stove, toaster and garbage can. But I really want to work on altering the random dungeon generator. My current generator generates a nice layout, but I need it to give me a list of rooms back so that I can decorate each room appropriately. That way the stove will be in the kitchen, rather than just some random spot on the first floor.

Unfortunately, the dungeon generator would be quite a bit of work. But it will look very nice when I'm done. Each room will probably have a "unique" (random) floor color and design. Some rooms will have black and white tiles. Some rooms will have blue carpet. Some rooms will have green rugs. That kind of thing. I would like to do this with the walls, too, but that is more complicated.

If I do overhaul the dungeon generator, I don't know if I should write a new generator entirely or just modify the old one. I'd probably start by modifying the old one. What I want to do is to implement a function that automatically breaks a map down into "rooms" regardless of the layout of the tiles. There are complications with doing this, specifically how/when/where/why to/not to place doors. An easier way would be to use my existing algorithm for door placement, and merely use the new algorithm to determine which rooms are where for themes. Still, the theme system itself might be complicated.

So all I've added today is a screwdriver. And some bug fixes.

More dreamhack work!

2009-08-21T21:28:00.001-07:00

I added some nice trees that drop apples if the player is hungry. They're in the player's back yard. Right now, there's only a single species, "apple tree" and a single kind of apple; "apple". But I intend to insert different species of apple, because it's incredibly easy to do so. I just copy the first and rename it. This way, eventually the player might start with two pear trees, a plum tree and a green apple tree in his back yard.

Plans for the first floor:
- Need to create the town and link the first floor to the town.
- Add a closet, which is a special non-movable container that can hold any amount of anything.
- Add a fridge, the same, but can store food.
- Add a stove, can cook food.
- Add a sink, just like nethack..
- Add a toaster, always has toast when the player starts/loads. Can cook food.
- Add a garbage can, gets rid of stuff.
- Add some different kinds of plants in the garden that grow.

So, this might seem like a lot of useless stuff, but every level in Dreamhack is static once generated, so these resources are special perks of level 1 specifically. For now, anyway. Later, they can be found in other levels, but each occurrence of these items is somewhat special since it's always tied to specific level due to the player's inability to move it. So, if you're lucky maybe you'll run into a large pear grove on one of the floors. Or a stove. Or a sink.

I've done a tremendous amount of work on the code, and there's still more to do.

Dreamhack work.

2009-08-21T00:41:00.000-07:00

I added a ton of stuff to Dreamhack. All sorts of weapons and items, food, enemies, lots of stuff. It's a much more complete seeming game, now. I still need to add the town. I'm mostly afraid of doing the shop stuff. And I'm not sure what the town should look like. Still trying to decide. It'll take some work to code the town generator, too. Then I need special "town stairs" that transfer the player to the town if he steps on them. After that, I need to add things to the basement and the first floor.

Inspired.

2009-08-20T01:14:00.000-07:00

After being thoroughly reinspired by Kharne's progress, I decided to completely rewrite my Dreamhack sourecode as I've intended to for a while. It took about two days, but it's almost done now. I'm adding new features to dreamhack, new monsters, new items, going to add the town soon and other nifty things. Things are going along very nicely. I might reduce all my object's variables to a C++ map of strings.

I'll update more later, hopefully I'll get dreamhack running on windows and release a windows binary soon.

Tile based 3d.

2009-08-09T20:32:00.000-07:00

Recently, I've been working on a project in OpenGL, which is rare for me these days. I used to do quite a bit of work in OpenGL, but it's been a while. I'm making a tile based 3d engine, where the player and monsters are not "stuck in tiles". I haven't had too much motivation to program recently, but what motivation I have had has gone toward this. It has a nice little make file now, but still needs a lot of work.

I've been trying to use C++ STL maps more, as well as using STL more in general. I want to implement textures as a C++ map, something like:

map Textures;
map[CurrentTextureName]->Unbind();
map[NewTextureName]->Bind();

But before I do that, I want to get some basic text rendering up and running in OpenGL. I downloaded the old DOS/VGA codepage 437 in bitmap form to use as a texture for displaying text in OpenGL. The entire font will be a single texture, and I'll implement special functions to manipulate the texture coordinates in such a way that the correct character in the font texture is displayed.

I want to use 2d "sprites" which always face the camera to represent everything in the engine. All the sprite's graphics will be characters from the font. The walls/floors/etc will also only consist of characters from the font.

Unfortunately, I've made very little actual progress. I know the things I need to do: Font rendering, menu system, texture map, sprite implementation, objects/AI/etc... I just don't feel like doing it.

Update: I got text displaying in OpenGL, and have been using maps FAR more. I had no idea what I was missing all this time...

Tiny roguelike engine work

2009-08-01T14:53:00.000-07:00

I've been working mostly on a small roguelike engine, but it's going very slowly. I'm having a hard time finding the motivation to write some simple functions. My current engine design is annoying me a little, too. Every class is descended from a base object class. Weapons are descended from this class, so are monsters, the player, everything. To spawn something, I call a function inside one of these classes that duplicates itself. The problem is, I can't write this function just ONCE. Every descendant of the base Object class must re-implement the function. This is annoying because they all do the exact same thing. They just duplicate the object.

These functions are simple enough to implement, but there about five of them all alike that I don't feel like doing. Once before, I considered only having a base object class, no descendants. But this seemed to make everything incredibly cluttered and confusing. Now I'm looking at it again, because then I'd only need to write this function once, instead of five times.

But that's not an ideal solution. I want to have the best of both. I wish there was a way to do something like this in C++:

Object *o = new this;

There are other ways I could work around it. I could have the base object class switch depending on a variable specifying the Object's type. But then I'd have to update the switch every time a new class was descended, which is just as inefficient. I suppose I could have something like:

virtual CObject *SpawnThisType(){return new CObject};

That way I'd only need to change one line for every descended class. I still don't particularly like the idea.

I've been reading recently that many people on r.g.r.d. are using lists of flags and variables in their monsters and items. This is interesting because you can already declare flags and variables in the programming language itself. Why have a separate list of variables and flags from those in the code? I understand why it's useful, though. I've done this before myself. It helps to unclutter the class by keeping the number of actual variables down.

But really, this method just hides variables. There are some advantages, though. It's very easy to save and copy a list of variables. It is not so easy to implement, alter and copy variables in a class. Every time a new variable is added in code, some specific other code must copy or save or somehow deal with that variable specifically. When using lists, you don't ever need to worry about copying or saving new variables because these new variables become part of a list that is automatically saved in it's entirety. Thus, you could write "SaveObject" once, no matter how many variables you later added to the same class.

The disadvantage is obfuscation. It is much harder to tell what variables an object has. It is equally difficult to tell which variables are important to what part of the object. This, and it requires equally as much coding if not more to use a list of variables than to use real variables.

It is however very convenient to do things like:

Set("I'm on fire");
if(Get("I'm on fire"))
Run();

This is nice because I don't have to declare "I'm on fire" as a flag before using it. But I really should have declared this as a real flag. Something like "Fire_State". That way anything in the program can easily access it and knows that it's there.

The main thing I'm conflicted on is this whole question of object self duplication. With lists of variables, I could easily duplicate objects. But there's got to be a better way to do it than that..

TinyCurses documentation work.

2009-07-28T22:07:00.000-07:00

I worked on the quickguide to TinyCurses a bit. The basic section is essentially complete. The only thing I have left to write is the advanced section. I've also uploaded the NCurses port of TinyCurses to TinyCurses' SVN. It's named "TinyCursesC", so look for "TinyCursesC.c" and "TinyCursesC.h", the use is the same aside from that. It's very, very minimal right now. Not recommended, but work continues.

NCurses port of TinyCurses up and running.

2009-07-28T20:29:00.000-07:00

That's right, I've got TinyCurses running on NCurses under linux. It's a very minimal port right now, but it's running and that's the important thing.

Here is the same program running on...

TinyCurses with SDL:

TinyCurses with Curses:

It needs a lot of work, but my priority right now is to make sure it can compile and run under windows using pdcurses.

TinyCurses work.

2009-07-27T00:51:00.000-07:00

I did some work on TinyCurses today. I began work on porting it to display using curses. This is annoying because my functions are named the same thing as the curses functions. I'm using a bit of odd coding to fix this, but it should work. I also made a static library of TinyCurses for MSVC on windows. I uploaded this version, but later realized that it contained a rather major bug in the alpha levels above layer 0. I haven't fixed the problem yet or uploaded a new version, since I've been working on porting TinyCurses to curses.

The work on the port is going well so far aside from the namespace conflicts. It'll be an odd thing to look at for the end user when it's fixed. But it'll work. I'm trying to write it in the most pdcurses compatible way, though I'm using ncurses. Once I get the ncurses version up and running, I hope to be able to compile for windows under MSVC as a .lib. That would be nice.

I started work on another library, I'm not sure if/when I'll be releasing it. It's a roguelike "prototyping" library. It's a very, very simple roguelike engine that trades functionality for simplicity. Unfortunately, work on it is painfully slow. I just never seem to be motivated to work on it properly. I haven't been very motivated to program in general recently.

With TinyCurses, I keep going back and forth on the idea of per pixel based sprites. I can't decide if and how to implement them. For now, they won't appear for a while. I'm more interested in porting TinyCurses than expanding it right now.

I'd like to work on Dreamhack, but there's so much I want to change or remove. I don't know where to even start. The first thing would be to remove all the kdevelop stuff and get it a proper makefile. Also to port it to windows, get a windows binary up and running. It'd just be a lot of work to even start. I'd rather work on this general roguelike prototyping library than a single roguelike for now.

Some new random roguelike ideas:
- OfficeRL: You go up a large office building trying to reach the top floor to become CEO. You fight things like secretaries, staplers, printers, junk mail, annoying coworkers, etc. Levels are promotions and you get titles like "Senior associate junior supervisor in training" for each level.
- TentCityRL: Make it from one side of the tent city to the other to get the legendary soup and bring it back so you can eat.

I'd also like to distribute TinyCurses as a .deb file. I just haven't felt up to doing this so far.

New TinyCurses version!

2009-06-30T19:15:00.000-07:00

1.0a, that's the new version. I named it so because all core functionality should be present and working. I also included a makefile and readme in the latest release. Mouse is working, all keys are working, and TinyCurses should play better with compilers in general. Under linux, you can type "make" in the tinycurses directory to create a .so shared object. Enjoy.

Sprites?

2009-06-26T02:28:00.000-07:00

So, I was having second thoughts about putting sprites in TinyCurses, until for an unrelated reason I was reading some old Commodore 64 documentation. The C64 has sprites too, of course. And so do a lot of other systems. In fact, I even found this nifty list here: http://en.wikipedia.org/wiki/Sprite_(computer_science) that compares the capabilities of all the old systems. Interesting there seem to be a few common features:

- X number of tile based layers
- X number of sprites with X number of features

This is very close to what I'm doing. Only, instead of doing 3 tile based layers like the C64, I have 7. And instead of there being only 8 sprites, I might have 256. I also like some of the other features on that graph, specifically:

- Zoom
- Rotation
- Collision detection

These won't work with the ncurses port though, for obvious reasons. So, these have got to be yet more SDL specific functions. The problem is, I'm having trouble deciding what kind of library I'm trying to build. Am I trying to build something minimalistic that works everywhere? Am I trying to build something tiny?

One part of me wants an extremely minimal library that runs everywhere. Something I could port like crazy, so that everyone could have easy access to a small, sane implementation of curses.

But another part of me wants to add all sorts of modern features like zoom, rotation, transparency, layers, full color, unicode and all these other things. But all these things aren't portable. So what kind of library do I make?

I want to have some kind of balance between the two. I want to do both, but the combination will be very tricky. Somehow, I have to have a core set of features that runs everywhere. Then I need a sane system for accessing platform specific capabilities. Gee, this sounds like the kind of stuff they were dealing with back when Curses was first written..

The problem with any sort of platform specific features is the implementation and the interface. It is so incredibly easy to make the interface unusable and annoying. Also, extension features can't be overly important or programs will be essentially unportable between different ports of the same library, which surely is undesirable.

Part of the reason I started TinyCurses was to add the cool features of libraries like libtcod to Curses, but another reason was to implement a tiny and sane version of curses. Now I find myself stuck trying to do both and not knowing how.

Anyway, just rambling. For the time being not much is going to change in terms of the design. I'm going to implement sprites for now, and see where I want to go after that. If I want to add zoom, maybe I will. We'll see. Maybe porting TinyCurses will prove more fun than extravagant features..

TinyCurses work.

2009-06-21T01:10:00.001-07:00

I've been working on TinyCurses this weekend. So far, I've implemented a lot more keys, and changed how clear and clearlayer work slightly. \0 is now transparent instead of ' '. Fixed some basic bugs, too. I'm working on implementing better mouse functionality. It will work through getch. getch will return KEY_MOUSE1, KEY_MOUSE2 and KEY_MOUSE3 and so on. When this happens, getmouse can be called to determine the location of the click. I also encased all the function definitions in extern "C" to make sure the library compiles correctly on different platforms. The upcoming release will be version 1.0a, because all the basic functionality will be implemented and should be working correctly.

Here's some plans for future releases:
- Sprites (Moving blocks of text independent of the background. Can be positioned by pixel..)
- ncurses and pdcurses port (This will likely be it's own zip file)
- Java port (I'm looking forward to this)
- Simplifying the advanced functions somehow. Not sure how. Might combine a few.

If all that goes in, I'll bump it up to version 1.2a.

After that, here's my long term goals:
- Prebuilt libraries for Windows, Linux, FreeDOS and Java. Including pdcurses and ncurses ports.
- A simple makefile that works (Haha)
- Multiple joystick support under the SDL port.
- printw that supports Unicode.
- No bugs :)

If all that gets added, I'll bump it up to version 2.0.

New TinyCurses version!

2009-06-03T00:19:00.000-07:00

Just released TinyCurses v0.9f. Here's roughly what I added:

- Per character alpha is finally working! Yay!
- clearlayer added.
- mvprintw and mvaddch now conform to printwext and addchext. They accept x and y AFTER the data to be displayed.
- More key definitions, including full keypad functionality.
- Changed #include to #include "SDL.h", as this is preferred.
- No more initscr and endwin! Now, just use the library! No more initialization! (You can still call initscrext to get a specific window size. Just call it before anything else.)
- Other random bug fixes.

TinyCurses for Java?

2009-06-01T19:31:00.000-07:00

Coming soon, if I can get gcj to work :) Things that are being worked on for the next release:

- Java port?
- Support for using the Curses library (pd AND n) instead of SDL
- Changing #include with #include "SDL.h"
- setoffset will work
- Alpha will work mostly correctly (Hopefully. I'm just going to go with per character alpha for now. No separate background alpha yet.)
- Text "sprites" (Additional text displays whose position can be specified by pixel location)
- Color definitions
- More key definitions
- Bug fixes with certain font sizes
- Precompiled libraries for MSVC and mingw
- clearlayer (Thanks Giomancer!)
- Make mvprintw and printwext match in argument order. (Thanks Giomancer!)
- No more initscr or endwin. Just initscrext if you need a custom screen size.

Probably, I wont implement all of these before the next release. But this is what I'm working on, roughly. The text sprites are interesting. In Curses mode, the location won't be per pixel, because that would be impossible. But it will get as close as possible to the intended location.

TinyCurses forum!

2009-05-31T19:51:00.000-07:00

No new version yet, but I did just start a new forum for the discussion of TinyCurses! It's located here: http://groups.google.com/group/tinycurses

TinyCurses new version.

2009-05-25T22:58:00.000-07:00

This version is mostly a bugfix version, and should be far easier to use than the old version. It doesn't yet have binaries for mingw or MSVC, but that will take a while so I wanted to release this bugfixed version now.

Inlines have been taken out and replaced with externs, functions have been moved from TinyCurses.h to TinyCurses.c, which is much more sane even though I initially resisted it. I wanted the whole library to be in the .h file, but it's just much better to have it all in the .c.

TinyCurses work continues.

2009-05-22T02:15:00.000-07:00

Work continues on TinyCurses. I've been trying to make it easier to compile under mingw, but this is no small task. My summer semester in college has also started, so work on TinyCurses is a little slow. For the next release, I'm hoping to include a binary development library for Mingw and MSVC. Of course, Linux will be getting no such binary. But I will better support compiling TinyCurses into a library under Linux.

I've also updated the documentation slightly. I'm hoping to work more on the documentation over the weekend.

New TinyCurses Version

2009-05-09T02:16:00.001-07:00

This one is a small change, but it fixes a large bug. I wasn't properly writing everything to be included by more than one file, since most of my recent engines have been a single file. I've changed this, so TinyCurses should now compile without errors in projects with more than a single file. You'll need to include with your project and build TinyCurses.c when you build your application, though.

New TinyCurses version!

2009-05-07T00:25:00.000-07:00

Now that my semester is over, here's a new version of TinyCurses! There are too many changes to list. I added an mvprintw and mvaddch function, and significantly cleaned up the source, hopefully making it easier to include. Alpha still isn't working correctly. I spent several hours on it, but SDL's alpha stuff is highly unintuitive.

Screenshot:

New TinyCurses version.

2009-05-01T03:08:00.000-07:00

I just released a new version of TinyCurses, with my most recent improvements. Major bug fixes, getstr will work correctly now, a lot more things will work as intended. No input should crash any of the functions now, either. It should work correctly.

Currently, if you call a function that takes a color, it changes the color of all text placed after that function unless you call "color" again. I thought this was a good idea when I did it, but now I find it really annoying. Functions that take a color should not change the color of other text. The only time the color of new text should change is when the user of the library calls the color function. This will probably be different next release.

Still no transparency.

LibrarianHack.

2009-05-01T02:45:00.000-07:00

Had an idea for a game recently where you play a librarian helping people with various problems in a library. Today I started work on it using my TinyCurses library. As a result, I worked out a ton of bugs in TinyCurses, and feel bad for leaving such large bugs in TinyCurses' last release. However, that was just the first beta release. Not even 1.0 yet. TinyCurses is now a lot better than it was, but I haven't uploaded any new version yet. I will as I work more on LibrarianHack as I run across more bugs in TinyCurses. Though, the library is very small, I may have already found all the bugs in TinyCurses. Probably not, though.

LibrarianHack will be a very small game. The main character will have 100 hit points and the enemies will do almost no damage. But the entire screen is filled with enemies almost constantly. As enemies die, occasionally new enemies spawn. These enemies are called "problems". Each time a problem spawns, there's a chance that a "solution" will spawn. A solution is a weapon or item that helps the player. The player can only hold 9 items at a time, but they're quite powerful. The player is scored in money earned from working at the library.

The game starts with few problems; only enough to fill the map. After these problems are complete, the "work day" is over, and you're given the option to either quit now, or play another day. Each day there are more problems, beyond the ones that are initially spawned and fill the screen. Every once in a while, the game will randomly spawn new problems if space is available on the map. This way, each day the player faces more enemies than the last, and new enemies slowly spawn over time.

It's a neat game, my attempt at a real coffee break roguelike. The general idea is that items are all really fun and cool things, and different enemies have all sorts of strange different attacks. But nothing does the player much damage, so he can take on a lot of enemies at once.

Oh, and when the player hits an enemy it says things like "You help the lost child for 40" or "You calm the angry teenager for 20". Equally, the enemies do things like "Angry Customer annoys you for 15!" and "Screaming Children distract you for 22" or "Soccer Mom insults you for 12."

Anyway, I'm already started on it, it'll be cool.

TinyCurses work.

2009-04-20T20:28:00.001-07:00

I just implemented it so that printw in TinyCurses can accept arguments the same as printf does, through standard use of vsprintf. It was actually much easier than I thought. I also added it so that getmouse returns -1 if the left mouse button is down or 1 if the right button is down. I'm not sure if I should buffer this or not. In the documentation, it says that it's buffered, but I think that just returning the current state may work better. Not sure.

I thought about making a small roguelike based on this library. One of my ideas was a smaller version of clean rogue manor called dishes. It'd take place in the kitchen of a resteraunt where you constantly have to "clean" dishes. But I should really be doing school work, not programming.

TinyCurses released!

2009-04-18T05:26:00.001-07:00

I released an early version of TinyCurses. It's mostly complete, except that most functions don't return 0 as they should, and alpha blending is current non-functional. Also, mouse clicks aren't registered yet. But all other functionality is already in there. I expect there are quite a few bugs in it still, but this is just the first release. I'll have plenty of bug fix releases, I'm sure.

TinyCurses screenshot.

2009-04-18T00:46:00.000-07:00

Major work has started on the initial TinyCurses library itself. Here is a self explanatory screenshot:

A lot of the most basic functions are already implemented, the rest will be done soon.

More TinyCurses

2009-04-15T03:15:00.000-07:00

Unlike Clean Rogue, I'm very excited about this new TinyCurses library, and I'm having a lot of fun working on it. Which is very detrimental to my school work considering it's the end of the semester and I need to do a bunch of work. I have put off school work all day while working on documentation for TinyCurses. But this is more than just documentation, the library isn't written yet. I'm writing the documentation first, figuring out exactly what I want the library to be as I write the documentation for it.

But it's a very simple library, won't take much coding. The most coding will probably be spent on getstr, which I'm not looking forward to. But I've done a hundred of those sorts of functions, so it's no big deal. I'm not looking forward to it, because I've implemented that same basic functionality a hundred times. Take SDL key, convert to a more convenient format and insert into a string. Very simple, I've done it so many times.

I'm very proud of this library. It's exactly the kind of library I like and want. To hell with anyone who doesn't use it. I'm using it, and I'm going to like it. This is my library, after all.

School, school, school, school. It never ends. Not that I'm complaining. I live the best life I could possible imagine. Aside from a few minor details... I must learn to work harder on school, and less hard on programming. Oh, but programming.

TinyCurses

2009-04-13T23:01:00.000-07:00

I've started on an interesting project today. After some discussion on IRC in the #rgrd chatroom, I've been inspired to write my own modified version of Curses. Only, it's not really curses. What I wanted to do was write an incredibly simplified version of Curses. Throw out absolutely everything that wasn't completely needed and start over. Curses largely is the way it is because it was made so long ago. I thought "What's really needed is a modern Curses library. One that's written specifically for developers today."

Also, I've been inspired by TinyXML, particularly that TinyXML is only two files both of which are directly included. TinyCurses will be similar, but it will only be a single header file, nothing else. The entire library is in the header file. To start, it's going to use SDL exclusively, but I'm going to port it fairly quickly to other libraries, possibly starting with termcap. They won't always be perfect ports, SDL will be what TinyCurses is designed to run on. But I still intend to have ports of the library that don't use SDL.

Clean Rogue has gone no where. I just have never been in the mood to program it at all. I don't know why. I just don't feel like writing it right now. So instead, at first I started work on my own version of the Curses library, which lead me to the idea for TinyCurses. Anyway, the webpage is here.

Clean Rogue Manor

2009-04-09T22:30:00.001-07:00

I started on a new roguelike game today called Clean Rogue Manor. The whole idea of the game is that you're a maid who must do various household chores in Rogue Manor. The "enemies" are things like "D" for "Dishes" or "A" for "Ants" or "T" for "Trash" or "d" for dirt and so on. Each game has a player chosen number of chores, like 5 or 10, even 23.

Example chores would be like "Do the dishes". In that chore, in every Kitchen in Rogue Manor dishes are spawned as enemies. You must attack and defeat them like in a normal roguelike. Only instead of it saying "You hit the dish for 24" it says things like "You clean the dish for 19". Once all the dishes are clean, the chore is over and another chore is started. That might be "Clean the Living Room" which might spawn a bunch of dirt in the living room which you'd have to fight.

Weapons would be things like brooms, vacuum cleaners, window cleaner, dish soap, mops, etc. Enemies would drop money and item on occasion. Perhaps "Do laundry" would spawn clothing as enemies which would have a greater chance of dropping money, or something.

The map is done in a style similar to that of Rogue's map. Thus, the title. Each map is a 3x3 set of randomly connected rooms. Sometimes the house might be generated with more than one floor or a basement. Eventually, I'd like to add a front and backyard, as well as a town with stores for chores like "Buy Groceries".

It's an awesome idea, here's a screenshot of what I've got so far:

It's not much to look at, but if only you knew the coding that was behind it...

Pong Clone

2009-04-03T21:53:00.000-07:00

Here's a pong clone I programmed last night in about five hours. I wrote it because the implementation of the game Pwong really annoyed me but I loved the game. After I got this far in this "pwong clone", I realized I wasn't having any fun playing it, even though it's the same as Pwong. I don't like it I think because of the lack of things that really annoyed me in Pwong. The annoying features of Pwong might have been what made it fun. Not sure. Here it is:

http://sites.google.com/site/noprogramming/pong-clone
Here's a screenshot:

To compile, install SDL and type:
g++ main.cpp -o pongclone -lSDL

Note: SDL must be located in "SDL/SDL.h"

No Software?

2009-04-03T20:23:00.001-07:00

No Software is my general programming page on which I'm going to blog about the random various programming projects I'm working on at any given time. Although some of my projects have their own blogs, I wanted to have a place where I could talk about all my projects as a whole, in a more general way. On the menu to the right are links to my projects.

I'm the developer of ZGCS (Link), Dreamhack (Link) and Backwards Gravity (Link).