First things first (as opposed to second), I've finished the design of the new combat system. The last issues were : Getting the "Staggered" enemy state to work correctly and how an enemy's attacks would be created. So here's what I got.
The Staggered Enemy state can happen after a new Thief attack - the Charge Attack. Just like it sounds, you hold the button, the character goes into a charging looking stance (for high or low) and attacks on release. If said attack hits, then the enemy gets staggered, allowing for free hits until they fall down. If they are already staggered, the Charging Hit will look different and deal extra damage - very similar to how the enemies will attack The Thief if he is dizzy. If The Thief is hit, or he releases his attack after the enemy has begun theirs, the Charge will not hit. So it's a high risk, high reward kind of mechanic.
Speaking of falling down, if the enemy receives a number of quick hits (based on their type) they will be knocked down. When they get up, they will be temporarily invincible. The trick is that their invincible state will last long enough for them to launch an attack if the player is close enough. This will encourage players to not rush.
Right then, the other bit is how the enemy attacks would work. The new concept deals with shorter strings, but more advanced AI. So having a 9 hit string isn't really feasible. 4 will probably be the upper limit for attack strings. I considered having them be purely randomized like in the original system, but now I think that giving each enemy a set of Strings will work better. This will allow me to speed up the combat since the player can learn to anticipate certain behaviors. I can also have canned combo animations. The colors, will still be used though. I do not want the player to learn by memorization and the colors give the player a chance to use their reflexes to stay safe.
The strings will be designed to be used up close. Close being a relative term. The current AI distancing system works quite well and the new AI will have a modified version of that. Different length weapons works even better in a more mobile combat system. Anyway, the enemy AI will be set up to have 2 movement attacks - like a lunge, run in or jumping attack to get up close. Then chain into the strings.
So, the enemies need attack sequences and animations, and they're all different and have different values and numbers and blah. This sounds tricky. This sounds hard, this sounds...just like the Object system that I built. My Kung Fu is Strong. I'll set up some arrays and get it dancing, probably this weekend.
- Right, the second bit of the title. I turned in my final graduation paperwork today. It'll be official shortly. I've found that since I took so many classes in so many different subjects I've fulfilled requirements for 3 different kinds of recognition. I've an AA, my Game Art Certificate and a CSU Transfer Certificate. In effect, I've got 4 years worth of schooling already. Now with that and my CSU Acceptance (hopefuly) I should be able to get the career that I want. Either way, it's taken me forever, but now, on the other side of it and looking back, I'm glad I did it, and would do it all over again. Probably not the same way, but I think the process and the effort and the kinds of small benefits that I gained (like being able to fashion prose at the level that I do) well worth it.
Looking in the other direction, I'm not out of the river yet. But now, I know I'm at least past the middle. Going forward will be much easier than going back.
Friday, February 27, 2009
Thursday, February 26, 2009
Vertical Epic Slice
On publishing - I'm thinking that I need a demo, and if that demo falls down, I need to be able to throw out another pitch. So I need 2 games, possibly more. At least, that's what a screenwriter does, and that's the best and most useful information I've got in terms of trying to convince somebody that you're as good as you think you are. In any event, I do need a demo. The industry parlance refers to this as a "Vertical Slice" or "Razor Slice" depending on who you ask. In effect, you need 10-15 minutes of the game finished and working, and here's the important bit, as it will be when it is finished. So a tech demo isn't it. I suppose you could get green-lit (I think that's the term - again screenwriting concepts) with a tech demo, but that seems less likely to happen today given the number of prebuilt engine "solutions" in play.
Right then, it seems that the team is well on our way to that just as we're scheduled. The first level art is coming along (I think) and the animations are popping along. The thing is, there are a lot of things that are end of development cycle stuff that we'd have to get done now for a vertical slice to work. The cinematics come to mind as do background animations and all of that. So, actually creating said slice may be quite a bit of work that would have to be done out of order which increases our chances of throwing something out later. I'll see what the team thinks the next time we meet.
What I can do, is come up with some of those B options. Or rather, put to paper some of the ideas that are floating for codenames Knight and Physics Block MetroidVania. "What's that? Thief doesn't fit with your current publishing portfolio? We'll how about these equally awesome ideas? Now in Design Doc form with art."
-Speaking of brain work, I've been busy mulling the combat system. Not to sound like a pretentious douche, but it's part of my "Process." I start with a goal, and let the idea just gestate for a while and periodically come back to it and talk myself through it. I find the car is a good place for this since I'm being stimulated and if people see me talking to myself they just assume I'm talking on a cell phone they can't see. As a side effect, I've come up with:
-Enemy reactions to the environment, including collision. This also includes the ability for enemies to jump, chase, fall down/ off of things to be defeated and at least in one occasion - wall run. This is going in and now The Princess with be that much scarier to fight.
-Multiple Enemy AI system. Basically, by abstracting the code for the AI and using "states" like The Thief has, the enemies and their information can be saved into an array (oh how I do love those). Then the array can be poured into the AI functions like Pachinko balls, and voila - multiple enemies. Of course, I still only want 1 enemy per screen in Thief. It's a design decision. The other ideas, they'll use this. Knight will extensively.
Right then. So the new combat system is rolling along. The biggest issue I'm having was trying to consider "Priority." In that, if somebody attacks, and somebody else attacks in response, what happens? For example, I considered having the attacks cancel each other out, but that would lead to the attack being used as a defensive mechanic, and I don't want that. Same with a kind of "Clash" where buttons would have to be mashed. The solution that I'll prototype is that the first attack, wins by default. So whoever threw first will knock the other out of their attack.
To counter the natural want to rush down the enemies and button mash, I'm adding the following:
- High/Low Blocks for enemies that stun The Thief out of his attacks if he throws the matching attack.
-High/Low attacks of The Thief - see above.
-Invincible State for enemies after they get knocked down. Possibly following a series of blows. I'm still polishing the concept in my brain.
-Staggered State for enemies after they get hit. Variations dependent on the kind of enemies.(maybe - see below)
-Defensive moves for enemies based on a random modifier. So if you hit them, they may jump back, pull a block, change their block or throw a counter. So even when you're wailing on the enemies, you still have to pay attention.
-Special moves both offensive and defensive based on the enemy type. So Knights will have huge shields you can't attack from the front, the Skeletons will be able to frighten The Thief and stun him, The General may have a super powerful jumping attack and The Princess may have an acrobatic unblockable and an Auto-Counter.
Add to this the extra movement abilities of the enemy AI, and the combat becomes a little more tricky, and certainly more interesting.
- I'm also going back to school. I needs loans and I needs grants. I could go without these, but I would rather my life not suck. The battle of my Pride versus my Pragmatism has come out differently than it usually does. Either way, using some of that grant and loan money to pay my bills would be sweet. I'm also considering applying for a campus job. Then I'd be able to work a funny schedule and still go to on hour classes. Of course, my concepts of what said jobs pay may be a little optimistic. At the least I expect that a college student would be able to live off said monies.
Right then, it seems that the team is well on our way to that just as we're scheduled. The first level art is coming along (I think) and the animations are popping along. The thing is, there are a lot of things that are end of development cycle stuff that we'd have to get done now for a vertical slice to work. The cinematics come to mind as do background animations and all of that. So, actually creating said slice may be quite a bit of work that would have to be done out of order which increases our chances of throwing something out later. I'll see what the team thinks the next time we meet.
What I can do, is come up with some of those B options. Or rather, put to paper some of the ideas that are floating for codenames Knight and Physics Block MetroidVania. "What's that? Thief doesn't fit with your current publishing portfolio? We'll how about these equally awesome ideas? Now in Design Doc form with art."
-Speaking of brain work, I've been busy mulling the combat system. Not to sound like a pretentious douche, but it's part of my "Process." I start with a goal, and let the idea just gestate for a while and periodically come back to it and talk myself through it. I find the car is a good place for this since I'm being stimulated and if people see me talking to myself they just assume I'm talking on a cell phone they can't see. As a side effect, I've come up with:
-Enemy reactions to the environment, including collision. This also includes the ability for enemies to jump, chase, fall down/ off of things to be defeated and at least in one occasion - wall run. This is going in and now The Princess with be that much scarier to fight.
-Multiple Enemy AI system. Basically, by abstracting the code for the AI and using "states" like The Thief has, the enemies and their information can be saved into an array (oh how I do love those). Then the array can be poured into the AI functions like Pachinko balls, and voila - multiple enemies. Of course, I still only want 1 enemy per screen in Thief. It's a design decision. The other ideas, they'll use this. Knight will extensively.
Right then. So the new combat system is rolling along. The biggest issue I'm having was trying to consider "Priority." In that, if somebody attacks, and somebody else attacks in response, what happens? For example, I considered having the attacks cancel each other out, but that would lead to the attack being used as a defensive mechanic, and I don't want that. Same with a kind of "Clash" where buttons would have to be mashed. The solution that I'll prototype is that the first attack, wins by default. So whoever threw first will knock the other out of their attack.
To counter the natural want to rush down the enemies and button mash, I'm adding the following:
- High/Low Blocks for enemies that stun The Thief out of his attacks if he throws the matching attack.
-High/Low attacks of The Thief - see above.
-Invincible State for enemies after they get knocked down. Possibly following a series of blows. I'm still polishing the concept in my brain.
-Staggered State for enemies after they get hit. Variations dependent on the kind of enemies.(maybe - see below)
-Defensive moves for enemies based on a random modifier. So if you hit them, they may jump back, pull a block, change their block or throw a counter. So even when you're wailing on the enemies, you still have to pay attention.
-Special moves both offensive and defensive based on the enemy type. So Knights will have huge shields you can't attack from the front, the Skeletons will be able to frighten The Thief and stun him, The General may have a super powerful jumping attack and The Princess may have an acrobatic unblockable and an Auto-Counter.
Add to this the extra movement abilities of the enemy AI, and the combat becomes a little more tricky, and certainly more interesting.
- I'm also going back to school. I needs loans and I needs grants. I could go without these, but I would rather my life not suck. The battle of my Pride versus my Pragmatism has come out differently than it usually does. Either way, using some of that grant and loan money to pay my bills would be sweet. I'm also considering applying for a campus job. Then I'd be able to work a funny schedule and still go to on hour classes. Of course, my concepts of what said jobs pay may be a little optimistic. At the least I expect that a college student would be able to live off said monies.
Monday, February 23, 2009
iCoup
Had my meeting on Friday with the team. All was well, more or less. Then they wanted to talk to me about the combat system. The general agreement was that it isn't very good and the basic blocking mechanics are lacking and too defensive in nature. After doing my best to not take it all personally, we set out to try to figure out what kinds of things we could do. They varied in scope from adding more attacks, adding more enemies and making the Thief character do more stuff.
So, taking notes and suggestions is something a designer does. The real trick is then condensing it all down and creating a workable, enjoyable system out of the parts.
The basic concept that I'm taking as the basis for the new combat is mobility. The Thief and the enemies need to move. Not just up to each other, but while they are fighting. I want the enemies to move backwards, jump in and be able to block when the player attacks them. Further, I'll still get enemies to attack in chains based on how good they are.
To make up for that, the player needs to move and be forced to. Since I feel the high/low blocking system still works on a fundamental level, I'm keeping that, but I'm pulling that mechanic out of the front. Now, it's just how the blocking system works in a more robust combat system. To match that, the player is going to get to attack more frequently at their own discretion, with a high/low attack based on what the enemy is doing.
Finally, I'm adding an uncommon 3rd kind of attack - an attack you have to Dash Dodge to avoid. The Dash Dodge is a feature that nobody but me uses. Since I already tried mixing a 3rd attack and found the results sub-par, I think this attack can be used if it is really slow and has a crazy tell on the front. Then, stop the attack sequence if the player dodges correctly and give a huge payoff for doing it.
Plus, I still like the Dizzy hit move. I will continue to like it until the prototype proves otherwise.
I think with these, I'm going to use the word "changes" the combat will be way opened up. It may be a little less skill based, but I think it could be a lot more fun and looser.
-Speaking of things the team brought up, I think we may be making an iPhone game next. I don't know why, but at least one member of the team thinks it's a good idea. The issue I'm having is that I've never thought about making an iPhone game before and what kind of features it brings to the table from a design standpoint. I've always considered the Jesus Phone to be just that - a phone. Given enough minutes to think about it, I think I can think of something. Or we'll do the Knight project.
So, taking notes and suggestions is something a designer does. The real trick is then condensing it all down and creating a workable, enjoyable system out of the parts.
The basic concept that I'm taking as the basis for the new combat is mobility. The Thief and the enemies need to move. Not just up to each other, but while they are fighting. I want the enemies to move backwards, jump in and be able to block when the player attacks them. Further, I'll still get enemies to attack in chains based on how good they are.
To make up for that, the player needs to move and be forced to. Since I feel the high/low blocking system still works on a fundamental level, I'm keeping that, but I'm pulling that mechanic out of the front. Now, it's just how the blocking system works in a more robust combat system. To match that, the player is going to get to attack more frequently at their own discretion, with a high/low attack based on what the enemy is doing.
Finally, I'm adding an uncommon 3rd kind of attack - an attack you have to Dash Dodge to avoid. The Dash Dodge is a feature that nobody but me uses. Since I already tried mixing a 3rd attack and found the results sub-par, I think this attack can be used if it is really slow and has a crazy tell on the front. Then, stop the attack sequence if the player dodges correctly and give a huge payoff for doing it.
Plus, I still like the Dizzy hit move. I will continue to like it until the prototype proves otherwise.
I think with these, I'm going to use the word "changes" the combat will be way opened up. It may be a little less skill based, but I think it could be a lot more fun and looser.
-Speaking of things the team brought up, I think we may be making an iPhone game next. I don't know why, but at least one member of the team thinks it's a good idea. The issue I'm having is that I've never thought about making an iPhone game before and what kind of features it brings to the table from a design standpoint. I've always considered the Jesus Phone to be just that - a phone. Given enough minutes to think about it, I think I can think of something. Or we'll do the Knight project.
Friday, February 20, 2009
...loading title...
I so like it when something finally works the way it is supposed to. The Object Loading system is all done now, TheifEd saves it, the Engine loads it and it works when the game is running without the faintest hint of slowdown or irony. I'll toss up some before and after pictures and we can all be impressed by (and by "all" I mean both of you that read this). That's really great. The only thing that doesn't work yet is the background parallax effect, only because the backgrounds don't have any yet to test. But since they work just like the foreground effects but in the back and the code is already written, it's no big deal. I can move along to more and different.
Of particular note is that I made my code pretty again. I previously um, bitched, about how I couldn't reference an array "Off Page." Well, I still can't. But my then solution was to add all of the bloated saving/loading code (of which there are about 500 lines) to both the engine and ThiefEd. This made me a very unhappy panda. But it worked.
I found a hack though that made me yell some very choice words at the code, mostly about my greatness and sexual prowess. Think of the words you'd use when you beat a very hard boss, like those, but really really vulgar. I'd found that although I can't reference the array off page, I can reference a function that has the array in it on an off page.
I'll explain. There is some code that loads up the objects. This was included in the Load Code (say that 5 times fast) and the Saving Code. Since that code has to be on the main page, I went ahead and had all of the loading coding on the same page too. Well, I found that if I make just the Object Loading its own function, I can put all of the loading stuff back in its own area and add the Object Loading function to it. Since the tiny Object Loading Function is on the Main Page, it works and I don't have 500+ lines of bloated loading/saving code in my main source code. So when that worked, four letter words ensued.
Next up on the dock it to finish out the prototype for the Major/Minor sound code for combat, then I can move along to the other prototypes that need doing. I'm thinking that my idea for an enhanced throw won't add much. I did some thinking about it with my XBox controller, and the side to side motion doesn't seem to add anything, unlike the key mashing for the combat dizziness. Right now, I'm trying to figure out what other input I can use that is both different enough from the main combat to be unique and not totally random. Methinks it may end up being hacked.
-Ah, right. Another person has decided that they want to join Star Frog Games for fortune and/or glory. Well, maybe not fortune. I mean, I'm poor, and I technically own the studio. Either way, I'm happy for the help honestly. I think I mentioned before that I want another Level Designer (so the levels can be huge and awesome and opposed to huge or awesome) and another will allow me to focus on the levels that I've personally constructed and more of the programming work that I find myself doing most of the time.
-Speaking of doing all the programming. I've found that doing all of that affects my design process by adding a 3rd step. 1st - Will this feature be cool? This is the easy one that everybody can do. "You know what would be cool? If Sonic had Guns!" 2nd - Will that feature break the rest of the game or add to the pieces that already exist in a positive way? This is the really hard one. Mostly because games have lots of systems that interact. Dozens, and all of them work with each other. Being able to calculate effect before you make cause is the skill a Game Designer needs as far as I am concerned. Prototyping will also help, but being able to figure out in advance some of the problems that the prototype is likely to run into will make you loved by all of your artists and your programmers. Less thrown out work = better used work.
Right, so usually the first 2 steps are everything you'd need on a day to day basis. The 3rd thing is this : Can I implement the feature? The quick answer is often - no. I then have to cycle through the first 2 steps again. Often I find the implementation isn't worth the effort. Other times, I find that I have to figure it out. No matter what, it always adds a step. I would think that in a professional environment you're dealing with CS Graduate Coders who can do code like Jackie Chan does kung fu - with extreme prejudice. Even still I'm thinking that knowing, at least on some level, how a feature could be installed into the current code would always be a good thing for a designer to know.
-Speaking further about programming, I looked at my code yesterday for the new objects system and it looks, at first glance, like some kind of alien hieroglyphs. Yet, I knew and continue to know what it does and how it works. Even better, I can build another one if I need to. Still not a 9th Dan id Programmer, but I think I've earned my Green Belt.
- Ah, and the internets seemed to be involved in some kind of Warp Storm, so my emails seem to be getting eaten by the dark things from beyond space and sanity. So I'm of the mind of using StarFrogGames.com as the actual official place for this and game development news/rants/thoughts. Then I can have an actual, super pro, email address like Best Designer Evar @ SFG or CID @ SFG. Or not, probably not.
Of particular note is that I made my code pretty again. I previously um, bitched, about how I couldn't reference an array "Off Page." Well, I still can't. But my then solution was to add all of the bloated saving/loading code (of which there are about 500 lines) to both the engine and ThiefEd. This made me a very unhappy panda. But it worked.
I found a hack though that made me yell some very choice words at the code, mostly about my greatness and sexual prowess. Think of the words you'd use when you beat a very hard boss, like those, but really really vulgar. I'd found that although I can't reference the array off page, I can reference a function that has the array in it on an off page.
I'll explain. There is some code that loads up the objects. This was included in the Load Code (say that 5 times fast) and the Saving Code. Since that code has to be on the main page, I went ahead and had all of the loading coding on the same page too. Well, I found that if I make just the Object Loading its own function, I can put all of the loading stuff back in its own area and add the Object Loading function to it. Since the tiny Object Loading Function is on the Main Page, it works and I don't have 500+ lines of bloated loading/saving code in my main source code. So when that worked, four letter words ensued.
Next up on the dock it to finish out the prototype for the Major/Minor sound code for combat, then I can move along to the other prototypes that need doing. I'm thinking that my idea for an enhanced throw won't add much. I did some thinking about it with my XBox controller, and the side to side motion doesn't seem to add anything, unlike the key mashing for the combat dizziness. Right now, I'm trying to figure out what other input I can use that is both different enough from the main combat to be unique and not totally random. Methinks it may end up being hacked.
-Ah, right. Another person has decided that they want to join Star Frog Games for fortune and/or glory. Well, maybe not fortune. I mean, I'm poor, and I technically own the studio. Either way, I'm happy for the help honestly. I think I mentioned before that I want another Level Designer (so the levels can be huge and awesome and opposed to huge or awesome) and another will allow me to focus on the levels that I've personally constructed and more of the programming work that I find myself doing most of the time.
-Speaking of doing all the programming. I've found that doing all of that affects my design process by adding a 3rd step. 1st - Will this feature be cool? This is the easy one that everybody can do. "You know what would be cool? If Sonic had Guns!" 2nd - Will that feature break the rest of the game or add to the pieces that already exist in a positive way? This is the really hard one. Mostly because games have lots of systems that interact. Dozens, and all of them work with each other. Being able to calculate effect before you make cause is the skill a Game Designer needs as far as I am concerned. Prototyping will also help, but being able to figure out in advance some of the problems that the prototype is likely to run into will make you loved by all of your artists and your programmers. Less thrown out work = better used work.
Right, so usually the first 2 steps are everything you'd need on a day to day basis. The 3rd thing is this : Can I implement the feature? The quick answer is often - no. I then have to cycle through the first 2 steps again. Often I find the implementation isn't worth the effort. Other times, I find that I have to figure it out. No matter what, it always adds a step. I would think that in a professional environment you're dealing with CS Graduate Coders who can do code like Jackie Chan does kung fu - with extreme prejudice. Even still I'm thinking that knowing, at least on some level, how a feature could be installed into the current code would always be a good thing for a designer to know.
-Speaking further about programming, I looked at my code yesterday for the new objects system and it looks, at first glance, like some kind of alien hieroglyphs. Yet, I knew and continue to know what it does and how it works. Even better, I can build another one if I need to. Still not a 9th Dan id Programmer, but I think I've earned my Green Belt.
- Ah, and the internets seemed to be involved in some kind of Warp Storm, so my emails seem to be getting eaten by the dark things from beyond space and sanity. So I'm of the mind of using StarFrogGames.com as the actual official place for this and game development news/rants/thoughts. Then I can have an actual, super pro, email address like Best Designer Evar @ SFG or CID @ SFG. Or not, probably not.
Wednesday, February 18, 2009
Crap
I fixed it. The issue from below. I found that I was calling the wrong kind of information. I didn't want to know what specific object I wanted, I really wanted to know what kind of object it was. A subtle difference, but good nonetheless. So, the new object system is all installed and works like a charm. Well, except I can't save anything, not a goddamn thing. I remembered as I was setting up the loop (arrays need loops like fish need water and child stars need therapy) that I can't reference an array "off page." I mean, I can do all kinds of things to it, including and not limited to doing the robot, but I can only do these things when the array is mentioned in the same bit of code. It does not work through an include function at all. I tried that and I get an error. Since my Save Function is included in its own file, I can't mod that to save it. Of course, I could always just move the save function into the main ThiefEd code, but what's the point of using different sub-programs if you have to put everything in the same bloody file. Yeah, Riddle me that Batman.
Right, so now I have a cornucopia of different objects and they all display correctly and all that jazz. I even got my Key to work, up until it all fell apart. Hey, at least it works now.
-Speaking of disappointment, I'm going to share a story about Fable II. Stop reading now if you haven't finished it and care about the ending at all. No? Alright. I played through the game as the lovable rogue the Scarlet Sparrow. The name coming from the color of my coats and the name the game gave me that I was too lazy to change. Anyhow, at the end of the game you get the choice to either A) Bring back the dead people that went out like dufuses building a powerful yet evil artifact. B) Screw those people and bring back loved ones and your rotten mutt. C) Screw everybody and take the gold. I thought to myself, "I'll bring back the wife. That's the heroic thing to do." So I went with option number 2 and credits rolled and I generally felt good about myself. But one line kept bothering me, "He will have to live with his choice." So I ran home to see what the real ending was. I mean, I saved the girl, that's what the hero does right? Right!?
So I get back from my ordeal and run up to see what the wife has to say. She says, "Oh dear, you've been so good to me lately, I got you this gift," and she proceeds to give me some lousy potion. I own most of the known world and bring her back from the dead at the cost of thousands of lives and she gives me a trifle, a rotten bauble. It's like, "I forgot about your birthday, sorry. Here's some pocket lint." I guess I was just hoping for more, some change in the game and the story and yet, there was none. The game disappointed me and that line, that singular, "He will have to live with his choice," haunted me. In desperation I talked to the wife again, same line, different variation, different worthless trinket. The situation revealing how truly lifeless she was. "He will have to live with his choice." So, for the first time in the game, the Scarlet Sparrow did something evil. Finding that being a hero doesn't matter for anything in Albion, he pulled out his trusty Masterwork Clockwork pistol, shot 2 rounds and never looked back.
I've never felt that way about a game before. The game made me feel as if the last 8 hours really didn't matter. What I did and the story that played out really were for nothing. The magic trick that was the game revealed to all really just be smoke and mirrors. After becoming the Hero of Albion, I'd found that I still counted for very little.
I want to say that my expectations are to blame, and that's the rationale that I use when thinking about it. Some changes could have been made at the end somehow to give me something, anything. But thinking about it makes me depressed. The Scarlet Sparrow isn't supposed to come home and find only heartbreak. He's not supposed to find out that his wife doesn't care about him and that the world at large, cares nothing for a middle aged hero in a crimson coat. He's supposed to sail off into the sunset and quote Ulysses, "...for my purpose holds To sail beyond the sunset, and the baths Of all the western stars..." That's an ending.
Right, so now I have a cornucopia of different objects and they all display correctly and all that jazz. I even got my Key to work, up until it all fell apart. Hey, at least it works now.
-Speaking of disappointment, I'm going to share a story about Fable II. Stop reading now if you haven't finished it and care about the ending at all. No? Alright. I played through the game as the lovable rogue the Scarlet Sparrow. The name coming from the color of my coats and the name the game gave me that I was too lazy to change. Anyhow, at the end of the game you get the choice to either A) Bring back the dead people that went out like dufuses building a powerful yet evil artifact. B) Screw those people and bring back loved ones and your rotten mutt. C) Screw everybody and take the gold. I thought to myself, "I'll bring back the wife. That's the heroic thing to do." So I went with option number 2 and credits rolled and I generally felt good about myself. But one line kept bothering me, "He will have to live with his choice." So I ran home to see what the real ending was. I mean, I saved the girl, that's what the hero does right? Right!?
So I get back from my ordeal and run up to see what the wife has to say. She says, "Oh dear, you've been so good to me lately, I got you this gift," and she proceeds to give me some lousy potion. I own most of the known world and bring her back from the dead at the cost of thousands of lives and she gives me a trifle, a rotten bauble. It's like, "I forgot about your birthday, sorry. Here's some pocket lint." I guess I was just hoping for more, some change in the game and the story and yet, there was none. The game disappointed me and that line, that singular, "He will have to live with his choice," haunted me. In desperation I talked to the wife again, same line, different variation, different worthless trinket. The situation revealing how truly lifeless she was. "He will have to live with his choice." So, for the first time in the game, the Scarlet Sparrow did something evil. Finding that being a hero doesn't matter for anything in Albion, he pulled out his trusty Masterwork Clockwork pistol, shot 2 rounds and never looked back.
I've never felt that way about a game before. The game made me feel as if the last 8 hours really didn't matter. What I did and the story that played out really were for nothing. The magic trick that was the game revealed to all really just be smoke and mirrors. After becoming the Hero of Albion, I'd found that I still counted for very little.
I want to say that my expectations are to blame, and that's the rationale that I use when thinking about it. Some changes could have been made at the end somehow to give me something, anything. But thinking about it makes me depressed. The Scarlet Sparrow isn't supposed to come home and find only heartbreak. He's not supposed to find out that his wife doesn't care about him and that the world at large, cares nothing for a middle aged hero in a crimson coat. He's supposed to sail off into the sunset and quote Ulysses, "...for my purpose holds To sail beyond the sunset, and the baths Of all the western stars..." That's an ending.
Double Cross Reference
I've found my problem. The brown snake in my cereal so to speak. The nasty metaphor in my post.
The object animation system works. Heck, I even got the system to allow forwards and rewinding animations to function on some basic level. It works great, for the first 5 objects. Then it just falls down and only plays the first frame of the animation for the rest. First I thought it was a load issue, maybe only the first frame is loaded. Nope not that. Then I thought the system wasn't updating the animation frame like it was supposed to. I went ahead and installed a counter that shows what frame it is on and it turns out, that's not it either. Double dammit. I've found that in coding, like in life, there are 3 kinds of solutions : The ones that can work if everything goes great, the ones that will never work, and the ones you haven't thought of yet. I'm firmly in the land of the 3rd solution here.
I think the issue may be how I'm referencing my animations. I've found that I can nest my calls and cross reference my tables like this:
DrawImage ObPics(Objects(Loop,1), Objects(Loop,4)), Objects(Loop, 2), Objects(Loop,3)
It says "Draw the picture of the object type in the Objects Folder (The ObPics(Objects(Loop,1) command) and draw the frame that has the current animation (the Objects(Loop,4) part) at the Objects(Loop,2)XObjects(Loop,3) position. Um, yeah. In English, it says "Draw the current animation frame of the flavor of object that is listed."
This is what led me to believe that the animation frame wasn't being updated (the Objects(Loop,4) part of the code), but when I told it to draw that it says all is well like I said before. So I'm waiting for inspiration to crash into me like an Extinction Level Comet - laying waste to my problem like a thousand nuclear bombs and billions and billions of tonnes of TNT.
Methinks that I'll go ahead and have it draw, everything, everything! Then I can see if A) My array can handle the amount of data that it's got in it and B) if maybe the display code itself has a weird bug in it. I'm reasonably sure that A) is okay since when it runs it doesn't crash and claim the data isn't there, but B) may be a very real issue.
-Okay then, enough of that. I've also have an idea that may or not work. The basic plan for the scenes in the final game are going to be movies using the character models. This would allow The Animator to show off his impressive skills a little better than just the gameplay animations. Anyhow, I was thinking that the Camera of said movies could be moved around too and get up close to the characters and when they are talking. Know I know that my engine doesn't have a camera, but I also know that Maya does and like many things I can totally fake it. After all, the characters are 3D models anyway.
The issues I see with this are three fold. 1) Depending on the angle, the background may fail. I mean, it is flat. So with the right angle the background will look not as good as it should. Then again, depending on how the thing is shot, this may not be a problem at all.
2) The closeups would require new rigs to be built. Now with fingers, faces and other little pieces. Plus, new character models. I mean, the ones we have are great, but at 1600X1200 and taking up much of the screen, much higher detail would suddenly be needed.
3) ...and all of this keeping in the same style of the game itself. The look we've got is a painted woodcut (at least in theory - I'm getting some more art soon and I'll see what the artists have come up with in the meantime.). So the look of the game suddenly has to also be very scalable.
So other than these, and the giant amount of extra work that this would require, I think that would be awesome and people may call the game 2D/3D, when it's really not.
The object animation system works. Heck, I even got the system to allow forwards and rewinding animations to function on some basic level. It works great, for the first 5 objects. Then it just falls down and only plays the first frame of the animation for the rest. First I thought it was a load issue, maybe only the first frame is loaded. Nope not that. Then I thought the system wasn't updating the animation frame like it was supposed to. I went ahead and installed a counter that shows what frame it is on and it turns out, that's not it either. Double dammit. I've found that in coding, like in life, there are 3 kinds of solutions : The ones that can work if everything goes great, the ones that will never work, and the ones you haven't thought of yet. I'm firmly in the land of the 3rd solution here.
I think the issue may be how I'm referencing my animations. I've found that I can nest my calls and cross reference my tables like this:
DrawImage ObPics(Objects(Loop,1), Objects(Loop,4)), Objects(Loop, 2), Objects(Loop,3)
It says "Draw the picture of the object type in the Objects Folder (The ObPics(Objects(Loop,1) command) and draw the frame that has the current animation (the Objects(Loop,4) part) at the Objects(Loop,2)XObjects(Loop,3) position. Um, yeah. In English, it says "Draw the current animation frame of the flavor of object that is listed."
This is what led me to believe that the animation frame wasn't being updated (the Objects(Loop,4) part of the code), but when I told it to draw that it says all is well like I said before. So I'm waiting for inspiration to crash into me like an Extinction Level Comet - laying waste to my problem like a thousand nuclear bombs and billions and billions of tonnes of TNT.
Methinks that I'll go ahead and have it draw, everything, everything! Then I can see if A) My array can handle the amount of data that it's got in it and B) if maybe the display code itself has a weird bug in it. I'm reasonably sure that A) is okay since when it runs it doesn't crash and claim the data isn't there, but B) may be a very real issue.
-Okay then, enough of that. I've also have an idea that may or not work. The basic plan for the scenes in the final game are going to be movies using the character models. This would allow The Animator to show off his impressive skills a little better than just the gameplay animations. Anyhow, I was thinking that the Camera of said movies could be moved around too and get up close to the characters and when they are talking. Know I know that my engine doesn't have a camera, but I also know that Maya does and like many things I can totally fake it. After all, the characters are 3D models anyway.
The issues I see with this are three fold. 1) Depending on the angle, the background may fail. I mean, it is flat. So with the right angle the background will look not as good as it should. Then again, depending on how the thing is shot, this may not be a problem at all.
2) The closeups would require new rigs to be built. Now with fingers, faces and other little pieces. Plus, new character models. I mean, the ones we have are great, but at 1600X1200 and taking up much of the screen, much higher detail would suddenly be needed.
3) ...and all of this keeping in the same style of the game itself. The look we've got is a painted woodcut (at least in theory - I'm getting some more art soon and I'll see what the artists have come up with in the meantime.). So the look of the game suddenly has to also be very scalable.
So other than these, and the giant amount of extra work that this would require, I think that would be awesome and people may call the game 2D/3D, when it's really not.
Tuesday, February 17, 2009
High Deaf
Yep, totally misspelled that on purpose.
Right then, after yesterday's, let's use the term "Statement of Purpose" I went ahead and started doing my research. What I propose is difficult - almost to the point of being impossible. The key bit being the almost, but certainly possible provided that I'm prepared, have a clear plan and a clear vision of what I want. I can't go in and say, "Here's my game idea, give me monies, hur hur hur," because that will end in tears. Instead saying, "Here's my game in production, here's more concept art of what the rest will look like, here's a playable version so you can see what the gameplay is all about. This works on Live because there are few well crafted, character based, platforming games on the service and the strong performance of Prince of Persia Classic shows that there is a niche awaiting to be filled. Oh, and I can have this ready to publish on Live in 6 months for $60,000." That may work out better. No matter what? Hardly. More like, that's the tact I'll need a dozen times with a dozen publishers in two dozen meetings. Now, I just have to be prepared. Not for camping, but for war.
Right, so I've been planning the offensive, picking out targets, and when I'm ready with a plan, mobilization of the troops. So, yeah, Google Surfing looking for publishers in San Diego and Los Angeles, but it sounded better in the previous sentence and spread my metaphor a little longer. But no matter. I've found a half dozen publishers that seems to be just what I'm looking for. Either with a track record of Live publishing, or obviously dealing with small budget developers. So, not EA2KActiRockwayQ (there's 6 in there- Figure them out! It's like a game!). So that's promising, now I need to find out what to do to schedule pitch meetings. Hmmm.
-In other news I think I've figured out a hack for high definition. It's by far the most requested, um, request made by the artists and after seeing what the models (especially the skelington enemies) look like when they're bigger, I'm inclined to at least leave the possibilities open. Anyway, the system is currently set up to have a standard size. The images are all sized for 800X600 and more importantly, the collision and physics engine is set up for that too. So it's not as easy as just changing the resolutions, the whole game would have to be changed to make that work on some level. But here's the hack anyway, if I change the way the system tracks placement, I can make the game do any resolution I damn well want.
Basically, instead of absolute placement, I can use relative placement. Let's use 100 as a base like a percentage (although it wouldn't work for real - it's not granular enough). 0 is the far left, 100 the far right and 50 right in the middle. Anyway, if all the movement was based on a percentage it wouldn't matter. So instead of adding 10 to the character placement every frame when they run (moving them 10 pixels to the right) I could add 2 to the percentage. This would give the same proportional movement no matter what the resolution is.
Current problem is one of data. The levels are all constructed using the current space set as they're template, but I suppose if I start with 800X600 as my base, then I could them as my "percentage." Hmm. Either way, when I meet the artists next I'm going to tell them to make all the art in high res before shrinking it. Then when we do have the ability to change, the art's already done. Besides, on Live, It's going to have to run 1080p anyway.
-Maybe, maybe not after all. After reading through all of that again, maybe I could just display the difference. Like on XBox 360, it draws the whole game out 4X the regular size and shrinks it down, but the engines all run assuming the larger size. Just because my engine runs at 800X600 doesn't mean that I can draw different ratio based on what the engine is doing. I mean, I can run the game at 1600X1200 just by doubling all the coordinates when the screen is drawn. That's easier to implement that my rambing on up above and would work just as well. It seems like most things, I can fake it. That's almost doable tomorrow.
Right then, after yesterday's, let's use the term "Statement of Purpose" I went ahead and started doing my research. What I propose is difficult - almost to the point of being impossible. The key bit being the almost, but certainly possible provided that I'm prepared, have a clear plan and a clear vision of what I want. I can't go in and say, "Here's my game idea, give me monies, hur hur hur," because that will end in tears. Instead saying, "Here's my game in production, here's more concept art of what the rest will look like, here's a playable version so you can see what the gameplay is all about. This works on Live because there are few well crafted, character based, platforming games on the service and the strong performance of Prince of Persia Classic shows that there is a niche awaiting to be filled. Oh, and I can have this ready to publish on Live in 6 months for $60,000." That may work out better. No matter what? Hardly. More like, that's the tact I'll need a dozen times with a dozen publishers in two dozen meetings. Now, I just have to be prepared. Not for camping, but for war.
Right, so I've been planning the offensive, picking out targets, and when I'm ready with a plan, mobilization of the troops. So, yeah, Google Surfing looking for publishers in San Diego and Los Angeles, but it sounded better in the previous sentence and spread my metaphor a little longer. But no matter. I've found a half dozen publishers that seems to be just what I'm looking for. Either with a track record of Live publishing, or obviously dealing with small budget developers. So, not EA2KActiRockwayQ (there's 6 in there- Figure them out! It's like a game!). So that's promising, now I need to find out what to do to schedule pitch meetings. Hmmm.
-In other news I think I've figured out a hack for high definition. It's by far the most requested, um, request made by the artists and after seeing what the models (especially the skelington enemies) look like when they're bigger, I'm inclined to at least leave the possibilities open. Anyway, the system is currently set up to have a standard size. The images are all sized for 800X600 and more importantly, the collision and physics engine is set up for that too. So it's not as easy as just changing the resolutions, the whole game would have to be changed to make that work on some level. But here's the hack anyway, if I change the way the system tracks placement, I can make the game do any resolution I damn well want.
Basically, instead of absolute placement, I can use relative placement. Let's use 100 as a base like a percentage (although it wouldn't work for real - it's not granular enough). 0 is the far left, 100 the far right and 50 right in the middle. Anyway, if all the movement was based on a percentage it wouldn't matter. So instead of adding 10 to the character placement every frame when they run (moving them 10 pixels to the right) I could add 2 to the percentage. This would give the same proportional movement no matter what the resolution is.
Current problem is one of data. The levels are all constructed using the current space set as they're template, but I suppose if I start with 800X600 as my base, then I could them as my "percentage." Hmm. Either way, when I meet the artists next I'm going to tell them to make all the art in high res before shrinking it. Then when we do have the ability to change, the art's already done. Besides, on Live, It's going to have to run 1080p anyway.
-Maybe, maybe not after all. After reading through all of that again, maybe I could just display the difference. Like on XBox 360, it draws the whole game out 4X the regular size and shrinks it down, but the engines all run assuming the larger size. Just because my engine runs at 800X600 doesn't mean that I can draw different ratio based on what the engine is doing. I mean, I can run the game at 1600X1200 just by doubling all the coordinates when the screen is drawn. That's easier to implement that my rambing on up above and would work just as well. It seems like most things, I can fake it. That's almost doable tomorrow.
Monday, February 16, 2009
Going for Broke / Plan C
I'm ready for more now. I'm tired of waiting now. I'm ready to have everything I've ever wanted. I'm ready to try this for real. I'm ready, and I'll only waste away waiting for it to happen. So, Plan C - I'm going to try to find a way to fund me. The idea of course, is to try to find a publisher that can see the potential that Thief can have on Xbox Live and is willing to pony up some funding. Then, Star Frog Games can be my job, not just my hobby. In an odd kind of way, the whole point of this little project was to show the world that I can do this. Yet, somehow, this project has shown me that I can and that I should.
There are too many questions that need answering : How do I set up a pitch? How do I write one? Where do I have to go? What do I have to do? What do I do when I get funding? What will the terms be? Will I still have the same freedoms? How will this change the dynamics that my plucky little team has created? Will they still want to come along?
But, there are always questions. I mean, when I started this I knew almost nothing. It was all theory and big ideas. But I've proven to myself the ability to figure it out. Being a start-up. Making a product, making a return on an investment. This I can do. But this, this would be Big. Large, life changing. The possibilities staggering, the price of Failure - paralyzing. Yet I think I'm at a crossroads, where the fear of doing something is outmatched by the fear of being nothing.
So now, I look for the possibilities. I will have to travel, I will have to find the way to do it all, I must find a way to make it happen.
We can do this. We can have everything we've ever wanted. We can be anything.
It's too late, it's too soon, it's too late, it's too soon, or is it tick tick tick tick tick tick tick BOOM.
There are too many questions that need answering : How do I set up a pitch? How do I write one? Where do I have to go? What do I have to do? What do I do when I get funding? What will the terms be? Will I still have the same freedoms? How will this change the dynamics that my plucky little team has created? Will they still want to come along?
But, there are always questions. I mean, when I started this I knew almost nothing. It was all theory and big ideas. But I've proven to myself the ability to figure it out. Being a start-up. Making a product, making a return on an investment. This I can do. But this, this would be Big. Large, life changing. The possibilities staggering, the price of Failure - paralyzing. Yet I think I'm at a crossroads, where the fear of doing something is outmatched by the fear of being nothing.
So now, I look for the possibilities. I will have to travel, I will have to find the way to do it all, I must find a way to make it happen.
We can do this. We can have everything we've ever wanted. We can be anything.
It's too late, it's too soon, it's too late, it's too soon, or is it tick tick tick tick tick tick tick BOOM.
Thursday, February 12, 2009
Like a Candle in the Dark
The beginnings of the new menu are beginning to form. Like some kind of digital fetus on its way to growing into a fully functional bit of code. Now you can press the Alt key and click to select which object of the 30 ThiefEd can handle. Now it needs to:
Highlight the selected Object in the workspace screen
Let you pick the object you want from a mouse driven menu.
Then, the system needs to save it. No problem. Right? Well almost, mostly because I'm not a terribly good programmer. The idea was to reuse the code from my Map Menu, a system that allows me to create a giant menu with the minimum amount of code and effort. The problem first came about because I could not remember for the life of me, how the thing worked. I mean, I built the code, so clearly I can do it. But that system was set up differently than what I wanted for the menu. So yesterday I went ahead and rebuilt a new menu using the Map Menu like I posted in (http://indieconfessions.blogspot.com/2008/07/6-2-08.html) as a guide. So now it works, and the next bit should be a little better.
An issue I encountered is a new Array I built. The thinking went that I could load images into an Array and still reference them. Load 'em up with a loop since I designed the file structures to be purely numeric. Problem I encountered was that I couldn't load stuff that doesn't exist, and I can't hard code the values for the loops until the art is all finished. So that's a big fat waste.
In the meantime as a proof of concept all of the art bits has distinct variables assigned. It's really messy, but it works right now, which brings me to the titles. I built an Animated Candle, and it works. Now I can select and object, press my hotkey to make it a type 1 object and click the screen, a little animated candle appears. I can do this 30 times! I can make the screen look like the Temple of Doom. It's sweet. The whole thing doesn't work yet, but I can see that it works very much like it is supposed to.
When I get a little more time, I'm going to reinstall the loop loading and fill out the objects folder with tiny little pictures of puppies or something. Then the load will just work and art can just be stuffed in.
Today though, I'm going to finish the menu, make the key system work and save the stuff. Tomorrow is a meeting and I want to show the artists how easy it is to play with ThiefEd. I think the best art and the best designed levels will require the use of PhotoShop and ThiefEd. mmmm...animated backgrounds.
-Ah right. Microtexturing works. The candle's light is transparent and it looks much better over a background than it does in PhotoShop. It is a little more opaque than I was expecting. But then again, the transparent bits are 50% mask color, so that means a 50% transparency. I can probably do better then that and devise methods to get different percentages. Hmm, tests for another day.
- By the way, Candle in the Dark is a Carl Sagan book. It's short, go read it. Afterwards you'll thank yourself.
Highlight the selected Object in the workspace screen
Let you pick the object you want from a mouse driven menu.
Then, the system needs to save it. No problem. Right? Well almost, mostly because I'm not a terribly good programmer. The idea was to reuse the code from my Map Menu, a system that allows me to create a giant menu with the minimum amount of code and effort. The problem first came about because I could not remember for the life of me, how the thing worked. I mean, I built the code, so clearly I can do it. But that system was set up differently than what I wanted for the menu. So yesterday I went ahead and rebuilt a new menu using the Map Menu like I posted in (http://indieconfessions.blogspot.com/2008/07/6-2-08.html) as a guide. So now it works, and the next bit should be a little better.
An issue I encountered is a new Array I built. The thinking went that I could load images into an Array and still reference them. Load 'em up with a loop since I designed the file structures to be purely numeric. Problem I encountered was that I couldn't load stuff that doesn't exist, and I can't hard code the values for the loops until the art is all finished. So that's a big fat waste.
In the meantime as a proof of concept all of the art bits has distinct variables assigned. It's really messy, but it works right now, which brings me to the titles. I built an Animated Candle, and it works. Now I can select and object, press my hotkey to make it a type 1 object and click the screen, a little animated candle appears. I can do this 30 times! I can make the screen look like the Temple of Doom. It's sweet. The whole thing doesn't work yet, but I can see that it works very much like it is supposed to.
When I get a little more time, I'm going to reinstall the loop loading and fill out the objects folder with tiny little pictures of puppies or something. Then the load will just work and art can just be stuffed in.
Today though, I'm going to finish the menu, make the key system work and save the stuff. Tomorrow is a meeting and I want to show the artists how easy it is to play with ThiefEd. I think the best art and the best designed levels will require the use of PhotoShop and ThiefEd. mmmm...animated backgrounds.
-Ah right. Microtexturing works. The candle's light is transparent and it looks much better over a background than it does in PhotoShop. It is a little more opaque than I was expecting. But then again, the transparent bits are 50% mask color, so that means a 50% transparency. I can probably do better then that and devise methods to get different percentages. Hmm, tests for another day.
- By the way, Candle in the Dark is a Carl Sagan book. It's short, go read it. Afterwards you'll thank yourself.
Wednesday, February 11, 2009
I Think I'm Paranoid
Things are clicking along too well. If stuff continues at this rate I may actually finish the new object system sometime today and get on to the other prototypes that need doing. But, that just doesn't happen. Ease exists only to lull you into a false sense of security so that when the proverbial cow patty hits the alegorical fan it destroys your world.
I got the object system installed. It was made easier when I figured out that the individual parts of an array can be used as a variable would. I mean "if Map(Loop,2) - 7 > 65" works. It barely looks like anything, but it works anyway. With this out of the way I assigned a hot key and started plastering my test level with "Objects!" tags. Next up in the docket it to assign the type to the objects and update the save system. I'm thinking I can build a Selection Loop like for the map to select the objects. With that done, I'll build the animation system - but that should go fast too since I can refer to the bloody things as variables. This is too easy, I'm clearly doing something wrong.
Of course I do have to make ThiefEd a little easier to use. The plan is to give it the Ron so he can put the animated bits he wants right into the level where he wants them. Between that and the constantly updated background image that is already a feature, it should help with making the levels look very pretty.
- Speaking of which, I probably should talk to the artists about the gameplay features. I mean, if they can't get the art done for some of the newish features (like the combat upgrade) then I could skip building the prototype and get right back into level building. I'll find out on Friday when we meet up.
- Oh, and I got my new files moved over to my new computer, and nothing works. The code fails for silly stupid crap: "What do you mean "WaitTimer()" isn't a Blitz Command?" "Why are you crashing? The Files are all in the same damn place!" 'Yes Vista, I still do want to load that. You can shut the hell up now." Argh. I don't know why it does that. So even though I have a shiny new laptop I can't do work on it. It's okay though, I like the old keyboard more.
I got the object system installed. It was made easier when I figured out that the individual parts of an array can be used as a variable would. I mean "if Map(Loop,2) - 7 > 65" works. It barely looks like anything, but it works anyway. With this out of the way I assigned a hot key and started plastering my test level with "Objects!" tags. Next up in the docket it to assign the type to the objects and update the save system. I'm thinking I can build a Selection Loop like for the map to select the objects. With that done, I'll build the animation system - but that should go fast too since I can refer to the bloody things as variables. This is too easy, I'm clearly doing something wrong.
Of course I do have to make ThiefEd a little easier to use. The plan is to give it the Ron so he can put the animated bits he wants right into the level where he wants them. Between that and the constantly updated background image that is already a feature, it should help with making the levels look very pretty.
- Speaking of which, I probably should talk to the artists about the gameplay features. I mean, if they can't get the art done for some of the newish features (like the combat upgrade) then I could skip building the prototype and get right back into level building. I'll find out on Friday when we meet up.
- Oh, and I got my new files moved over to my new computer, and nothing works. The code fails for silly stupid crap: "What do you mean "WaitTimer()" isn't a Blitz Command?" "Why are you crashing? The Files are all in the same damn place!" 'Yes Vista, I still do want to load that. You can shut the hell up now." Argh. I don't know why it does that. So even though I have a shiny new laptop I can't do work on it. It's okay though, I like the old keyboard more.
Monday, February 9, 2009
"I Am Invincible!"
Epic, that's how I feel right now. Yes, that is a GoldenEye reference and yes, Boris is my favorite character from the movie and in olde skool FPS combat (a ha! take that Oddjob you short little cheating piece of crap). Anyway, as per the previous post, I've gotten my bloody array to work.
-Oh, got my cord too. CID is back on-line and Star Frog Games is back into full scale production mode. Life is good.
Right, so back to the array. I would like to point out that Blitz Basic has some pretty terrible documentation on the subject, so I'll scribble this down so other people may or may not experience my personal hell. So there are 2 different kinds of data arrangements in Blitz. The first is called a Type. I beat on this for a while before realizing it wasn't correct. Basically, it allows one to create an assortment of objects that can be referenced as a group with individual properties. This sounds great, but you cannot reference individual aspects of that group by itself. So while you could have each bit fed through an AI routine and check for collision and whatnot, you cannot say, "Get me that one, with the funny head." So that's clearly not going to work, but in the future if I end up building the engine again, that's how enemies in Knight are going to roll.
The other kind is referenced by the obscure "Dim" command. I think it's programmer short hand for "Dimensional Array." After one summons this command through arcane means, you can opt to create fields in this array thusly:
Dim Map(20,20)
This creates an array with 20 rows and 20 columns and calls the array "Map". Once I had this all set, I built a quick loop to fill it in with some numbers and then told it to give me the numbers back and arrange them all pretty like. Which it did.
The real catch was this : I told the system to find Map(19,19) and change the value like this:
Map(19,19) = 1337
Then I ran it again, and it worked, it bloody worked and the space at 19,19 was "1337." So that makes my whole day. I'll get the thing installed tomorrow into ThiefEd and really get something cooking, but I'm really glad the prototype worked.
-Yes, I know, "1337" is so 1997. But I would have had to change the style of the array to actually have it say "I Am Invincible" or "Yatta!"
-Oh, got my cord too. CID is back on-line and Star Frog Games is back into full scale production mode. Life is good.
Right, so back to the array. I would like to point out that Blitz Basic has some pretty terrible documentation on the subject, so I'll scribble this down so other people may or may not experience my personal hell. So there are 2 different kinds of data arrangements in Blitz. The first is called a Type. I beat on this for a while before realizing it wasn't correct. Basically, it allows one to create an assortment of objects that can be referenced as a group with individual properties. This sounds great, but you cannot reference individual aspects of that group by itself. So while you could have each bit fed through an AI routine and check for collision and whatnot, you cannot say, "Get me that one, with the funny head." So that's clearly not going to work, but in the future if I end up building the engine again, that's how enemies in Knight are going to roll.
The other kind is referenced by the obscure "Dim" command. I think it's programmer short hand for "Dimensional Array." After one summons this command through arcane means, you can opt to create fields in this array thusly:
Dim Map(20,20)
This creates an array with 20 rows and 20 columns and calls the array "Map". Once I had this all set, I built a quick loop to fill it in with some numbers and then told it to give me the numbers back and arrange them all pretty like. Which it did.
The real catch was this : I told the system to find Map(19,19) and change the value like this:
Map(19,19) = 1337
Then I ran it again, and it worked, it bloody worked and the space at 19,19 was "1337." So that makes my whole day. I'll get the thing installed tomorrow into ThiefEd and really get something cooking, but I'm really glad the prototype worked.
-Yes, I know, "1337" is so 1997. But I would have had to change the style of the array to actually have it say "I Am Invincible" or "Yatta!"
Combating Mediocrity
The Combat system in Thief is designed from the ground up to be simple. Mostly since I'm not that good of a programmer, and further justified because the main focus of the game is supposed to be the platforming. Of course, the next game in the docket of my brain (codename Knight) is all about combat - so it's not that I'm afraid of it. The combat is the way it is to break up the gameplay a little and add some variety.
The key to it was always a system I referred to as "Variable Animations." Basically, the combat timing is all canned, a system that I worked out and documented somewhere lower in the diary. Since the timing is all set up, the animations become secondary and can be made variable. So, instead of just one "attack" animation, there can be half a dozen. Along with 5 high blocks, 5 low blocks and lots of other variations. Basically, the underlying system is designed to be simple, but look really slick.
The issue with this is that, although it may look very slick, the gameplay is the bit the player is actually playing. So, it was posited that the combat could be upgraded a little bit. I initially thought the idea wasn't "right" so I thought about other stuff. The reasoning was:
A) The enemy AI is pretty stupid. I mean, they function, but asking them to do more than that will only serve to confuse and annoy.
B) It's still a secondary feature.
Even still, when I got to thinking about it, the combat could be upgraded within the confines of the current system. So no, not throw out the current system (which I am quite fond of), but instead make it better.
So here's what I thought of - different Enemy attacks and a rebalanced Deflect mechanic. First, the Enemies. Since having the enemy AI react to the player is quite difficult, I think it would be easier to implement more things for the player to react to. But wait, didn't I already rip out the third flavour of dodge way back in the day? Well, yes I did, but this is different. Now, while an enemy will still have high and low attacks, some of those attacks will have "Stun" and "Throw" properties. So an attack may also stun the player or begin the "Throw" minigame.
Stunning for example. When the AI figures out the enemy attacks, there will be a random chance that the attack will be a Stun Attack. If this attack hits, it will deal damage and stun the player. If this happens and the enemy still has attacks available the next attack will automatically be a longer duration Super Attack or something similar. So the Fencers may flourish or the Knights may do a spinning wind up attack or the bosses may have a longer, more elaborate swing with a flip or something. While this is going on, the player will mash the keys and generally try to "wake up." If they fail, the big attack will hit and do considerable damage. If they wake up, then they will still have to press the correct dodge or else take some pain also. Basically, the system is designed to require additional input other than Up and Down while in combat.
The second part of that is a more elaborate Throw. Right now, the Throw is built in there so the enemies and the player do not overlap while fighting. So there is a quick "move away" animation. Instead, I think that the enemy should grab the player and start a different mini-game wherein the enemy punches or jumps on or generally causes minor injury to The Thief. While this is going on, the player will push left and right in an attempt to break free. This will also be available from an attack of the enemy.
So, with there is, I think the combat will be a little more interesting - unless you're good - at which point you'll just dodge well enough to never even see a throw or stun attack. In that case I've decided to modify the Deflect code to make it easier to use and quicker to see. So it'll need a bigger flash and a bigger window.
For both of these, I need to build a prototype of course. I mean, they work really well in my head, but in the head and on the screen are very different things I find.
The key to it was always a system I referred to as "Variable Animations." Basically, the combat timing is all canned, a system that I worked out and documented somewhere lower in the diary. Since the timing is all set up, the animations become secondary and can be made variable. So, instead of just one "attack" animation, there can be half a dozen. Along with 5 high blocks, 5 low blocks and lots of other variations. Basically, the underlying system is designed to be simple, but look really slick.
The issue with this is that, although it may look very slick, the gameplay is the bit the player is actually playing. So, it was posited that the combat could be upgraded a little bit. I initially thought the idea wasn't "right" so I thought about other stuff. The reasoning was:
A) The enemy AI is pretty stupid. I mean, they function, but asking them to do more than that will only serve to confuse and annoy.
B) It's still a secondary feature.
Even still, when I got to thinking about it, the combat could be upgraded within the confines of the current system. So no, not throw out the current system (which I am quite fond of), but instead make it better.
So here's what I thought of - different Enemy attacks and a rebalanced Deflect mechanic. First, the Enemies. Since having the enemy AI react to the player is quite difficult, I think it would be easier to implement more things for the player to react to. But wait, didn't I already rip out the third flavour of dodge way back in the day? Well, yes I did, but this is different. Now, while an enemy will still have high and low attacks, some of those attacks will have "Stun" and "Throw" properties. So an attack may also stun the player or begin the "Throw" minigame.
Stunning for example. When the AI figures out the enemy attacks, there will be a random chance that the attack will be a Stun Attack. If this attack hits, it will deal damage and stun the player. If this happens and the enemy still has attacks available the next attack will automatically be a longer duration Super Attack or something similar. So the Fencers may flourish or the Knights may do a spinning wind up attack or the bosses may have a longer, more elaborate swing with a flip or something. While this is going on, the player will mash the keys and generally try to "wake up." If they fail, the big attack will hit and do considerable damage. If they wake up, then they will still have to press the correct dodge or else take some pain also. Basically, the system is designed to require additional input other than Up and Down while in combat.
The second part of that is a more elaborate Throw. Right now, the Throw is built in there so the enemies and the player do not overlap while fighting. So there is a quick "move away" animation. Instead, I think that the enemy should grab the player and start a different mini-game wherein the enemy punches or jumps on or generally causes minor injury to The Thief. While this is going on, the player will push left and right in an attempt to break free. This will also be available from an attack of the enemy.
So, with there is, I think the combat will be a little more interesting - unless you're good - at which point you'll just dodge well enough to never even see a throw or stun attack. In that case I've decided to modify the Deflect code to make it easier to use and quicker to see. So it'll need a bigger flash and a bigger window.
For both of these, I need to build a prototype of course. I mean, they work really well in my head, but in the head and on the screen are very different things I find.
Thursday, February 5, 2009
Game Design 102
Let's talk theory, mostly because I got to talk about these things recently and they're fresh on my mind.
I was asked, "What is the most important thing about a game," and what could I do to make a game less fun. The obstinate answer I received was Balance. The concept is that without Balance, the game is either unfair or too easy. Finding the middle ground between too challenging and too easy the Holy Grail of game design. This is, I think, wrong. Balance is a virtue of a mechanic. An individual Mechanic or Feature has Balance both within itself and within the confines of the game system. Important? Yes. The most Important? No.
To wit, fighting games try to be as balanced as possible and try to keep everybody even to ensure quality play. Every other game ever made is not made this way. The game is unbalanced by design, and still works. In Pac-Man you're always fighting 6 on 1 and they're faster than you. In Space Invaders its little you versus dozens of them. Halo, Gears, Zelda - they are all out to get you. So Balance of a game is impossible and not the point. Instead, it's another feature of a well crafted mechanic.
Further, another thing to consider are the 3 "C's" They are Control, Camera and Characterization. These are design concepts used by some of the bigger firms. I'll tear into them thus:
Control - Yes, control is the one that gets away. Without consistent controls with consistent outcomes the game does not work. For example, someone once posited that the jump height of The Thief should be variable to add flavour. Any Designer in their right mind would cringe at the thought because it would break the game. If the input of the player is nothing more than a suggestion you have failed the Control aspect.
Camera - No, not camera. Maybe that's the term used in 3D spaces, but what is meant is View. Not every game has a camera, but they all allow you to see. Well, there are a couple that only have sounds, but we'll ignore those for now. Without the ability to see, you cannot play. The trick is being able to always see, regardless of what is going on in the game. Don't make a feature that takes away from this. In the new Prince of Persia the bosses have this attack where they spit black duke on the "screen," making it impossible to see while fighting. Um, yeah, don't do that. It's stupid then and it's stupid now.
Characterization - Fail. There are so many examples of how this particular word isn't correct for what is wanted that I could skip them. Won't though, Tetris, Bejeweled, Centipede, Snake, Gradius none of them have characters that you see or give a crap about. This is not a pillar of gameplay. What is meant is "Representation." Gamers do not want to play as a character, they want to relate to that character and be that character. Master Chief works so well because you never see him, he could be anybody. Some Designers refer to this as the"Vessel." Miyamoto went so far as to call this connection "Link." The Connection is the correct "C" word here, the space for the player to be involved and given the option to do what they want - a safe haven when the rest of the game is out to get them. Do games need a story? No because without it (or within the confines of it) the player will create narrative with the tools that they are given.
Of course, all of this is just Theory and it holds up until code is actually written. So where does "fun" happen? What is the magic that has to happen for a game to click and become enjoyable? I don't know. There isn't any one thing that can work. Game Design is still the Wild West, nothing is set and everything is possible. There is no hard and fast rule for anything and while someone can learn the theory, that doesn't mean that they can create the fun. The same way that a painter can learn technique, but not know how to create beauty. That's one of the reasons I do not think that "Game Colleges" work - the methodologies are still too liquid to be nailed down. The catch 22 of it all is if fun is ever proven as a theory, it will stop being new and stop being fun. The ever elusive spark of fun avoiding the theory like a rabid Saint Bernard.
So, make your game but understand that you are not the target audience of your game. Find the part that's fun to you, and see if it is still fun to other people and work from there. Do a thousand prototypes, write a dozen design documents, draw a million pictures, have a hundred dreams, whatever works for you. Don't let the theory of it all stop you.
-Cord incoming, and I may have some new art on the way. Those will be posted when I have them.
I was asked, "What is the most important thing about a game," and what could I do to make a game less fun. The obstinate answer I received was Balance. The concept is that without Balance, the game is either unfair or too easy. Finding the middle ground between too challenging and too easy the Holy Grail of game design. This is, I think, wrong. Balance is a virtue of a mechanic. An individual Mechanic or Feature has Balance both within itself and within the confines of the game system. Important? Yes. The most Important? No.
To wit, fighting games try to be as balanced as possible and try to keep everybody even to ensure quality play. Every other game ever made is not made this way. The game is unbalanced by design, and still works. In Pac-Man you're always fighting 6 on 1 and they're faster than you. In Space Invaders its little you versus dozens of them. Halo, Gears, Zelda - they are all out to get you. So Balance of a game is impossible and not the point. Instead, it's another feature of a well crafted mechanic.
Further, another thing to consider are the 3 "C's" They are Control, Camera and Characterization. These are design concepts used by some of the bigger firms. I'll tear into them thus:
Control - Yes, control is the one that gets away. Without consistent controls with consistent outcomes the game does not work. For example, someone once posited that the jump height of The Thief should be variable to add flavour. Any Designer in their right mind would cringe at the thought because it would break the game. If the input of the player is nothing more than a suggestion you have failed the Control aspect.
Camera - No, not camera. Maybe that's the term used in 3D spaces, but what is meant is View. Not every game has a camera, but they all allow you to see. Well, there are a couple that only have sounds, but we'll ignore those for now. Without the ability to see, you cannot play. The trick is being able to always see, regardless of what is going on in the game. Don't make a feature that takes away from this. In the new Prince of Persia the bosses have this attack where they spit black duke on the "screen," making it impossible to see while fighting. Um, yeah, don't do that. It's stupid then and it's stupid now.
Characterization - Fail. There are so many examples of how this particular word isn't correct for what is wanted that I could skip them. Won't though, Tetris, Bejeweled, Centipede, Snake, Gradius none of them have characters that you see or give a crap about. This is not a pillar of gameplay. What is meant is "Representation." Gamers do not want to play as a character, they want to relate to that character and be that character. Master Chief works so well because you never see him, he could be anybody. Some Designers refer to this as the"Vessel." Miyamoto went so far as to call this connection "Link." The Connection is the correct "C" word here, the space for the player to be involved and given the option to do what they want - a safe haven when the rest of the game is out to get them. Do games need a story? No because without it (or within the confines of it) the player will create narrative with the tools that they are given.
Of course, all of this is just Theory and it holds up until code is actually written. So where does "fun" happen? What is the magic that has to happen for a game to click and become enjoyable? I don't know. There isn't any one thing that can work. Game Design is still the Wild West, nothing is set and everything is possible. There is no hard and fast rule for anything and while someone can learn the theory, that doesn't mean that they can create the fun. The same way that a painter can learn technique, but not know how to create beauty. That's one of the reasons I do not think that "Game Colleges" work - the methodologies are still too liquid to be nailed down. The catch 22 of it all is if fun is ever proven as a theory, it will stop being new and stop being fun. The ever elusive spark of fun avoiding the theory like a rabid Saint Bernard.
So, make your game but understand that you are not the target audience of your game. Find the part that's fun to you, and see if it is still fun to other people and work from there. Do a thousand prototypes, write a dozen design documents, draw a million pictures, have a hundred dreams, whatever works for you. Don't let the theory of it all stop you.
-Cord incoming, and I may have some new art on the way. Those will be posted when I have them.
Wednesday, February 4, 2009
Another Day
I recently had another job interview. There was an NDA so I can't go into the specifics, so just assume I was applying to work as a Game Designer at the CIA. So I went, got to speak to both the Designer in charge of the project and the owner of the company and play an Alpha Demo of their game. Consequently, I was asked to consider the design and see what kinds of things I would change. I thought that the game would require a more or less complete tear down of the more esoteric features and a return to a more "core" style of gameplay. You know, the part that would make the game special. This didn't seem to be what they were looking for though, and I'm still working freelance.
Still, getting an interview and a sit down is another step towards my goals, so I have to consider that on some level as a win. Besides, as I thought about it, the job could have gone two ways, and I wrote my suggestions based on that. 1) the Gameplay could have been left unchanged and I could have given suggestions on how to try to polish gameplay features I felt were inherently broken. 2) Give suggestions on how the core gameplay could be fixed, while the suggestions may have proven unpopular. So, if I had gotten the job with #1, then it could have been me working at trying to fix and balance gameplay that I do not think can be fixed. Or, with #2, my suggestions and feedback would be something that would have merit and I would have had the ability to make the game as good as I could. So I went with #2, and argued for core changes. I mean, if #1 got me the job - or #2 didn't, then it would not be something that would make me happy. So given the options based on the choices I made, I think it's okay.
- In a post a few days ago, I did mention doing something reckless. In that theme I sent an email to the Designer on the project to ask if there was something I was missing, some skill I was without that I could learn. If I was doing something wrong. What's the worse thing that happens? No reply? Everything makes you learn something. Sometimes you have the ability to ask questions afterwards though. I'm doing that.
- Ah, yes, laptop still not up. I went back to the store and returned the incorrect cord, only to shortly find out that the cord I need is only made by the manufacturer. No still no es bueno. So yeah, that continues to be a savage case of lame. I've ordered one off of the internet and I should have it soon. Maybe. Hopefully.
- With new laptop I've taken the advice of a reader (yes I have them now) and registered the space www.StarFrogGames.com. Soon, this may be posted there. Or it won't. I'm not sure how that would work, but at least somebody can't buy it and then hold my domain ransom. Oh, and even though people may come here and/or read this, I'll still write it like nobody else does. That's the point after all. I mean, I could have verifiable data that thousands visit, but that won't change how I write. That would be selling out, or something.
Still, getting an interview and a sit down is another step towards my goals, so I have to consider that on some level as a win. Besides, as I thought about it, the job could have gone two ways, and I wrote my suggestions based on that. 1) the Gameplay could have been left unchanged and I could have given suggestions on how to try to polish gameplay features I felt were inherently broken. 2) Give suggestions on how the core gameplay could be fixed, while the suggestions may have proven unpopular. So, if I had gotten the job with #1, then it could have been me working at trying to fix and balance gameplay that I do not think can be fixed. Or, with #2, my suggestions and feedback would be something that would have merit and I would have had the ability to make the game as good as I could. So I went with #2, and argued for core changes. I mean, if #1 got me the job - or #2 didn't, then it would not be something that would make me happy. So given the options based on the choices I made, I think it's okay.
- In a post a few days ago, I did mention doing something reckless. In that theme I sent an email to the Designer on the project to ask if there was something I was missing, some skill I was without that I could learn. If I was doing something wrong. What's the worse thing that happens? No reply? Everything makes you learn something. Sometimes you have the ability to ask questions afterwards though. I'm doing that.
- Ah, yes, laptop still not up. I went back to the store and returned the incorrect cord, only to shortly find out that the cord I need is only made by the manufacturer. No still no es bueno. So yeah, that continues to be a savage case of lame. I've ordered one off of the internet and I should have it soon. Maybe. Hopefully.
- With new laptop I've taken the advice of a reader (yes I have them now) and registered the space www.StarFrogGames.com. Soon, this may be posted there. Or it won't. I'm not sure how that would work, but at least somebody can't buy it and then hold my domain ransom. Oh, and even though people may come here and/or read this, I'll still write it like nobody else does. That's the point after all. I mean, I could have verifiable data that thousands visit, but that won't change how I write. That would be selling out, or something.
Tuesday, February 3, 2009
Post Post Mortem
Today the Post-Mortem of The Thief's Tale went live, and consequently somebody may actually be reading this today. If this is your first time here, the link to the previous entries are all listed at the lower right. So if you want even more information than what I could include in the space in the Post-Mortem it's all there. A Day by Day of all the small triumphs and sometimes failures.
Then, if you'd like to actually play the game, the game can be downloaded at the right. The version you see there is the build we sent for IGF.
Right then. I'll also like to say (considering this may be the first time people not on the team have read this) thank you to everybody that helped along the way.
Finally, don't be bashful. If you got here after reading the article, let me know in the comments.
Then, if you'd like to actually play the game, the game can be downloaded at the right. The version you see there is the build we sent for IGF.
Right then. I'll also like to say (considering this may be the first time people not on the team have read this) thank you to everybody that helped along the way.
Finally, don't be bashful. If you got here after reading the article, let me know in the comments.
Subscribe to:
Posts (Atom)
