Knotwood - Character Movement

I made a white square which shall henceforth be called a "character".  Someday, this character if ours may look like more than a white square, but only if we feed it and take care of it and make sure it knows it is loved.

Anyway, it's just another bitmap.

Next I had a bit of fun remembering how to make the character move.  I've made the simplistic version first, where just holding an arrow key down or the WASD keys sends the character is the right direction on the screen that you want.  Unfortunately figuring out the correct placement of the event listener took some time.

First I made a Player class with a Bitmap in it, and put the event listener in there.  That didn't take, so I put it in Main.  That didn't work, so I attached it to the Player object through main.  That didn't work, so I attached it to the stage.  That didn't work, so I changed the Player class so it extends the Bitmap class, and added it inside there.  That didn't work, so I then added it to Main again.  That didn't work, so I attached it to the Player class again through Main.  That didn't work so I attached it to the Stage again through Main.  Ah! There we are.

Only the last possible combination of class types and attachments, of course.

But it works.  And that is a lovely thing.

Knotwood - All About Bitmaps

So the short version of Knotwood is this: Knotwood is a graphical adventure game featuring exploration as the main mechanic.  You travel through Knotwood, an endless forest, which changes and evolves and grows larger as you explore, so dead ends become pathways, and places you've visited before now sport new features, like there may be streams where there wasn't before.

I wanted to give Knotwood an early graphical adventure game feel, a la the original King's Quest.  It wouldn't require me to draw anything, because the exact pixels would all be handled in code with color values, (and a limited selection at that).

First I decided to update FlashDevelop, since I hadn't done so since I first downloaded it years ago, but of course updating always causes problems, and after some time of trying to fix some basic issues, I discovered I had to do a clean install of it, and couldn't just use the update tool, because the version number increased by a whole number (actually multiple whole numbers), so trying a simple update caused weird errors.

But with that out of the way, I started playing around with graphics.  At first, I did what I knew: I used textbox objects, made them 1x1 pixel, and colored the backgrounds and left everything else invisible.

Of course, that's a silly way to do things, but I did it just to know myself that it was a possibility if all else failed.

But fortunately all else didn't fail, and I soon learned about how to work Bitmap Objects.  It basically let me do what I wanted to do with the text boxes, but without all the fluff (and with a lot more tools at my disposal), and came with its own array, so I didn't need to make an array that would take a bunch of 1x1 bitmaps; a Bitmap Object is an array of pixels.

So that's all well and good, but making a 320x240 Bitmap is... small, of course.

With this game, I want to give players the ability to resize the window as they see fit, so they don't have to stay maximized, or can do other things.  Unlike Latchkey, this is a pleasant (nonthreatening) experience, so there's no need to forever be paying 100% attention if you don't want to.

But setting the window to the size I want in pixels is tiny.  I did discover, fortunately, that I can adjust the window size and the pixels scale up, exactly as I'd like, without distortion (you just get white bars on the sides if the window ratio is out of sync).  So the window looks nice now.  Of course the player can make it any size they want, auto-scaling without trouble, but it's nice to at least have an easy to see default.

Next I played with changing colors in the Bitmap I made on an individual pixel basis.  This is quite easy, and so far all my worry over the difficulty of playing with pixels has been unnecessary.  But of course we'll see what happens when things get more complicated.

Next up, I think I'll need to make layers of bitmaps, so, say, dirt might be on the bottom and grass above it and water above that, and then change transparencies for top layers to hide what needs to be hidden.

Hmm... collision detection may become a problem, although I suppose my next task (after making a moving player character, of course) is to see if there's a way to link collision detection to alpha values.  We'll see how that works.

News from the front

So there's this basic concept in game design that many designers follow, and for that matter it's the same basic concept for any artist of one stripe or another: make a product that you would enjoy using.  Directors like to make movies that they would watch, novelists like to write novels that they would read, and game developers like to make games that they would play.

When it comes to games, however, there's a bit of a tougher problem: you also have to have the resources available to you to make the game.  So if you like playing God of War, you're not going to just go making something like God of War on your own.

For me, I had to carefully strike a balance between the type of game I'd like to play and the resources available to me (and my current skill with those resources).  Being that I'm at least moderately skilled in Flash ActionScript, when it comes to making videogames that's my first choice.  Next came the problem of choosing a game to make.  Latchkey bubbled up in my mind, and while I enjoy Adventure games, a problem arises: I've never played a text-based Adventure game that I liked.  So I thought I could make a text-based Adventure game my way, and enjoy the result.  Latchkey also contained themes which I would carry over to later projects, so I could learn how to program those concepts on Latchkey first.

New problem: since I don't enjoy even the genre of what I'm making, when I hit snags or long periods of recoding, I lose all motivation.  This has been the case for some time now, and it's also why I've been working in spurts on it.

When it comes to tabletop games, however, I've got a lot more free reign.  So I could make almost anything I wanted, and the idea I came up with was, of course, FissureVerse (then called The Vortex).  FissureVerse is working well, but slow going because I'm tired of looking at bad placeholder art and want to look at good placeholder art, and get permission from the artists to do so.  So the holdup here isn't that I've lost the drive to work on it, but rather that it's simply long work with little to show--I don't bother posting all of the artists that haven't given me permission, for instance.

So on thinking hard about this, I've come to the conclusion that FissureVerse is to stay, but Latchkey is to go--at least on indefinite hiatus, or come sporadically when the mood strikes.  It's difficult to make that decision, because it's difficult to murder your darlings, and also because of the sunk cost fallacy, which I find I am particularly prone to (how many books have I finished reading that completely sucked and I knew they would from halfway through?).

I do, however, want to continue making videogames, and it's a question of finding the project that I can see myself working on.

One of the ideas I had in the running (back when I was deciding on doing Latchkey) was a graphical adventure/exploration game called Knotwood.  Some concepts in Knotwood got parsed out and subsumed in the initial creation of FissureVerse (pieces which ultimately got removed), and other aspects, particularly the setting, began to be turned into a work of fiction.

As a videogame, however, Knotwood would take one of the main characteristics of Latchkey:  it would be a massively single-player game, where the player would explore a randomly generated world, but there would be common areas where players could meet.  This concept I also want to apply to more game ideas, as well, and it's a pretty big central theme I'd like to see expanded on.

The reason I chose Latchkey over Knotwood initially, however, is because Latchkey is entirely text-based, and Knotwood is graphical.  My aversion to creating my own graphics kept me from starting Knotwood, and opting for the less graphically intimidating (but ultimately less intriguing) game first, to be a test run of the massively single-player concept before trying it in Knotwood.  Well, so far It's been over a year with Latchkey and I haven't even started that aspect, because I've been too busy with dictionaries and verbs and locked doors and directional words and a whole host of other things that would not be carried over into Knotwood (or any other game).

Latchkey still has potential to me, and I think I might go back to it when I've got a better handle on programming such things, but for now, I want to try my hand at Knotwood, which I hope will be a far more interesting exercise in game design than Latchkey--at least for the moment.  I think once I have more fully understood some of the programming principles I haven't mastered yet, I could bring back Latchkey, possibly even to restart from scratch, and make it right.  Or I'll just diddle with it when motivation strikes.  (Perhaps if I can't bear to kill it outright, I'll let it bleed to death.)

But in the meantime, Knotwood will begin, and rejuvenate my lagging creativity and blog posts.

Once upon a time, winter was my favorite season...

Boy, has this winter been something.  This blog has fallen by the wayside it seems with having one thing after another pop up all last month and into this one.  I'll be attempting to get back into this blog now, with something or other once a week.

I think I need a vacation from this snow.  Does anyone know if Mercury has good wifi?