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
Wednesday, August 6, 2008
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)
