I was doing some thinking recently. I was thinking about my current job and how, in my free time on the side, my engagement in freelance writing - which by the way proves that my words have no value without context, but I digress. I got to thinking about the next project that I want to work on, The Star Frog EP, and how the real point of it is to create many games quickly. How I want to be able to do everything, without explicitly having to. But the freedom of it being the important bit.
My mind eventually wandered back into the XNA toolset, and queries about cross compatibility, and function libraries and rapid development. What I could leverage C# to do and what kinds of things I can do with it. These thoughts floated free about my head, like a thought bubble halo.
Then I considered the most dangerous thought of all, "Could I do this all the time?"
"No, that's crazy. XBLI games don't make that much. If I built one in a year the odds of me making enough to, well, not starve would be tiny to the point of being invisible. Weapon of Choice, critical darling that it was, proved that."
To which I considered, "Well, yeah, if I only built one in a year. What if I could go faster?"
Which is the dangerous thought really. I got to doing some math, and if I could make a game for XBLI, offer it up for $2 and sell a thousand of them I could avoid standing in the soup line with Oliver asking if I could have a little more. But that thousand has one big caveat, I'd need to manage doing all that in no less than a month and a half.
Assuming that I don't crunch and work myself like a beaten animal I'm looking at 40-50 hours per week, times an average of 5 weeks. So with 250 hours, could I build a game and make it happen? I mean, build an engine, do the programming, do the art, the music, the SFX and everything else that floats my way. Or do I need a team? Am I Garfunkel, or am I Sting?
Which got me back to the EP, where the whole point is to do a crazy minimalism. Lots of iteration and very quick production. From a cohesive whole standpoint, the EP is designed to give disparate works context. What I'm talking about here are one offs, not albums, but singles offered up piecemeal.
Further, since the games don't really ever get eaten (unless they're crap - but I'll toss crap with the ruthlessness of a Czar) any finished thing will provide some kind of revenue stream ad perpetuity, keeping the freezer stocked with Hot Pockets even while I toil.
Which led to the final piece of the puzzle, the question of how. How could I do that? Quit my job (wait...let me indulge in that daydream...and I'm done) and start writing a Design Document and Tech Blueprint? No, although there is a kind of rogue charm to the idea, I am an adult with adult responsibilites, like bills, rent and a sushi addiction that isn't cheap. What I need to do, like any great endeavor, is start slowly and build steam. I need to start on that next project and keep track of how long it takes to do, keep a timesheet maybe. It's possible that this is a fever dream with no grounding in my reality and I'll need facts to back me up.
So start building, start coding and start doing. Once I have a few games in the Box I can re-asess my position and move from there. Sitting and thinking about it only gets one so far.
-Ah right, what does this mean for TTT? Nothing. It doesn't mean a damn thing. You'll notice that over yonder => there are a large number of orange things and stuff still waiting for their own Orange Crush. What you won't notice are things that I can do that need it still, short of Gamepad compatibility (which I'll probably complete tomorrow). Instead, the Team continues along building content as they can. What they don't need is me standing around waiting for stuff to happen. So when I gets stuff, I'll lay it lovingly onto the framework that we have. In the meantime, I need to get back to work.
Wednesday, December 30, 2009
Monday, December 28, 2009
A Controlling Interest
I believe that I had previously mentioned that once I had a gamepad working it would be a "Rockstar Moment," and now that I'm looking at it, I'm let down. What I had thought should have taken me an hour or so, took me two last night and it still isn't done yet. The issue, the biggest one anyway, is that all the control code was clearly done using only my giant monkey feet. It's written poorly. It's like, the first thing I wrote for this project so many moons ago. It's not standardized, so the functions ask important questions like, "Are we pushing an arrow key?" then it goes ahead and makes the character run around. However, the Run() function then asks, "So what key are we pushing again?"
If I wrote it again today I would take a nice top down approach and ask the thing once what it's doing and then just let other stuff know. As it is, every single little instance has to be modified and checked to ensure that it isn't excluding anything or breaking something. Like there was a time where the character would only run if an arrow key was pressed and the stick on the XBox controller was pushed in the same direction. Now let's go ahead and solve that same problem a few dozen times.
Oh, right, and all the menus need fixin' too. Plus testing.
Right, talking about testing, The Tester doesn't own a wired XBox controller (considering that they aren't even made anymore, reasonable), so I can't strip out keyboard control. It needs to work with both inputs, and since I don't want to have two different builds it needs to do so simultaneously.
It's not all rage and hate though. Towards the end of the night, it started to work. I used a control pad and pushed the little buttons and used the little stick to make my little dude run about the screen. Sure it was broken, but my inner six year old cheered.
If I wrote it again today I would take a nice top down approach and ask the thing once what it's doing and then just let other stuff know. As it is, every single little instance has to be modified and checked to ensure that it isn't excluding anything or breaking something. Like there was a time where the character would only run if an arrow key was pressed and the stick on the XBox controller was pushed in the same direction. Now let's go ahead and solve that same problem a few dozen times.
Oh, right, and all the menus need fixin' too. Plus testing.
Right, talking about testing, The Tester doesn't own a wired XBox controller (considering that they aren't even made anymore, reasonable), so I can't strip out keyboard control. It needs to work with both inputs, and since I don't want to have two different builds it needs to do so simultaneously.
It's not all rage and hate though. Towards the end of the night, it started to work. I used a control pad and pushed the little buttons and used the little stick to make my little dude run about the screen. Sure it was broken, but my inner six year old cheered.
Thursday, December 17, 2009
Alchemist
It's that time of year again. The time after IGF where I have about zero stress and get to indulge my more esoteric wants and needs. So I thought I would put down, in some kind of concrete fashion, my thoughts on the basic tenets of Game Design.
You see, my basic field of reference is not that a Designer is a storyteller. They are not cinematic artists and they are certainly not doing anything that I would ever constitute as "art." I'm firmly in the "Games are Not Art" group, small and zealous as we may be.
No, the closest comparison that I can find for what a Game Designer should be, is a Systems Engineer. When the best games ever are boiled down to their most basic constituents, the things that make them intrinsically unique are the rules and systems at play. Think about it, take a game, any game really. Get rid of any story elements first, they're just candy. BioShock is known for having it's award winning story finalized at almost the last minute. Clearly it's a great story, but the game existed as a game before it was ever added. So we can throw that onto the heap. Next, graphics, dump them down the memory hole. Leave only the visual cues that are absolutely needed - the shapes of Chess pieces, the numbers and colors on a jersey, everything else is so much fluff. Textures, shaders, shadow maps gone. Sounds too (although I do love me some sounds) except for the ones that have to be there. Guitar Hero music gets to stay because it's an inherit part of the game - the gameplay falls apart without it. Acoustic GH sucks.
Still with me? Good. now what do we have left? All the glass and candy has been ripped out and I'll bet the game looks a lot different now. But, what we have left is a system. Input of some kind goes in, results are calculated. There's a black box at work in the middle and the Master and Commander of that black box is the Designer. So when a button, or key is pressed or dice rolled or an action taken, that is a certain kind of input. With a limited number of inputs the results can then be consistently processed through. So in The Thief's Tale there is an Action Key. When the player pushes it (the input) it activates a system that considers whether or not the player is in fighting or exploration mode and then does something and provides an output. Where it gets complicated, and this is the part people never think about, is when the systems cascade together. So push the action key, while armed, against the AI system of an enemy and there are traps in play. Those are systems that all overlap in some way and changing some part creates a ripple effect.
For example, let's give the player a gun. Let them shoot it with the Action Key. That allows them to dispatch enemies from afar and those same enemies are all designed for close range dueling. Now we've broken the system. It is unbalanced and no fun. Another example, let's make enemies do more damage. Simple change really. However, the player has no way in game to gain health back during levels. So we have to consider, how many enemies are in a level? Can the player avoid them? Does changing that one variable break anything else? Is there a "dizzy" state (there's not - I cut it) that triggers once so much damage is dealt? Is that easier to have happen now?
Needing to understand the deep inner workings of a game is what the Designer needs to do. Consider the game system to be a kind of model, and it's very fragile. They need to add things slowly, and consider how things will interact and effect each other at every step of the way. There is simply no other logical way to do it.
From my description it would seem that I don't think games are any fun, and making them seems like a detail hell. In fact, it's quite the opposite. I demand that games be fun. Yes, I even used the word "fun," not "enjoyable" not "effective" simply fun. That is the point of them in my eyes, and this is where being a Game Designer is far more difficult than being an Engineer. The latter doesn't need to care about enjoyment, their product simply has to work efficiently. A Designer has an whole other thing to worry about, and worse, it's not something that is fully understood.
Which brings me to the title. The search for this mythical "fun" is something that I do not think we can hammer down. I've read articles that try to define what this "fun" is and what to be able to describe it in a scientific way. The results, they argue, would be great. It would take away all that messy guesswork involved with the Iterative Method and allow games to be consistent and time frames locked in. It could provide a kind of built in language to express the concepts that are unique to games, instead of starting every design oriented statement with, "It's kind of like..."
That's the problem though, and arguably the greatest liability and greatest asset of games as a form. I use the term "mythical" when I say fun almost in a kind of sarcastic way, but it really is. I assert that it can't be locked down. Once "fun" is defined as anything it fails to be fun anymore. It's like the boy that's invisible only if nobody is looking.
Instead, we use tenets, basic guidelines that define what a game should be. Hard won little nuggets of truth. The reason is that no good game is summoned up from nothing. They take work, lots and lots (250+ posts worth) of work. The initial inspiration that hit is a distant memory and the urge for newness will sometimes be detrimental to the overall game system (remember the fragile model analogy). These guidelines are what we use to combat that, but they are hardly a formalized system.
It's Alchemy. We know that things work, and we have examples of them clearly working, but due to the big black box nature of a game system it is difficult if not impossible to know the deeper why of it. We don't know enough about why, and we can't nail down the elusive fun that we're striving for. The Fun that we keep looking for is a Philosopher's Stone.
But that's the beauty of it. The trying for it. The pursuit of the fun. So we iterate, over and over making small changes and additions to our given system to try to understand the outcomes better. It's the only method that has ever proven consistently useful to us.
So I say that Game Design is not, and should never be a science. It is a new way to do things, the hard core of systems engineering with the soft outer shell of ethereal fun. We don't need a new way to describe it though, we already have one. Game Design is pseudo-science. It's a set of unprovable tenets wrapped in ritual performed inside of a temple of the finest engineering.
At least, that's how I see it.
Let us pray...
You see, my basic field of reference is not that a Designer is a storyteller. They are not cinematic artists and they are certainly not doing anything that I would ever constitute as "art." I'm firmly in the "Games are Not Art" group, small and zealous as we may be.
No, the closest comparison that I can find for what a Game Designer should be, is a Systems Engineer. When the best games ever are boiled down to their most basic constituents, the things that make them intrinsically unique are the rules and systems at play. Think about it, take a game, any game really. Get rid of any story elements first, they're just candy. BioShock is known for having it's award winning story finalized at almost the last minute. Clearly it's a great story, but the game existed as a game before it was ever added. So we can throw that onto the heap. Next, graphics, dump them down the memory hole. Leave only the visual cues that are absolutely needed - the shapes of Chess pieces, the numbers and colors on a jersey, everything else is so much fluff. Textures, shaders, shadow maps gone. Sounds too (although I do love me some sounds) except for the ones that have to be there. Guitar Hero music gets to stay because it's an inherit part of the game - the gameplay falls apart without it. Acoustic GH sucks.
Still with me? Good. now what do we have left? All the glass and candy has been ripped out and I'll bet the game looks a lot different now. But, what we have left is a system. Input of some kind goes in, results are calculated. There's a black box at work in the middle and the Master and Commander of that black box is the Designer. So when a button, or key is pressed or dice rolled or an action taken, that is a certain kind of input. With a limited number of inputs the results can then be consistently processed through. So in The Thief's Tale there is an Action Key. When the player pushes it (the input) it activates a system that considers whether or not the player is in fighting or exploration mode and then does something and provides an output. Where it gets complicated, and this is the part people never think about, is when the systems cascade together. So push the action key, while armed, against the AI system of an enemy and there are traps in play. Those are systems that all overlap in some way and changing some part creates a ripple effect.
For example, let's give the player a gun. Let them shoot it with the Action Key. That allows them to dispatch enemies from afar and those same enemies are all designed for close range dueling. Now we've broken the system. It is unbalanced and no fun. Another example, let's make enemies do more damage. Simple change really. However, the player has no way in game to gain health back during levels. So we have to consider, how many enemies are in a level? Can the player avoid them? Does changing that one variable break anything else? Is there a "dizzy" state (there's not - I cut it) that triggers once so much damage is dealt? Is that easier to have happen now?
Needing to understand the deep inner workings of a game is what the Designer needs to do. Consider the game system to be a kind of model, and it's very fragile. They need to add things slowly, and consider how things will interact and effect each other at every step of the way. There is simply no other logical way to do it.
From my description it would seem that I don't think games are any fun, and making them seems like a detail hell. In fact, it's quite the opposite. I demand that games be fun. Yes, I even used the word "fun," not "enjoyable" not "effective" simply fun. That is the point of them in my eyes, and this is where being a Game Designer is far more difficult than being an Engineer. The latter doesn't need to care about enjoyment, their product simply has to work efficiently. A Designer has an whole other thing to worry about, and worse, it's not something that is fully understood.
Which brings me to the title. The search for this mythical "fun" is something that I do not think we can hammer down. I've read articles that try to define what this "fun" is and what to be able to describe it in a scientific way. The results, they argue, would be great. It would take away all that messy guesswork involved with the Iterative Method and allow games to be consistent and time frames locked in. It could provide a kind of built in language to express the concepts that are unique to games, instead of starting every design oriented statement with, "It's kind of like..."
That's the problem though, and arguably the greatest liability and greatest asset of games as a form. I use the term "mythical" when I say fun almost in a kind of sarcastic way, but it really is. I assert that it can't be locked down. Once "fun" is defined as anything it fails to be fun anymore. It's like the boy that's invisible only if nobody is looking.
Instead, we use tenets, basic guidelines that define what a game should be. Hard won little nuggets of truth. The reason is that no good game is summoned up from nothing. They take work, lots and lots (250+ posts worth) of work. The initial inspiration that hit is a distant memory and the urge for newness will sometimes be detrimental to the overall game system (remember the fragile model analogy). These guidelines are what we use to combat that, but they are hardly a formalized system.
It's Alchemy. We know that things work, and we have examples of them clearly working, but due to the big black box nature of a game system it is difficult if not impossible to know the deeper why of it. We don't know enough about why, and we can't nail down the elusive fun that we're striving for. The Fun that we keep looking for is a Philosopher's Stone.
But that's the beauty of it. The trying for it. The pursuit of the fun. So we iterate, over and over making small changes and additions to our given system to try to understand the outcomes better. It's the only method that has ever proven consistently useful to us.
So I say that Game Design is not, and should never be a science. It is a new way to do things, the hard core of systems engineering with the soft outer shell of ethereal fun. We don't need a new way to describe it though, we already have one. Game Design is pseudo-science. It's a set of unprovable tenets wrapped in ritual performed inside of a temple of the finest engineering.
At least, that's how I see it.
Let us pray...
Monday, December 14, 2009
With This Ring I Thee Kill
No game development news really today. Other than continued work towards the port is on hold for a few weeks.
Instead, my XBOX died. It caught a case of the infamous red ring and is now boxed up for UPS. Of course, having a non-working console is nothing new to me really. I once had an NES that only worked if I poured water into the cartridges and then set a dictionary precariously on top. Actually 3, and I wish that I was making that up. I also had a Genesis (no SNES for me *sob*) that worked occasionally if I jiggled the little cart just so.
I also had an N64 that worked fine, if you consider the games that weren't Zelda to be "working."
I also had a first generation (very likely first factory run) PS2 that worked flawlessly until the power of Kratos overpowered it will awesomeness. It's having the same issue really as my green XBOX, it's not something I can fix. I mean when I was 10 or so I opened up my NES and lovingly cleaned the boards with alcohol and q-tips before I very carefully bent back the little connector pins to ensure its working for another 5 years.
With the XBOX, it just has little lights that appear that tell me, "Hey, we're uh...dead." It's not like I can open it up and try to fix it with any hope of success. Further, the act of doing so will void the warranty ensuring that nobody qualified will fix it either.
So, yeah, merry fucking Xmas.
- In game news I'm taking this extra time to finish some stuff up. So that little final boss area, totally getting that done today. Probably going to install the achievement counters too.
Instead, my XBOX died. It caught a case of the infamous red ring and is now boxed up for UPS. Of course, having a non-working console is nothing new to me really. I once had an NES that only worked if I poured water into the cartridges and then set a dictionary precariously on top. Actually 3, and I wish that I was making that up. I also had a Genesis (no SNES for me *sob*) that worked occasionally if I jiggled the little cart just so.
I also had an N64 that worked fine, if you consider the games that weren't Zelda to be "working."
I also had a first generation (very likely first factory run) PS2 that worked flawlessly until the power of Kratos overpowered it will awesomeness. It's having the same issue really as my green XBOX, it's not something I can fix. I mean when I was 10 or so I opened up my NES and lovingly cleaned the boards with alcohol and q-tips before I very carefully bent back the little connector pins to ensure its working for another 5 years.
With the XBOX, it just has little lights that appear that tell me, "Hey, we're uh...dead." It's not like I can open it up and try to fix it with any hope of success. Further, the act of doing so will void the warranty ensuring that nobody qualified will fix it either.
So, yeah, merry fucking Xmas.
- In game news I'm taking this extra time to finish some stuff up. So that little final boss area, totally getting that done today. Probably going to install the achievement counters too.
Friday, December 11, 2009
Traveling Without Moving
C# University keeps some incredibly odd hours, with personal study seemingly located between 10:00 PM and ending sometime before the Sun greets the Earth. Of course, with the other stuff that I do, convenient times are all taken up by inconvenient things. So that leaves only inconvenient times to do convenient things.
No matter. Yesterday I learned how to overload a function. It's a tricky little bastard, but crazy useful. So let's use some examples (I love examples! - and parentheses!):
Static DrawCrap(Picture, Position)
Okay then, let's say this is the basic function. It draws a picture on the screen at a certain position. No, that's not correct code syntax, but blogspot doesn't have the code fixer than my IDE does. In any event, it's simple and basic. We could also do this, in the same program:
Static DrawCrap(Picture, Position, MaskColor)
You'll notice that this new one is named the same as the last one - DrawCrap(). Usually, having functions, or anything really, named the same as something else is a recipe for holiday themed, peppermint flavoured disaster. However, since they want different stuff, then it still works. The computer will know which one you want based on the context of it. Give it only the name of the picture and the position, it'll use the top one and give it some mask color information and it'll use the bottom.
That's not the only thing either, it'll also know based on what type of information you feed it. So,
DoStuff(int) is different than DoStuff(string). It knows what to do based on what it just ate.
Cute, no? I'm still not sure how I want to use this, but I'm positive that I can think of something. The DoStuff example will probably turn into a function that draws me some bloody text without the nine pounds of dusty nonsense that C# wants to enforce.
-Which reminds me, I hate fonts. Firstly because I can't seem to load them. Secondly, because the online tutorial sucks and finally, because the code to make it work is long, tedious and unnecessary. I'll tell you what I want, what I really, really want (other than to not hate myself for just typing that) is to just draw some fuggin text on the screen. It's what I use to debug stuff in real time. Turning on Debug Mode in The Thief's Tale turns on dozens of little labels and numbers in a bunch of very colorful little characters. That's what I want. Instead, C# wants me to load a font, and assign a font and make sure that my font isn't licensed and I can use it and then it wants only a string, so I have to convert stuff and try not to play laptop Frisbee.
So, yeah. I may build an overloaded function for that and then use it ad perpetuity.
- Wait for it...here comes the titles. I figured out yesterday via tutorial and practical application how to make the keyboard do stuff. I have the computer check for the state of the keyboard and then play twenty questions.
"Is the spacebar pressed?
"How about the Right Arrow Key?"
"How about the Escape Key?"
"The left Shift Key?"
"Is that little Key up at the left with that little "~" on it, is that pressed?"
So it basically works exactly like it does in Blitz, but with squiggly fuggin' brackets. I also saw that I can have the computer remember what I pressed. So I can ask important questions like:
"Are you still holding the spacebar?"
"Was the Escape Key just pressed?"
"Did somebody just let go of the little Key up at the left with that little "~" on it?"
The answers to which allow me the summon the same functionality that KeyDown() and KeyHit() have in Blitz, plus the extra functionality of the non-existent KeyJustLetGo().
So I quickly leveraged that and now the little Knight Sprite (rhyme!) moves across the screen like a tiny puppet.
The reason that this is of value? Because with this most basic of abilities coupled with the logic and method behind drawing stuff on a screen, it's safe to say that I can now write games using C#. Nothing good yet mind you, but TTT started this way. Right now I have a seed, and from it I can grow a giant thing, and my knowledge with it. That's a big deal to me.
Of course, need to finish TTT first. But I'm thinking that this new seed can grow into Thief on XBLI with the proper care and feeding.
-Oh yes, that is another Jamiroquai reference in the title. Deal with it. Although looking back there is a kind of running theme of 90's dance pop music in today's post. Lack of sleep obviously clouds the mind.
No matter. Yesterday I learned how to overload a function. It's a tricky little bastard, but crazy useful. So let's use some examples (I love examples! - and parentheses!):
Static DrawCrap(Picture, Position)
Okay then, let's say this is the basic function. It draws a picture on the screen at a certain position. No, that's not correct code syntax, but blogspot doesn't have the code fixer than my IDE does. In any event, it's simple and basic. We could also do this, in the same program:
Static DrawCrap(Picture, Position, MaskColor)
You'll notice that this new one is named the same as the last one - DrawCrap(). Usually, having functions, or anything really, named the same as something else is a recipe for holiday themed, peppermint flavoured disaster. However, since they want different stuff, then it still works. The computer will know which one you want based on the context of it. Give it only the name of the picture and the position, it'll use the top one and give it some mask color information and it'll use the bottom.
That's not the only thing either, it'll also know based on what type of information you feed it. So,
DoStuff(int) is different than DoStuff(string). It knows what to do based on what it just ate.
Cute, no? I'm still not sure how I want to use this, but I'm positive that I can think of something. The DoStuff example will probably turn into a function that draws me some bloody text without the nine pounds of dusty nonsense that C# wants to enforce.
-Which reminds me, I hate fonts. Firstly because I can't seem to load them. Secondly, because the online tutorial sucks and finally, because the code to make it work is long, tedious and unnecessary. I'll tell you what I want, what I really, really want (other than to not hate myself for just typing that) is to just draw some fuggin text on the screen. It's what I use to debug stuff in real time. Turning on Debug Mode in The Thief's Tale turns on dozens of little labels and numbers in a bunch of very colorful little characters. That's what I want. Instead, C# wants me to load a font, and assign a font and make sure that my font isn't licensed and I can use it and then it wants only a string, so I have to convert stuff and try not to play laptop Frisbee.
So, yeah. I may build an overloaded function for that and then use it ad perpetuity.
- Wait for it...here comes the titles. I figured out yesterday via tutorial and practical application how to make the keyboard do stuff. I have the computer check for the state of the keyboard and then play twenty questions.
"Is the spacebar pressed?
"How about the Right Arrow Key?"
"How about the Escape Key?"
"The left Shift Key?"
"Is that little Key up at the left with that little "~" on it, is that pressed?"
So it basically works exactly like it does in Blitz, but with squiggly fuggin' brackets. I also saw that I can have the computer remember what I pressed. So I can ask important questions like:
"Are you still holding the spacebar?"
"Was the Escape Key just pressed?"
"Did somebody just let go of the little Key up at the left with that little "~" on it?"
The answers to which allow me the summon the same functionality that KeyDown() and KeyHit() have in Blitz, plus the extra functionality of the non-existent KeyJustLetGo().
So I quickly leveraged that and now the little Knight Sprite (rhyme!) moves across the screen like a tiny puppet.
The reason that this is of value? Because with this most basic of abilities coupled with the logic and method behind drawing stuff on a screen, it's safe to say that I can now write games using C#. Nothing good yet mind you, but TTT started this way. Right now I have a seed, and from it I can grow a giant thing, and my knowledge with it. That's a big deal to me.
Of course, need to finish TTT first. But I'm thinking that this new seed can grow into Thief on XBLI with the proper care and feeding.
-Oh yes, that is another Jamiroquai reference in the title. Deal with it. Although looking back there is a kind of running theme of 90's dance pop music in today's post. Lack of sleep obviously clouds the mind.
Thursday, December 10, 2009
Like a Rosetta Stone
In the late hours, I mean really late almost encroaching on early hours, I had a breakthrough. I was reading things like Method and Class and not understanding what that was exactly. My issue, once again, was one of vocabulary. The lightning bolt that hit, was that "method" is just the way C# refers to a "function." Methods I've never worked with before, but functions? Oh man, we go way back.
So I'm staring at code and trying to put things together and writing just a giant pant load of comments to keep the logic flowing like boxed wine, and I'm finding that functions/methods live inside a Class, which resides on Namespace Street. Or can. It seems that such a hierarchy is slightly disingenuine, since I can create a new Class inside a method and summon a Namespace whenever I feel like it, but I think that at this stage thinking is those kind of global terms is helpful. It avoids an overabundance of riches.
Anyway, once a function/method is called we can make it so that it only works inside the Class where is lives, or available anywhere. We can also call it "Static," which opens up whole new worlds of possibility.
You see, the other way to create a function/method is to not call it Static, then it can be called as an "Instance." To do that, I summon up the function/method and stick it to a variable. Kind of like this, but with correct syntax:
New Function Version1 = WhateverClass.Function(Stuff)
Then you would put information (or arguments) into the little brackets there. It creates a new (like the first command) version, or "instance" of the function/method that uses the variables that you've given it. Afterwards, you can call back that specific version of the function.
To put it another way with something I've done before. The collision rectangle code in The Thief's Tale is built around 12 rectangles. Each of those rectangles has an X and Y position and a height and width. Each of those attributes is saved in the computer as a single variable, like Rect1X and Rect1Y.
However, instead they could be built using an instanced function/method. Like this:
New CollisionRectangle Rect1 = WhateverClass.CollisionRectangle(Position,H,W)
Afterwards, whenever I need to check something for collision against that rectangle I could simply call back that particular instance (Rect1). It'll bring all of the information I'd given it previously and then run the code that resides inside using it.
The real cute trick, is that I can create those from nothing as they are needed since all of the variables are local, but saved. In Blitz only Global variables are consistent, and they have to be declared in advance. Instancing allows me to create whole new things on the fly. So hypothetically, I could recreate the ThiefEngine and build screens with thousands of rectangles.
- I ran across a slightly odd thing in my explorations, something called "Vector." I was in the process of drawing sprites on the screen (in this case, The Knight enemy since I have lots of assets for it) and the stupid little window kept telling me that 200,200 is an integer and not wanted. To which I said, very likely aloud, "No shit, I'm aware that 200 is a bloody number." It turns out, it wanted something different, a Vector. Basically, it's like a tiny box that holds other variables, in this case, X,Y and if you want, Z. So before you can use it you have to fill the box, like this : Vector2 WhateverPosition(200,200)
I think the syntax is right, but it's just as likely not. In any event, afterwards, I just refer to WhateverPosition when I want to put Whatever where it needs to go. This seems kind of silly in 2D, but I suppose that doing it in 3D and a couple of hundred times per cycle it probably helps quite a bit.
So I'm staring at code and trying to put things together and writing just a giant pant load of comments to keep the logic flowing like boxed wine, and I'm finding that functions/methods live inside a Class, which resides on Namespace Street. Or can. It seems that such a hierarchy is slightly disingenuine, since I can create a new Class inside a method and summon a Namespace whenever I feel like it, but I think that at this stage thinking is those kind of global terms is helpful. It avoids an overabundance of riches.
Anyway, once a function/method is called we can make it so that it only works inside the Class where is lives, or available anywhere. We can also call it "Static," which opens up whole new worlds of possibility.
You see, the other way to create a function/method is to not call it Static, then it can be called as an "Instance." To do that, I summon up the function/method and stick it to a variable. Kind of like this, but with correct syntax:
New Function Version1 = WhateverClass.Function(Stuff)
Then you would put information (or arguments) into the little brackets there. It creates a new (like the first command) version, or "instance" of the function/method that uses the variables that you've given it. Afterwards, you can call back that specific version of the function.
To put it another way with something I've done before. The collision rectangle code in The Thief's Tale is built around 12 rectangles. Each of those rectangles has an X and Y position and a height and width. Each of those attributes is saved in the computer as a single variable, like Rect1X and Rect1Y.
However, instead they could be built using an instanced function/method. Like this:
New CollisionRectangle Rect1 = WhateverClass.CollisionRectangle(Position,H,W)
Afterwards, whenever I need to check something for collision against that rectangle I could simply call back that particular instance (Rect1). It'll bring all of the information I'd given it previously and then run the code that resides inside using it.
The real cute trick, is that I can create those from nothing as they are needed since all of the variables are local, but saved. In Blitz only Global variables are consistent, and they have to be declared in advance. Instancing allows me to create whole new things on the fly. So hypothetically, I could recreate the ThiefEngine and build screens with thousands of rectangles.
- I ran across a slightly odd thing in my explorations, something called "Vector." I was in the process of drawing sprites on the screen (in this case, The Knight enemy since I have lots of assets for it) and the stupid little window kept telling me that 200,200 is an integer and not wanted. To which I said, very likely aloud, "No shit, I'm aware that 200 is a bloody number." It turns out, it wanted something different, a Vector. Basically, it's like a tiny box that holds other variables, in this case, X,Y and if you want, Z. So before you can use it you have to fill the box, like this : Vector2 WhateverPosition(200,200)
I think the syntax is right, but it's just as likely not. In any event, afterwards, I just refer to WhateverPosition when I want to put Whatever where it needs to go. This seems kind of silly in 2D, but I suppose that doing it in 3D and a couple of hundred times per cycle it probably helps quite a bit.
Wednesday, December 9, 2009
Achievement Unlocked
I'll skip the usual soliloquy that usually starts off one of these posts and dive right into the tasty meats like some kind of carnivorous Scrooge McDuck (eww). I've got 3, that right 3 things to be all happy and/or stressed about. One of which I won't talk about here in the harsh light of the internet for fears that it may wither. Right now it's like Rome, and the idea of it can only be spoken of in whisper else it be blown away.
Hmm, it seems I am incapable of skipping soliloquies.
Moving on first to game related stuff. I've built a list of Achievements to install. They're all basic things that will be quick to implement. Things like, "Beat the Story Mode on Hard" and "Collect all the Dolls." I am following what I consider to be good Achievement Design though. So when a player finishes on Hard, they'll also unlock the Achievements for beating it on Normal and Easy. The same will be true for Speed Running the game. So getting the tentatively named Zephyr accolade by doing the game in 30 minutes or less, will also unlock the also tentatively named Thief Done Quick and Arabian Royal for beating the game in less than 45 and 60 minutes respectively.
Other than adding another front page to the main menu, the actual implementation of this new feature shouldn't take too long. Generally speaking, since I'm waiting for art content to finish cooking I get to work on other stuff. Yet, I'm not ready to move on to another project since I feel my dedication to this Thief is one of the defining factors of my leadership. Some of the rivets holding the project together. So yes, this is a kind of feature creep, but I'm oddly okay with it given the circumstances. Besides, I'm not technically competent enough with C# to start off the EP...yet.
The other thing hit me yesterday. It's an odd kind of feeling, like when you're climbing a mountain. You spend so much time staring at your feet and the rocks that when you finally turn around your progress surprises you. That happened. I was checking out schools, mostly because I found that Full Sail offers an online course. So I was cruising the information traffic jam of internet and browsing reviews and discovering that it's quite expensive when I started reading the syllabus. I quickly wondered if I could audit the classes, since I, you know, have done all that stuff before in one way or another. So I trekked over to see if The Art Institute offers an online option, and wouldn't you know it, they do. They were even nice enough to show me all the classes required to get a Bachelor's Degree in Game Design.
Again, I started reading and then it hit me, like patchouli flavoured truck, I know all of that already. Game Design Theory? Yep, and Practical Application - which isn't offered. Game Programming? Yeah, that too. Plus Engine Construction, Scripting Implementation and learning to fuggin code. 3D modeling, History of Game Design, Writing Composition were all a yes, yes and a duh.
In all, there wasn't anything that they could teach that I didn't already know, or could quickly apply skills I do have to. That's when I realized that yes, I am a real game developer. Even though I just happened to consider myself an "Indie" which has zero application process, somewhere along the way I had passed the line between what people would consider to be just a guy that dabbles in games, and a guy that has the abilities to create them from the raw aether itself.
To put it another way, it's like this:
"Do you have an Engineering Degree?"
"Nope."
"So, why do you think you can be a Structural Engineer?"
"You see that bridge over there?"
"The one across the bay?"
"Yeah, I built it. Figured it out. Would you like to see the blueprints?"
*bloop*
Hmm, it seems I am incapable of skipping soliloquies.
Moving on first to game related stuff. I've built a list of Achievements to install. They're all basic things that will be quick to implement. Things like, "Beat the Story Mode on Hard" and "Collect all the Dolls." I am following what I consider to be good Achievement Design though. So when a player finishes on Hard, they'll also unlock the Achievements for beating it on Normal and Easy. The same will be true for Speed Running the game. So getting the tentatively named Zephyr accolade by doing the game in 30 minutes or less, will also unlock the also tentatively named Thief Done Quick and Arabian Royal for beating the game in less than 45 and 60 minutes respectively.
Other than adding another front page to the main menu, the actual implementation of this new feature shouldn't take too long. Generally speaking, since I'm waiting for art content to finish cooking I get to work on other stuff. Yet, I'm not ready to move on to another project since I feel my dedication to this Thief is one of the defining factors of my leadership. Some of the rivets holding the project together. So yes, this is a kind of feature creep, but I'm oddly okay with it given the circumstances. Besides, I'm not technically competent enough with C# to start off the EP...yet.
The other thing hit me yesterday. It's an odd kind of feeling, like when you're climbing a mountain. You spend so much time staring at your feet and the rocks that when you finally turn around your progress surprises you. That happened. I was checking out schools, mostly because I found that Full Sail offers an online course. So I was cruising the information traffic jam of internet and browsing reviews and discovering that it's quite expensive when I started reading the syllabus. I quickly wondered if I could audit the classes, since I, you know, have done all that stuff before in one way or another. So I trekked over to see if The Art Institute offers an online option, and wouldn't you know it, they do. They were even nice enough to show me all the classes required to get a Bachelor's Degree in Game Design.
Again, I started reading and then it hit me, like patchouli flavoured truck, I know all of that already. Game Design Theory? Yep, and Practical Application - which isn't offered. Game Programming? Yeah, that too. Plus Engine Construction, Scripting Implementation and learning to fuggin code. 3D modeling, History of Game Design, Writing Composition were all a yes, yes and a duh.
In all, there wasn't anything that they could teach that I didn't already know, or could quickly apply skills I do have to. That's when I realized that yes, I am a real game developer. Even though I just happened to consider myself an "Indie" which has zero application process, somewhere along the way I had passed the line between what people would consider to be just a guy that dabbles in games, and a guy that has the abilities to create them from the raw aether itself.
To put it another way, it's like this:
"Do you have an Engineering Degree?"
"Nope."
"So, why do you think you can be a Structural Engineer?"
"You see that bridge over there?"
"The one across the bay?"
"Yeah, I built it. Figured it out. Would you like to see the blueprints?"
*bloop*
Monday, December 7, 2009
Class Warfare
My continued education into the basic format of C# continues. Once past the, let's call it "culture shock," the language isn't altogether too dissimilar, save for the one thing I'll get to in a second.
"Ifs" and "Whiles" work just like they should, and the "++" notation is a cute shorthand.
There is a "do" command, which I hate the syntax of though. Basically, it's a "while" statement. More basically for those of you at home without programming experience, a "while" statement tells the computer to keep on doing something while something is true. The Game engine for example is more or less:
While (exit = false)
Run Engine
Wend (end of while loop)
So as long as the "exit" variable = false then keep running the game. "Do" works sort of like that, but guarantees that the code runs at least once. I'm sure I can find a use for that, but hate how I do it:
Do{
Code Goes Here}
While(something = something else)
With that, the condition goes at the end. Right ^ there it's not a big deal, but add a hundred lines in between and it's easy to forget why something is doing something.
Other stuff works like it should too. Arrays (tables of data - see my rambling about combat animations in the diary for an idea of how those work) can be arrayed and inputs do exactly that.
I'm still at a slight loss about how Functions work, but other than being needing to say "void" to not return a variable directly they seem to be the same animal.
Except for one thing - Classes. I'm not there yet. They seem to be the hidden Qi that powers the language and mastery thereof will allow me to see the green rain code of the Matrix. I get that, at a basic level, they are a structural component. They keep the code pieces all separate, which somehow facilitates communication of some kind. Then individual "instances" of the classes can be summoned up from the spaces in-between and those code bits, or chunks of variables or functions can be used for other things.
The two things that are getting me, I mean really getting me coming from Basic are:
1) How the hell do I summon an "instance" of code? Doesn't it have to be compiled? Or is it just pointing at other code like a convoluted function call? Why do my examples have pointers inside a class that that appear to be local variables inside the same bloody class? Like a goddamn digital ourobouros. How do you reference something from inside itself? That doesn't make any fuggin sense I tells ya.
2) How do these classes even talk to each other? They don't share variables, they pass around the same local variables and once they start I don't seem to have a way to make them actually do anything. I could probably get away with coding the way I normally do and then just put everything inside a single class and then never mention it again, but then I'm not really using the power of the language. Plus, the stuff that makes things run on XNA are all written with a SARS riddled cornucopia of classes and local functions, so that doesn't really help me.
It's okay though, I have faith that I can figure it out. I mean after only a week I can read C#, which is more than I could previously. I'll think I'll be ready to make some code soon.
- I mentioned "++" in the words above. It seemed like so long ago. Anyway, what it is, is a counter trick. Basically, if you do - variable++, it's the same as - variable = variable + 1. It's shorter and faster. There are also "--" versions which decrease by one and other flavours that I find both exotic and nauseating, like those pepper lollipops from Mexico..
- I've gotten Namespaces buttoned down. They're a way to code like a retard by yourself, or have your group written code usable. I think that what it is, is a collection of variable and function names, almost like a folder that you can make. So you can have a variable in Namespace Ernie called Rubber_Ducky and then also have a Namespace Bert and a variable called Rubber_Ducky. Even though they have the same specific name, they are different because they come from different places. It's like how you can have different documents in your computer called the same stuff in different places.
It makes sense in a group, since then you can all have your own little sandbox and not worry about using variables the wrong way. In my own code, if someone went in a thought that iX (the player's X coordinate) might be a nice thing to use for a counter, it would lay waste to the game engine.
But like I said, if you're coding by yourself, I can't think of a decent reason to do this. Granted you can call variables from other Namespaces like this : Bert.Rubber_Ducky, but really, why would you do that instead of simply making it have its own specific name? I may be missing something here. I'll throw some IQ at it and see what sticks.
- Yay! Technical post! Hopefully I'll be able to leverage some of this new voodoo into something useful. Hopefully soon. I feel like I'm writing an essay test for a programming class sometimes. Only with more swearing.
"Ifs" and "Whiles" work just like they should, and the "++" notation is a cute shorthand.
There is a "do" command, which I hate the syntax of though. Basically, it's a "while" statement. More basically for those of you at home without programming experience, a "while" statement tells the computer to keep on doing something while something is true. The Game engine for example is more or less:
While (exit = false)
Run Engine
Wend (end of while loop)
So as long as the "exit" variable = false then keep running the game. "Do" works sort of like that, but guarantees that the code runs at least once. I'm sure I can find a use for that, but hate how I do it:
Do{
Code Goes Here}
While(something = something else)
With that, the condition goes at the end. Right ^ there it's not a big deal, but add a hundred lines in between and it's easy to forget why something is doing something.
Other stuff works like it should too. Arrays (tables of data - see my rambling about combat animations in the diary for an idea of how those work) can be arrayed and inputs do exactly that.
I'm still at a slight loss about how Functions work, but other than being needing to say "void" to not return a variable directly they seem to be the same animal.
Except for one thing - Classes. I'm not there yet. They seem to be the hidden Qi that powers the language and mastery thereof will allow me to see the green rain code of the Matrix. I get that, at a basic level, they are a structural component. They keep the code pieces all separate, which somehow facilitates communication of some kind. Then individual "instances" of the classes can be summoned up from the spaces in-between and those code bits, or chunks of variables or functions can be used for other things.
The two things that are getting me, I mean really getting me coming from Basic are:
1) How the hell do I summon an "instance" of code? Doesn't it have to be compiled? Or is it just pointing at other code like a convoluted function call? Why do my examples have pointers inside a class that that appear to be local variables inside the same bloody class? Like a goddamn digital ourobouros. How do you reference something from inside itself? That doesn't make any fuggin sense I tells ya.
2) How do these classes even talk to each other? They don't share variables, they pass around the same local variables and once they start I don't seem to have a way to make them actually do anything. I could probably get away with coding the way I normally do and then just put everything inside a single class and then never mention it again, but then I'm not really using the power of the language. Plus, the stuff that makes things run on XNA are all written with a SARS riddled cornucopia of classes and local functions, so that doesn't really help me.
It's okay though, I have faith that I can figure it out. I mean after only a week I can read C#, which is more than I could previously. I'll think I'll be ready to make some code soon.
- I mentioned "++" in the words above. It seemed like so long ago. Anyway, what it is, is a counter trick. Basically, if you do - variable++, it's the same as - variable = variable + 1. It's shorter and faster. There are also "--" versions which decrease by one and other flavours that I find both exotic and nauseating, like those pepper lollipops from Mexico..
- I've gotten Namespaces buttoned down. They're a way to code like a retard by yourself, or have your group written code usable. I think that what it is, is a collection of variable and function names, almost like a folder that you can make. So you can have a variable in Namespace Ernie called Rubber_Ducky and then also have a Namespace Bert and a variable called Rubber_Ducky. Even though they have the same specific name, they are different because they come from different places. It's like how you can have different documents in your computer called the same stuff in different places.
It makes sense in a group, since then you can all have your own little sandbox and not worry about using variables the wrong way. In my own code, if someone went in a thought that iX (the player's X coordinate) might be a nice thing to use for a counter, it would lay waste to the game engine.
But like I said, if you're coding by yourself, I can't think of a decent reason to do this. Granted you can call variables from other Namespaces like this : Bert.Rubber_Ducky, but really, why would you do that instead of simply making it have its own specific name? I may be missing something here. I'll throw some IQ at it and see what sticks.
- Yay! Technical post! Hopefully I'll be able to leverage some of this new voodoo into something useful. Hopefully soon. I feel like I'm writing an essay test for a programming class sometimes. Only with more swearing.
Thursday, December 3, 2009
Steppin' Razor
I'm finding C# to be kind of scary. There's just so many things that it's capable of doing that it needs way to keep all of those things in order. It's got libraries of content and the IDE has the cute capability to show me what a give function needs for input. Oh, and it has autofill like my Jesus Phone, so a quick tab and I've called code into the world.
Yet, it does a lot of things that give The Rage and The Fear like squiggly brackets, main function loops and the ever present semi-colon. Not to mention a whole new vocabulary including Static, Void, Main and Namespace, oh which I didn't know anything as of yesterday. It's like my brain has a hole in it and stuff is being pumped right in. To wit:
"Static" means that the function or variable you've got there isn't ever going to change. I guess this means it takes less memory or something. I'm not sure what the point is.
"Void" is something added to the front of functions that doesn't return a value. My Blitz Code would probably have 99% of the functions with this on the front because my software runs from the top to the bottom using global variables.
"Main" is the program itself. C# and C based languages all use one of these because the thought is, "Find the Main Function, and run it." This is different than Basic bases languages which say, "Find the Top and run to the bottom, stop when you get there." Basically, in C#, if it's not a declaration of variables (or independence) it's probably lives inside a function.
"Namespace" I still have no idea, but it seems to be a linchpin of the whole language. I think it's a way for C# to not confuse itself, but I'm still not sure.
Right then, "why am I doing this" is a legitimate query. I mean, I'm already super versed in another language and have the capability to make games. The honest answer is so I can play The Thief's Tale on XBLI and other people can too. Yes, we'll probably get hits and people playing our game if it's given away via the altruism of internet. But we'll get more my several factors of 10 on Indie Games, which is the true point. I mean, I'd give it out for free on XBLI if I could if people play it.
Further, I've decided that moving forward, I'm going to use C# exclusively on the next project (the EP). Specifically because it's portable. I can do something once and (cue the Batman SFX) BAM! on the computer and then BLAMMO! it's on XBox too.
But I'm moving into big kids territory here. The abilities that I'll have at my disposal will be more than I have now, I just need to take the time to learn it. Baby steps a little at a time, slowly and surely. Then, oh yes, my Kung Fu will be Strong.
...like a strong House Beat Dub...
Yet, it does a lot of things that give The Rage and The Fear like squiggly brackets, main function loops and the ever present semi-colon. Not to mention a whole new vocabulary including Static, Void, Main and Namespace, oh which I didn't know anything as of yesterday. It's like my brain has a hole in it and stuff is being pumped right in. To wit:
"Static" means that the function or variable you've got there isn't ever going to change. I guess this means it takes less memory or something. I'm not sure what the point is.
"Void" is something added to the front of functions that doesn't return a value. My Blitz Code would probably have 99% of the functions with this on the front because my software runs from the top to the bottom using global variables.
"Main" is the program itself. C# and C based languages all use one of these because the thought is, "Find the Main Function, and run it." This is different than Basic bases languages which say, "Find the Top and run to the bottom, stop when you get there." Basically, in C#, if it's not a declaration of variables (or independence) it's probably lives inside a function.
"Namespace" I still have no idea, but it seems to be a linchpin of the whole language. I think it's a way for C# to not confuse itself, but I'm still not sure.
Right then, "why am I doing this" is a legitimate query. I mean, I'm already super versed in another language and have the capability to make games. The honest answer is so I can play The Thief's Tale on XBLI and other people can too. Yes, we'll probably get hits and people playing our game if it's given away via the altruism of internet. But we'll get more my several factors of 10 on Indie Games, which is the true point. I mean, I'd give it out for free on XBLI if I could if people play it.
Further, I've decided that moving forward, I'm going to use C# exclusively on the next project (the EP). Specifically because it's portable. I can do something once and (cue the Batman SFX) BAM! on the computer and then BLAMMO! it's on XBox too.
But I'm moving into big kids territory here. The abilities that I'll have at my disposal will be more than I have now, I just need to take the time to learn it. Baby steps a little at a time, slowly and surely. Then, oh yes, my Kung Fu will be Strong.
...like a strong House Beat Dub...
Wednesday, December 2, 2009
The Next Step
The Wall Level's gone now. I couldn't think of anything that could make that level interesting, and instead of having an extra level that didn't add anything to the sweet gameplay stew that I've cooked up, I'd rather just have one less. It's oddly freeing to hack things not due to time constraints, but due to content quality. It's a nice option to be able to exercise occasionally.
That means that, for all intents and purposes, the level crafting for The Thief's Tale is finished. I need to put together the final boss area, but other than that, it's good and done.
Which brings me to the next thing. Since I'm waiting for content to arrive (which is does, in tasty little morsels) before dong more coding, I found myself thinking about different stuff and thinking about the framework for the stuff I want to do later. Recording functions, tile collision engines and fluid dynamics algorithms have been coming together slowly in my head meat and sometimes finding their way down to the hands where prototypes have been coded. But that's not the next step I should be taking. It's not correct. The Programmer and Designer part of me craves the new, while the Producer side of me demands completion. It's the side that must always win, for good or ill.
So, the true next step, is XNA. I've a wrapper put together that will launch my software into an XNA environment, but I've not done so yet. I don't know how well it'll function through the wrapper on a non-PC platform. I don't know if the controls will work, or the display will function or any of it. It's stuff I can figure out, but the answers may be in a language that I don't know. From a programming perspective, it's being born again into a strange new land that has only traces of familiarity surrounded by new dangers and mistakes to make. I wonder if the programming that I've done up to now is without real value, like code training wheels. That frightens to ever so much.
But that's just me. Producer side of me has an altogether external fear, that for the Team. Made up entirely of volunteers all wanting to have resume experience (like myself) and the start of a (hopefully) great, big MobyGames entry, I hope that the idea of monies won't spoil it. It probably won't since I want to, and plan to, split anything we make fairly. But fears of negotiations dissolving and work being left for dead is enough to keep me awake at night, staring at the ceiling and making a frowny face.
The least of my current worries, is IGF. We have time to spare and in what will probably never happen again in game development, an entire game framework upon which to hang gorgeous arts and sounds. I know we can do that, I hope that we can survive everything else.
I want to Believe.
That means that, for all intents and purposes, the level crafting for The Thief's Tale is finished. I need to put together the final boss area, but other than that, it's good and done.
Which brings me to the next thing. Since I'm waiting for content to arrive (which is does, in tasty little morsels) before dong more coding, I found myself thinking about different stuff and thinking about the framework for the stuff I want to do later. Recording functions, tile collision engines and fluid dynamics algorithms have been coming together slowly in my head meat and sometimes finding their way down to the hands where prototypes have been coded. But that's not the next step I should be taking. It's not correct. The Programmer and Designer part of me craves the new, while the Producer side of me demands completion. It's the side that must always win, for good or ill.
So, the true next step, is XNA. I've a wrapper put together that will launch my software into an XNA environment, but I've not done so yet. I don't know how well it'll function through the wrapper on a non-PC platform. I don't know if the controls will work, or the display will function or any of it. It's stuff I can figure out, but the answers may be in a language that I don't know. From a programming perspective, it's being born again into a strange new land that has only traces of familiarity surrounded by new dangers and mistakes to make. I wonder if the programming that I've done up to now is without real value, like code training wheels. That frightens to ever so much.
But that's just me. Producer side of me has an altogether external fear, that for the Team. Made up entirely of volunteers all wanting to have resume experience (like myself) and the start of a (hopefully) great, big MobyGames entry, I hope that the idea of monies won't spoil it. It probably won't since I want to, and plan to, split anything we make fairly. But fears of negotiations dissolving and work being left for dead is enough to keep me awake at night, staring at the ceiling and making a frowny face.
The least of my current worries, is IGF. We have time to spare and in what will probably never happen again in game development, an entire game framework upon which to hang gorgeous arts and sounds. I know we can do that, I hope that we can survive everything else.
I want to Believe.
Subscribe to:
Posts (Atom)
