Right off the proverbial bat, I still can't get the C# compiler to notice that I have a text file that lives among the code. It won't do it. I spent the better half of an hour researching importers and loaders to no real avail (although now I know the theory behind adding 3D models and meshes to a game). In an odd kind of seething fury, I hacked the loading functions right out of the code and assigned a string of letters to be looked at. Then, it almost worked.
So basically, I skipped a step. Before I tried loading a text file, taking the contents of that file and making them a string of letters/numbers and then I tried reading that string. No, I just told it what the letters are supposed to be and had the computer read that.
That breakthrough however came just as the promised drowsiness of Tylenol PM kicked my brain into lizard mode . So I have an idea of how, but now I still need to apply. Provided I can remember of course. Either way, it's part of the larger goal of reading from text. So if that works, I could add a bit later to fetch the data from someplace else. If it doesn't, I could always just assign the variables in the code itself, which is also text. That's a win regardless.
Usually I don't post half finished theories on the diary, and today is really no different. The real reasons are:
1) Look at the site! It's so clean now, and uses pages even.
2) If you look at the little box that I've called "Re-Sources" you'll see a lot of the stuff from before. (although by the time anybody reads this, I may have changed my mind and called it something else)
3) You'll notice that the design document for Paper Zeppelin is up, or at least the parts I have done.
Couple things to notice if I could direct your eyes yonder. There is no Break Point listed. It seems odd that I would wax philisophically about it and then not include it. I got hung up on an issue before I could add it. Issues, I will add comments for in purple. Right now I'm having a design issue regarding player progress and how I can combine a drop in and out style of multiplayer gameplay with a merit based system of level advancement. That will make no sense unless you read the thing.
Next you'll notice that it's really quite short. The Thief enemy defense AI was longer than this. That's because PZ uses very few mechanics, but they're integrated in a way to cascade the mechanics together. The pieces all link together somehow, so my short design and limited ingredients is set up to create an assortment of emergent gameplay. At least, I hope that it will.
Finally, there's no numbers in it. Everything is described (at this point) in relative terms. Numbers are the most variable of variables, so there's no point in trying to make them concrete, especially at this early stage.
Someone out there, assuming that they read this (which I doubt, seriously) may be asking, "Why would you put your work up for someone to steal it?" The answer is simple - it's worthless. That's not quite right, it should say - it's fuggin Worthless. Ideas are crap. Garbage. Even basic designs and documents aren't worth the digital paper they may or may not be written on.
"No," the people cry, "ideas are powerful and wonderful and rare!" I'm sorry to burst the bubble, but they're not. For some people, they may have a good idea once or twice and hoard it like the Gnomes of Zurich.
Others, get ideas all the time. I have lots of ideas. They float on through and sometimes they get caught by my brain. Others float right through and are discarded. But I'm not most people. I'm a designer of systems and a prolific writer of prose. I decide a dozen ideas are crap before I leave my house in the morning.
But it does lead to the point, the only thing worth anything is doing. If Founders just had an idea for a Declaration of Independence it doesn't mean anything. They have to do something with it. Further, it's the act of doing that will shape the outcome. A single idea can be taken and made into different things based on who does it. So like, The Thief's Tale is based on the idea of the original Prince of Persia (oddly, a game I had never played). Obviously Jordan Mechner based his game off the same idea. Our games are quite different because of the people making them.
To wit, here's a list of ideas for games I have cooking in my head at this very moment. Some I may have mentioned here, others have never been and probably never will again. They are, in no particular order.
The Thief's Tale - We know about this one. You can play it over there =>
Silver Knight - Side Scroller Action Hell with inside out storytelling
AeroKnight - Tactical RTS featuring fantasy airships.
Legend - A cycle of games featuring downloadable content. 3D action with destructible environments and physics.
SHADOW - A stealth spy game featuring characters with different skill sets, set in a Renaissance world.
The SHADOW TCG - A TCG based on the above property.
Thrae - 3D shooter focusing on Action Movie tropes and basing the mechanics off of them.
Sword of the Slayer - 3D weapons based fighting game (cancelled)
Paper Zeppelin - 2D sidecrolling multiplayer shooter.
The Star Frog EP - The first "Game Album" - mechanics based on Time, Loss and Failure
- Track 1 : Inevitability
- Track 2 : Time
- Track 3 : Entropy
- Track 4 : Fatalism
SF : Learning to Smile Again - The second "Game Album" - based on Love, Hope and Freedom
Psi-Kye - Metroidvania with psionics, physics and multiplayer.
The Adventures of FlyBoy - 3D flying game featuring a would be superhero.
These are just things that I happen to have written about. Some (like SHADOW) have extensive background that I've worked on. In the case of SHADOW, it's also a comic book script I've developed.
One of them hurts a little, but I'm happy for it. When I was young I played a lot of Street Fighter 2, and thought that the game would be better if I had weapons. Oh, and it should be 3D. Virtua Fighter was 3D, and it was so smooth and pretty. I called it Sword of the Slayer and I designed a dozen characters, wrote out move sets and drew a ton of pictures (I was like, 12 so I had lots of time). I even had the idea of making the female character the "heavy" - slow and powerful.
I set it aside and got thinking about other stuff. One day I was at the local arcade and they had Soul Calibur just sitting there. It was almost exactly the same idea that I had, and executed so perfectly that it brought joy. I then realized that my game, would never be this good. The idea executed too well. Namco had simplified and streamlined, balanced, perfected it. So instead, I played the hell out of SC.
My idea was good, but the doing was the important bit. I'll always remember that, and then get back to coding.
So yes, I share all of my ideas in one way or another. I mean, seriously, how many thousands of words have I thrown at internet describing my ideas? So here's an idea - take anything I've written above, and make it. I'll do the same. We'll see how different those seeds will grow.
- I had once regaled with the tale of chatting with the dudes from PAX. I think it's here. I came across something this morning, and had the weirdest feeling. At PAX East, they had an indie area. Not just the PAX 10, but an indie area with booths and stuff.
I'm not saying that I had really anything to do with that, but maybe just maybe, the meme got inserted and rattled around a bit. Maybe when planning the thing it rattled back to the fore.
Else maybe I was one of a legion of indie developers that have posited that same question. One more straw onto that particular camel.
This year, I'll tell them that their booth should have cookies...and blackjack.
Wednesday, March 31, 2010
Tuesday, March 30, 2010
Dead Letter Society
Nope. The title doesn't make any sense today, and it probably never will. I'm pretty sure that nothing I'm about to write will get us there in the round-a-bout way that I frequently use either. It seemed like a good idea at the time (which was about 35 second ago). The less said about it, the better. Let's move on.
Music is all installed in Thief now. Well, not all installed, but everything I have is in. The music plays when you start, when you play a level and stuff. It gets quiet when you pause (which is pretty cute really). It also pauses and restarts when you die, with the adorable little, "Ah, I bet that hurt dinit?" doom music in the middle. Finally, the little dolls also trigger a similar, yet happy jingle to play to let you know that you've done something right. Now that it's finally working, I'm rather quite happy with it.
What I want to rip like a TPS Report is the other thing. I'll call it that for now because I have both Fear and Loathing for it. Like I mentioned before, the basic class structure of the thing that will one day be Paper Zeppelin is all finished. It works, and the parts of the design that should interact, do. At this point, it's quite easy to add things to that structure. I could use my time and make what would seem to be "good" progress by filling out the rest of that structure and then making the load engine work. I used quotation marks around "good" because I mean "stupid." The loading engine will be the thing that conjures up the different class things. They require it, and they'll rely on it for the game to work as anything that resembles fun.
So, I could go through and add the rest of the little dudes and add 4 player support and all of that, but unless I can get the game to read my levels, it amounts to about zero. So, I felt an experiment was in order.
I set up a quick new program (having learned from The Thief's Tale that doing experiments in the main code is a bad idea if you can avoid it). It this program, I created a text file with some numbers in it. I then researched (which is plagiarizing from lots of people instead of just one) the function that will read a text file and can assign bits to variables. Then I told the screen to change colors based on what that number was. The theory says that if it's working right, it should sparkle in many colors like Josephs coat. Ah, wait, I hate bible references. I mean to say, "Like Saruman of Many Colours' Robe." That's better.
Either way, it didn't work. The color changing thing works cause I tested it all by itself. The biggest problem that I'm struggling with is that it could not find the text file that I had added to the rest of the program files. It would simply say, "I don't know what you are talking about, because you are stupid." So I went to an example and set up my program exactly the same way and got the same answer, which is stupid because to my eye, the are exactly the fuggin same. Yet the other one works without issue.
Finally, I got a new error, which is a kind of progress really. It said that there wasn't anything that could interpret the text file. I'm not sure what the hells this means though. But if I'm ever going to get this working I'd better get started figuring it out.
- I had mentioned in a previous lamentation a somewhat lofty goal of producing a game in a matter of a month or so. The intent there was that if i could do such a thing and do it consistently, then I could conceivably do just that for a living, and make games full time. There's a odd mix of unease and glorious freedom there. However, since I don't have the requisite 10 hours a day to invest yet, a goal for this project was to see how many hours it would take for me to put Paper Zeppelin together.
Obviously, it's taking a long time. Although I kind of expected it, and I'm no longer sure that it'd ever be a good model anyway.
The first reason is the biggest - I didn't know anything about C# when I started working. I've made some staggering progress since I've started, but I not yet ready to call myself a programmer yet. I know that I'd be far quicker if I knew more about the ins and occasional outs of the language on a higher level. I'm even considering taking a formal class on the subject now.
The second, makes more sense the longer I do this. Classes, by their nature, are portable. This will make all of the later projects go much faster because I will already have the basic block to work with. For example, in the next project, the EP, out of 4 games 3 of them are shooters of some kind. Collision detection, bullets, enemy AI structures, all of that can start with what's already in Paper Zeppelin. I'll be able to get a working thing that I can iterate on very fast. I'm talking in a manner of days if not hours. I'll give you an example. Once I got the basic enemy in PZ working, I was able to copy most of it wholesale, make some small modifications and get bullets working. That was in the game in about 10 minutes, and I could do it faster now. Making them work correctly is a different matter entirely, but the theory holds.
So basically PZ is taking longer than I would thing most of these projects would take, but I'm still convinced this is both do-able and positive.
- Finally, for those of you chomping at the bit (Readers? HA!) to get your hands on some Design Document, it's still in the works. The biggest issue it that I could sit and write with my limited hours, or I could code. Right now, the coding seems like a better use of my time when I'm home. So the design document (and the development diary) get written when I have time at a machine that isn't in my Fortress of Solitude. I'll add it soon-ish. I'll probably also use that opportunity to spruce up the blog a little, and add some more pages. Less stuff running down the side that way.
Music is all installed in Thief now. Well, not all installed, but everything I have is in. The music plays when you start, when you play a level and stuff. It gets quiet when you pause (which is pretty cute really). It also pauses and restarts when you die, with the adorable little, "Ah, I bet that hurt dinit?" doom music in the middle. Finally, the little dolls also trigger a similar, yet happy jingle to play to let you know that you've done something right. Now that it's finally working, I'm rather quite happy with it.
What I want to rip like a TPS Report is the other thing. I'll call it that for now because I have both Fear and Loathing for it. Like I mentioned before, the basic class structure of the thing that will one day be Paper Zeppelin is all finished. It works, and the parts of the design that should interact, do. At this point, it's quite easy to add things to that structure. I could use my time and make what would seem to be "good" progress by filling out the rest of that structure and then making the load engine work. I used quotation marks around "good" because I mean "stupid." The loading engine will be the thing that conjures up the different class things. They require it, and they'll rely on it for the game to work as anything that resembles fun.
So, I could go through and add the rest of the little dudes and add 4 player support and all of that, but unless I can get the game to read my levels, it amounts to about zero. So, I felt an experiment was in order.
I set up a quick new program (having learned from The Thief's Tale that doing experiments in the main code is a bad idea if you can avoid it). It this program, I created a text file with some numbers in it. I then researched (which is plagiarizing from lots of people instead of just one) the function that will read a text file and can assign bits to variables. Then I told the screen to change colors based on what that number was. The theory says that if it's working right, it should sparkle in many colors like Josephs coat. Ah, wait, I hate bible references. I mean to say, "Like Saruman of Many Colours' Robe." That's better.
Either way, it didn't work. The color changing thing works cause I tested it all by itself. The biggest problem that I'm struggling with is that it could not find the text file that I had added to the rest of the program files. It would simply say, "I don't know what you are talking about, because you are stupid." So I went to an example and set up my program exactly the same way and got the same answer, which is stupid because to my eye, the are exactly the fuggin same. Yet the other one works without issue.
Finally, I got a new error, which is a kind of progress really. It said that there wasn't anything that could interpret the text file. I'm not sure what the hells this means though. But if I'm ever going to get this working I'd better get started figuring it out.
- I had mentioned in a previous lamentation a somewhat lofty goal of producing a game in a matter of a month or so. The intent there was that if i could do such a thing and do it consistently, then I could conceivably do just that for a living, and make games full time. There's a odd mix of unease and glorious freedom there. However, since I don't have the requisite 10 hours a day to invest yet, a goal for this project was to see how many hours it would take for me to put Paper Zeppelin together.
Obviously, it's taking a long time. Although I kind of expected it, and I'm no longer sure that it'd ever be a good model anyway.
The first reason is the biggest - I didn't know anything about C# when I started working. I've made some staggering progress since I've started, but I not yet ready to call myself a programmer yet. I know that I'd be far quicker if I knew more about the ins and occasional outs of the language on a higher level. I'm even considering taking a formal class on the subject now.
The second, makes more sense the longer I do this. Classes, by their nature, are portable. This will make all of the later projects go much faster because I will already have the basic block to work with. For example, in the next project, the EP, out of 4 games 3 of them are shooters of some kind. Collision detection, bullets, enemy AI structures, all of that can start with what's already in Paper Zeppelin. I'll be able to get a working thing that I can iterate on very fast. I'm talking in a manner of days if not hours. I'll give you an example. Once I got the basic enemy in PZ working, I was able to copy most of it wholesale, make some small modifications and get bullets working. That was in the game in about 10 minutes, and I could do it faster now. Making them work correctly is a different matter entirely, but the theory holds.
So basically PZ is taking longer than I would thing most of these projects would take, but I'm still convinced this is both do-able and positive.
- Finally, for those of you chomping at the bit (Readers? HA!) to get your hands on some Design Document, it's still in the works. The biggest issue it that I could sit and write with my limited hours, or I could code. Right now, the coding seems like a better use of my time when I'm home. So the design document (and the development diary) get written when I have time at a machine that isn't in my Fortress of Solitude. I'll add it soon-ish. I'll probably also use that opportunity to spruce up the blog a little, and add some more pages. Less stuff running down the side that way.
Wednesday, March 24, 2010
Mix Master
If I could hate things to death I think I would, probably way too frequently. Could my evil eye increase in potency enough to cause harm to things? That would be good.
Actually, that would be bad. My laptop would have a 40 caliber glare hole through it by now. A smoking void that would probably increase the air flow through it. Yeah, it's probably best that I can't hate stare something to harm.
In any event, I figured out the stupidity of the program yesterday. The loop only wanted to work if I put graphics up. I don't know why really, but once it functioned I was able to make progress. I discovered that I can have Sounds and I can have Channels. Channels are made up of sounds, and exist in a 1-1 ratio, so I thought that they were interchangeable. It turns out that they aren't. I don't have finer control over channels, just different control over them. So I can pause a channel, I can only stop and restart a sound. I can alter the volume of both, but the volume knob on sounds seems to be broken. I can also pan both, and again, only channel panning works worth a damn.
So now, all the music is a channel. 2 channels actually. The normal music and the other is a different tune. So I set these up with some music and assigned a little switch, so if I make The Thief duck, it changes the channel playing. So I can switch back and forth between them on a whim (using something other than ducking obviously).
This new knowledge of something that works will also allow me to add working functionality for positional stereo sound. My new tricks will make the game that much more Pro. I'm happy with them, although I fear that the new ability to change music dynamically, or mix songs together may be giving The Composer some worry.
Actually, that would be bad. My laptop would have a 40 caliber glare hole through it by now. A smoking void that would probably increase the air flow through it. Yeah, it's probably best that I can't hate stare something to harm.
In any event, I figured out the stupidity of the program yesterday. The loop only wanted to work if I put graphics up. I don't know why really, but once it functioned I was able to make progress. I discovered that I can have Sounds and I can have Channels. Channels are made up of sounds, and exist in a 1-1 ratio, so I thought that they were interchangeable. It turns out that they aren't. I don't have finer control over channels, just different control over them. So I can pause a channel, I can only stop and restart a sound. I can alter the volume of both, but the volume knob on sounds seems to be broken. I can also pan both, and again, only channel panning works worth a damn.
So now, all the music is a channel. 2 channels actually. The normal music and the other is a different tune. So I set these up with some music and assigned a little switch, so if I make The Thief duck, it changes the channel playing. So I can switch back and forth between them on a whim (using something other than ducking obviously).
This new knowledge of something that works will also allow me to add working functionality for positional stereo sound. My new tricks will make the game that much more Pro. I'm happy with them, although I fear that the new ability to change music dynamically, or mix songs together may be giving The Composer some worry.
Tuesday, March 23, 2010
DJ Zero
Well I wasted an hour yesterday. I had but a simple goal, to install a crossfader into the sound code for Thief. Instead I got to bang my head bone on the wall for 60+ minutes and have nothing to show for it but a headache and the evaporation of a couple of brain cells.
The idea was basic enough. I was thinking about how to make the music work really well in The Cliff level (see the last post), and I remembered playing DJ Hero, a game I suck at by the way. In it, the player uses a little switch to set the volume of the right and left records into the speaker. So move the little knob to the left and you hear more of the left record and less of the right. So if the musics line up, you can combine them into a different thing altogether. A "Mix" if you would.
So I thought, "Hey, let's play 2 music tracks at the same time and let's make the volume of each a function (used in the mathematical term here) of some other variable. So let's have one be that, and the other be the inverse." The thinking was, if that number was between 1 and 0, then having the variable be set to 0 would be all of one track and none of the other, like pushing the little knob all the way to the left on a DJ Board. The 1, would be all the way to the right and anything in between would be a mix of the two.
Having done some tests on it, it worked out pretty well. At least in theory. I don't have musics that match, but I could get 2 things to play at once.
Then the whole thing was shit.
You see, I then tried to make the twice damned thing controllable. So I installed a little bit into my control code that would allow me to modify that Crossfader variable, and...nothing. It didn't work. So I told the computer to tell me when it was running the code I had just installed. The conversation went like this:
"Hey, computer, are you running that code?"
"What code?"
"The code I just wrote. It's right next to that other code you just ran."
"No it's not."
"No, really, it is. Could you look again?"
"Why?"
"Because I asked?"
"Wait, what are we talking about?"
"The code. Remember?"
"I like kittys."
That's exactly how I remember it anyway. So, like a good little code monkey I copied the whole thing over to a new program. Thief has like, 12000 lines of code, so maybe, just maybe, something else was screwing the pooch. I hit the "Go" button and:
"Hey, no problem now right? I'll push the key for you."
"..."
"Computer, did you see that key?"
"No?"
"Are you asking me?"
"Nooo?"
"So you don't think a key is being pressed?"
"No."
"Really? You're doing this to me? Now?"
"MMmmm...panda cookies."
So I cut the sound code out of the code I was writing. Now we were reduced to just loops - the basic building blocks of almost everything in a computer system. The Bread and Butter that keeps a coder coding, although less oily. So with that done, I mashed the keys, hoping for any sign of intelligence or life. Instead the loop just ran, oblivious to the outside world until I gave opened my razor and gave it the Sweeny.
I'm not sure yet exactly what happened, but I managed to swear a whole lot before I went to bed in a hazy anger, a kind of half hearted digital blood lust.
I'll try again later. Although now I have a crazy jones for those chocolate panda cookies, you know, the ones with the little pandas (or koalas, if you're into that) doing different jobs. I wonder if there is a Code Panda, they'd be the ones with the laptop and the furious eyes.
The idea was basic enough. I was thinking about how to make the music work really well in The Cliff level (see the last post), and I remembered playing DJ Hero, a game I suck at by the way. In it, the player uses a little switch to set the volume of the right and left records into the speaker. So move the little knob to the left and you hear more of the left record and less of the right. So if the musics line up, you can combine them into a different thing altogether. A "Mix" if you would.
So I thought, "Hey, let's play 2 music tracks at the same time and let's make the volume of each a function (used in the mathematical term here) of some other variable. So let's have one be that, and the other be the inverse." The thinking was, if that number was between 1 and 0, then having the variable be set to 0 would be all of one track and none of the other, like pushing the little knob all the way to the left on a DJ Board. The 1, would be all the way to the right and anything in between would be a mix of the two.
Having done some tests on it, it worked out pretty well. At least in theory. I don't have musics that match, but I could get 2 things to play at once.
Then the whole thing was shit.
You see, I then tried to make the twice damned thing controllable. So I installed a little bit into my control code that would allow me to modify that Crossfader variable, and...nothing. It didn't work. So I told the computer to tell me when it was running the code I had just installed. The conversation went like this:
"Hey, computer, are you running that code?"
"What code?"
"The code I just wrote. It's right next to that other code you just ran."
"No it's not."
"No, really, it is. Could you look again?"
"Why?"
"Because I asked?"
"Wait, what are we talking about?"
"The code. Remember?"
"I like kittys."
That's exactly how I remember it anyway. So, like a good little code monkey I copied the whole thing over to a new program. Thief has like, 12000 lines of code, so maybe, just maybe, something else was screwing the pooch. I hit the "Go" button and:
"Hey, no problem now right? I'll push the key for you."
"..."
"Computer, did you see that key?"
"No?"
"Are you asking me?"
"Nooo?"
"So you don't think a key is being pressed?"
"No."
"Really? You're doing this to me? Now?"
"MMmmm...panda cookies."
So I cut the sound code out of the code I was writing. Now we were reduced to just loops - the basic building blocks of almost everything in a computer system. The Bread and Butter that keeps a coder coding, although less oily. So with that done, I mashed the keys, hoping for any sign of intelligence or life. Instead the loop just ran, oblivious to the outside world until I gave opened my razor and gave it the Sweeny.
I'm not sure yet exactly what happened, but I managed to swear a whole lot before I went to bed in a hazy anger, a kind of half hearted digital blood lust.
I'll try again later. Although now I have a crazy jones for those chocolate panda cookies, you know, the ones with the little pandas (or koalas, if you're into that) doing different jobs. I wonder if there is a Code Panda, they'd be the ones with the laptop and the furious eyes.
Monday, March 22, 2010
P's and Cues
The Cliffs Level, I know that you're sick of hearing about the Cliff Level. Well, that statement is assuming that anybody reads this, or cares, or even remembers really. In any event, I got something finally working correctly. Recently, I've been getting a lot of very high quality music from our resident composer, and I've been putting it into the appropriate game places and it's really quite nice. With the art in various states of completion, having the music in and done really provides a kind of cohesiveness to the thing. However, the one piece of music that I've been very hesitant about it the music for the Cliffs Level.
If you look way back, you'll see that the design paradigm for that level was to make it tightly scripted, with a ton of invisible switches and deformable areas. It's easily the most complicated level in the game from an art, coding and music perspective. But now I've a solution.
The idea here, is to have different music cue up at different times. I could have a single song, but then I really do think it'll lose the impact that it should have. It could be upbeat and perilous, or somber and cerebral. I'd rather have both. For most of the areas I really do want to have soft, almost quiet music that ramps up into something more, um, robust when certain things are happening. The problem with that from a composing perpective is that none of that will happen at set times. I can't say, "Oh, and there's a boulder sequence at 1:15 seconds," because the player could play it at a different speed entirely.
Which is the issue I tackled yesterday like a roided bull. The solution as I see it, is to write 2 different pieces of music with the same timing that could be played at the same time. So they could match in most things, but one would have a lot more stuff going on, and louder, What I'll do is start both pieces at the same time, but have the loud one be turned off to start. The scripting will cross fade from one to the other as I need them. So like the boulder sequence will trigger the a volume increase on the loud music and a decrease/mute on the quiet one. Afterwards, it'll cross fade back. Using some test MP3s, it's working as a system so far. Although I get the impression that this may take far more effort than it has.
I also discovered something yesterday. Blitz Basic is very, very easy to code in. Especially if you've been wandering the C# desert for the last month or so. A little bashing and online command look up and I got the solution that I've been looking for since I started the Cliff Level working in about 5 minutes. It's as if I'm thinking of things a little differently, more abstracted.
I'm reading Snow Crash, and I came across something a little off putting. It posited that when you learn to code, or I assume learn a language, that your brain changes the way it thinks about things. The meat starts to change itself and create new pathways, which then facilitate the understanding of the task at hand (the book also says it would be possible to upload information, like a virus, into a properly configured meat, but that's beside the point).
It's an odd concept that I think holds some liquid. Once you begin thinking about something a certain way, it becomes easier to understand, so you make progress on a logarithmic scale, exponentially. It's a weird feeling though; considering that this thing I've been doing has very likely changed the way my brain functions on a basic level. Very weird.
You can never go back.
If you look way back, you'll see that the design paradigm for that level was to make it tightly scripted, with a ton of invisible switches and deformable areas. It's easily the most complicated level in the game from an art, coding and music perspective. But now I've a solution.
The idea here, is to have different music cue up at different times. I could have a single song, but then I really do think it'll lose the impact that it should have. It could be upbeat and perilous, or somber and cerebral. I'd rather have both. For most of the areas I really do want to have soft, almost quiet music that ramps up into something more, um, robust when certain things are happening. The problem with that from a composing perpective is that none of that will happen at set times. I can't say, "Oh, and there's a boulder sequence at 1:15 seconds," because the player could play it at a different speed entirely.
Which is the issue I tackled yesterday like a roided bull. The solution as I see it, is to write 2 different pieces of music with the same timing that could be played at the same time. So they could match in most things, but one would have a lot more stuff going on, and louder, What I'll do is start both pieces at the same time, but have the loud one be turned off to start. The scripting will cross fade from one to the other as I need them. So like the boulder sequence will trigger the a volume increase on the loud music and a decrease/mute on the quiet one. Afterwards, it'll cross fade back. Using some test MP3s, it's working as a system so far. Although I get the impression that this may take far more effort than it has.
I also discovered something yesterday. Blitz Basic is very, very easy to code in. Especially if you've been wandering the C# desert for the last month or so. A little bashing and online command look up and I got the solution that I've been looking for since I started the Cliff Level working in about 5 minutes. It's as if I'm thinking of things a little differently, more abstracted.
I'm reading Snow Crash, and I came across something a little off putting. It posited that when you learn to code, or I assume learn a language, that your brain changes the way it thinks about things. The meat starts to change itself and create new pathways, which then facilitate the understanding of the task at hand (the book also says it would be possible to upload information, like a virus, into a properly configured meat, but that's beside the point).
It's an odd concept that I think holds some liquid. Once you begin thinking about something a certain way, it becomes easier to understand, so you make progress on a logarithmic scale, exponentially. It's a weird feeling though; considering that this thing I've been doing has very likely changed the way my brain functions on a basic level. Very weird.
You can never go back.
Tuesday, March 16, 2010
Members Only
So it turns out I was both correct and wrong in equal measure regarding the previous posts. First of all, it turns out that whether or not I can access information has nothing, nada, zero to do with whether or not the information I'm looking for is somehow abstract. It turns out, that I had done something stupid. You see, when I originally set up my Arch Sprite Class - the one that contains all the little details about how the sprites themselves will function - I had followed what online tutorials said I should, which is to mark the class variables as "Private."
I'll start over so we can all keep up. Classes, like I've mentioned before, are just like little robots. I can make a new on and it'll follow the instructions I gave it. The Sprite Class is a big Class that all the little Sprites are connected to. So the player pictures, and the enemies, and bullets and all of that are all sprites. Instead of giving all of them the specific instructions for how they are drawn and the logic that controls all of that, they instead are all the little childrens of the Sprite Class proper, and that Sprite Class controls all of their display logic and stuff for them.
That big Sprite Class also defines all the bits that the little Classes are made of. So their positions, and their speed, and what picture they use, and all of the other silly things (like how big their pictures are). Those are the variables that I'm talking about. They can be marked as either "Private" which means that only the Class that the variable belongs to can use (or access) that variable. "Public" means that anything can get the information as long as I can be specific enough. "Internal" means that the information can be shared inside the Class Family. So an internal variable could be seen by both the player class and the enemy class if I wanted it to be.
My problem, was that I had made the position of the different things a Private matter. I told the computer that it wasn't anybody else's business and they should stay out of it. Now I've told it that it's okay to gossip a little. Share the knowledge really.
Long story short, I can get to any of the data anywhere as long as it's a sprite. This new access to my own bullshit has allows progress to advance quickly. So after a fashion, like the start said, I was correct in a previous assumption - the data is all organized like a bunch of little tables, and I can get to it if I want.
What I don't understand, is why the ability to make a variable Private is event there in the first bloody place. Unless it's a variable that controls something inside a function I don't see why you wouldn't want to be access that information wherever it is convenient. It may be faster somehow when the program is running, but I'm finding the access is making things far easier to implement.
Ah right, what do I mean by "inside a function?" Say you want the computer to do something ten times. So you would create a counter inside a function. Every time the function does something, you'd increase that counter by one. When the counter is at 11, you would make the function stop. That counter would be "inside" the function. It's a made up number that doesn't exist anywhere else, because it doesn't need to. The next time the function comes around, we'll make a new counter number. Contrast that to say, the player's life total. That's important information that we would need to remember.
Yay! Technical!
Speaking of silly other crap, I went ahead an built a new way to see if things are touching. I already had a way, but it required that something be there. So I could see if bullets hit enemies or things were crashing into the player, but I had now way of knowing if something was touching an area with nothing it it. So I built a function that compares two sets of points. It checks to see if the first four points are inside the area of the other four. It works pretty well actually. Try as I might, I couldn't make it really perfect, but then I remembered I don't need to. These areas are really just for AI, and they work great in that capacity. So now I have enemies that dive on the player if the player happens to be in the target area below them.
In all, now my software works. There are no bugs that I can see, and the whole thing is spinning along nicely. The basic backbone of the thing is constructed, and now I can hang the rest of the elements on like little tree ornaments.
-Yes, I know. This is like, the 7th technical post in a row. If I got letters (from readers - HA!) they would probably say things like, "Um, you ramble too damn much and we don't know what you're talking about sometimes." Or "Get back to talking about design and making stuff fun." Maybe "Oh, and the kitten punting thing. You haven't mentioned that in like, forever."
Sorry boys and / or girls, but that's the second, cool part. I mean, you don't start off playing in front of thousands, you have to put the time in to learn power chords and rockstar slides first. Besides, you'd be surprised how much of game development is this.
Oh, and I feel smart sharing my victories. It's slightly better than ranting against my shortcomings, even if it's less interesting to read.
- Oh, and CID still doesn't condone the punting of kittens. Even if they deserve it. Little Brutes.
I'll start over so we can all keep up. Classes, like I've mentioned before, are just like little robots. I can make a new on and it'll follow the instructions I gave it. The Sprite Class is a big Class that all the little Sprites are connected to. So the player pictures, and the enemies, and bullets and all of that are all sprites. Instead of giving all of them the specific instructions for how they are drawn and the logic that controls all of that, they instead are all the little childrens of the Sprite Class proper, and that Sprite Class controls all of their display logic and stuff for them.
That big Sprite Class also defines all the bits that the little Classes are made of. So their positions, and their speed, and what picture they use, and all of the other silly things (like how big their pictures are). Those are the variables that I'm talking about. They can be marked as either "Private" which means that only the Class that the variable belongs to can use (or access) that variable. "Public" means that anything can get the information as long as I can be specific enough. "Internal" means that the information can be shared inside the Class Family. So an internal variable could be seen by both the player class and the enemy class if I wanted it to be.
My problem, was that I had made the position of the different things a Private matter. I told the computer that it wasn't anybody else's business and they should stay out of it. Now I've told it that it's okay to gossip a little. Share the knowledge really.
Long story short, I can get to any of the data anywhere as long as it's a sprite. This new access to my own bullshit has allows progress to advance quickly. So after a fashion, like the start said, I was correct in a previous assumption - the data is all organized like a bunch of little tables, and I can get to it if I want.
What I don't understand, is why the ability to make a variable Private is event there in the first bloody place. Unless it's a variable that controls something inside a function I don't see why you wouldn't want to be access that information wherever it is convenient. It may be faster somehow when the program is running, but I'm finding the access is making things far easier to implement.
Ah right, what do I mean by "inside a function?" Say you want the computer to do something ten times. So you would create a counter inside a function. Every time the function does something, you'd increase that counter by one. When the counter is at 11, you would make the function stop. That counter would be "inside" the function. It's a made up number that doesn't exist anywhere else, because it doesn't need to. The next time the function comes around, we'll make a new counter number. Contrast that to say, the player's life total. That's important information that we would need to remember.
Yay! Technical!
Speaking of silly other crap, I went ahead an built a new way to see if things are touching. I already had a way, but it required that something be there. So I could see if bullets hit enemies or things were crashing into the player, but I had now way of knowing if something was touching an area with nothing it it. So I built a function that compares two sets of points. It checks to see if the first four points are inside the area of the other four. It works pretty well actually. Try as I might, I couldn't make it really perfect, but then I remembered I don't need to. These areas are really just for AI, and they work great in that capacity. So now I have enemies that dive on the player if the player happens to be in the target area below them.
In all, now my software works. There are no bugs that I can see, and the whole thing is spinning along nicely. The basic backbone of the thing is constructed, and now I can hang the rest of the elements on like little tree ornaments.
-Yes, I know. This is like, the 7th technical post in a row. If I got letters (from readers - HA!) they would probably say things like, "Um, you ramble too damn much and we don't know what you're talking about sometimes." Or "Get back to talking about design and making stuff fun." Maybe "Oh, and the kitten punting thing. You haven't mentioned that in like, forever."
Sorry boys and / or girls, but that's the second, cool part. I mean, you don't start off playing in front of thousands, you have to put the time in to learn power chords and rockstar slides first. Besides, you'd be surprised how much of game development is this.
Oh, and I feel smart sharing my victories. It's slightly better than ranting against my shortcomings, even if it's less interesting to read.
- Oh, and CID still doesn't condone the punting of kittens. Even if they deserve it. Little Brutes.
Thursday, March 11, 2010
Creationism
Yesterday I got the first type of Crasher enemy installed into the code that will eventually be Paper Zeppelin. In the Design Doc, which is I haven't posted yet cause it's not done yet, when enemies or players are destroyed instead of exploding they fall towards the ground. If they hit something else, a cascade of destruction will happen. This particular mechanic should also make multiplayer a little more communication oriented. I mean if the other players are destroying enemies all willie and/or nillie, it will probably put you in danger of their particular crap. It's a different way of thinking about a shooter.
Anyway, I got the Crasher type going down in a big ball of flames. However, it's not working yet. You see, when I hit an enemy will a bullet, they both get erased from time and space and a crasher is summoned. That's not quite right. Truthfully, the crasher is summoned right before I make with the erasing, so I still have variables to use. The issue is that I cannot get the crasher to appear where the enemy just was. The enemy position variables seem to be locked behind some kind of iron door. The stupid thing is that I can clearly use the damn numbers, since the drawing and collision functions clearly work. But as soon as I explicitly ask for them, it falls down. Further, unlike the work around I was able to cleave for the bullets, this particular information only exists in the abstract.
The really dumb thing is that, hypothetically, the different classes are really just a bunch of data in a table. The cells are full of different stuff, but basically, it's a table. They're numbered somehow, and the column means something. So, hypothetically, if I were to say, "Hey, you, get me the number from Row 7, Column 5," it shouldn't be a fuggin issue.
Instead it tells me that I don't have the correct access level. It's something I assume comes from the enemies having Public or Private numbers and attributes. I'm not exactly sure though, and it makes hate well right up from the deep recesses of my brain like a black oil.
So I guess what I'm saying is, "Good news everybody! I got another framework type of thing built and installed, and it almost works!"
I'll pound my cranium on this wall until one of us gives.
Anyway, I got the Crasher type going down in a big ball of flames. However, it's not working yet. You see, when I hit an enemy will a bullet, they both get erased from time and space and a crasher is summoned. That's not quite right. Truthfully, the crasher is summoned right before I make with the erasing, so I still have variables to use. The issue is that I cannot get the crasher to appear where the enemy just was. The enemy position variables seem to be locked behind some kind of iron door. The stupid thing is that I can clearly use the damn numbers, since the drawing and collision functions clearly work. But as soon as I explicitly ask for them, it falls down. Further, unlike the work around I was able to cleave for the bullets, this particular information only exists in the abstract.
The really dumb thing is that, hypothetically, the different classes are really just a bunch of data in a table. The cells are full of different stuff, but basically, it's a table. They're numbered somehow, and the column means something. So, hypothetically, if I were to say, "Hey, you, get me the number from Row 7, Column 5," it shouldn't be a fuggin issue.
Instead it tells me that I don't have the correct access level. It's something I assume comes from the enemies having Public or Private numbers and attributes. I'm not exactly sure though, and it makes hate well right up from the deep recesses of my brain like a black oil.
So I guess what I'm saying is, "Good news everybody! I got another framework type of thing built and installed, and it almost works!"
I'll pound my cranium on this wall until one of us gives.
Tuesday, March 9, 2010
Collision Imminent
I've found the fourth piece. Yes I did. This "fouth piece" is the final bit needed for a game to work from a programming perspective. They are : Drawing Stuff, Controling Stuff, Updating Stuff and now, making stuff Collide.
It did take me the better part of an hour though. The main reason is that I never stopped to consider for a moment what it is the hells I'm trying to summon sometimes. I tried functions that would call for numbers that don't always exist. So on my first try, I went ahead and had the computer go float up the variables from the player bullets. Of course, I ran into an error message as soon as I compiled because no bullets existed. Other times the computer was nice enough to let me know as soon as I typed it out, "Hey, um, yeah, that doesn't work. Quit being stupid."
Floating variables for these particular types of objects is clearly different than floating up player variables. Players are clearly defined and have names. Everything else is just digital huddled masses, like the nameless hordes in Rambo movies that are granted existence only long enough to have it stripped from them forcefully.
So, if I write a function that asks, "Can I have the X and Y for a bullet please?" the answer is rightfully, "The bullet? I have no idea what you are talking about. You fail at life."
"So," I reasoned, "Maybe there must be another way to compare objects."
What I came upon, was buliding a second list. Actually, build several lists of objects. So now there is a list for players, one for player bullets and one for enemies. When I run the enemy update codes (basically the same as the SpriteList from before) I added another little loop inside that also asks, "Hey, while you're here, are you touching any of the player bullets?"
Consequently, it works. They touch and their short, and I have to assume - miserable, lives are wiped out by the raw power of an emerald Bullet Bill.
In any event, with the basic code of collision in place I can get that whole system dancing. My lists are flexible enough to do almost anything with them. Further, they're portable and abstract enough that I can use them in lots of things. Other things, strange things, EP-esque things. I'm quite a happy panda.
- In other news, the Team continues to work along buliding assets for The Thief's Tale. New stuff continues to come in. Sometimes in bursts, other times at a trickle. If you go back, say, 3 months, there was once a tentative Complete Date of the end of January. That didn't happen. Yet, I still continue to believe that a Complete Date will happen.
My belief is granted strength by the periodic infusion of justification.
I've also decided to give The Tester a chance to do some animation. He's been studying dilligently and has learned a good number of things at school, like how to rig up a model. I've found that learning by doing to be the best way (well learning by doing and then writing extensivley about it), and we have time. I'm positive about it.
It did take me the better part of an hour though. The main reason is that I never stopped to consider for a moment what it is the hells I'm trying to summon sometimes. I tried functions that would call for numbers that don't always exist. So on my first try, I went ahead and had the computer go float up the variables from the player bullets. Of course, I ran into an error message as soon as I compiled because no bullets existed. Other times the computer was nice enough to let me know as soon as I typed it out, "Hey, um, yeah, that doesn't work. Quit being stupid."
Floating variables for these particular types of objects is clearly different than floating up player variables. Players are clearly defined and have names. Everything else is just digital huddled masses, like the nameless hordes in Rambo movies that are granted existence only long enough to have it stripped from them forcefully.
So, if I write a function that asks, "Can I have the X and Y for a bullet please?" the answer is rightfully, "The bullet? I have no idea what you are talking about. You fail at life."
"So," I reasoned, "Maybe there must be another way to compare objects."
What I came upon, was buliding a second list. Actually, build several lists of objects. So now there is a list for players, one for player bullets and one for enemies. When I run the enemy update codes (basically the same as the SpriteList from before) I added another little loop inside that also asks, "Hey, while you're here, are you touching any of the player bullets?"
Consequently, it works. They touch and their short, and I have to assume - miserable, lives are wiped out by the raw power of an emerald Bullet Bill.
In any event, with the basic code of collision in place I can get that whole system dancing. My lists are flexible enough to do almost anything with them. Further, they're portable and abstract enough that I can use them in lots of things. Other things, strange things, EP-esque things. I'm quite a happy panda.
- In other news, the Team continues to work along buliding assets for The Thief's Tale. New stuff continues to come in. Sometimes in bursts, other times at a trickle. If you go back, say, 3 months, there was once a tentative Complete Date of the end of January. That didn't happen. Yet, I still continue to believe that a Complete Date will happen.
My belief is granted strength by the periodic infusion of justification.
I've also decided to give The Tester a chance to do some animation. He's been studying dilligently and has learned a good number of things at school, like how to rig up a model. I've found that learning by doing to be the best way (well learning by doing and then writing extensivley about it), and we have time. I'm positive about it.
Friday, March 5, 2010
Keeper of the House
I'm thinking that I've got a pretty goo handle on C# now. It's not quite yet enough for me to declare that "My Kung Fu is Strong," but certianly enough to do what I demand of it. I'm also beginning to think about ways to do other projects in the docket, specifically the incredibly esoteric EP (a project that I very well could code is Blitz, since I'm fuggin Li Mu Bai in that particular Matrix). In any event, I've got a fine competentcy in classes. I can summon them, serve them, update them, and most importantly, I can make them talk to each other. Also, when I write things they tend not to crash outright, and that's miles ahead of where I started. Far less swearing now - the key word there being "less."
So yesterday after diving into the code I starte putting together one of the most basic enemies to allow me to code collision and so on, and I could not find a decent way to insert them into the code as it was. I made a new class of objects, gave it a few things to do and then could not easily add a way to pull them from nothingness. On a longer term, I'm planning on basically stealing the code out of one of the code samples that came with the C# compiler. In it a string of character is translated into tiles. I'm going to expand that considerably to allow for scrolling, and then spawn ground, enemies, background elements and everthing else through this system. Then I'll be able to put together whole levels using a text editor. It'll save me a bunch on time building tools, since my computer came preinstalled with WordPad. Of course, adding these additional functions to the "borrowed" code will require that I have a far deeper understanding of the thing, so I don't consider it cheating.
Anyway, I haven't done that yet, but I still need to create the little buggers so I can build the rest of the engine. My easy work around is to create them on the screen through a press of a button (the big green A button in this case). But I couldn't, since all of my control functions were inside the spawning functions of players and bullets. It's a situation that, I've learned the hard way, needs avoiding.
So, even though I really wanted to make little planes doing little plane stuff, I instead found that I had to rewrite and reorganize not un-small chunkies of code. So the spawn functions were stripped of their controls and a new centralized Control Function was built. After some, let's say, dumbassery I got it doing a two step.
Along the way, I discovered the bestest thing ever (this week). By creating functions that only call constructors (little commands that make new instances of classes) I can deal with adding only the information that I give a steaming crap about. Let me try that again, from the beginning. Functions, as we know (if not, go back 2 years and read up to here {like anybody reads this}) are little bits of code that can be looked at and treated as little blocks of informations and instructions. So in Thief when I make the dude run, there's a "Run" function that has all the code that makes him run. I could write that out every time, or I could do it once and label the whole chunk Run(). Later, instead of typing it out again, I just have to put "Run()" and the computer will go find the code I already did. It allows me to make changes in one place and have it go everywhere. The little ( ) at the end let's me tell it stuff.
Constructors make instances. That sounds very complicated. The way I think about it is to say that the code for Classes are instructions for a robot. So all my Robot Chickens will follow the Chicken Class Code. When I call the constructor code for a Chicken, it makes a new Robot Chicken that will also follow that Chicken code. It's a cute thing. When you make a new Chicken (or any new instance, chicken or otherwise) you tell it starting information and most of that information is the same every time.
This is where the two meet in the middle. So let's say that there's a dozen bits of information for making a new Chicken, silly stuff like animation frame information and stuff like that. The only one we care about is which color the Chicken will be. So instead of writing out the whole thing with a dozen little bits, I can make a function with all of that already there and a variable for the color. Then just do this :
MakeAChicken(Red)
It's how bullets work now in the Prototype for Paper Zeppelin.
- Oh, up towards the top you’ll notice I mentioned that I try to avoid spreading my control functions all over the place. There’re a couple of reasons for that. The first is that, hypothetically, if I wanted to change something I’d have to find every single instance of the controls being looked at and update them, which is stupid. I know this because it took me 2 days to add gamepad support to The Thief’s Tale. Those are days I’m not getting back.
The other reason is one of speed. You see, a piece of software runs in your computer; CPUs and GPUs and motherboards and a bunch of other technical sounding things. Imagine that the innards of your computer are a city like San Diego. Now imagine that all the little bits are scattered around in their own buildings. So the CPU is City Hall, and the Motherboard is the streets and PetCo Park (or whatever it’s named this week) is your hard drive. Now say that the CPU needs some info from the hard drive, so it sends a message via Bike Messenger.
Since PetCo is reasonably close to City Hall, it’s a pretty short trip and goes pretty fast.
A controller or keyboard or anything else, isn’t even in the same city. It’s not on the same streets even. So say, the CPU wants to look at something at the keyboard. It again sends a Bike Messenger, only this time, he has to pedal his little ass all the way to Los Angeles. That’s kind of slow. Now do that a couple of dozen times per cycle and we see why that’s something to dodge. If you need to do it, just once should be enough.
- Hmm, technical post today. It’s what happens when the Designer also does all the programming then feels the need to explain it. I’ll see if I can’t use even more tortured metaphors in the future.
So yesterday after diving into the code I starte putting together one of the most basic enemies to allow me to code collision and so on, and I could not find a decent way to insert them into the code as it was. I made a new class of objects, gave it a few things to do and then could not easily add a way to pull them from nothingness. On a longer term, I'm planning on basically stealing the code out of one of the code samples that came with the C# compiler. In it a string of character is translated into tiles. I'm going to expand that considerably to allow for scrolling, and then spawn ground, enemies, background elements and everthing else through this system. Then I'll be able to put together whole levels using a text editor. It'll save me a bunch on time building tools, since my computer came preinstalled with WordPad. Of course, adding these additional functions to the "borrowed" code will require that I have a far deeper understanding of the thing, so I don't consider it cheating.
Anyway, I haven't done that yet, but I still need to create the little buggers so I can build the rest of the engine. My easy work around is to create them on the screen through a press of a button (the big green A button in this case). But I couldn't, since all of my control functions were inside the spawning functions of players and bullets. It's a situation that, I've learned the hard way, needs avoiding.
So, even though I really wanted to make little planes doing little plane stuff, I instead found that I had to rewrite and reorganize not un-small chunkies of code. So the spawn functions were stripped of their controls and a new centralized Control Function was built. After some, let's say, dumbassery I got it doing a two step.
Along the way, I discovered the bestest thing ever (this week). By creating functions that only call constructors (little commands that make new instances of classes) I can deal with adding only the information that I give a steaming crap about. Let me try that again, from the beginning. Functions, as we know (if not, go back 2 years and read up to here {like anybody reads this}) are little bits of code that can be looked at and treated as little blocks of informations and instructions. So in Thief when I make the dude run, there's a "Run" function that has all the code that makes him run. I could write that out every time, or I could do it once and label the whole chunk Run(). Later, instead of typing it out again, I just have to put "Run()" and the computer will go find the code I already did. It allows me to make changes in one place and have it go everywhere. The little ( ) at the end let's me tell it stuff.
Constructors make instances. That sounds very complicated. The way I think about it is to say that the code for Classes are instructions for a robot. So all my Robot Chickens will follow the Chicken Class Code. When I call the constructor code for a Chicken, it makes a new Robot Chicken that will also follow that Chicken code. It's a cute thing. When you make a new Chicken (or any new instance, chicken or otherwise) you tell it starting information and most of that information is the same every time.
This is where the two meet in the middle. So let's say that there's a dozen bits of information for making a new Chicken, silly stuff like animation frame information and stuff like that. The only one we care about is which color the Chicken will be. So instead of writing out the whole thing with a dozen little bits, I can make a function with all of that already there and a variable for the color. Then just do this :
MakeAChicken(Red)
It's how bullets work now in the Prototype for Paper Zeppelin.
- Oh, up towards the top you’ll notice I mentioned that I try to avoid spreading my control functions all over the place. There’re a couple of reasons for that. The first is that, hypothetically, if I wanted to change something I’d have to find every single instance of the controls being looked at and update them, which is stupid. I know this because it took me 2 days to add gamepad support to The Thief’s Tale. Those are days I’m not getting back.
The other reason is one of speed. You see, a piece of software runs in your computer; CPUs and GPUs and motherboards and a bunch of other technical sounding things. Imagine that the innards of your computer are a city like San Diego. Now imagine that all the little bits are scattered around in their own buildings. So the CPU is City Hall, and the Motherboard is the streets and PetCo Park (or whatever it’s named this week) is your hard drive. Now say that the CPU needs some info from the hard drive, so it sends a message via Bike Messenger.
Since PetCo is reasonably close to City Hall, it’s a pretty short trip and goes pretty fast.
A controller or keyboard or anything else, isn’t even in the same city. It’s not on the same streets even. So say, the CPU wants to look at something at the keyboard. It again sends a Bike Messenger, only this time, he has to pedal his little ass all the way to Los Angeles. That’s kind of slow. Now do that a couple of dozen times per cycle and we see why that’s something to dodge. If you need to do it, just once should be enough.
- Hmm, technical post today. It’s what happens when the Designer also does all the programming then feels the need to explain it. I’ll see if I can’t use even more tortured metaphors in the future.
Monday, March 1, 2010
Adatir of Gondor
Ah, much to talk about. Let's start with the stuff from the last post. The design document for Paper Zeppelin is coming along, just taking longer than I wanted. Important questions regarding the structure of things come up when you actually have to write them out instead of simply thinking about them in abstracted ways. The hard truth of some aspects becomes very apparent when it's literally black and white. It can also save a lot of time instead of getting right into prototyping.
For example, in PZ the point of each stage is to pick up a bomb and drop in onto an enemy base. Sounds easy, but what if they don't? So what? Now what do you do? You can't make a player redo an entire level because they screwed one aspect, yet I don't want to add convoluted systems that I will have to code into a language that I have a base familiarity with. Important questions. (By the way, the solution is branching level sequences).
So yeah, I'm into that. I do have the enemies and the basic engine concepted all out. Really, it's simply faking a scrolling environment. Everything in the game that isn't the players, like the ground tiles, enemies, background elements and so forth are all spawned on the right side of the screen. They then travel to the left side and are subsequently culled when they leave the screen. But if I make the ground and any ground based enemies go all the same speed then it appears to scroll on by, even though the player's really don't move around too much.
I also have the basic enemies sorted out, so I'll get to coding those up soon and maybe I'll get to my Break Point.
Ah, Capital Letters seems to imply a keyword there. It's an odd little quirk of my game designs. I figure out, if there is nothing else, at what point will I know if the basic concept and gameplay is sound and interesting. In other words, the Break Point is where I have done the least amount of work to get the idea of what the game will be like on a super basic level. From there I decide to either throw out the whole thing, keep on going, redesign parts or do something else if. So that Point is what I'm working on now. It's not pretty, I mean the BP for Thief was my Zero sprite moving around a blank screen with no platforms yet to see if the most basic of movements was interesting or not.
Of course, that's not to say that I don't prototype. I mean, read the other posts that start with, "I was thinking about..." and end with, "...but then I decided I hated it." But I find the best and fastest way to do that is with thorough thought experiments. Running the would be game a thousand times in my head trying to discern unseen interactions between game systems before I code a line. PZ though, is getting to the point where coding in the very next part.
- Speaking of a game that's past that Point, I've got a couple of more animators involved with Thief. So I'm going to get one of them involved in combat animations for The Knight character so I can have a full combat animation set. Then, finally, I'll be able to really have other people test it without needing a cheat sheet explaining what the deuce a yellow rectangle on the enemy means (high block, unless the enemy is moving, then it's a lunge {do you see what I mean now?})
Also, I continue to get smashing good musics into the game. Which I'm really very happy with. I love opening the mail in the morning and finding stuff.
- Finally, for the other site I'm involved with writing a review for The Lord of the Rings Online (or LotRO as the cool kids call it). I won the opportunity through happenstance, and the fact that my phone boops when I get an email. Anyway, I'll be writing several articles about that. The idea is that the game is simply way too big for a thousand snarky works to really do any kind of justice. I mean, whole systems should be worthy of critique, provided they have enough meat to chew. Add to that the fact that end of game stuff can take several (dozen) hours to get to and we find that a different approach is needed.
So I'm planning on writing a series of articles, each going into certain aspects of the game itself, from starting, the main quests, PvP, raiding and so on. To that end, I've built me up a character called Adatir of Gondor. The name, of course, is a stupid play on words that I simply must share (even though it's a little wanky and self indulgent). The name is two parts, "Ada" means "Again" and "Tir" means "To See, or to Look" like the Palantir that Saruman had. Put the words together and Adatir means, "So Look/See Again" or "Re-View."
In any event, I'm 5 levels into it, stabbing boars, wild dogs and creepy bandit types and finding myself having an unnaturally decent time with it. It's like I can see the underlying loot and abilities treadmill, the gears running just below the surface and I don't really care. I know I'm being manipulated on a super basic level, and yet I keep on going. I kill something with a spear (or a shield bash - I love those!) and get XP and loot. I sell said XP and loot to gain new weapons, which I want to play with. Playing with sharp, pointy things nets me more XP and loot and then I've gained a level and have new abilities. Of course, my session wouldn't be over until I've rocked out with my new Super Stab of Bree or whatever and the cycle continues. Now I'm supposed to go stab a giant boar of some kind. Not sure how that relates to the end of the Third Age, but I'm willing to have my puppet strings pulled enough to find out.
I could see that adding friends to this particular mix would create a very potent cocktail indeed.
- Ah, right, almost forgot. I'm still posting the Design Document for Paper Zeppelin....when it's ready. Maybe soon.
For example, in PZ the point of each stage is to pick up a bomb and drop in onto an enemy base. Sounds easy, but what if they don't? So what? Now what do you do? You can't make a player redo an entire level because they screwed one aspect, yet I don't want to add convoluted systems that I will have to code into a language that I have a base familiarity with. Important questions. (By the way, the solution is branching level sequences).
So yeah, I'm into that. I do have the enemies and the basic engine concepted all out. Really, it's simply faking a scrolling environment. Everything in the game that isn't the players, like the ground tiles, enemies, background elements and so forth are all spawned on the right side of the screen. They then travel to the left side and are subsequently culled when they leave the screen. But if I make the ground and any ground based enemies go all the same speed then it appears to scroll on by, even though the player's really don't move around too much.
I also have the basic enemies sorted out, so I'll get to coding those up soon and maybe I'll get to my Break Point.
Ah, Capital Letters seems to imply a keyword there. It's an odd little quirk of my game designs. I figure out, if there is nothing else, at what point will I know if the basic concept and gameplay is sound and interesting. In other words, the Break Point is where I have done the least amount of work to get the idea of what the game will be like on a super basic level. From there I decide to either throw out the whole thing, keep on going, redesign parts or do something else if. So that Point is what I'm working on now. It's not pretty, I mean the BP for Thief was my Zero sprite moving around a blank screen with no platforms yet to see if the most basic of movements was interesting or not.
Of course, that's not to say that I don't prototype. I mean, read the other posts that start with, "I was thinking about..." and end with, "...but then I decided I hated it." But I find the best and fastest way to do that is with thorough thought experiments. Running the would be game a thousand times in my head trying to discern unseen interactions between game systems before I code a line. PZ though, is getting to the point where coding in the very next part.
- Speaking of a game that's past that Point, I've got a couple of more animators involved with Thief. So I'm going to get one of them involved in combat animations for The Knight character so I can have a full combat animation set. Then, finally, I'll be able to really have other people test it without needing a cheat sheet explaining what the deuce a yellow rectangle on the enemy means (high block, unless the enemy is moving, then it's a lunge {do you see what I mean now?})
Also, I continue to get smashing good musics into the game. Which I'm really very happy with. I love opening the mail in the morning and finding stuff.
- Finally, for the other site I'm involved with writing a review for The Lord of the Rings Online (or LotRO as the cool kids call it). I won the opportunity through happenstance, and the fact that my phone boops when I get an email. Anyway, I'll be writing several articles about that. The idea is that the game is simply way too big for a thousand snarky works to really do any kind of justice. I mean, whole systems should be worthy of critique, provided they have enough meat to chew. Add to that the fact that end of game stuff can take several (dozen) hours to get to and we find that a different approach is needed.
So I'm planning on writing a series of articles, each going into certain aspects of the game itself, from starting, the main quests, PvP, raiding and so on. To that end, I've built me up a character called Adatir of Gondor. The name, of course, is a stupid play on words that I simply must share (even though it's a little wanky and self indulgent). The name is two parts, "Ada" means "Again" and "Tir" means "To See, or to Look" like the Palantir that Saruman had. Put the words together and Adatir means, "So Look/See Again" or "Re-View."
In any event, I'm 5 levels into it, stabbing boars, wild dogs and creepy bandit types and finding myself having an unnaturally decent time with it. It's like I can see the underlying loot and abilities treadmill, the gears running just below the surface and I don't really care. I know I'm being manipulated on a super basic level, and yet I keep on going. I kill something with a spear (or a shield bash - I love those!) and get XP and loot. I sell said XP and loot to gain new weapons, which I want to play with. Playing with sharp, pointy things nets me more XP and loot and then I've gained a level and have new abilities. Of course, my session wouldn't be over until I've rocked out with my new Super Stab of Bree or whatever and the cycle continues. Now I'm supposed to go stab a giant boar of some kind. Not sure how that relates to the end of the Third Age, but I'm willing to have my puppet strings pulled enough to find out.
I could see that adding friends to this particular mix would create a very potent cocktail indeed.
- Ah, right, almost forgot. I'm still posting the Design Document for Paper Zeppelin....when it's ready. Maybe soon.
Subscribe to:
Posts (Atom)
