I know, no posting in the last 5 days. Well, I have been busy doing Project Stuff (!). The day before yesterday I got the first level all nice, and began to install the scripting into it. Where I ran into some issues was with the Combat Tutorial.
Generally speaking, the Combat should be something really well integrated into the general game systems. Other times, the combat plays out as its own kind of game. Examples of which include Prince of Persia, Flashback, and generally any game like that. Consequently, I felt that I really wanted the combat and the platforming to be separate for the most part. In some level designs, you will be able to platform around enemies, but when I want combat, I'll force the issue.
However, that does tend to make it a little harder to have the combat be introduced in normal gameplay. I mean, in Super Mario you can jump, and there are enemies, and you can jump on them. The 2 facets are combined into a single element. In Thief I really wanted to keep the two a little separate. There are 2 reasons for this, the first of which is that I'm not that good of a programmer. The other is that I wanted both systems to be robust, but with limited control inputs.
Either way, I needed a combat tutorial. I learned a few things:
1) It's easy to set up certain circumstances (when you hit/Get Hit/Press a button) but it's a lot more difficult to have it deal with other stuff. Like, "I don't want to pull out my sword, I just want to jump around," and other similar nonsense.
2) It's very important to have the steps link together in some way. So we don't cover walking, and then reset to make the player walk to the next bit. That's a little stupid.
3) The scripting engine (tool?) is flexible, but stupid. For example, each "talky" bit is rendered like its own frame. This means that I have to draw everything on the screen, all the enemies, the player and any animations, and the background for each frame of dialog. That kind of sucks, but it will have to do.
So now the tutorial is all done, and I'm quite happy with that. Pictures incoming.
Sunday, August 31, 2008
Tuesday, August 26, 2008
Level 1, and the Sound of Deadlines
Yesterday I finished Level 1. The whole thing is blocked out, it has the tutorial scripting in it and you can play with it. The art isn't finished yet (grrr...) but for my part I'm feeling good about it. Now I get to make small adjustments for playability (that is a word, but it looks so, incorrect...) and pacing in regards to the story and the scripted scenes. Overall, I feel good about the first level, and it has given me a lot of thoughts on the next levels. I found myself wanting to construct screens with puzzles that require 2 or more moves in a row, and thought to myself, "No, this has 3 moves, this kind of puzzle really should go in the Castle Level," and things like that. So I began to get a feel for the difficulty as I built them. So, the next levels should be a little easier and faster to do.
So, the idea was to have all of the levels at least blocked out by now. What I didn't anticipate was throwing work away, and all of the testing by other people to make sure it works and makes any sense. The due date for the levels was going to be 8-30, but that clearly didn't happen, and probably won't. Now I just want to get them done by IGF and with art. I heard a quote by a developer once regarding milestones. They said, "I love the sound they make when they go flying past."
For the art, I think I have a problem. I posted a note on Craigslist looking for artists to work on the project with me, mostly to work on the backgrounds. I had 3 people with me - the animator, a background artist and a character artist for the scripty bits. Except for the Animator - a friend of mine since High School, I would send email messages and things like that. Now, for whatever reason, I don't get replies back from my artists, and I can't seem to get ahold of my friend. So, I find myself in an awkward position. I'm not sure if I should try to repair the working relationships that I have, or look for new artists.
I get the feeling that it was something that I did. Like I somehow didn't use the correct artist speak or something. I violated some custom that I didn't know about, or said something that I shouldn't. I just don't know. I think the main reason is my lack of communication for some things. I found myself often working late into the night, and the thinking was that I could email tomorrow, and then a week would go by like that, and another. It became a cycle of punishment. Eventually, the thoughts began to creep in, "What will they think, now that it's been 3 weeks?" "Will they all think you're just dicking with them?" "Are you serious abut the project?" Soon, self doubt overrode my better judgements. By the time the Producer half of my brain said, "Hey, asshole- quit being a dick and get back to work, and get everyone else on track," I find that I just can't get ahold of anyone anymore.
This is painful. Not to sound like some half-assed emo "boi" but this is the hardest part so far. Now all I can do I try to send an email, or call, and see what I can do with what I can do. I've never been so close to something, and the work that I've done so far, it staggers me. I never thought that I would be able to do something so bold, so outside of anything I've ever done before, and I find it exhilarating. Now, I need to convince the people that will make the endeavour possible to see the same thing I see.
So, the idea was to have all of the levels at least blocked out by now. What I didn't anticipate was throwing work away, and all of the testing by other people to make sure it works and makes any sense. The due date for the levels was going to be 8-30, but that clearly didn't happen, and probably won't. Now I just want to get them done by IGF and with art. I heard a quote by a developer once regarding milestones. They said, "I love the sound they make when they go flying past."
For the art, I think I have a problem. I posted a note on Craigslist looking for artists to work on the project with me, mostly to work on the backgrounds. I had 3 people with me - the animator, a background artist and a character artist for the scripty bits. Except for the Animator - a friend of mine since High School, I would send email messages and things like that. Now, for whatever reason, I don't get replies back from my artists, and I can't seem to get ahold of my friend. So, I find myself in an awkward position. I'm not sure if I should try to repair the working relationships that I have, or look for new artists.
I get the feeling that it was something that I did. Like I somehow didn't use the correct artist speak or something. I violated some custom that I didn't know about, or said something that I shouldn't. I just don't know. I think the main reason is my lack of communication for some things. I found myself often working late into the night, and the thinking was that I could email tomorrow, and then a week would go by like that, and another. It became a cycle of punishment. Eventually, the thoughts began to creep in, "What will they think, now that it's been 3 weeks?" "Will they all think you're just dicking with them?" "Are you serious abut the project?" Soon, self doubt overrode my better judgements. By the time the Producer half of my brain said, "Hey, asshole- quit being a dick and get back to work, and get everyone else on track," I find that I just can't get ahold of anyone anymore.
This is painful. Not to sound like some half-assed emo "boi" but this is the hardest part so far. Now all I can do I try to send an email, or call, and see what I can do with what I can do. I've never been so close to something, and the work that I've done so far, it staggers me. I never thought that I would be able to do something so bold, so outside of anything I've ever done before, and I find it exhilarating. Now, I need to convince the people that will make the endeavour possible to see the same thing I see.
Saturday, August 23, 2008
Bad bugs, bad stupid bugs
Yesterday I fixed a stupid bug. Basically, when Zero would jump up onto one of the catch rectangles, it would make a small adjustment and he would appear to "slide" into the correct position. It wasn't the ideal situation, since there are so many of the ledges in the game. I really didn't want to deal with having a bug be visible, and openly irritating, for that much of the game. So that had to go. Sooner, rather than later. So I tried fixing it, and gods help me, the bloody thing just would not be fixed. I tried converting some of the collision code and seeing if it was a Event Handling bug, but it wasn't, and all it managed to do was break the rest of the collision.
Next, I tried set the game to display a variety of variables while the game was running. Eventually discovered that the Physics Modifier wasn't reseting correctly. The physics are a little silly in this case. Basically, when you are falling or generally not on the ground, the physics system calculates a continually increasing speed to simulate the additional velocity - like in real life. Originally there was no modifier and the fall speeds were all constant, but I felt that was stupid. Anyway, it wasn't being reset when you hit the Catch Rectangles and now it is, so now it works.
- Also decided on a few things.
1) The player runs too damn fast. I noticed that the Tester sometimes had issue with the small platforms and I thought that by slowing the player's running speed a little it would make the game slightly longer in the end. So I reduced the speed by 20% or so and it works really nice.
2) The Drop Bit is a little too far before it becomes lethal. I found I could drop off of what amounted to 3 story falls and would just walk away. Not a huge issue, but the distance is important. If the fall isn't enough to kill, then it makes the "danger" of the puzzle inconsequential. No danger, no suspense, no fun.
Next, I tried set the game to display a variety of variables while the game was running. Eventually discovered that the Physics Modifier wasn't reseting correctly. The physics are a little silly in this case. Basically, when you are falling or generally not on the ground, the physics system calculates a continually increasing speed to simulate the additional velocity - like in real life. Originally there was no modifier and the fall speeds were all constant, but I felt that was stupid. Anyway, it wasn't being reset when you hit the Catch Rectangles and now it is, so now it works.
- Also decided on a few things.
1) The player runs too damn fast. I noticed that the Tester sometimes had issue with the small platforms and I thought that by slowing the player's running speed a little it would make the game slightly longer in the end. So I reduced the speed by 20% or so and it works really nice.
2) The Drop Bit is a little too far before it becomes lethal. I found I could drop off of what amounted to 3 story falls and would just walk away. Not a huge issue, but the distance is important. If the fall isn't enough to kill, then it makes the "danger" of the puzzle inconsequential. No danger, no suspense, no fun.
Wednesday, August 20, 2008
Star Frog Games
A Studio name is like a name for a Rock Band. It has to be memorable, decent, and a little confusing for other people. Like Bungie, or Vicarious Visions or Spyglass. Other times, it's just what you make - like Team Ninja or Sonic Team. (Of course, I would pay decent money for something by Sonic Ninja Team).
Then there are the rest, which like Rock Bands, have a wide variety of names and so on. I thought that I had one figured out years ago - "Energy Games." Then I turned 14 and realized that was pretentious. So I started thinking about others. Icarus Studios was in the lead for a while - then I found that they are an outfit in North Carolina making a MMORPG (pronounced "Ma-MOR-PA-GAH) and are clearly much better funded than myself. Although I do think that my logo for Icarus Studios was way better.
So I came along to trying to think about what I'm trying to do. So I came up with RetroGrade - with the silly Capitalizaion that I like. The thinking went that my games are "Retro" in their mechanics, and the "Grade" bit implied that they were a high quality - like old games are perceived to be. I was really happy since I though it was clever, like the One-Ders. But I couldn't get over the fact that it sounded so similar. Then I realized that Retro Studios -already existed. This took the wind right out of my sails.
Anyway, the one that I felt was good recently was Clockwork Games. Then I did a Google search (because everything worth knowing can be found in Google) and found that, not only was that name taken by another studio, but they have 4 published titles already. So that kind of sucks.
Now, I'm back to one of the first names, which is so random (like Ninja Bee) as to not be taken by anybody since it makes no sense. The name of the Studio is now Star Frog Studios / Star Frog Games. There I said it, and I published it on 8-20-08 and now I own it.
-Check the first thing. I'm sure that if Team Ninja and Sonic Team had a baby - the game would suck. Like, a lot. I shudder thinking about the furry gibs and the enormous animal breasts - with physics. *shudder*
Then there are the rest, which like Rock Bands, have a wide variety of names and so on. I thought that I had one figured out years ago - "Energy Games." Then I turned 14 and realized that was pretentious. So I started thinking about others. Icarus Studios was in the lead for a while - then I found that they are an outfit in North Carolina making a MMORPG (pronounced "Ma-MOR-PA-GAH) and are clearly much better funded than myself. Although I do think that my logo for Icarus Studios was way better.
So I came along to trying to think about what I'm trying to do. So I came up with RetroGrade - with the silly Capitalizaion that I like. The thinking went that my games are "Retro" in their mechanics, and the "Grade" bit implied that they were a high quality - like old games are perceived to be. I was really happy since I though it was clever, like the One-Ders. But I couldn't get over the fact that it sounded so similar. Then I realized that Retro Studios -already existed. This took the wind right out of my sails.
Anyway, the one that I felt was good recently was Clockwork Games. Then I did a Google search (because everything worth knowing can be found in Google) and found that, not only was that name taken by another studio, but they have 4 published titles already. So that kind of sucks.
Now, I'm back to one of the first names, which is so random (like Ninja Bee) as to not be taken by anybody since it makes no sense. The name of the Studio is now Star Frog Studios / Star Frog Games. There I said it, and I published it on 8-20-08 and now I own it.
-Check the first thing. I'm sure that if Team Ninja and Sonic Team had a baby - the game would suck. Like, a lot. I shudder thinking about the furry gibs and the enormous animal breasts - with physics. *shudder*
Sunday, August 17, 2008
Testing Take 2
Today I managed to finish off both the current Prison level, install the Scripting again (which is really a joy to use - no sarcasm) and draw out the next section. So it was productive. Then I got my tester to go ahead and have a look at the new level. I'm pleased to say that the levels went much better than before and she was able to get the whole way through. Even when she got to the new ledges that I installed it went quite good. There were only 2 complaints and they are both control issues, which I'm happy to fix. They go like this:
1) The Double Jump with the UP arrow seems to confuse and annoy. On the one hand, I know that you can get used to it - since I am. But the whole point of having testers is to get feedback on something that pisses off. Controls are like rocks. What you really want are nice, smooth rocks that you can hold for a good long time without discomfort. You do not want jagged rocks that never quite feel comfortable. Metroid Prime had jagged rock controls. Granted, you eventually get used to them, but their never really second nature and really smooth - like say Halo's controls. So, I'm thinking about using putting the Double Jump move on the same button. My idea is this - When you press the Jump key, it will start a small timer. If you press the button again while this is running, it will ignore the press - so you don't mash the key a bunch of times. If you press it after the timer, then it will double jump you. Not sure about why I didn't think of this before, but it should work and I'll give it a try tomorrow.
2) The Wall Grab is too "sticky." This one is weird. (why is it when I spell "weird" it always looks misspelled?) When you jump at the wall, it detects your position and your current state. It was set to "When you touch this and you are Jumping or Dashing." Now, it detects to see if you are Dashing, or if you are at a certain point in the jump. Before, if you stood right next to the wall, Zero would stick right to the wall and soon as he left the ground. This of course, sucked when you are trying to jump on top of something. So now it works better now, although I did have an issue with the order. Basically, I wanted to say, "If your are Jumping, and the jump is at a certain point, Or if you are dashing." This didn't work for some reason, and the Aerial Dash just wouldn't do it. Then I realized that the, "If your are Jumping, and the jump is at a certain point," line is redundant, since if the Jump is at a certain point, you are clearly jumping already.
On a side note , I noticed that the HUD goes away when talky bits appear, which I find nice.
What I find less nice is that the HUD is ugly and sometimes overlaps the play area in ways that I don't like. I'll figure something else out. Maybe by putting info on the character - but I hate that. It's all the rage now to have a HUD-less screen. This, of course, is distasteful if you have a little screen. What? A goddamn life bar is too much to ask? So I don't think that I'll be going in that direction.
-Okay. So I went ahead and got the Double Jump thing going, but it's a little dumb. What I want is for the flip to happen after you have already jumped and what happens is nothing. The jump goes, but then mash the key as you might, it ignores the rest of the of the commands...
-Got it. It turns out that it doesn't like to have to deal with multiple uses of the same KeyHit in the same frame. In other words, it gets to the second one, and thinks, "Nope, nothing new here. Move along." So it would skip the rest, then it would come around to the first reference again and get all confused and crap. So, I made a modification and it only reference the bloody key once and checks to see what is going on. So now Zero double jumps like a champ using the same key. I had no idea how crap the Up arrow for a double jump was until I didn't have to do it any more. So that's, well, nice.
- I know I shouldn't, but there were just too many uses of the italics in this post. Oh well. It seems too many things required sarcastic emphasis.
1) The Double Jump with the UP arrow seems to confuse and annoy. On the one hand, I know that you can get used to it - since I am. But the whole point of having testers is to get feedback on something that pisses off. Controls are like rocks. What you really want are nice, smooth rocks that you can hold for a good long time without discomfort. You do not want jagged rocks that never quite feel comfortable. Metroid Prime had jagged rock controls. Granted, you eventually get used to them, but their never really second nature and really smooth - like say Halo's controls. So, I'm thinking about using putting the Double Jump move on the same button. My idea is this - When you press the Jump key, it will start a small timer. If you press the button again while this is running, it will ignore the press - so you don't mash the key a bunch of times. If you press it after the timer, then it will double jump you. Not sure about why I didn't think of this before, but it should work and I'll give it a try tomorrow.
2) The Wall Grab is too "sticky." This one is weird. (why is it when I spell "weird" it always looks misspelled?) When you jump at the wall, it detects your position and your current state. It was set to "When you touch this and you are Jumping or Dashing." Now, it detects to see if you are Dashing, or if you are at a certain point in the jump. Before, if you stood right next to the wall, Zero would stick right to the wall and soon as he left the ground. This of course, sucked when you are trying to jump on top of something. So now it works better now, although I did have an issue with the order. Basically, I wanted to say, "If your are Jumping, and the jump is at a certain point, Or if you are dashing." This didn't work for some reason, and the Aerial Dash just wouldn't do it. Then I realized that the, "If your are Jumping, and the jump is at a certain point," line is redundant, since if the Jump is at a certain point, you are clearly jumping already.
On a side note , I noticed that the HUD goes away when talky bits appear, which I find nice.
What I find less nice is that the HUD is ugly and sometimes overlaps the play area in ways that I don't like. I'll figure something else out. Maybe by putting info on the character - but I hate that. It's all the rage now to have a HUD-less screen. This, of course, is distasteful if you have a little screen. What? A goddamn life bar is too much to ask? So I don't think that I'll be going in that direction.
-Okay. So I went ahead and got the Double Jump thing going, but it's a little dumb. What I want is for the flip to happen after you have already jumped and what happens is nothing. The jump goes, but then mash the key as you might, it ignores the rest of the of the commands...
-Got it. It turns out that it doesn't like to have to deal with multiple uses of the same KeyHit in the same frame. In other words, it gets to the second one, and thinks, "Nope, nothing new here. Move along." So it would skip the rest, then it would come around to the first reference again and get all confused and crap. So, I made a modification and it only reference the bloody key once and checks to see what is going on. So now Zero double jumps like a champ using the same key. I had no idea how crap the Up arrow for a double jump was until I didn't have to do it any more. So that's, well, nice.
- I know I shouldn't, but there were just too many uses of the italics in this post. Oh well. It seems too many things required sarcastic emphasis.
Thursday, August 14, 2008
Dashes and FPS
Today I went ahead and finished making the opening level playable. It is still lacking the scripting, but I have high hopes that these levels work well enough to go gold with little additional reconfiguring. Granted, I thought that last time, but now I really think that it's good. I still have a Milestone of trying to get the levels all plotted by the end of the month, and I think I'm a little behind, but still on track.
I also started playing around with an idea that I had. While watching the wife test the last set of levels, I noticed that she really liked the Dash move, and used it exclusively, since she never got a hang of the Flip. What occurred to me was that the recharging Dash Bar - that let's you know when you can Dash - is all the way up in the corner. Now I know what the Dash is, and I tend to spam the Flip move, since I prefer it. So when I think about needing to Dash, I just do since the bar is always filled and I don't think about it. However, for people that may prefer to Dash, or for later levels where you have to Flip and Aerial Dash on command with precision, I realized that they can't be looking up at the bar all the time, that's not what it is there for. Instead, I needed something on the character, some kind of particle or something, that would let the player know that it was good to go. So now, there is a little ring that swells quickly and a cute (subtle) noise that plays when the Bar is full again. Just so the player knows that everything is ducky with the Dash. A picture is included.
I also started playing around with an idea that I had. While watching the wife test the last set of levels, I noticed that she really liked the Dash move, and used it exclusively, since she never got a hang of the Flip. What occurred to me was that the recharging Dash Bar - that let's you know when you can Dash - is all the way up in the corner. Now I know what the Dash is, and I tend to spam the Flip move, since I prefer it. So when I think about needing to Dash, I just do since the bar is always filled and I don't think about it. However, for people that may prefer to Dash, or for later levels where you have to Flip and Aerial Dash on command with precision, I realized that they can't be looking up at the bar all the time, that's not what it is there for. Instead, I needed something on the character, some kind of particle or something, that would let the player know that it was good to go. So now, there is a little ring that swells quickly and a cute (subtle) noise that plays when the Bar is full again. Just so the player knows that everything is ducky with the Dash. A picture is included.
Sunday, August 10, 2008
Testing Despondency
I've heard that to be a good game designer, you have to be able to look at work that was done and then throw it all out. Still, it doesn't make it feel any better when you actually have to do it. The images listed at the right (--->) are all pieces that I built with the intention of teaching the player how to do things. Yesterday I even began to do some scripting using a little scriplet of code that I had written previously. It was all going well. The levels - or so I thought - were well put together and they use new abilities one at a time to help the player come to grips with the abilities and move on. The screens were designed to do just that and, I thought, were doing just that.
- That was how it was supposed to work anyway. I let a tester look at it and give it a play. This tester of course being my lovely wife Jessie (who I'll put in the credits now). She knows how to play games reasonably well, and I felt that she would be a good case for the opening tutorial styled level. So she goes plays for a little bit, and she does 2 things I wasn't expecting.
First of all, she messes around with the controls and manages to figure out the Dash earlier than expected. That was nice I found, since she never quite got a handle on the Double Jump as she never got that far. Since she was using moves the levels weren't designed for, she of course did them in ways that I wholly unanticipated. So that was really good I think. It was some of that emergent gameplay that I find so nice. I mean, I figure out a level, and plot out how to finish it, but other people clearly find other ways to do it, that work just as well. That's really nice and great.
The second is that she managed to break the game on no more than 2 separate occasions. I mean, she found bugs that I hadn't run into, since she did the levels in ways that I didn't think you could do them. But, I suppose that's a good thing.
-So back on the first point again. I realized early on, that the players would find out how to use the different moves if I do something about them or not. I mean, I could lock the moves down until you get to that tutorial, but that would piss people off I think. What I need to do, is introduce them earlier with a full tutorial, so the player knows what they are and what to do with them. This of course means that I throw out the levels and restart them. This is what I am doing now. I suppose it's for the best, as I went in all cavalier thinking that I was the God of Level Design (chilli) incarnate and my first levels in my first project would be a gift from god. In the long run, I think the new levels will be better and the game will be better for it.
Of course, I'm not totally throwing them all out. Some of the designs are pretty decent overall and work well. But they tend to be in the wrong orders and I want to cover things in a certain - new order. The Old Tutorial Order was:
Jump(climb), Fight, Double Jump, Dash
The New Order needs to be:
All of the movement stuff - Jump(Climb), Double Jump, Dash, Fight.
Putting the Fighting at the end allows me to really focus on that bit first. Since the Fighting is an important bit in the game. After all, the levels are completed by Fighting (well, except for one that I have plotted) a boss. I even figured out in the Script the full Tutorial for the Fighting. So in terms of the order, I need to put that in a spot where I can really bring it forward. The movement needs to come first, and the player needs to be able to experiment with all of the movement at once. Then they need to learn to fight. I mean, for real. Otherwise every guard will be a nuisance and they'll have nightmares about the Knights. I really want the player to be able to fight and be challenged, but I do want them to win in the end. So, in the long term, to do that I need to restructure the levels.
- That was how it was supposed to work anyway. I let a tester look at it and give it a play. This tester of course being my lovely wife Jessie (who I'll put in the credits now). She knows how to play games reasonably well, and I felt that she would be a good case for the opening tutorial styled level. So she goes plays for a little bit, and she does 2 things I wasn't expecting.
First of all, she messes around with the controls and manages to figure out the Dash earlier than expected. That was nice I found, since she never quite got a handle on the Double Jump as she never got that far. Since she was using moves the levels weren't designed for, she of course did them in ways that I wholly unanticipated. So that was really good I think. It was some of that emergent gameplay that I find so nice. I mean, I figure out a level, and plot out how to finish it, but other people clearly find other ways to do it, that work just as well. That's really nice and great.
The second is that she managed to break the game on no more than 2 separate occasions. I mean, she found bugs that I hadn't run into, since she did the levels in ways that I didn't think you could do them. But, I suppose that's a good thing.
-So back on the first point again. I realized early on, that the players would find out how to use the different moves if I do something about them or not. I mean, I could lock the moves down until you get to that tutorial, but that would piss people off I think. What I need to do, is introduce them earlier with a full tutorial, so the player knows what they are and what to do with them. This of course means that I throw out the levels and restart them. This is what I am doing now. I suppose it's for the best, as I went in all cavalier thinking that I was the God of Level Design (chilli) incarnate and my first levels in my first project would be a gift from god. In the long run, I think the new levels will be better and the game will be better for it.
Of course, I'm not totally throwing them all out. Some of the designs are pretty decent overall and work well. But they tend to be in the wrong orders and I want to cover things in a certain - new order. The Old Tutorial Order was:
Jump(climb), Fight, Double Jump, Dash
The New Order needs to be:
All of the movement stuff - Jump(Climb), Double Jump, Dash, Fight.
Putting the Fighting at the end allows me to really focus on that bit first. Since the Fighting is an important bit in the game. After all, the levels are completed by Fighting (well, except for one that I have plotted) a boss. I even figured out in the Script the full Tutorial for the Fighting. So in terms of the order, I need to put that in a spot where I can really bring it forward. The movement needs to come first, and the player needs to be able to experiment with all of the movement at once. Then they need to learn to fight. I mean, for real. Otherwise every guard will be a nuisance and they'll have nightmares about the Knights. I really want the player to be able to fight and be challenged, but I do want them to win in the end. So, in the long term, to do that I need to restructure the levels.
Wednesday, August 6, 2008
Egads
This has nothing to do with anything, but just clicked on my little "View Profile" button at the right, next to the S'Bear picture. The thing has been viewed 13 times (as of right now). When I consider that I've only looked at it like, 3 times (once when I registered, once now and once again to see if the system is smart enough to look for unique IPs - which it isn't) that means that upwards of 10 people not only read my rambling nonsense, but were actually curious as to who I am!
If you are visiting CID for the first time : Welcome! Bookmarks and all that. I update all the time. Please, post a comment. You don't even have to register or anything. The archive of stuff is at the right, just below the pictures.
>D
If you are visiting CID for the first time : Welcome! Bookmarks and all that. I update all the time. Please, post a comment. You don't even have to register or anything. The archive of stuff is at the right, just below the pictures.
>D
Braids and Doing Your Own Thing
Recently I read an article on Gamasutra (the best place for game stuff ever) on Braid - a platforming game that had been entered in the IGF last year and won some awards. The article was about the art specifically and how it was created. Of special note was the fact that the artist did some tests for what it would look like by drawing over the level, and his results were pretty good. Notwithstanding, I thought that it would be prudent to play a little of a competitor's (peer's?) product, so I got me the demo. First of all, I have to say that I am not impressed. The art is wonderful, it even has the cute rewindy POP style gimmick where you can undo your errors. It immediately reminded me of Sands of Time, and not in a good way.
In Braid, you jump around wonderfully rendered backdrops and the emphasis is on puzzle platforming. The design is simple - you jump on enemies, you have a button to pull switches and stuff and you have a stolen rewind ability. The game forces you to find ways to collect puzzle pieces. Oddly, I found that the goal of trying to collect these was worthwhile and I think the best part of the design. It was the only part of made me want to go collect the chotchkie puzzle pieces strewn about, since I used them to put together a puzzle. Of course, if you don't have all of the pieces it drives you nuts and makes you want to find them.
However, (and this gave me bad Sands memories) the platforming design wrapped around these ideas is lacking. In Sands you have a rewind mechanic, but the game is not based on it - it is based on sound platforming design. In fact, the last level of Sands forces you to play the last level without rewind ability and really puts the platforming up front. In Braid, the platforming just isn't there. There is no, substance. I'm not sure if they were trying to put the rewind and time abilities up front by making the platforming a secondary function, but that is the gameplay. Without it, it is a cute tech demo with outstanding art.
Oh, and so as to not totally crap on the game, the story, such that it was, was touching and gave me another reason to want to play the game...but it only goes so far.
Oh, and the "Princess is in another castle" thing was really cute. No seriously, I liked that.
- On doing your own thing, it occurred to me that my game has only a few basic gameplay elements, and I'm okay with that. You run, jump, dash and fight. You also press the Ctrl key when people are talking. You can even not read if you don't want to. But here's the thing - as the Designer it's exactly like I want it. Sure, the placeholder animation leaves a little to be desired, but the game is simple by design. Each piece constructed so as to provide the maximum enjoyment of itself. I could install a combo system, or something with super flashy effects and all that, but I don't want to, because they would just be more for the sake of more. If I cannot have something in a game and give the mechanic a chance to not only be the focus, but to interact with the rest of the pieces in a way that makes the whole better, then I do not need it. Those may just be good ideas that just don't fit.
Also, to hell with what anybody else says. "You need guns, " "The Thief is a jerk." "Your people talk too damn much." "The jumping isn't far enough." Blah blah blah. The only comment that should ever get any leeway with you (I'm assuming you are a designer too) is, "I am confused. I don't know..." followed by, "Where to go next," "How to do this," or "What I am supposed to be doing." Those are not the fault of brain dead players - those are your fault.
- So as to not poke holes and then call myself all mighty, this seems to be what happened with Braid. Admittedly, there are design choices that I would not have gone with, but the project was clearly the result of people that had a clear view of what they wanted exactly and their game is the result of that. In that, I salute them.
-In game stuff, I made a small adjustment to the falling code. Before, the "Falling to your death " thing only worked if you were actually in the "Falling" state. This became a little weird though since you could fall a short distance and hurt yourself, but jump a surprising distance and be fine. So now the code is a little different so you can jump or fall and still accumulate velocity at the ground, which in turn figures if the fall killed you. I also tweaked the code a little to good effect. Now, the Stun effect is less and the Kill effect is a little more (so the levels I made before still work). This has a different effect on gameplay. Basically, early on it gives the impression that your little guy is fragile. The falls don't deal damage - they did and I found that to be stupid, but they do let the player know that, "Hey, The Thief is cool and all, but nobody survives a 4 story drop. Be careful." So it teaches before it tests. So, yes, the little guy looks hurt when you do that, imagine what happens if you drop him really far.
-In another thing, I seemed to have broken the Enemies somehow when I fixed the leak. Now they continue to attack no matter what. Their attack systems aren't resetting correctly. Hmmm.
-Wow, that was an easy fix. Still no leaks too. May actually get a level built today.
-Okay, got more of the Prison Level built today. I'm finding that giving the player enough opportunities to learn the abilities and get a handle on them before I throw more at them to be a challenge. Mostly since the first half of the level is all Prison and mostly done. Granted, I could just add more, and I may, but I am concerned about the flow of the game so far. By flow I mean, teaching, testing, stress testing and giving a rest. The Rest turns out to be very difficult. Too much and you're bored, too little and your anxiety level increases. It gives a, "Another puzzle? So soon?" kind of feeling. So getting all of that in the first level has been an issue so far. On the other hand, I am finding building the levels to be quite a treat.
-When ThiefEd works. Found a bug where it would erase my 1st rectangle. Not a huge issue, but the 1st is most often been the floor, so that had to go. All better now. I'll get some pictures up later. Right now it's 11:00 PM and I want to go to bed (up till 1:00AM last night with the leak. I did mention I hate leaks, right?)
In Braid, you jump around wonderfully rendered backdrops and the emphasis is on puzzle platforming. The design is simple - you jump on enemies, you have a button to pull switches and stuff and you have a stolen rewind ability. The game forces you to find ways to collect puzzle pieces. Oddly, I found that the goal of trying to collect these was worthwhile and I think the best part of the design. It was the only part of made me want to go collect the chotchkie puzzle pieces strewn about, since I used them to put together a puzzle. Of course, if you don't have all of the pieces it drives you nuts and makes you want to find them.
However, (and this gave me bad Sands memories) the platforming design wrapped around these ideas is lacking. In Sands you have a rewind mechanic, but the game is not based on it - it is based on sound platforming design. In fact, the last level of Sands forces you to play the last level without rewind ability and really puts the platforming up front. In Braid, the platforming just isn't there. There is no, substance. I'm not sure if they were trying to put the rewind and time abilities up front by making the platforming a secondary function, but that is the gameplay. Without it, it is a cute tech demo with outstanding art.
Oh, and so as to not totally crap on the game, the story, such that it was, was touching and gave me another reason to want to play the game...but it only goes so far.
Oh, and the "Princess is in another castle" thing was really cute. No seriously, I liked that.
- On doing your own thing, it occurred to me that my game has only a few basic gameplay elements, and I'm okay with that. You run, jump, dash and fight. You also press the Ctrl key when people are talking. You can even not read if you don't want to. But here's the thing - as the Designer it's exactly like I want it. Sure, the placeholder animation leaves a little to be desired, but the game is simple by design. Each piece constructed so as to provide the maximum enjoyment of itself. I could install a combo system, or something with super flashy effects and all that, but I don't want to, because they would just be more for the sake of more. If I cannot have something in a game and give the mechanic a chance to not only be the focus, but to interact with the rest of the pieces in a way that makes the whole better, then I do not need it. Those may just be good ideas that just don't fit.
Also, to hell with what anybody else says. "You need guns, " "The Thief is a jerk." "Your people talk too damn much." "The jumping isn't far enough." Blah blah blah. The only comment that should ever get any leeway with you (I'm assuming you are a designer too) is, "I am confused. I don't know..." followed by, "Where to go next," "How to do this," or "What I am supposed to be doing." Those are not the fault of brain dead players - those are your fault.
- So as to not poke holes and then call myself all mighty, this seems to be what happened with Braid. Admittedly, there are design choices that I would not have gone with, but the project was clearly the result of people that had a clear view of what they wanted exactly and their game is the result of that. In that, I salute them.
-In game stuff, I made a small adjustment to the falling code. Before, the "Falling to your death " thing only worked if you were actually in the "Falling" state. This became a little weird though since you could fall a short distance and hurt yourself, but jump a surprising distance and be fine. So now the code is a little different so you can jump or fall and still accumulate velocity at the ground, which in turn figures if the fall killed you. I also tweaked the code a little to good effect. Now, the Stun effect is less and the Kill effect is a little more (so the levels I made before still work). This has a different effect on gameplay. Basically, early on it gives the impression that your little guy is fragile. The falls don't deal damage - they did and I found that to be stupid, but they do let the player know that, "Hey, The Thief is cool and all, but nobody survives a 4 story drop. Be careful." So it teaches before it tests. So, yes, the little guy looks hurt when you do that, imagine what happens if you drop him really far.
-In another thing, I seemed to have broken the Enemies somehow when I fixed the leak. Now they continue to attack no matter what. Their attack systems aren't resetting correctly. Hmmm.
-Wow, that was an easy fix. Still no leaks too. May actually get a level built today.
-Okay, got more of the Prison Level built today. I'm finding that giving the player enough opportunities to learn the abilities and get a handle on them before I throw more at them to be a challenge. Mostly since the first half of the level is all Prison and mostly done. Granted, I could just add more, and I may, but I am concerned about the flow of the game so far. By flow I mean, teaching, testing, stress testing and giving a rest. The Rest turns out to be very difficult. Too much and you're bored, too little and your anxiety level increases. It gives a, "Another puzzle? So soon?" kind of feeling. So getting all of that in the first level has been an issue so far. On the other hand, I am finding building the levels to be quite a treat.
-When ThiefEd works. Found a bug where it would erase my 1st rectangle. Not a huge issue, but the 1st is most often been the floor, so that had to go. All better now. I'll get some pictures up later. Right now it's 11:00 PM and I want to go to bed (up till 1:00AM last night with the leak. I did mention I hate leaks, right?)
Tuesday, August 5, 2008
Pampers man, Pampers
So I've decided that I hate memory leaks. I hate 'em. I hate them like Indy hates snakes. This hate stems from a cute coincidence. I had the foresight of making ThiefEd and the Engine pull from the same information, just so long as it is saved. The pictures are all the same and the collision bits are all the same. So when I make a change in ThiefEd and save it, it shows up in the Engine as soon as I walk off screen and come back. This, combined with the cute window trick I learned, made it quite easy to play with the Editor and the game and really help make each screen a little nicer to play.
Everything was ducky, but the Engine would start to get slower and slower. Eventually it would make the rest of the computer go slow too. So I had to pull the plug and take a hit of the CAD (not the comic. I find the comic boring. I'm talking about the Key Command - which I find thrilling.) and like I try to do, have a look at the processes. So there was the Engine. It was eating 245000 kB, or 250 MB or a quarter of a GIG of my Ram. In effect, the Engine had somehow managed to eat no less than 1/2 of all of the memory in my laptop - in about 7 minutes. Clearly, steps had to be taken.
A test was in order. So, I went into the code and put little breaks in with little commands to let me know where the break was. Then I fired up the CAD menu (I don't think that's what it is really called, but I don't care) and watched the memory usage. Once it hopped up, I checked the last break that I let run and went to stare at it.
By the way, watching the screen build itself in pieces is kinda cool.
Anyhow, the issue was with my enemy Streaming technique. You see, I had this idea - I was going to use the same variables for all of the enemy crap. Their attacks animations would all have a standard call and they would be set by the enemy type and the frame of the attack, and they would be loaded right before I needed them. I was really trying to avoid having lots and lots of specific variables, like I have for Zero. Each of his little frames has a variable handle and is loaded when the program starts. I had considered doing a similar stream for him, but after this - forget it. Either way, the system worked, but it seemed that every time any of the enemy animations was streamed, it would copy the whole thing to memory in a brand new place and forget about the last one. Mind you, it didn't remove the information, it just forgot that it left it there. This of course makes it impossible for the computer to use. The computer looks at that and says to itself, "Hmm, something's using this. Well, guess I'll go use different memory." Or to put it another way. It's like I have a field for picnics, and I tell Robo - the Super Robo Computer - to go put a blanket someplace. Then I tell it, "You know what, how about we put a different color down instead?" Then Robo finds a different color blanket and puts it down without picking up the first one. Generally, not a problem. It's a big field after all and can have lots and lots of blankets. When you make the same mistake a couple thousand times, you can't see the grass anymore.
But wait, there's more! I couldn't just tell the thing to erase them as soon as I drew them of course, since I had referenced them in other stuff too. If I deleted it, then the program would get confused. "Hey Robo," I say, "go pick up that blanket and eat it. Great." "Hey Robo," I continue, "what color and how big is the blanket?" "What blanket?" Robo replies. I by 'replies' I mean 'crashes', and by Robo I mean the Program.
So, like I said before. I hate memory leaks. I hate 'em.
Which brings me to my next point - Pampers. "Pampers" is a n3rd term that I'm going to try and popularize. It is used thusly: "Yeah, debugged that. Now the code is totally Pampers." or "I feel a lot safer knowing this submarine is Pampers." It means, that there are no leaks. No leaks is good.
***After 6 hours, my Engine is now Pampers***
Even better. When it idles with Zero just standing around, it cleans itself up and begins to use less memory. So:
```O````O```
\_________/
-Oh, and one more thing. I still don't come up on Yahoo search when I type in "Confessions of an Indie Developer." Not that I care all that much - since this is the Diary That Nobody Reads, but I do like to be able to find my own crap. So from here on out, Yahoo is dead to me. Yeah, I said it.
-On a side note, I'm 3rd now when I look for Indie Confessions or "Confessions of an Indie Developer" (with or without quotes) on Google. To celebrate this achievement, I've added another clicky box for adverts. Then took it down because it was tacky.
Everything was ducky, but the Engine would start to get slower and slower. Eventually it would make the rest of the computer go slow too. So I had to pull the plug and take a hit of the CAD (not the comic. I find the comic boring. I'm talking about the Key Command - which I find thrilling.) and like I try to do, have a look at the processes. So there was the Engine. It was eating 245000 kB, or 250 MB or a quarter of a GIG of my Ram. In effect, the Engine had somehow managed to eat no less than 1/2 of all of the memory in my laptop - in about 7 minutes. Clearly, steps had to be taken.
A test was in order. So, I went into the code and put little breaks in with little commands to let me know where the break was. Then I fired up the CAD menu (I don't think that's what it is really called, but I don't care) and watched the memory usage. Once it hopped up, I checked the last break that I let run and went to stare at it.
By the way, watching the screen build itself in pieces is kinda cool.
Anyhow, the issue was with my enemy Streaming technique. You see, I had this idea - I was going to use the same variables for all of the enemy crap. Their attacks animations would all have a standard call and they would be set by the enemy type and the frame of the attack, and they would be loaded right before I needed them. I was really trying to avoid having lots and lots of specific variables, like I have for Zero. Each of his little frames has a variable handle and is loaded when the program starts. I had considered doing a similar stream for him, but after this - forget it. Either way, the system worked, but it seemed that every time any of the enemy animations was streamed, it would copy the whole thing to memory in a brand new place and forget about the last one. Mind you, it didn't remove the information, it just forgot that it left it there. This of course makes it impossible for the computer to use. The computer looks at that and says to itself, "Hmm, something's using this. Well, guess I'll go use different memory." Or to put it another way. It's like I have a field for picnics, and I tell Robo - the Super Robo Computer - to go put a blanket someplace. Then I tell it, "You know what, how about we put a different color down instead?" Then Robo finds a different color blanket and puts it down without picking up the first one. Generally, not a problem. It's a big field after all and can have lots and lots of blankets. When you make the same mistake a couple thousand times, you can't see the grass anymore.
But wait, there's more! I couldn't just tell the thing to erase them as soon as I drew them of course, since I had referenced them in other stuff too. If I deleted it, then the program would get confused. "Hey Robo," I say, "go pick up that blanket and eat it. Great." "Hey Robo," I continue, "what color and how big is the blanket?" "What blanket?" Robo replies. I by 'replies' I mean 'crashes', and by Robo I mean the Program.
So, like I said before. I hate memory leaks. I hate 'em.
Which brings me to my next point - Pampers. "Pampers" is a n3rd term that I'm going to try and popularize. It is used thusly: "Yeah, debugged that. Now the code is totally Pampers." or "I feel a lot safer knowing this submarine is Pampers." It means, that there are no leaks. No leaks is good.
***After 6 hours, my Engine is now Pampers***
Even better. When it idles with Zero just standing around, it cleans itself up and begins to use less memory. So:
```O````O```
\_________/
-Oh, and one more thing. I still don't come up on Yahoo search when I type in "Confessions of an Indie Developer." Not that I care all that much - since this is the Diary That Nobody Reads, but I do like to be able to find my own crap. So from here on out, Yahoo is dead to me. Yeah, I said it.
-On a side note, I'm 3rd now when I look for Indie Confessions or "Confessions of an Indie Developer" (with or without quotes) on Google. To celebrate this achievement, I've added another clicky box for adverts. Then took it down because it was tacky.
Monday, August 4, 2008
On the subject of Windows windows.
-I discovered something today. Now my programs can run in a window! How cool is that? No more of the opening up in full screen whether I want them to or not. So, that's nice in lots of directions.
I had a thought earlier today. I noticed that I was smiling, and it was a Monday. It took me a moment to figure out why I was so contented and I realized what it was - I was doing the job that I wanted and it is everything that I thought it would be. Let me explain, as some people have some half baked notion of what it means to be a Game Developer, let alone what a Designer does exactly. I always thought that making games are hard. Not because the ideas are hard, because they're not (heck, I discard a few dozen a day. Not that they aren't good, they're just not right). It's hard because of the commitment.
I'll explain further. On the one hand, when you do something that you don't care about, or at least, when you're doing it for somebody else, there is a level of commitment there, which is to say - very little. Well, in the grand scheme of things. For this, and for games in general with very talented and committed people, you're also making it for you. This is the key distinction. On the one hand, it is very important that you take pride in your work (else it drives you to depression), but , when you're doing it for yourself it becomes something totally more important and much more difficult. It become hard to say, "Good Enough" because you do want it to be just a little better. After all, I'm not doing this to impress somebody somewhere, I am doing it for me.
So, I can't bullshit myself and say stuff like, "No, that's really as good as it can be," because I know that's bullshit and I know that I can make it better. Long story short, living up to your own expectations is the hardest thing to do. If you have low expectations of yourself, then why bother in the first place?
Anyway, in spite of the late hours and coding and just now seeing some results, I really like this time that I have. Clark Kent goes to work, but at 5:00PM (or during work if he can sneak it) he's Superman. That's what I feel like. By day, I'm mild mannered Eric the Graphic Designer, and by night, I morph into Eric - Game Developer Extraordinaire! This of course is flawless for the guy that always wanted to be just that kind of superhero. If nothing else, this time, right now as I type these words and send them into the internet, this is the time that I will always look back on as my first game that I,I created from nothingness. It reminds me of a quote in Jurassic Park, the old guy that built the place (his name escapes me) said, "Creation is an act of sheer will."
I had a thought earlier today. I noticed that I was smiling, and it was a Monday. It took me a moment to figure out why I was so contented and I realized what it was - I was doing the job that I wanted and it is everything that I thought it would be. Let me explain, as some people have some half baked notion of what it means to be a Game Developer, let alone what a Designer does exactly. I always thought that making games are hard. Not because the ideas are hard, because they're not (heck, I discard a few dozen a day. Not that they aren't good, they're just not right). It's hard because of the commitment.
I'll explain further. On the one hand, when you do something that you don't care about, or at least, when you're doing it for somebody else, there is a level of commitment there, which is to say - very little. Well, in the grand scheme of things. For this, and for games in general with very talented and committed people, you're also making it for you. This is the key distinction. On the one hand, it is very important that you take pride in your work (else it drives you to depression), but , when you're doing it for yourself it becomes something totally more important and much more difficult. It become hard to say, "Good Enough" because you do want it to be just a little better. After all, I'm not doing this to impress somebody somewhere, I am doing it for me.
So, I can't bullshit myself and say stuff like, "No, that's really as good as it can be," because I know that's bullshit and I know that I can make it better. Long story short, living up to your own expectations is the hardest thing to do. If you have low expectations of yourself, then why bother in the first place?
Anyway, in spite of the late hours and coding and just now seeing some results, I really like this time that I have. Clark Kent goes to work, but at 5:00PM (or during work if he can sneak it) he's Superman. That's what I feel like. By day, I'm mild mannered Eric the Graphic Designer, and by night, I morph into Eric - Game Developer Extraordinaire! This of course is flawless for the guy that always wanted to be just that kind of superhero. If nothing else, this time, right now as I type these words and send them into the internet, this is the time that I will always look back on as my first game that I,I created from nothingness. It reminds me of a quote in Jurassic Park, the old guy that built the place (his name escapes me) said, "Creation is an act of sheer will."
Sunday, August 3, 2008
CheckPoint and the Corpse
I would like to point out that the title sounds like a bad 70's cartoon, but I won't. Today, I've been able to correct more of the nonsense that happened when I converted the Engine to recognize the stuff from the editor. So now the CheckPoint works. It seemed to be confused by the way I worded it, so I changed it and now it works. I noticed that CheckPoint thing only happens once on a page. Not once every frame, but only once total. So I changed the settings a little.
Also, funny thing. TheifEd seems to hate negative numbers. So, when I would set up the Enemies to have a -1 as their "Alive" state (1 is alive, 0 is dead and -1 is not even around to leave a corpse) the system would somehow convert my -1's to 0's. So now, if it loads a 0 it converts it automatically in this case.
This week I figured out a cute idea for the foregrounds, and have included images. Of course, these are crappy Programmer art (no offense to most programmers) and the background will be really nice in the near future. These are proof of concept.
Also, funny thing. TheifEd seems to hate negative numbers. So, when I would set up the Enemies to have a -1 as their "Alive" state (1 is alive, 0 is dead and -1 is not even around to leave a corpse) the system would somehow convert my -1's to 0's. So now, if it loads a 0 it converts it automatically in this case.
This week I figured out a cute idea for the foregrounds, and have included images. Of course, these are crappy Programmer art (no offense to most programmers) and the background will be really nice in the near future. These are proof of concept.
Saturday, August 2, 2008
Fluid
Controls are yummy. I was playing with the new bit I had built, and as part of the Miyamoto Theory (see New Plan) I was trying to make the levels work using only the Standard Jump (no Flip or Aerial Dashes) and the Climb ability (which is part of the collision system - so I can't turn it off). I ended up noticing that I had previously used the Flip all the time without realizing it. After all, just push Up while jumping and everything is cool. What that had prevented me from doing was catching a bug. The Jump would sometimes get confused and ignore the left and right commands. Considering this is a Platform Game, and being able to consistently jump in, um, a direction is probably one of the most important bits, this had to get killed ASAP. So after looking at it and tweaking it, I found that the issue was that it would think you were hanging on a wall, even when you aren't. I had previously set the system to ignore the left/right commands when jumping off of a wall, since it was doing a Super Jump - and adding the regular wall jumping distance to the pushing a direction distance. So, I fixed that and I discovered something - the game actually controls very, very well. Like, I can play it and not encounter a spot where the controls do something that I don't want them to. Which is good news all around.
-The CheckPoint system works again, sorta. Now it keeps track of the Checkpoint, but not the spot, and sometimes it kills you again because it is hateful.
-Enemies are broken, and I don't know why. When you get to an enemy, it works fine. The ThiefEd gives good info and the parameters are all where they are supposed to be. Then you fight and the Enemy Skill level that I set works. So, Yay. However, once I kill an enemy, it stays dead. Honestly, that's not the worse thing in the world, but the loading system isn't keeping up. So in effect, the game would have a single enemy. You would kill it, and then encounter a string of defeated enemies along the way, like if Solid Snake came in just before you got there. So that's the plan for tomorrow. Well, that and build some more levels. I do have a lot of work to do.
-Yes, that was a MGS2 joke. Deal with it.
-If that doesn't do it for you, replace the Solid Snake reference with a Master Chief reference. Happy?
-On other things, the artist thing is going well. I have 3 candidates and all of them are really talented and seem really interested in this little project. Since all of them are really quite good, I'm hoping that I can use all 3. The hope then would be the break the work up among them. Then they could each do 50 backgrounds each and the overall level of art would be better. I get the impression that each of them could do the whole thing, but the overall quality may suffer due to the sheer amount and lack of time. By splitting it up, then I hope that they'll be happier with their contribution and the game will be that much better for it.
-Speaking of art, here's my 2 cents on the whole "Are Games Art?" question. :
No, games are not art. But, they DO have art in them. I know, it's a cop out, but let me explain. People mention games and say that they, like good art, create emotion. Hence, they are art. I disagree on a basic level. For example, in Sands of Time you experience the story of the Prince, hear the music that paints the scene and look at the 3d models. So, when somebody says, "That game is art." they are wrong. The Game part of that is the platforming and sword fighting and by definition, it is in the control of the player. So the artist can give no specific meaning to the actions, since they do not have directorial control. However, the parts that they do have control over, the architecture, the music, the story and plot I argue can be considered art. The Game, is just a series of mechanics. They are the Laws that create the boundaries and the game space. In and of themselves, they are no more art than the canvas an artist uses to put paint on, or the rock that will become a sculpture.
To put it another way. Baseball is a game. The rules of which are simple. 9 innings, 3 outs, 4 bases. No one would ever consider the rules to be art. Rules are not art.
If we consider games to be the vehicle, then they still are not art. A museum is all full of art, much like I argue a game is. Inside the museum, exhibits are set up, art is categorized in some manner and someone sits down and works out a flow plan, to make sure that people walking through are likely to see most of it. However, the museum is not art (well, except for the Louvre - but Architecture is art - remember) since it is just the container for it.
Mind you. I am saying this as a Game Designer. I would love for games to be art, then I could call myself an Artist. But they aren't and I'm not. As Game Designer I am a Systems Engineer and my only goal is to make something fun. I have a lot of talented people that provide the art to look at.
-The CheckPoint system works again, sorta. Now it keeps track of the Checkpoint, but not the spot, and sometimes it kills you again because it is hateful.
-Enemies are broken, and I don't know why. When you get to an enemy, it works fine. The ThiefEd gives good info and the parameters are all where they are supposed to be. Then you fight and the Enemy Skill level that I set works. So, Yay. However, once I kill an enemy, it stays dead. Honestly, that's not the worse thing in the world, but the loading system isn't keeping up. So in effect, the game would have a single enemy. You would kill it, and then encounter a string of defeated enemies along the way, like if Solid Snake came in just before you got there. So that's the plan for tomorrow. Well, that and build some more levels. I do have a lot of work to do.
-Yes, that was a MGS2 joke. Deal with it.
-If that doesn't do it for you, replace the Solid Snake reference with a Master Chief reference. Happy?
-On other things, the artist thing is going well. I have 3 candidates and all of them are really talented and seem really interested in this little project. Since all of them are really quite good, I'm hoping that I can use all 3. The hope then would be the break the work up among them. Then they could each do 50 backgrounds each and the overall level of art would be better. I get the impression that each of them could do the whole thing, but the overall quality may suffer due to the sheer amount and lack of time. By splitting it up, then I hope that they'll be happier with their contribution and the game will be that much better for it.
-Speaking of art, here's my 2 cents on the whole "Are Games Art?" question. :
No, games are not art. But, they DO have art in them. I know, it's a cop out, but let me explain. People mention games and say that they, like good art, create emotion. Hence, they are art. I disagree on a basic level. For example, in Sands of Time you experience the story of the Prince, hear the music that paints the scene and look at the 3d models. So, when somebody says, "That game is art." they are wrong. The Game part of that is the platforming and sword fighting and by definition, it is in the control of the player. So the artist can give no specific meaning to the actions, since they do not have directorial control. However, the parts that they do have control over, the architecture, the music, the story and plot I argue can be considered art. The Game, is just a series of mechanics. They are the Laws that create the boundaries and the game space. In and of themselves, they are no more art than the canvas an artist uses to put paint on, or the rock that will become a sculpture.
To put it another way. Baseball is a game. The rules of which are simple. 9 innings, 3 outs, 4 bases. No one would ever consider the rules to be art. Rules are not art.
If we consider games to be the vehicle, then they still are not art. A museum is all full of art, much like I argue a game is. Inside the museum, exhibits are set up, art is categorized in some manner and someone sits down and works out a flow plan, to make sure that people walking through are likely to see most of it. However, the museum is not art (well, except for the Louvre - but Architecture is art - remember) since it is just the container for it.
Mind you. I am saying this as a Game Designer. I would love for games to be art, then I could call myself an Artist. But they aren't and I'm not. As Game Designer I am a Systems Engineer and my only goal is to make something fun. I have a lot of talented people that provide the art to look at.
Friday, August 1, 2008
Diesel
So I now have got the engine to recognize the save data files spit out by the editor. So, that's a positive. The bad part is that it seemed to break stuff. Like stupid stuff. In effect, I've built the engine to run on a certain kind of input - namely having all of the level information hard coded. Now, I'm telling it to run using a different input, with different attributes, and they telling it, "You'll like it. It's better for you, and the environment." So, like the title says, I put Diesel in it.
So, first issue first. After some tweaking I finally got the code to compile again. Then, it would load the level. Heck, even the Portal Rectangles on the edges would work when you touched them. If you managed to die (from a new bug probably) it would load nothing! Nothing at all. It would create a nothingness, and then drop you into it. At which point a safeguard built into the engine from way back before it worked well would give Zero the final mercy and kill him. Then it would again reload into a deep pit of despair, from which there is no escape.
So, killed that. Killed that HARD. Had to update the Check Point code a bit. So now, the Editor saves if the screen is a checkpoint or not as a 1 or 0. Now, in the Engine, when it loads it looks for that number and updates the Check point like a good little system.
Second, for some reason, the stupid climbing code stopped working too. I don't have any idea why it would do this, other than it is dumb. It worked fine previously. Now, it won't. I think i have to double check the Event Handling to be sure everything is going in the right order.
-For those at home that don't know what Event Handling is, I'll explain. When a computer does anything, it does it in a specific order - usually top to bottom (well, we'll think about it that way for the sake of simplicity). Individually, there are little bits of coded instructions that tell the computer what to do. An Event Handling bug occurs when the individual coded pieces are all working fine, but an error happens due to the order that the pieces are happening in. Sometimes they cancel, other times they amplify (I had the jump doing some really weird stuff once), but they are generally difficult to spot and fix. Since, the error isn't a single line, but often, the System itself. Here's my thought on these:
>(
-Woo hoo. All better now. I increased the amount of play the climbing gives, so it's a little better now. Also, found a weird bug. Seemed that, if you grab on something that is shorter than you with something below you, then it gets confused and kills you. Hmm...
-Nope. Still no go. It'll just be a known bug for now. In the future I'll have to try to avoid making small ledges.
So, first issue first. After some tweaking I finally got the code to compile again. Then, it would load the level. Heck, even the Portal Rectangles on the edges would work when you touched them. If you managed to die (from a new bug probably) it would load nothing! Nothing at all. It would create a nothingness, and then drop you into it. At which point a safeguard built into the engine from way back before it worked well would give Zero the final mercy and kill him. Then it would again reload into a deep pit of despair, from which there is no escape.
So, killed that. Killed that HARD. Had to update the Check Point code a bit. So now, the Editor saves if the screen is a checkpoint or not as a 1 or 0. Now, in the Engine, when it loads it looks for that number and updates the Check point like a good little system.
Second, for some reason, the stupid climbing code stopped working too. I don't have any idea why it would do this, other than it is dumb. It worked fine previously. Now, it won't. I think i have to double check the Event Handling to be sure everything is going in the right order.
-For those at home that don't know what Event Handling is, I'll explain. When a computer does anything, it does it in a specific order - usually top to bottom (well, we'll think about it that way for the sake of simplicity). Individually, there are little bits of coded instructions that tell the computer what to do. An Event Handling bug occurs when the individual coded pieces are all working fine, but an error happens due to the order that the pieces are happening in. Sometimes they cancel, other times they amplify (I had the jump doing some really weird stuff once), but they are generally difficult to spot and fix. Since, the error isn't a single line, but often, the System itself. Here's my thought on these:
>(
-Woo hoo. All better now. I increased the amount of play the climbing gives, so it's a little better now. Also, found a weird bug. Seemed that, if you grab on something that is shorter than you with something below you, then it gets confused and kills you. Hmm...
-Nope. Still no go. It'll just be a known bug for now. In the future I'll have to try to avoid making small ledges.
Subscribe to:
Posts (Atom)
