Controller input is done. All done. From the front menu to the combat controls, the buttons and the sticks just work. With their inclusion, the game just works better. I've found that sometimes you get used to something without it necessarily being the best way. Like originally the Double Jump was done by pressing Up during a jump. It worked great for me, but everybody else seemed to hate it with the kind of passion usually reserved for the people on VH1 reality shows. I mean, they treated the mechanic like it had the Herp, everywhere. So after doing some fiddling it worked using the same key, the all around "Jump/Contextual Action" key. The change made the game so, I can't quite find the words now, but I did then.
What I'm getting at is that now, I can't really use the keyboard anymore. I mean, I still can, since I've done it for the last two (!) years, but the controller is so much smoother, such a superior way to enjoy Thief. Now I know that there is a slight Familiarity-Breeds-Contempt action going on here, and anything different in the experience will be considered new and shiny, but really the difference the controller brings is superb.
What I did find out though, one it's had time to sit and stew, is that the Enemy Combat AI is about as smart as stupid rocks. In fact, the whole system is buggy and hardly playable. Add that to the fact that actions happen and the only way I have of telling that actions are happening is a displayed numeric code that I only faintly remember. So things get stabbed, attacks get dodged (which still works, so hurray) and enemies get bounced around like short bus occupants on a windy road, and I enjoy the spectacle of it about as much.
So, it's buggy, but it's not broken. That's going to need some serious spit and polish, but that system still needs the rest of the pieces for that polish to mean anything.
Finally, I got a new letter from our good friend, Timmy the Tukwut (or whatever the fuck he is). It went a little like this, seriously.
Hey there little guy!
Remember how before you wanted to come to our school and then we said okay? Then we changed our mind and dropped you? Yeah, that was great! Almost as good as afterwards when we let you apply again, so we could reject you. That was the best joke ever! We love jokes! Do you love jokes too? They are soooo funny.
Anyway, time for jokes is over. We got the new application that you sent in, and we decided that we still would rather have somebody else, especially after that short bus comment you made.
Are your dreams and hopes dashed yet? Mmm, we love your tears as much as we love jokes! Of which this is one!
Yes, that's right! We've decided that your dollars are in fact good enough for us, and would be happy to have you give them to us. Times are tough after all, and Tukwuts (or whatever the fuck I am) have to be sated with a steady diet of freshly clubbed baby seals and True Sadness. Your dollars will be sufficient to buy both.
See you in the Fall!
Love,
Timmy the Tukwut(or whatever the fuck I am)
So, two things there. First of all, I regret nothing about what I just wrote/transcribed. I should, and yet I don't. Second, the "whatever" bit after every time I say Tukwut (you know the rest by now) is something that I will continue doing for as long as I remember to do it, because I find it humorous, in spite/because of the salty language. Although the new mascot is just a Cougar or something, which is somehow lamer. Anyhow, long story short, I'm officially a student again, at least for the time being. I should be in a better mood about it, but really, I just can't anymore. Way too jaded now. I'll try to muster giving a crap.
Tuesday, January 26, 2010
Friday, January 22, 2010
Archaeologist
No real game development news today, but I do have something simmering which may turn out to be downright delicious. Maybe I'll have more about that later. Hopefully.
Instead what I have is something that I promised a long time ago. Now, for your enjoyment you can get the original The Thief's Tale that our plucky little team submitted for the IGF. Playing it is like going into a time machine as that version is missing some of the newer, shinier functions that have been added since. It is however, the most polished version of the game currently available, so what's there is really very playable. Small things that I have grown accustomed to, like the wall hop move and, well, playing with a control pad are missed, but I still find myself enjoying the game as it was, and now maybe you can too.
You can get it both hot and fresh here : http://starfroggames.com/ThiefDownload.html
Which gets me to the title. Both me, and the Team, had to do some searching to find this little nugget of gameplay. You see as the game gets updated, we tend to set aside the previous versions as incomplete, since they are in a sense. My own files become overwritten and in this case, the file structures have changed. So even the original executable did not work anymore, since the lack of certain assets caused an Epic Fail on the compiler's part.
Over the last few days I had my team searching inboxes and recycling bins like digital hobos in the search of the original install file, the executable that would recreate the file structure as it was so the demo can be played by other people too. Finally, I went back to the sandy well that is the Lazarus Drive (click on that for the start of what I refer to as The Necromancer Saga). I ran a new protocol on it that allowed me to map the thrice damned thing, so in the future I may be able to get things out of it just a little quicker than before. What it had though, hidden deep within it's writhing, steaming, TaunTaun-esque guts, was an install file. Or rather, The Install File.
I told it to go ahead and save it and...crash. Alright, again then. Nope? Crashing? Really? Then I said, "Fine then. Run the executable." I had been trying to avoid that, worried that the code had somehow been corrupted like my previous Text files (that's the entry named "Zombie" by the way). I had no idea of what a corrupted installer may be capable of. Maybe like giving your computer an immunization but using a junkie's rusty needle, but by then I was over it, and just went with it.
The installer worked. I'd be lying if I said I wasn't ever so slightly surprised by it, and it brought back to light the original code, with the original art and assets. So I took that file structure, checked every component for cleanliness, and built a new installer for it, which I am happy to share with everybody now.
-Hmm, self referential today. Eh, there was a context.
Instead what I have is something that I promised a long time ago. Now, for your enjoyment you can get the original The Thief's Tale that our plucky little team submitted for the IGF. Playing it is like going into a time machine as that version is missing some of the newer, shinier functions that have been added since. It is however, the most polished version of the game currently available, so what's there is really very playable. Small things that I have grown accustomed to, like the wall hop move and, well, playing with a control pad are missed, but I still find myself enjoying the game as it was, and now maybe you can too.
You can get it both hot and fresh here : http://starfroggames.com/ThiefDownload.html
Which gets me to the title. Both me, and the Team, had to do some searching to find this little nugget of gameplay. You see as the game gets updated, we tend to set aside the previous versions as incomplete, since they are in a sense. My own files become overwritten and in this case, the file structures have changed. So even the original executable did not work anymore, since the lack of certain assets caused an Epic Fail on the compiler's part.
Over the last few days I had my team searching inboxes and recycling bins like digital hobos in the search of the original install file, the executable that would recreate the file structure as it was so the demo can be played by other people too. Finally, I went back to the sandy well that is the Lazarus Drive (click on that for the start of what I refer to as The Necromancer Saga). I ran a new protocol on it that allowed me to map the thrice damned thing, so in the future I may be able to get things out of it just a little quicker than before. What it had though, hidden deep within it's writhing, steaming, TaunTaun-esque guts, was an install file. Or rather, The Install File.
I told it to go ahead and save it and...crash. Alright, again then. Nope? Crashing? Really? Then I said, "Fine then. Run the executable." I had been trying to avoid that, worried that the code had somehow been corrupted like my previous Text files (that's the entry named "Zombie" by the way). I had no idea of what a corrupted installer may be capable of. Maybe like giving your computer an immunization but using a junkie's rusty needle, but by then I was over it, and just went with it.
The installer worked. I'd be lying if I said I wasn't ever so slightly surprised by it, and it brought back to light the original code, with the original art and assets. So I took that file structure, checked every component for cleanliness, and built a new installer for it, which I am happy to share with everybody now.
-Hmm, self referential today. Eh, there was a context.
Friday, January 15, 2010
Control Freak
The controls are more or less all done for The Thief's Tale now. The sticks work and everything is really quite ducky. Other than the combat controls which are a totally different thing altogether. In any event, they work. You can run around using the controller, and the front menu is more of less correct and the buttons are mapped and they all work. I did a run of The Cliff level for giggles and the controls performed admirably, without the slightest hint of lag or other weirdness. It's really the way the game is meant to be played, and it shows.
The Combat Controls (and the functions that feed it) are next up. They're different because they are tied into the enemy AI to some extent. They both need to have a rapport for the combat system to work, variables need to be exchanged like phone numbers and people need to call people, it's all very complicated. Although I do not remember how complicated the inputs are. It may be easy, but I got into something else first which ate the time.
That something else is the Front Menu. I said that it more or less works and that is true, you can navigate the menus, but it's really awkward. The issue is that the sticks have no "off" function. It's not like the keyboard where I can easily ignore a key at any point. So if you push the stick down, the cursor moves at the speed of the menu loop, which is crazy fast since I don't limit it. I'm sure there's some slick way to correct that, but it was pushing 12:30 in the AM and my brain was in the process of shutting down piece by sleepy piece. So that can wait.
This experience has taught me something though. In the future, consolidated controls for everything. Have a single function that takes all input and spits out a wide variety of variables that I can look at. Basically, add a level of abstraction to the system. So say, if the A Button is pressed then change the value of the AButton variable to something. Then, when something wants to know if that button is being pressed, it need only look at the variable instead. That way, if I wanted to make changes, or hell, offer customised control schemes, it wouldn't take me several hours of adding code to every instance of control input in the program.
Oh, and now that it works, yes, it was a Rockstar Moment.
The Combat Controls (and the functions that feed it) are next up. They're different because they are tied into the enemy AI to some extent. They both need to have a rapport for the combat system to work, variables need to be exchanged like phone numbers and people need to call people, it's all very complicated. Although I do not remember how complicated the inputs are. It may be easy, but I got into something else first which ate the time.
That something else is the Front Menu. I said that it more or less works and that is true, you can navigate the menus, but it's really awkward. The issue is that the sticks have no "off" function. It's not like the keyboard where I can easily ignore a key at any point. So if you push the stick down, the cursor moves at the speed of the menu loop, which is crazy fast since I don't limit it. I'm sure there's some slick way to correct that, but it was pushing 12:30 in the AM and my brain was in the process of shutting down piece by sleepy piece. So that can wait.
This experience has taught me something though. In the future, consolidated controls for everything. Have a single function that takes all input and spits out a wide variety of variables that I can look at. Basically, add a level of abstraction to the system. So say, if the A Button is pressed then change the value of the AButton variable to something. Then, when something wants to know if that button is being pressed, it need only look at the variable instead. That way, if I wanted to make changes, or hell, offer customised control schemes, it wouldn't take me several hours of adding code to every instance of control input in the program.
Oh, and now that it works, yes, it was a Rockstar Moment.
Tuesday, January 12, 2010
(Get)ting a Clue
I'll get right into the titles today. I tend to ramble about before finally getting to the point, and not so today. Well, maybe a little. You see, I can, and do, write about everything involved in my game projects be they good, bad, or incredibly stupid. It allows me to comment on them in my own odd way, say by including an Oxford Comma in that last sentence.
But there I go again, going on about nothing. Let's start this over again, but not really, because I hate the delete key.
Yesterday, I learned how the Get function works in C#. In and of itself, that's cute. The Get function can pull individual variables or structures right out of Class Instances. So I can see what direction an object is going, or like I did yesterday, figure out which way it is facing. This is part of me wanting to create functions that will allow me to create bullets of all sizes, shapes and colors. Collision is easy after I can make the damned things. Same is true for enemies and other, well, objects.
But, that's not the thing I feel kind of dumb about. That actually makes me feel all smart, since I deduced how it works. The problem was that I had to deduce how it works. Online tutorials don't really go into it, they just say that it helps to create a Return Function, and are otherwise silent.
A Return Function does exactly what I explained above, it fetches a variable from somewhere. It turns out that it's one of the most basic tools available. It's in the same category as an "if" statement. So if you don't understand it, the logic goes, why did somebody let you have a computer in the first place? Silly noob.
But those are lamentations for another day really. I'm over it...now. I can move forward. The other thing that I worked out, is basic structure of C# code. First though, I need to explain basic code structure for Blitz Basic. As a basic language, it doesn't instance things and everything is super modular. Everything lives on the same page and functions can be called easily. Variables can be 'Global' which means that they are the same thing everywhere. That's why I never bothered to figure out a return function. Instead my functions altered those same Global Variables. It was a Monolithic Structure, everything was tied into the central whole. That's the biggest reason it was such a Caligula-esque orgy to confine that structure inside of a menu wrapper.
In contrast, C# is built using Classes, which are almost like tiny sub-programs. In the code, you can create instances of those Classes, like making a little autonomous robot that follows the code it has. These robots don't really give too much of a damn about the rest of the code, so focused are they on their own crap. Also, those instances all have their own little variables and their own little stuff. There isn't a 'Global' variables in C# to the best of my knowledge. Which is why a Return Function is suddenly so important.
Consequently, the code isn't structured like it is in Blitz. In previous experiments I'd tried to organize things by chains. So there is a Sprite Class, and a Player Sprite Class and I thought that I would add a Bullet Class to the Player Sprite Class. The logic went that the origin of the thing should also be the code that is responsible for its creation.
Turns out that's about as wrong as it could be. The better way to do it, is to tie all Vishnu style creation, Shiva themed destruction and Brahma based updates into a single Monotheic Class. I called this Class the Sprite Manager. It's the happy little tree at the center of the code that I can hang little ornaments on.
So now, all of my Sprites are sub-classes of the Arch Sprite Class, which controls adorable shit like making them display and animate correctly (no need to have each type of sprite have distinct drawing code, that's just asinine). Specific logic is done for an object is done by that object's Class Code. So the enemy sprites have their own instructions in their own code that is unique to them. When they interact with things, they will do a Return Function and send some info back to the Sprite Manager. It sounds kind of complicated when I say it like that, but it's really starting to gel now. I was actually able to add functionality without causing a compiler error or an odd access violation. I should be able to have something to show for all of this soon.
- In not programming news, I'm also hip deep into Assassin's Creed 2. As somebody that really rather loved the first one, the second is like the first, but better in every possible way. Well, the controls are the same except I have the Metal Gear Solid 2 problem of having way too many weapons that I have to bother with. Oh, and I can play dress up with my character, which I find I enjoy more than I should.
My options, post XBox surgery, were it or ODST. I think I chose wisely. Although everybody speaks in bloody Italian. Nice, but I own a standard definition TV, so the little subtitles are incredibly little. Borderline unreadable really. Instead I get to pick up the Italian via exposure and context. Which is, how do you say, no bene. So I miss every third word, but I get to take out my fury on an unsuspecting guard population with two (2!) wrist daggers. So I guess what I'm saying is, in addition to C#, I'm also learning how to speak Italian.
But there I go again, going on about nothing. Let's start this over again, but not really, because I hate the delete key.
Yesterday, I learned how the Get function works in C#. In and of itself, that's cute. The Get function can pull individual variables or structures right out of Class Instances. So I can see what direction an object is going, or like I did yesterday, figure out which way it is facing. This is part of me wanting to create functions that will allow me to create bullets of all sizes, shapes and colors. Collision is easy after I can make the damned things. Same is true for enemies and other, well, objects.
But, that's not the thing I feel kind of dumb about. That actually makes me feel all smart, since I deduced how it works. The problem was that I had to deduce how it works. Online tutorials don't really go into it, they just say that it helps to create a Return Function, and are otherwise silent.
A Return Function does exactly what I explained above, it fetches a variable from somewhere. It turns out that it's one of the most basic tools available. It's in the same category as an "if" statement. So if you don't understand it, the logic goes, why did somebody let you have a computer in the first place? Silly noob.
But those are lamentations for another day really. I'm over it...now. I can move forward. The other thing that I worked out, is basic structure of C# code. First though, I need to explain basic code structure for Blitz Basic. As a basic language, it doesn't instance things and everything is super modular. Everything lives on the same page and functions can be called easily. Variables can be 'Global' which means that they are the same thing everywhere. That's why I never bothered to figure out a return function. Instead my functions altered those same Global Variables. It was a Monolithic Structure, everything was tied into the central whole. That's the biggest reason it was such a Caligula-esque orgy to confine that structure inside of a menu wrapper.
In contrast, C# is built using Classes, which are almost like tiny sub-programs. In the code, you can create instances of those Classes, like making a little autonomous robot that follows the code it has. These robots don't really give too much of a damn about the rest of the code, so focused are they on their own crap. Also, those instances all have their own little variables and their own little stuff. There isn't a 'Global' variables in C# to the best of my knowledge. Which is why a Return Function is suddenly so important.
Consequently, the code isn't structured like it is in Blitz. In previous experiments I'd tried to organize things by chains. So there is a Sprite Class, and a Player Sprite Class and I thought that I would add a Bullet Class to the Player Sprite Class. The logic went that the origin of the thing should also be the code that is responsible for its creation.
Turns out that's about as wrong as it could be. The better way to do it, is to tie all Vishnu style creation, Shiva themed destruction and Brahma based updates into a single Monotheic Class. I called this Class the Sprite Manager. It's the happy little tree at the center of the code that I can hang little ornaments on.
So now, all of my Sprites are sub-classes of the Arch Sprite Class, which controls adorable shit like making them display and animate correctly (no need to have each type of sprite have distinct drawing code, that's just asinine). Specific logic is done for an object is done by that object's Class Code. So the enemy sprites have their own instructions in their own code that is unique to them. When they interact with things, they will do a Return Function and send some info back to the Sprite Manager. It sounds kind of complicated when I say it like that, but it's really starting to gel now. I was actually able to add functionality without causing a compiler error or an odd access violation. I should be able to have something to show for all of this soon.
- In not programming news, I'm also hip deep into Assassin's Creed 2. As somebody that really rather loved the first one, the second is like the first, but better in every possible way. Well, the controls are the same except I have the Metal Gear Solid 2 problem of having way too many weapons that I have to bother with. Oh, and I can play dress up with my character, which I find I enjoy more than I should.
My options, post XBox surgery, were it or ODST. I think I chose wisely. Although everybody speaks in bloody Italian. Nice, but I own a standard definition TV, so the little subtitles are incredibly little. Borderline unreadable really. Instead I get to pick up the Italian via exposure and context. Which is, how do you say, no bene. So I miss every third word, but I get to take out my fury on an unsuspecting guard population with two (2!) wrist daggers. So I guess what I'm saying is, in addition to C#, I'm also learning how to speak Italian.
Thursday, January 7, 2010
Paper Zeppelin
I've been making some really excellent process on the finer points of C# and Object Oriented Programming in general. My previous work in Blitz Basic, while admittedly different is very similar on a basic level. Game Loops work the same, code logic works the same and input has almost the same code but with brackets. So the Trial by Combat that the development of The Thief's Tale was has left me in a position where I am way ahead of the game from a large scale structure standpoint. Oh, and basic AI is just that after making little dudes that can duel.
What I have needed, especially for C# to make a whole lot of sense, is a couple of paradigm shifts. The first of which is the idea that I can tell the code to make me something, but I don't have to give it an explicit name. It's part of that sweet "instancing" that I referred to in a previous post, but whereas before it was all theory, now it's been applied on a code level. So I can say, "make me a bullet and put it here, going in this direction," and the computer just will.
But that's not the thing that has me excited. The really exciting thing, are Lists. Re-reading that last sentence it makes exactly no sense. Basically, a List is a kind of Structure. I'll back up further. A Structure is almost like a kind of advanced variable. Instead of keeping a single value (like we learned in school : x = 1) a Structure can hold any number of things.
The Vector2 command is a Structure, it holds the values for 2 different Vectors, an X and a Y. The Vector3 command is also a Structure that holds X, Y and Z for some 3D gaming goodness.
So a List is another kind, but it holds data about instances. So when I make a new object, it goes like this, more or less:
Update Goodie.List ( add new Thingy(with these delicious values);
This would, if the code worked, go to the Goodie List and add a new Thingy to it. That Thingy would then have the values that I tell it that it should have, probably position and speed and things like that, but really anything can be dumped in there in a non-gaming situation.
The reason that this kept me up all night with sleepless, almost pre-Xmas Joy was that it also allows me to keep track of what I want. Previously, I was thinking that I could sort the objects that I've made. Resigning myself to not having explicit names to call instances I made, I thought that I could add code to each kind of object so that it would sort itself. So see where on the screen it was, and what it was doing. Basically, it would add a Standard Metric Shitload (which is different than an Imperial Shitload - which is used in the UK) of code and logic to everything. Everything.
However, with a List, I can do all the logic for all the instances that I want to via Loop. I can say, "Hey you, with the List. Find the first thing on it and run the Update Function/Method it has. When you're done, do all the rest of them too. Then draw stuff."
With this, it's the last piece of the Object Oriented Puzzle that I was missing. This basic thing, this simple thing has crystallized everything about the language for me and has shown me what I can do with it. More specifically, it's shown me how I can make pretty much everything on the EP in what should border on a recklessly short time. Now my armies can be Legion and march to the far flung ends of the screen, and I don't even have to know their names.
Which brings me to the title. With The Thief's Tale I started by making it as a way to learn and it grew. I started out as a way to apply newly gained knowledge, which explains the crazy feature creep. But, it started off with no real direction or purpose, it grew organically from the humblest of beginnings to what it is now - a way to showcase the raw talent of the people involved so they can all get paying jobs in the future.
The next thing, as per my last post, is going to be different. It's designed from the get go to be on XBLI, and be able to buy me Hot Pockets and contribute to rent. Further, it's going to be something where I will be responsible for everything. I don't want payments and monies involved in my little endeavor at this point, too fragile is the thing. Yet, I still need a testbed for the application of new stuff. So I need a staggeringly limited scope that's fun on a basic level. So nothing on the EP can be on the docket, since all of them utilize some kind of Time Manipulation for gameplay. Instead, I needs a heavily instanced thing. So a platformer is right out. I can't do that sheer amount of art myself. Shooter is the way to go. It'll also allow me to build Classes that I should be able to re-use later with minimal effort. A Bullet AI is pretty much the same everywhere. Oh, and I wants multiplayer. Probably just 2 player though, since the addition of more adds exponentially to the complexity of AI routines.
A basic(ish) design then. I was doing some reading and I'm currently enamoured with Blimps and Zeppelins, mostly because they are awesome. Also, I had a dream. It was one of those odd dreams where you're half remembering something. In it, I was playing a game from my time in Japan when I was 8 or 9 or so. In it, you flew a Bi-Plane and avoided enemies, picked up a bomb and dropped it on an enemy base for points. I remember the most basic of elements and how it looked. Which is pretty much what I started Thief with, the basic idea of The Prince of Persia. Of course now, it's nothing like it. But it's a good place to start.
So I need to build classes for player Zeppelins and controls, bullets, enemy planes, enemy turrets, enemy cannons, enemy shells, enemy bases and the bombs themselves. Comparatively, the Big List for this game is downright tiny sitting next to the one for TTT. Also, more importantly, extremely do-able. Hopefully fast too.
Speaking of fast, the "Paper" part. I'm finding myself being a big, huge whore for new visually exciting things. TTT is inside a bloody book with turning pages for example. Yet, I also need to create visual assets without the aid of a dedicated artist (see the the tenth paragraph). My other projects are going to use ASCII, minimalist crystal look and Vector art (the tentative art styles of EP tracks 1,2 and 3) all of which are either code based or PhotoShop doable. For this, I want something different to the point of being almost silly. So, I'm going to use photographs and paper cutouts. Give the whole thing a mixed media look, like a diorama. Construction paper enemies, cotton ball smoke, drawn with markers details. All things that I can do since, as a shooter, Paper Zeppelin will have about zero traditionally animated things in it. Further, I can photograph and PhotoShop all of those elements together to create my assets.
Of course, I may change my mind between now, and the end of this sentence.
What I have needed, especially for C# to make a whole lot of sense, is a couple of paradigm shifts. The first of which is the idea that I can tell the code to make me something, but I don't have to give it an explicit name. It's part of that sweet "instancing" that I referred to in a previous post, but whereas before it was all theory, now it's been applied on a code level. So I can say, "make me a bullet and put it here, going in this direction," and the computer just will.
But that's not the thing that has me excited. The really exciting thing, are Lists. Re-reading that last sentence it makes exactly no sense. Basically, a List is a kind of Structure. I'll back up further. A Structure is almost like a kind of advanced variable. Instead of keeping a single value (like we learned in school : x = 1) a Structure can hold any number of things.
The Vector2 command is a Structure, it holds the values for 2 different Vectors, an X and a Y. The Vector3 command is also a Structure that holds X, Y and Z for some 3D gaming goodness.
So a List is another kind, but it holds data about instances. So when I make a new object, it goes like this, more or less:
Update Goodie.List ( add new Thingy(with these delicious values);
This would, if the code worked, go to the Goodie List and add a new Thingy to it. That Thingy would then have the values that I tell it that it should have, probably position and speed and things like that, but really anything can be dumped in there in a non-gaming situation.
The reason that this kept me up all night with sleepless, almost pre-Xmas Joy was that it also allows me to keep track of what I want. Previously, I was thinking that I could sort the objects that I've made. Resigning myself to not having explicit names to call instances I made, I thought that I could add code to each kind of object so that it would sort itself. So see where on the screen it was, and what it was doing. Basically, it would add a Standard Metric Shitload (which is different than an Imperial Shitload - which is used in the UK) of code and logic to everything. Everything.
However, with a List, I can do all the logic for all the instances that I want to via Loop. I can say, "Hey you, with the List. Find the first thing on it and run the Update Function/Method it has. When you're done, do all the rest of them too. Then draw stuff."
With this, it's the last piece of the Object Oriented Puzzle that I was missing. This basic thing, this simple thing has crystallized everything about the language for me and has shown me what I can do with it. More specifically, it's shown me how I can make pretty much everything on the EP in what should border on a recklessly short time. Now my armies can be Legion and march to the far flung ends of the screen, and I don't even have to know their names.
Which brings me to the title. With The Thief's Tale I started by making it as a way to learn and it grew. I started out as a way to apply newly gained knowledge, which explains the crazy feature creep. But, it started off with no real direction or purpose, it grew organically from the humblest of beginnings to what it is now - a way to showcase the raw talent of the people involved so they can all get paying jobs in the future.
The next thing, as per my last post, is going to be different. It's designed from the get go to be on XBLI, and be able to buy me Hot Pockets and contribute to rent. Further, it's going to be something where I will be responsible for everything. I don't want payments and monies involved in my little endeavor at this point, too fragile is the thing. Yet, I still need a testbed for the application of new stuff. So I need a staggeringly limited scope that's fun on a basic level. So nothing on the EP can be on the docket, since all of them utilize some kind of Time Manipulation for gameplay. Instead, I needs a heavily instanced thing. So a platformer is right out. I can't do that sheer amount of art myself. Shooter is the way to go. It'll also allow me to build Classes that I should be able to re-use later with minimal effort. A Bullet AI is pretty much the same everywhere. Oh, and I wants multiplayer. Probably just 2 player though, since the addition of more adds exponentially to the complexity of AI routines.
A basic(ish) design then. I was doing some reading and I'm currently enamoured with Blimps and Zeppelins, mostly because they are awesome. Also, I had a dream. It was one of those odd dreams where you're half remembering something. In it, I was playing a game from my time in Japan when I was 8 or 9 or so. In it, you flew a Bi-Plane and avoided enemies, picked up a bomb and dropped it on an enemy base for points. I remember the most basic of elements and how it looked. Which is pretty much what I started Thief with, the basic idea of The Prince of Persia. Of course now, it's nothing like it. But it's a good place to start.
So I need to build classes for player Zeppelins and controls, bullets, enemy planes, enemy turrets, enemy cannons, enemy shells, enemy bases and the bombs themselves. Comparatively, the Big List for this game is downright tiny sitting next to the one for TTT. Also, more importantly, extremely do-able. Hopefully fast too.
Speaking of fast, the "Paper" part. I'm finding myself being a big, huge whore for new visually exciting things. TTT is inside a bloody book with turning pages for example. Yet, I also need to create visual assets without the aid of a dedicated artist (see the the tenth paragraph). My other projects are going to use ASCII, minimalist crystal look and Vector art (the tentative art styles of EP tracks 1,2 and 3) all of which are either code based or PhotoShop doable. For this, I want something different to the point of being almost silly. So, I'm going to use photographs and paper cutouts. Give the whole thing a mixed media look, like a diorama. Construction paper enemies, cotton ball smoke, drawn with markers details. All things that I can do since, as a shooter, Paper Zeppelin will have about zero traditionally animated things in it. Further, I can photograph and PhotoShop all of those elements together to create my assets.
Of course, I may change my mind between now, and the end of this sentence.
Subscribe to:
Posts (Atom)