New Plan

Okay, so I was thinking about it, and 2 things occurred to me. The first is that the game will probably be shorter than I thought at first. Honestly, I was thinking that 4-5 hours would be a nice short game. Then, after dong some running in my own levels, I found that when I do it, I can clear a screen in about 12 seconds. So, 12 seconds per (on average) X 5 levels X 30 screens per level and I get 30 minutes. Add some exploration, a little designed backtracking and the talky bits, and I could see finishing the game in about an hour or so. Other people may work slower, since they didn't design the levels, so the game make take on average 1-2 hours to finish. Some extra meat will come from the Grade given at the end, and the total speed (to encourage replays). Then, after IGF, I'll get ThiefEd to a point where other people can use it, so that will increase the playability too.

Second thought. Backgrounds are hard, or they were going to be. So, new plan (like the title says). My thinking is that the screen images will have 2 parts. The Background, drawn by the artist that I find, will be just that, a background. It will have no gameplay built in, and will instead feature the landmarks and general level stuff to make the game look nice. The Foreground will have all of that stuff though. The thought hit that, since the ThiefEd rounds all of the rectangles to the nearest 10 pixels, I can create textures and build the foreground myself. Once I have the level mapped out and have the background art, then I will layer the foreground on, and save the combined image as the main asset. This has 2 good things going for it, and both Producer Eric and Designer Eric are happy with them. The first, is that this allows the artist more flexibility for the backgrounds and the ability to work with a little less input once the levels are planned and the concept art is agreed upon. Both of these should give the art creation a little more speed. The second bonus, is that the stuff that can be interacted with, will be consistent from screen to screen. So, the player will be able to easily see what they can, and cannot, play with.

Oh right, art. I was thinking about the art. Here's what I came up with:
-I want the whole thing to look like a story book.
-I want the backgrounds to be stylized and not realistic. With strong silhouettes and easily identifiable landmarks
- I would like a subdued color palette. I don't want the Next Gen brown and gray, I do want color. What I don't want is neon green and fuchsia.

-New picture up. The Thief - as drawn by the Animator.

Today, the plan is to update the save file with all of the new stuff I added. Then go ahead and build a few screens worth. The reason for that is, 1) Now that the ThiefEd is complete, I want to play with it. And 2) Then when I update the engine to recognize the Files, it won't load blank levels and drop me into the void.

-Done. Funny thing happened. After I added an enemy, it would lose it when I loaded and saved. So, some minutes later, I learned something - always make sure you tell the computer the right place to look for variables.

-6 preliminary screens finished. Without playtesting or anything like that. I decided to start at the beginning, with the Prison level and work from there with that mindset. I found something. When I was designing levels on paper, I was trying to make them as difficult as possible. After all, the gameplay comes from the level, not the combat. Getting past the level is the goal. However, I can't throw one of the messed up Impossible Machine levels that I created at the player in the first level, let alone the first few minutes of play. That would be totally messed up (with a Capital F). Instead I have to find good gameplay, but by introducing the player to new things they can do. In effect, I'm taking the Miyamoto design philosophy and applying it here. One of the precepts is this : Introduce gameplay elements in a vacuum. Train the player to use them in a vacuum. Then combine the elements in interesting ways. For example, in Zelda, each temple/castle/Pee Wee's Playhouse has a single weapon/ item inside. That weapon/item is instrumental in finishing the area, and it is used exclusively. So you get to play with it and find out what it does. After you finish, then the game throws more stuff at you : "Alright hotshot, got your bow? Think you're hot shit on a plate? Alright then, let's see you shoot it while riding a horse." ...and that's why Miyamoto is on T-shirts.

Team Building

Okay, so the Independent Games Festival submission are due on 11-15. Sos it occurred to me that I have an Engine, I have a Level Editor, I have some character designs and a working script (which I am quite proud of - since I wrote comic books and short stories in a previous life). What I don't have, is content. I mean, backgrounds, stages and the meat of the game itself. So, here's the story that I thought about :
I'm reminded about a movie I saw and love. For those at home who haven't seen Seven Samurai (The Kurosawa flick, not the crap assed western or that first sign of Ragnarok - the Anime {They made Kikuchiyo a gods damned robot! Who the hell does that? Assholes.}). Anyhow, it starts off and the villagers are going to be attacked by bandits, so they ask their chief what to do. He tells them to find Samurai to protect them. Problem is, they don't have any money to pay Samurai, and all they can do if feed them. So, the Chief thinks for a moment, before declaring, "Hire Hungry Samurai."
So, like I said, my current situation caused my delectable brain meats to recall this. Right now, I'm looking for a Team. I need a Background artist/ level designer (other than myself), a Music & SE producer (let's say the first one is, um, indisposed) and another Programmer (for C#), and all I can't even offer them a bowl of rice. Instead, I have to find hard working and talented people who will work for the sake of working and the chance to be part of a team and make a game.
Now, I'm no longer just the programmer with an idea and a gameplay system. Now I get to be the role that I really want to do. Now I get to act as Lead Design, with say on the style, the content and the game itself, and as Executive Producer, with the responsibility to find talented people that know what the Team is trying to accomplish, meet the deadlines and make sure that the finished game is everything it can be.
Honestly, I'm totally conflicted on this point. On the one hand, passing off control of some aspect of the project, seems almost like I'm letting the thing leave the nest. Soon, it won't just be mine anymore, but it will be the Team's. On the other hand, seeing pieces of art come in, that I had no input on, that are new and unique to me, but made for the Game, it makes the whole thing seem bigger somehow. Like, I'm no longer just doing this for me. That people are depending on me, and my work for this to happen. So I feel burdened with responsibility, but freed by the fact that I'm not doing this alone.
-Right, so I posted a note for Background Artists on the List of Craigs. So far, I've gotten a variety of responses from a variety of very talented people. So, choosing one (or 2, maybe 3) will be difficult to say the least. Either way, i won't have a lot of time to think about it. The game needs to be playable by 11-15.
-The real trick is working out the Work Flow (man, that looks lame on the page, it seems like nothing office speak, like "synergy" or "productivity"). The Flow of course being the Level Designer to the Artist and back. So here's what I think should happen with this. I will lay out a level, and take a screen capture of it (PrtSc is awesome). Send it to the artist(s) who will block out the basic look of the thing and send it back to me. I approve (or don't, as the case may be) and send it back to them for finishing. Then they send it back to me when its done, I put it into the Level, and make the changes needed on my end for collision and so on. Or, they can send an idea to me, I'll block it out in the Editor and then start the process anew. Hopefully, this can all happen pretty quickly. I think that when I have some concept art available for the artists to work from, then it should go quick and easy.

Yobs man, yobs.

So, found a job on Craigslist. Tester position. It's one of those "Here's what we want, and we don't tell you anything in the description about who, where, what we are," kind of ads. I did give them the address for this, the Diary That Nobody Reads, so they can see I'm actually doing something and not pretending to be a game developer.
-Oh, yeah. New pictures up.

Damn all.

So on tap today is ThiefEd, and it is almost to the point where it is feature complete and does what I want it to. In the future will add the in Editor play, but for now, it only needs to work so I can start to create content.
- Just created the image database. So now there are pictures in the background of the level editor. Specifically, they are unique (from a file standpoint, they're all the same image now). So, when there are complete art assets, they can quickly be plugged in.
-...oh, and made a hotkey for it. Button incoming.
-Now, I'm working on the Enemy Limits. The Enemies work a little differently than the moving rectangles, since I need them to have a distinct spot on the screen. So they actually move (instead of just display movement, like the Moving Rectangles). This means I need to have a left and a right limit for them. Modifying the code for that seems to be harder than expected though. The damn second line just will not display, and I don't know why. I'm going to set up a test to see if it is even tracking the spot. So, BRB.
-Sorry for the internet speak. I had a stroke on inspiration and forgot about not being a D-bag. Anyway, found the issue. When I ran the test, it turned out that the variable wasn't being updated. So after some tweaks that did less than nothing, I found that the variable that I wanted and is used in 3 or 4 of the function I built, wasn't declared as a Global Variable. For those who read this (who am I kidding) a Global Variable is a name for a piece of data that you want all of your code to use. So, if you don't name it as Global (meaning that everything in the program can use it) it will just assume that you really want each time you mention it to be a brand new thing. So, when you change one, the other pieces won't know about it. Since, they have their own to worry about. Aarrgh.
- Okay then. Since that's finished, there is really only 1 thing left to do, which is to make the level a Checkpoint or not. The Check Point system that I built tracks your position when you enter a Check Point level. The level itself can be anything, but the system knows that it is one and takes a quick snapshot of the position of the PC and the Level. Then if you die, it resets the Level back to the Checkout Point you last reached, and sets your position to the spot you were when you first entered. So, conceivably if you jumped in and then died, you would restart in a jump. But I'm okay with that. The real trick is remembering to not include anything dangerous in a Check Point room. The last thing I want is for somebody to die, restart and die again. That just crappy, crappy design. It should be a quick addition, then I can move on to the Sound Bit that I worked out this morning.
-All done. The checkpoint thing was actually pretty easy. Now, on to the sound thing. I worked out the equations this morning, so it should work in theory. The trick now, is getting the SE to work in the first place. Hmmm.
-Nice. Really nice. The SE works fine. Also found out how to make the music a little less loud. Oddly, I thought that the panning effect would be better than it is. Even tried to double the variables that it is supposed to eat, but to no avail. Sound always comes out of both speakers. Odd...

Release Deadline

I have a deadline now. This will be finished by 11-15 of the Independent Games Festival. So help me. I will cut content to make it happen (then put it back in for general release). But it will be in a playable, feature complete form by then.
- This is my serious face:

:l

Pictures

One more thing. Found a way to post images. So, game screens incoming.

ThiefEd Additions

On tap for today, I'm going to go ahead and finish the portal rectangle bits and make the enemy button keep track of the enemy Level - with graphics and everything!
-Done. Well, the Portal Rect is done. I'm considering adding a thing to ask, really nicely, if you want to save what you've done. Right now, it helps when you may not want in to help. But no matter, the fact that it helps, let alone works, is good for me. What I finished by the way, was having it draw the character on screen when you place them. Then you can get it right where you want, for super specific placement. Otherwise, if you were a little low or a little high, it may hop out of a box or fall into one when the engine takes over. Now, none of that.
-Okay, cool. Ive gone ahead and made the Enemy Button work really well. Now there are little arrows you can click to increase the enemy skill level up to 9 (the theoretical skill level of the final boss) or decrease it to zero - which removes the enemy from the level. It also has a counter on it that let you know the what the current setting is. Tommorow, I'll add the final bit where you place the enemy on the screen and set up the limits. Or, I'll make a good attempt to. Then make the save info finalized and everything on the ThiefEd should be cool. The only things left to do then are the in-editor testing, which will require some decent coding work, and a way to have it show images.
-For the images, I had an idea. Since it worked so well for the levels, I though that I could create a file system for the pictures too. The issue is that the system would go all crashy crash when I tell it to find something that isn't there. So, a workaround would be to create blank images and put them there. The cute part of the idea is that if I have a picture to start from, then all I have to do is save it in the appropriate place and open the level. It should appear all cool like. Then if I have nothing, it will still show the basic template picture. Heck, I may even put some useful info on it. If I can think of some that is.
-Just browsed the blitz site, and I think I found a way to get some really good sound in the game. There already is a sound effect function, but it kind of sucks since it is so basic. I think I will use it and build a function that takes into account the position on screen of the character making the sound and then play the sound I want. Then, we'll get really nice panning sound effects, just like a real game!
- On random thoughts, something recently occurred to me. I am a member of the Middle Children of Gaming. Let me explain. The Firstborn were those that could remember of a time without games. These were the folks that fell in love with Pong and PacMan and generally made sure games weren't just a fad. These people may or may not have given games up after the crash, but they were weaned on the games that had a basic, if any story, and were more tests of skill. Nowadays, these are the gamers that 1) Make Games or 2) play the more simple Flash things you can find online, as they are the kind of games they know and enjoy playing.
The other gaming generation is what I call the Third Generation. I have a story for this. I was over at a friend's house, (Steve - my animator's house incidentally) and we were talking about old games, and the topic of The Adventure of Link came up. If you've never played TAOL, then go do it now, and you'll see how wicked hard it is. So, anyway, one of his little brothers comes up and says "Yeah, Zelda. I love that game. It's not that hard though, only the Pyramid part." It took me a second to realize that he was talking about A Link to the Past, a game I had seen him playing on an emulator on his computer. I let him know that we were talking about a previous game in the series, to which he replied, "There were Zelda games before that one?!" Which made me feel very, very old. The Third Generation of game players demand story and plot progression. They have little issue with playing 60- hours to finish and many of them are too young to have jobs, yet manage to spend Millions on games like Dynasty Warriors.
So I, am a Middle Child. The Second Generation. The games I like, are those Olde Skool style games, where the focus is on genre. But, I grew up on TAOL and those old, really hard games. Now I know that Halo on Legendary is hard. I finished it that way (with friends). But these were games that tested you and gave you a sense of accomplishment when you finished them - like Mega Man.
I find myself in a weird place. On the one hand, if I see one more match three game, I will shit a perfectly formed and fired brick. No, I don't want casual crap, it's just not my bag baby. I like to learn something new that then challenges me.
On the other hand, I do not have the time or energy to pour 60 hours of my life into something that I do not care that much about. GTA4 is a good example. I started playing it, and now I'm on the 4th island, have a good many things unlocked, and I'm at 30%. I keep playing, getting false endings and so on, until I just get to a point where I think to myself, "When is this going to be over? I want to finish - since I'm not a quitter, but I really want to move on and play Mass Effect." Oh, I've heard, ME is supposed to be, like, 12 hours long in the main quest. That sounds awesome in every way.
So, I beg and ask, give me a good game that I can finish in 12-20 hours. That's fine. Anybody that complains the game is too short is complimenting you game designers. It means that they enjoyed your game so much that they wanted more of it. Recently I played Gears of War with a friend. That game is 7 hours long. I played it 3 times on 3 different difficulty settings, and not once did I think, "Man, I want to play me some Mass Effect. When is this over?"
-Oh, in case you're curious, for The Thief's Tale, I'm shooting for like 5 hours, tops, if you find Everything.

6-2-08

Rotten liar I turned out to be. Wax all poetic and then do nothing for 3 months. Well, not quite nothing – I did finish my classes for the Spring, and I got A’s. Plus, I finished the engine. It’s done and feature complete for the most part. The only thing it doesn’t have now is to be updated with the new ThiefEd tools.

-What, ThiefEd tools you say?! Yes, that’s right. I’ve been working on the ThiefEd program for the last Month, and now the Needs list is almost squashed. To wit:

1- it draws rectangles on the screen.

2- it lets me modify said rectangles using HotKeys and Tabbies.

3- it makes cute little grab rectangles – at the correct sizes.

4- The Moving Rectangles work, and the system lets you set limits.

5- You can decide if the Rectangles go up or sideways with the editor, and it draws the right limit lines.

6- You can Save the level you are on in a Project File, which has individual stages. Here’s how that worked out: On a basic level, I really wanted to include some variation of ThiefEd with the game. As it stood, I could name my files whatever the hells I wanted, since I could fiddle with the code and make it all line up. However, I would have no way to control what other people might call their crap and hard code that into the game. So, the idea that I had was to consider the whole bloody thing to be a Project File. The Project File would have 9 Stages in it. Each Stage would then have 144 cells or Levels in it, arranged like a 12 X 12 grid. I could then name these Cells numerically. So, 90101 is on Stage 9 and is the first Level (Cell) in the first column.

So, when someone loads their editor, they get 5 Stages to play with or (quick calculator stuff) 720 screens to use. Now, since I have the ability to make a Portal Rectangle go to anywhere in the whole game (I could make 10101 go right to 91212). The levels need not link together in any reasonable way. So with some clever mapping work, the TheifEd editor would be able to use the 5 stages given and make something that could be far larger than my own game – since I do plan to lay the stages out sequentially (like a map) so they flow logically from one to the next.

After I built this bit and worked out how to save it occurred to me that I need to update the LevelLoad function in the engine, but I’ve been busy.

7 – The buttons are dynamic and tell you if you’re using that rectangle, what the dimensions are and I don’t have a third thing…

8… oh, and the automatically selects that one again if you pick it. In other words, build a rectangle, then select a different one, then select the first, and it won’t erase it.

9- It rounds everything to the nearest 10^th pixel. This will be cool later when I tile images in it (See big deal below).

-The big deal that I worked out, is how the next project is going to work. It was supposed to be Knight, and use a modified Thief engine, but I ran across a better idea for the engine that is really, really pro. It happened as I worked out the Map (for the Stages and the level load system). The Map is a series of 144 rectangles that all work when you click on them. The first thought that I had was a nightmare – 144 rectangles that I have to build functions for – like the buttons. Then it occurred to me that the information contained in the buttons, what just a number. It wasn’t a funny alpha-numeric variable that I couldn’t generate with an equation. So, the thought was : “What if I ran the numbers, and then built a rectangle at the spot they should be. In other words, 0101 would be on the first row and in position 1 (say 0,0). 0102 would be in the first row in position 2. If they are all the same size, I could do this. Draw Rectangle at 0+(50 x Position). So it would be drawn at the second spot, then the third would be drawn at the third and so on. The specific code looks like this:

Rect 6 + (54*RowLoop), 80 + (20*ColumnLoop), 54, 20, 0

Text 6 + (54*RowLoop), 80 + (20*ColumnLoop), ""+LevelLoop+"

This is all fine and good, but the real money came after that. I thought, you know, for giggle, what would happen if I asked what would happen when you the mouse overlapped the rectangle listed above. I mean, in no real sense does the rectangle ever exist – it’s a fluke of the math really, it exists long enough to provide the evidence that it was there once. What happened was magic. Every time the screen updated at 30 frames per second, it would highlight the rectangle that I was over, just it, and nothing else. It let me select and act on an object that wasn’t there at the time I wanted it. So, with some playing, I found that if I clicked on one of them, it gave me the value that the rectangle represented. Somehow, I would click, it would draw everything to keep up, and then see what overlapped and where.

So what you say. Great, way to get all existential on us you say. Ah, but here’s the trick and the reason that the Knight Engine will be awesome. I could use the same trick to create tiles and a collision system. So instead of a Map screen that uses odd shapes like 54 x 20, I could use, say, 16 x 16. I could then also keep track of value in each. Say, if the tile triggers collision (which would give me Specific value – not a relative one), or death, or is icy, or anything else I can think of and want to do.

So, yeah. I’m happy with the progress that I made. So happy that I feel an odd urge just to work on it, and this is why the Diary hasn’t been updated in a while. Free Time goes into ThiefEd. Anyhow, almost done with it, and then I can get started on the Content. Yes, the C word (um, the other C word, that you can say in company). Then I can get the game to play and be, well, cool.

3-25-08

Don’t have a lot of time today to wax poetic. Instead, I’m going to make enemies dash proof.

-Done. Now when you dash through an enemy they throw you. Nice. I’ll figure out something involving the animation later, but it works for now.

-Uncovered a weird bug though. When an enemy reaches the end of their little patrol, they get confused and keep walking on. Which could be in the air- so that’s not good. I’ll swan-dive into the code to see what’s up.

-Mas Bien (That’s mo’ betta for those of you that don’t live in San Diego). The bug is fixed. I also installed the bit where the enemy forgets about you.

-But wait! Didn’t you say we wouldn’t be doing anything like that? I did. But a weird side effect happened that I’m quite fond of. You see, the “Alert” mode basically made it so the enemy can see you in 2 directions if it just lost sight of you. Well, that worked out stupid for patrolling (see the previous post), but combat flowed better with it. There was an odd bug, that I thought I fixed, where an enemy would kick your ass, and then forget all about you and walk away. Now, if it loses sight of you, it will be aware in 2 directions for a couple seconds, turn around and continue the beat down. This all happens in a single frame, so you don’t even see it anymore. Anyway, I don’t want it to happen after you’ve been seen, no matter what, that’s dumb. So it takes a couple seconds and then is resets…and works. So sweet.

-Next, I’m going to install the climb up code by modifying the wall code a little bit. Methinks that I’ll have it jump frames based on where you hit the wall. So if you hit really low it will play the whole climb animation, but if you hit high, I’m thinking it will skip ahead to the later frames where you are already up on the wall a little. The plan is that I can use a single climb animation and get it to look good.

3-24-08

New Plan. I got to thinking about the On Alert mode, and how enemies will be able to see you in two directions and so on. I could not, for the life of me, get that to work from a design perspective. Designing “Stealth” levels and getting the Alert Mode to not be a bad Metal Gear rip just doesn’t work. So, I sat back and reconsidered what the game itself is, and to quote myself, “Errol Flynn doesn’t stand there and wait for enemies to attack him, he gets up in their faces and kicks their ass.” Errol Flynn doesn’t hide like a sissy. Sinbad never said, “I hope those animated skeletons don’t see me.” And Hector with his blazing helmet (from the Iliad – read a book) never hid and thought, “I’ll hide here until they forget about me….in, say, 30 seconds or so.”

So anyway, back to basics. I found myself fighting to focus on this project, when my mind kept wanting to wander off and think about other things, like what I codenamed Knight. In effect, I started to loose what makes Thief, well, Thief. So back to next gen platforming with old skool (with a ‘K’) mentality. So no stealth. I want Prince of Persia, but with some extra awesome sauce poured lovingly on top.

Consequently, some of the extra stuff I wanted to add, are now no longer in the game. They were cut like the fat kid on the track team, which is to say, which prejudice and ridicule. So, no more alert stage, and no more staggered state. Added in their place, is the ability to put your arms over your head. I refer of course, to climbing a freaking wall. This will fix a stupid bug, and bring the game into the “next gen” method of platforming. The bug, by the way, is that you stick to the wall, no matter how high you are on it. So I’ve stuck when I was only touching the wall with my foot, leaving Zero to float like an idiot. Now, I’m thinking, since the coordinates used for both the rectangles and the character are the same, I tell it to put the character into a stunned, climbing mode if they collide with the box, and are higher than it.

- With that finished, I can maybe get restarted on ThiefEd. Now I see why tools programmers are so highly sought after. “Yes, I would like you to build a method for creating levels/ sounds/ input controls for something that doesn’t exist yet. Now get to work, we need it as soon as you would know what it is.” It’s a catch-23, which is like turning the absurdity/ stupidity up to an 11.

- What else? Ah yes. I think that once I get the game working and running on PC (where it lives and loves), I’ll get around to playing with controller options. I know, I should probably have built in controller support from the get go, but it sounded hard, and I didn’t have a controller to pay with, so I don’t have it yet, oh well. The trick for me, is not to get it to work, but to get it to work decently. You see, in the language of Blitz Plus, it polls the keyboard and looks for the key you tell it to look for (is the Spacebar being pressed computer?). With the controller, it seems to use a different system altogether…

-Check that. It seems you could tell the computer, “Hey computer, what button am I pressing?” I didn’t do that, since I would frequently need several buttons pressed at once (like a jump, doublejump while moving combination – 3 keys). Instead, I ask on a case by case basis, so installing controller support shouldn’t be that hard actually. I could probably also set it so the player can do their own button layouts too, since I use variables for all of the anyway (like the one I called CtrlKey – 5 points if you guess what that does). Anyway, the real meat and potatoes for doing it at all is so I can use analog control on it. That right there, is some more of that next gen nonsense I’ve been on about. Get that figured out, and the control will finally be golden.

-Furthermore, it brings me to my next point. I think I know a way to get this thing to play on my 360, and maybe a way to distribute it. Microsoft (spelled without the $ - you wankers) had previously created something called XNA for their fine Live service. I considered this, along with the Torque system for this project before finally moving on to Blitz, so I would learn something useful. Anyway, at the time projects had to be made using the built in XNA software, which used some variant of C – which I hate. So, I thought, F it, I’m putting this online with a “pay me what you can” method for maybe buying lunch. But the new system actually seems to allow you to use any Windows Executable file, so long as you packed it correctly using the built in tool. Turns out, the 360 on your TV actually runs a modified version of windows (again, spelled without the “bl”), but with a slightly esoteric file structure. This means that when it is finished, and have analog support, then I would conceivably put it up with the Creator’s Club and maybe get it approved for a real Live Arcade release. This is of course, all dreams and whispy hopes, but that would certainly be very, very cool. Besides, I think there is a lack of hand drawn platformers on the service, don’t you?

-Who am I kidding? I would so laminate the first $1.00 PayPal payment and frame it. I’m such a sucker for those kind of things.

- Finally, I have a word usage that I think is odd. The terms are “Next Gen” and “Old Skool” (spelled like in Invader Zim. I’m an English Major, I do it wrong on purpose and for effect) When I refer to games as either I am not referring to their graphics, since I don’t care that much. I prefer style of polygons, but that’s just me. I refer to the gameplay. Things I consider next gen are gameplay elements that are post N64. So, the double jump comes to mind, so does a block button, save points, wall jumping, analog control, open world games and emergent gamplay. This is not to say that some games before the N64/PlayStation didn’t have those things, but they became more commonplace afterwards. For example, Double Dragon is an old skool beat em up, while Ninja Gaiden Black is a next gen. Viewtiful Joe is a nutty hybrid I am very fond of. See the difference? Oh, and speaking of Ninja Gaiden, cut scenes are not next gen, they were in the original made almost 20 years ago. Old Skool games are all about genre conventions and a focus on the core gameplay. They didn’t do much, so they had to focus on doing 1 thing very well. Hence the chopping of the stealth. So Metal Gear had stealth, it’s what it did. Mario had jumping and moving, Sonic had speed, and the Prince of Persia had exploration and sword fighting. What I like to do, is the mash up. I want to do the focus on genre, but mix in influences from both generations to create something new and original. Like a modern western movie or anything by Tarantino. Make the old, new again, and make you feel like you did when you played it for the first time.

3-8-09

There was work done a few days ago, but I did it late and didn’t update the diary. I think it was on the 4^th, since that’s the last save file. Anyway, on that day I got the movement thing tweaked, so it fits with the levels better. Also fixed the Fallhurt damage, so you fall a less distance to die. Now it’s about what I would estimate to be about 3 stories or so.

2-27-08

Even though there has been no diary update, which is odd since this takes a lot less effort than the code, I have completed a bunch of work on the code itself and we’ll do a quick rundown and the stupid crap that happened.

-Got the include code to work for the level loads. It works out really well. In C++ include files do a bunch of nonsense and have to be included as boilerplate code*. What I never managed to understand was how to build them correctly and then include them. Anyhow, with Blitz Basic, all I do is point the code at a different blitz file. It would be like putting at the top of this diary : include: yesterdays post, and then having yesterday’s post appear magically at the top. The really nice thing is that the included code doesn’t have to work by itself, which comes to my next point. I included the level information is a separate file (so it’s not in the engine proper). Specifically, the level info does not include any of the useful code that allows it to run, like, at all. In effect, it’s nonsense gimp code that I don’t have to worry about too much.

-In other news, I started to understand more specifically how the include code works. Here’s a cute trick that does (work): Save a text file and rename it with .bb on the end. You can then include it! It’s great! This means that I can save a file out of the level editor as anything I damn well want, including a .bb file, and the code will be natively recognized by itself. This is good news for the level editor proper, as well as when it ships with the game itself. As long as the files are saved in the Player Created Levels file, then it should run all by its lonesome. That’s so nice.

- The include file for the levels, is also why, oddly, there are fewer lines in the new code.

-The deflect code works, and it works pretty well. It has a window of about 10 frames or so. It works when you’re paying attention, but it isn’t needed to win. You just have to be better at blocking. Also, in an odd turn of affairs, I can’t seem to get the lower one to work, for me. The code works fine, and when I turned the FPS down, I could get it every time. Heck, even the timing is the same, but I can’t seem to do it as consistently. Oh well, I guess I’m not very good. I also set the code up so that it can be changed depending on the enemy type, so the different enemies will all have a different rhythm to deflect them at. So if I wanted to be a pain, I could have someone fight a few different kinds in a row, just to mess with them =D.

- There is now an Action Button instead of 2 different keys for everything, but I may have included that already. Now however, the attack key is tied directly into the deflect code. So now I have, 1 button combat, but it actually requires quite a bit of reflex to work. The combat, after all, is twitch based, not tactical, so the 1 button thing actually works and allows you to focus on the more important aspects, like not getting your clock cleaned.

-Today I smashed an AI bug. Sometimes, when you reach a screen with an enemy, it would be stuck at it’s Limit, and flicker right and left and not move until you moved into it. So that was dumb. To fix it, I simply changed the code to be less/greater than or equal to the limit to switch it around and walk the other way. No more flicker.

-Back to the levels. I brought home some of the levels I did at work (getting a great sense of accomplishment by the way. In effect, I was getting paid to design levels.), and started putting them together by brail (no TheifEd) and getting them to work. 3 things occurred to me.

1) The game is actually quite fun to move around in. The levels all change like they are supposed to and the enemy works. The movement feels really good.

2) The movement is far too big for the levels I designed and the screen itself. It wasn’t an issue with the test levels I built, but as soon as I got to some honest to goodness gameplay, I realized the Thief jumps too high, runs too fast and the dash goes too far. So I need to reconfig the movement again. Still, this is good tweaking that will make the gameplay much better in the end and allow for a greater variety of level challenges.

3) The enemies are stupid. They were never bright to start, but I realized that I could dash right through them. Then since I was behind them, they would forget they saw me and go right back to patrolling in the direction they were facing, namely, away from me. So I had an idea, which brings me to my next point.

- I decided I want an “On Alert” mode for the enemies. So after they have seen you, but no longer see you they will be on the lookout and will attack you if they see you either way. In effect, Alert mode would make the line of sight all the way across the screen all the time. It would also give me a good marker to do things in scripting. But most importantly, you will not be able to dash through them anymore, since they will still see you. Then, since you’re probably still close, they could drop kick the teeth out of your head. Ah, bliss.

-Also figured out how to do retard transparency. I’m sure “real” transparent items have some kind of cute “draw every other” effect or some crap, but I want my thing to not flicker and look bad. So, I plan to have the frames have a tiny single pixel checkerboard on them in the color of the mask (the color the system does not draw), and offset this by a single pixel in every frame. So, every frame will only show half, then next will show the other half and each time it will show what is behind the transparent item, so it will look clear. I could then adjust how transparent something is by changing the number of mask pixels in it.

2-10-08

No updates, but I did do some work. Here’s the rundown of the new stuff:

-Jumping Animations. Mostly since I needed to create a “hop” animation and Zero only had jumping ones. So it does double duty and he has a few frames when in the air. Same old flip though, since I likes it.

-Completed dodge and hop animations, for realsies. Installed them too.

-Actually finished and debugged the animation lock code. So now the animations line up (sorta). It looks funny since I am lining up animations that have different timing and are totally dissimilar but the system works, so when I have the finished animations (from my animator) those should look great. So all in all, it’s been a very constructive day and I feel confident in the outcome.

-In random other news, I am taking a class in 3Ds Max and I have to do a final project. Methinks (it’s a real word, look it up…naysayers {also a real word}) that I may do parts of the final scene at the end of the game that way. Then I get double the outcome with half the work.

-In even more random news, I had a weird dream last night. In some odd way I was playing my game on XBOX, and it was super sweet. Not the gameplay (since it was a dream) but the hand drawn animations and backgrounds looked great. So, I have hope for that.

1-21-08

Yesterday I did do an update, although smaller than most. Yesterday, I added the code for the weapon put back. Now when the button is pressed and the sword is out, it goes back with a flourish. Good for the system flourish is by the way, as I noted in a different post.

- I didn’t split my infinitives in said post though.

1-20-08 4186 Lines.

Squished a weird bug so far. When you backed away from an attacking enemy, and then managed to hit a block button before the enemy attack finished, it would lock you into the block and shut off control. That’s not good, but it’s better now. I added a quickie correction that also turns off the block if nothing is attacking you.

-Piss ass bug. What I really wanted was for the block to show as long as the button is pressed, regardless of the distance. That way the player always has a tactile feedback on the system before an enemy tries to kill them. The previous fix corrected the issue, but now when you are out of range it does nothing when a button is pressed and the player only dodges when they are actually being attacked. That’s fine, but I only want to lock the player into one of those when they’re being attacked, and not when they are not.

-HA HA! Mo Fugg! That’s what you get! Mo’ better now. The bug is fixed, the right way. After mashing at it, trying multiple combinations of different variable and looking around for even more variables, I’ve found the solution. There are now two sets of control for how close you are. Up close, where an enemy will attack will still lock you into the move – which is what we want pending the animation line up. When far away, it is based on how long you hold the button, like the old system. Now it works more as it should. :D

-This bug took all day. That’s so stupid.

- In random other news, I hate my utter lack of notation in most of my code. One day I’ll make sure to put in the comments when I write the code, but until then I find myself making the damn thing work, and then quickly moving on. Or, oddly – I put the comments in the diary. Hmm…

1-19-08

No code update, because I suck, but I have built the new dodge animations (which required some major modification of the frames I had) so now I can install them into the system. It would be nice if I was past using placeholder (Zero) animations, but them’s the breaks for now.

Further, I have an idea to line up the combat. I will assign a specific variable based on enemy skill (and consequently, enemy type). This will be the actual hit frame. When an enemy attacks, and the correct defense button is pressed, the system will take the enemy’s current frame, and divide by the total number of player dodge animation frames. The number left will be how long to display the character animation frames.

(it sounds confusing because it is. By “Frames” I mean “Cycles.” Animation Frames usually take several cycles to show, since the game runs at 30 “Frames” or computer cycles per second).

So, in effect, it will synch the animations so that just as the enemy would hit, the attack will be blocked. After that, the animations can play normal since they don’t have to synch up anymore.

When this is in place I can install the Deflect code and finish the combat system. I also had an idea. It is fully possible, that there will be more block animation frames than there are cycles left before the enemy hits. In this case, I think I will go ahead and also count that as a Deflect. So the player will either be able to mash the attack button at the right time and issue a deflect, or hit the block at the last possible moment. By last possible moment, I figure that if there are 4 block animation frames, it means that the would have to be 3 or fewer cycles left. Running at 30 cycles per second, that means that if you hit the block button in the last tenth of a second before the hit, then you get a free deflect. So it’s more of a, “I got lucky” thing. Although I’m sure that it’s possible that someone out there will figure it out and be able to always block like that.

1-3-08

Still trying to sort out the animation bit. It seemed so easy at first, and now I have very little idea of how it is going to work. Starting with the thought from before, the first thing it should do is consider the distance. I would love to recycle the current code, but the distance will not always be the same. In the final game enemies will have different lengths that they attack at, so if the animations only line up at a certain spot, then that wouldn’t be consistent or work.

What I could do is draw a phantom frame. Originally, as I noted in a previous post, the system can detect collision on animation frames that are not displayed. In other words, if the longest animation frame (probably the hit frame btw) would have collision, then line up the animations. I could probably also modify this system for enemy attacks – so they only attack at the tip of their attacks. I’ll do some tests and see what I can see.

After that, the best way would be to sort out how many attack frames are left before the hit frame – and then speed up the animations for Zero to compensate. That way we’ll have fast – and slightly uneven yet more realistic – defense animations. I think that will work out too, but first, the control for testing.

Right now, I’ll put in the bit where when you select a defensive maneuver, the system will lock you into it for the remainder of the attack. Let’s try that first.

-Cool beans. The combat control will now lock you into a method once you enter it. So once you decide to hop, you’ve hopped for the rest of the attack. Which is nice and exactly what it is supposed to do. It also, oddly, makes the combat easier. The defensive maneuver is turned off when the attack finishes, so no more falling/standing into a halfway finished attack and getting punished for it.

-So now I need to test out the animations, but there aren’t any. Next is to tie the defense animation to the system, but there are only 1 frame placeholders, and those work great. So now I need something a little more robust. While I’m in there, I’ll get a proper jump animation too.

- All I got was the starting block frames done. Turns out that Zero doesn’t have a frame that I could use as is, so I had to create 2 of them for the high and low guard. Grr….

1-2-08 / 4143 Lines

5 Months since the beginning of development. Odd, it seems longer. Oh wait, it’s been 5 months since I began the diary. It doesn’t include the development of the collision system, the control system or the AI. So, it’s been longer, but I can finally see the ending for the engine. I think that’s the main reason I update less now. There’s nothing new to figure out, no puzzle to complete so the system works. Now all that is left is tuning and the final combat engine parts – which I already know what to do for. It seems the experimentation is all done. It’s a shame really, now is the part to move on, build ThiefEd, and actually start working. I feel odd trepidation since the work is the work. It’s not the, “Let’s play with the code and see what we can discover.” The discovery it seems, along with the magic, is gone.

But I’ve heard of this before. It’s the middle part of development that separates the BioShocks from the Duke Nukem Forevers of the world. Past the newness of it all and not to the point where the game plays, it’s the odd part in the middle. Engine tweaking, bulletproofing, none of it is new gameplay and it’s not the part at the end where you can see the product and understand that really, it is almost done. It’s the stupid bit where the project itself is an amorphous glob that can coalesce into something really great, or completely turn to vapor.

Further, I find this Diary weird, in that I know that I am the only person that will probably ever read this. Maybe Jessica will, curious what it is I do for several quiet hours, but the only person that will read this and have a great want to know the how of it is probably just me, yet I feel like if I don’t update this frequently (or dare I say – daily) I’m letting down Legions of non-existent fans. People somehow find this on my laptop and are somehow let down when there is no new content, banter or running demo. Everyday someone out there is doing this very same thing and it takes the wind out of their sails to know that good ol’ Eric, is losing the fight.

Maybe, it’s just me that feels let down. Like I have some great opportunity to create something that, if nothing else, is distinctly me. Flaws and all. Maybe the idea of wanting to be something so badly is better than actually being it. Or that I was doomed to fail from the start and I was just playing developer the whole time. The project just a minor diversion, a puzzle to be figured out and discarded when I was finished.

Instead, I continue to come back and write new code. A new part that needs installation or a new trick for graphics. So the one fan out there that really wants this to work out doesn’t feel like they invested time in nothing. Because I am that one fan and I read this to know that someone out there is trying to find a better life the way that they know how – 1 line of code at a time. Because every so often, I get to write poetic sounding statements and be that person. Because periodically (or, *gasp* daily), I get to be the developer Superstar, capital letters and all, and I’m building something that will be great. It is something that I made from nothing, something that I summoned forth from the aether through sheer force of will. Why? For the one person that reads this, who wants to be a Superstar.

- In non-rant news. I worked out a way to include scripting. I can use an Include file (like the levels). The scripts themselves will be cute things that are unique to the screen itself, like air vents or traps. These wouldn’t have to be built into the engine and would still work. I think including them as individual Functions (lots of them – grouped by level) I can call them up when I need them instead of always running the Ifs on them. I would be able to do some very cute things using that.

- So what’s on the menu for today? I’m going to start the final bit of combat code – the timing system. I’m not sure how it will work yet, since the enemy attack and the player animation run on different systems. Hmmm…..

-Here’s the idea. A function that controls the animations so they line up. Right now, the combat collision occurs when the animations overlap a collision rectangle. This is for Zero and for Akuma. It’s a consistent system which makes me happy. That system works, so I am not going to screw with it. All I want are lined up animations. So the new function will keep distance in mind (so Zero doesn’t parry when he is too far) and then somehow check for current state and enemy attack. It should work, but I need to figure out more.

12-3

Almost a month, worth of finals and projects for school. Consequently I’ve had less time for programming. In the meantime, I’ve reconsidered the backwards move. It should work, but should move at the end instead of the beginning. In other words, when you press the button, the PC should begin the back step animation, but not actually move until the end of it. That way it won’t break the enemy attack string. Also, disconnect it from the Dash Bar. Somehow, in my mind, being able to dash across a chasm and defy the laws of physics is more impressive and better use of the bar than a step back. So, I’ll tweak that today and try to install the animation to make Akuma face left. Finally.

-Cool, that works better now. Also, since it uses a basic equation to put the animation in the right place, it’s very smooth. It also seems to work well in the context of the combat and you can be kicked out of it. So, yeah. Cool.

-Akuma turns around now. Oddly, I had set all of the animations to draw at a specific place, so when you turns around he didn’t attack in the right place, say the attack was to the left, Akuma would kick and his foot would stay in one place and his body would jut forward. In other words, it was stupid. So I corrected that using a new variable. Now, depending on the direction Akuma faces, there is a variable that keeps track of his drawing modifier. Smiles all around on that.

- Now Akuma only sees you when he is facing in your direction. It’s not the hottest thing in the world but he sees you and chases you. He also doesn’t lose track of you when you roll behind him.

-New Dash. Now when you dash in close during combat you actually come out right behind him, but still in range. No more overshooting where you can get pummeled. It also keeps you close enough to not get the facing directions confused or knock Akuma out of his attack string. Now if you hop behind, he turns around and continues to beat you down.

-New attack bit. Since Akuma faces a direction, he will now turn to face you after you hit him. Also, extra damage for a sneak attack.

- Not all good news. I overwrote the last save, mostly since I am dumb.

11-20

Issues are what is up today. Home sick and getting some other work done. So I installed the combat movement in and now I’m debugging it. Odd thing is the Enemy Attack system. You see, when the enemy comes at you, they stop at a certain range (adjustable by Skill and by extension, enemy type) and then they attack you. Issue is, if they are not within that range they don’t attack. So if they come up, and you move, it disrupts their attack pattern and they don’t attack at all, regardless of how close they actually are to you. It’s confusing, but I found a workaround. Now, instead of a slow backwards movement like originally designed, the player can now do a short backwards hop away. I then tied the hop to the Dash meter (that also powers aerial dashes, ground dashes and the combat roll.) So now you can move in, but you can’t just hop away (since the Dash meter needs to be filled for it to work). So you can use it to dodge and move into a better position, or you can hop away and then block and hop again, but you cannot run away forever. Now it needs some animation to look sweet and everything should be good to go.

-Random consideration. Since the Combat system uses the Dash Meter almost as much as the Exploration system I may need to add something to the Player Character that represents it. Maybe having their weapon change color slightly or something. That way you don’t have to look at the upper right of the screen to see if you can hop/dash.

11-8

I uck, and the S key is going out on my keyboard. No update in forever. I have no excuse really, except for my shiny new XBOX 360 that I got for my birthday. Anyhow, back on the case. Yesterday I finally adjusted the lunge system and it works at a distance. The idea I had was to assign the attack variable to either 1 or 2 depending on the distance to the enemy you are when you press the attack button. The system then pays the appropriate animation and does the appropriate thing based on what the attack variable is. So the issue from before is all fixed now. Now the idea is to install the lunge damage system which will do damage on a random variable based on the enemies skill level.

-Had a design idea. First, the PC should be able to move forward and backwards while in the Combat mode. Forward should be pretty quick, but backwards should be slower than the enemy moves, so they can catch you. Kinda like the movement system in Street Fighter. To avoid lunging, then putting away the sword, then moving and lunging again, I’ll install a “put the sword away” delay when you put the sword back. So I’ll try to install that business.

10-13

Don’t worry about yesterday’s update. I barely had time to hit the save button before the whole system ran out of batteries. Turns out, my laptop has a battery that doesn’t work no more. So, hooray for that. Anyway, like I was saying yesterday, I think if I had a variable that controls the distance from the enemy, then the attack/action key could be sensitive to the distance. So use a 1 for close and 2 for medium and 3 for long, or something like that. I’ll give that a try and install the lunge graphics. After I have it worked out, I’ll work out a system so that the lunge stops where it is supposed to.

- Just tweaked the combat control system. For some reason, whenever Akuma hit Zero, he would move a little forward and that made it harder to see what was going on. Turns out, when Akuma kicked Zero, it knocked Zero up just a little, and out of Akuma’s Sight Line. Since Akuma didn’t “see” Zero, he continued his patrol route, which meant he would walk forward (or sometimes backwards) and continue to beat poor Zero to death. Even worse, when he actually overlapped Zero, the throw command didn’t work and a weird bug occurred where Zero got hit continually and died. So that’s all better now. Also, now when the enemy does hit you, it resets the attack mode so he stops hitting you. Makes it a little more fair and a lot less frustrating.

- Odd, now I can immediately hit Akuma after he hits me. This isn’t good since I have more HP than he does so we can trade blows until I win. Hmm.

-Still no fix on the above bug, now I’m onto other stuff. The lunge code is installed, but buggy. The rub of it is this – at long range Zero moves forward – eventually he’ll have animation, but he moonwalks for now. At medium range he dashes forwards and is supposed to do the new lunge animation. I know the lunge isn’t showing correctly since it is green (not red like the lunge is supposed to be – see 10-11). Then the close range is the regular attack. The issue is this. When the lunge moves close, then the character is close range – and does the regular attack instead. Grr…

-More news, New Damage Frame! Woohoo!

-…well I thought it was nice. =P

-The attack animation is really fast. It took 4 frames to do, running at 30 frames per second, so it was faster than Cassius Clay hopped up on Meth. (nobody got that reference.) So, I went ahead and changed it, so the animation runs on 2’s (changed every other frame) and looks better now.

10-12

Today the plan is to finish installing the lunge code and make the attack be dependent on the distance. I think the seti

-New Note. The computer crashed the first time I posted this, like it says next. I just noticed that I was in the process of mis-spelling the word "Settings."

-Speaking of Spelling. I wonder if the word spell has anything to do sorcery. So I wonder if the original term for when something is Mis-spelled then it literally is not done correctly, and ruined the magic spell. Or it was the other way around, but wouldn't it be cute if grammar was based on alchemy?

10-11 : 3655 Rows

Today I had some time to play with the main system. So I started just doing small tweaking. Now the Double Jump is more of a flip. After considering some of Steve’s (that my friend from High School who is kind enough to provide character designs and animations) artwork for the Thief, I realized that a standard Double Jump just doesn’t work thematically. He’s an acrobatic thief, not a fuggin ninja. So now it’s more of a Flip which give just a little extra height – maybe 125% or so. It also allows better changes in direction while in the air and looks better.

I also began some work on the Lunge system and set up the distances needed for testing. The lunge is really a variation on the Attack system that makes the attack system distance dependant. So if you are close you attack, further you lunge and further still you’ll approach. The idea is that if you are far away, you can hold the button, approach and the lunge when you get closer. For now, I have tentative systems in place that change color to let me know where the hell Zero is in relation to the enemy.

-In terms of this, I appreciate the fact that I worked out a way to put Akuma up on stuff first. It allowed me to put him safely up on top of a platform so I can test distances without him beating the hell out of me.

-Also added some tweaks to control. Now, the Ctrl key is an all around Action key. It jumps in Exploration Mode (not fighting) and attacks in Combat mode. Alt still does dashy style moves and shift still whips out a sword. Also have a new placeholder for combat – the old block animation. Looks good, for a placeholder.

-Built a lunge animation. The slash is red since I thought it would be cool. Still not in the game.

- Updated the ExitProgram() function with the CloseGraphics command and turned of the Unload() Function. I think that CloseGraphics closes all of my graphics which made Unload() redundant. Now the program closes and doesn’t crash. So, yeah, smiles.

- Now in random news that I didn’t add when it actually happened a week ago. Mittens passed away. I came home and she was all curled up in her box, so we took her to the parent’s house and buried her next to my old rat Scabbers. She fit into a size 9 shoe box. Now when I look at her box, I think she’s going to pop up looking for cheese or crackers. She doesn’t since she isn’t there anymore, and it makes me sad.

- Can’t end the entry on a downer, so Sonic is in SSB Brawl. So, yay. Still no word on whether Marth is AWOL though. *sigh*

- No new code file for today. I over wrote 10-10 since I didn’t really do anything on 10-10 and didn’t feel non-flickering was worth his very own update.

10-10

Such a wanker. Totally slacked off and was playing the original Prince of Persia. Good news is that since I designed the Thief game to be a Prince of Persia style game before I ever played it, the gameplay so far is almost nothing like Prince of Persia. It’s like I was given instructions on what a Prince of Persia game is like and decided to make my own. So the good news, like I was saying, is that My Game, is wholly unique.

-Not that I got any real coding done recently. Today I got 1 thing done. Akuma doesn’t flicker anymore. Looks sweet. But, for my thoughts on the progress this week, please refer back to the first sentence.

-In more news, I figured out what a Class is. It sucks since it is too late to implement.

Archive

More archive now, so, yeah. Same as the first chunk of archive, but fresher.

The Game

Okay, so it occurred to me that the Game that I keep mentioning has no context, so here goes. The game is tentatively called The Thief's Tale and features a main character with the inventive name of The Thief. The goal of the game is to escape a Castle and clutches of The Princess, the person who imprisoned him in the dungeon inside said Castle. Throughout, The Thief encounters a variety of mis-adventures eventually leading to several endings. You'll have to play the game when it is finished for more (sorry, no script postings - can't give it all away for free).
The names are done that way on purpose. Instead of just having nothing names that convey in some sense what I want to say, I've decided to leave the names themselves as a kind of cipher. In other words, nobody remembers the names anyway and the characters all get reduced to titles. So, instead of giving some made up name, he's just The Thief. The Princess is just what she sounds like. The Captain and The General are the same. Since I'm telling a fractured id centered fairytale I've decided to deconstruct the story at a super basic level. Then, the characters just are.
-The game itself is a platform game, in the style of the original Prince of Persia, but smoother and with better control. In effect, I really wanted to add some of the newer gameplay elements into that kind of game and make it relevant again. Then, once I've done that, the goal is to take the basic platforming gameplay and stretch it as far as it will go. Almost break it so it's new again. I have a previous post about Olde Skool and Next Gen, so look it up if you're confused.
-Oh, google lost me after I added the ad. Oh well, they'll spider again eventually.
-I had another idea. Today in the news Microsoft revealed that they will make XNA available to offer games for sale. FOR SALE! I thought that I may eventually port the code to XNA (which uses C# - a language without Global Variables. Who TF doesn't use Global Variables? It's like having sentences without nouns). But, the lack of really caring prevented me. You see, I don't care about the Microsoft custom language that they built. It strikes me like learning to speak Hawaiian. Sure you can talk to that one guy you know, but who else gives a crap? That changed when I learned I can offer a deal. Right now, I have no money for the project, so I could not pay a programmer really, well, anything. What I could do is try to convince them to work for scale. So, port the code to C# and get it to run on the XNA service and help me go through the appropriate hoops, and I give 25% of the net profit. In the end, could be nothing, or could be lots. I'll put ads up when the code is feature complete on my end and I have the assets in place.
-If, and it's a big if, considering Google lost me, you find this and are a programmer that knows C# and would like to work for "maybe" money, please leave a comment and I'll contact you.

Capitalism

So, I was screwing around and I found that I could sell out and put an ad on my page. I don't know if it does anything at all, but it makes me happy for all the wrong reasons. So, since nobody reads this but me, the link will get zero traffic, but If you happen to come across my crap in the sea of crap we know and love called Internet, then feel free to click the link. I think I might make a fraction of a cent, that, due to inflation, will immediately evaporate like Hawking Radiation.
-In other patting myself on he back news, I did finish A Brief History of Time.
-The inaugural advert is helping Burma survivors. So, I feel good about that, you know, not trying to sell Cialis or something built in Sweden by "Scientists."

ThiefEd

So, yeah. Since I haven't posted all of the archive yet, the Level Editor that I'm currently building is called "ThiefEd" (pronounced Thief-ed, like how a mental child would say Thieved). It is the Level Editor - hence the Ed part- for the game with the working title The Thief's Tale. Which is in turn a play on A Bard's Tale and The Prince of Persia, with an emphasis on the The.
Anyhow, I've worked out the Portal Rectangles, so that's super cool. When you select and build one, it saves what you're working on, takes you to the Map, allows you to select another (or the same, if you're crafty) level, place a marker, and then it reloads the thing you were working on and saves the marker you set. See, couldn't be easier. Next up is to set the buttons in place and the other cute bits of nothing that help make the editor easy to use. Ease of course being important, since I don't want to fight with the editor while I'm making the content.
In other stupid ideas, I worked out a neat way to combine the editor and the engine. You see, what I really want is the ability to play the game in the editor. That way I can make very fast changes to the system, play it and test, then make changes to really make each screen and puzzle flow really well. To do that, I realized that I was lazy and made all of the variables the same name. At first I thought this would be a liability, then I realized it was in fact an asset. The trick now, is to move the communal ThiefEd and Engine variables into their own file which I reference (since I can't have Global Variables declared in 2 different programs that reference each other). Then when that's done, I'll update the engine so read the Load File functions that I built, instead of the Cave Code that I have in their now. Then make the Engine Loop a single function, made up of the pieces already in it. Then call the Engine Function, as a whole, from the Editor. In essence 2 things will be going on onscreen. The Editor will allow me to move and create, while the Engine will find collision, and deal with movement. The really cute bit about the idea is that it will do both at the same time. So, I should be able to try a jump, realize it doesn't work, and then change it and try again in the same screen, without loading up anything. So, that's on deck after I install the enemy placement.
Speaking of which, I had this idea to make a pop up menu for baddies and all that. Instead, I'll put a clicker which will be easier to implement. So click up to change the enemy level and the enemy type. Sounds easy right?
-Basic game philosophy. I have a basic thought for game design and it goes like this. A game should make you look cool, and it should reward you by making you cooler. As an example I'll use Ninja Gaiden Black. If you want to know what it is, look it up on Wikipedia. Anyway, as you play, you start off with a pretty good assortment of moves and the ability to lop freakin heads off. You start off pretty bad ass. But, later in the game if you play the same way, you look like a retard and you get hacked. However, if you're skills improve, by the end of said game, you are Death Walking and are a super ninja. (As opposed to a Super Guy). So, it makes you look cool, but you can tell a good player from a crappy one, based on how cool they really look.

Pictures

Okay, it looks like I can insert a picture. So, there----->
It's a picture right? 'Sides my pet name is Sugar Bear, I know, adorable. Plus I own a green sweater just like it.
Otherwise, I see no reason to have my pictures in the diary. Maybe images of the project, but not of me. That would be, douchy. Instead, I'll update the image when I feel like it.
-In actual game related nonsense, the plan for tomorrow (after sweet, glorious sleep) is to go ahead and install the rectangles for the Portal Rectangles in the ThiefEd Level Editor. The idea is to have the program set the rectangle dimensions like it usually does, then keep track of the current level (lets say 1) and save it. Then it will load the Map and let you select the screen the Portal Rectangle goes to, it will then Load that screen - but lock the controls out (so you don't screw up the level). The only control that will work is to place the character. Then afterwards, it will load the previous level and save the destination Level and Coord. See, easy as pie.

CID Welcomes the Google Bot

Hmm, a break from the uploading of the archive for a moment. It seems that the Google Spider finally found me earlier today, when it was doing its internet crawl thing. Oddly, when I type in the exact name of the Diary "Confessions of an Indie Developer" I'm 4th in the list. I'm okay with that, since this is The Diary That Nobody Reads (Caps, since it is a title).
-In another thought, what's the deal with Internet? I mean, it sounds like a dangerous place, full of Nets, Spiders, Bots, Hordes, Daemons, Webs and Portals...and apparently these things all get by eating Spam. This is why the elderly sit in the kiddie pool section known as Yahoo! or, god help them, AOL. Maybe we (and by we I mean somebody else) could change the names to cute sounding things. We could have a Mail Puppy, the Google Goat could wander into sites and graze them a bit, and instead of the Global Web, we could call it a Series of Tubes.

9-27-07

Dumb, really dumb. That’s what the computer is. I tried to implement the new physics system, and then the program would crash every time it was loaded. So I’ve pondered for the last few days how the heck to test it so I can fix it.

-I also caught a weird bug. When you would dash and hold a direction in the air, you would disappear and then reappear when you let go of the key. Odd, but squishable.

-Sweet. Mas bien. The collision system now has the new counter system installed, which simplifies it and makes it more flexible. Now I could theoretically add more collision-ables and have it be more easily integrated into the engine. The issue was with the Event Handling. The function that controlled turning on the physics has a redundant rectangle overlap system in it and was first. The redundant system ensured that it would always work, regardless of where it was in the loop. When the redundant system was removed, the required information was not in place to control the outcome, so the function had to go after the regular collision. Yeah, I know. Took me 3 days to figure out WTF. But now it works.

-After that little side story, I’m going to go back to what I was doing – the enemy limits.

- I also worked out a new defensive/counter system. Instead of just dodging and then trying to attack on the off frame, I figured that I could install a counter system. So if the player hits the attack button at the right moment, the PC will counterattack, deal some damage and knock the enemy out of their attack sequence allowing a free hit. This way a good player will be able to lunge, duck, counter attack, attack and rush the enemies. More offense = better combat system. I’ve also considered that the actual dodge/block animation should be tied to the enemies’ attack. So when the button is pressed, the PC will enter a High Block or Low Block ready position. If it is the correct one, then the PC will do a defensive maneuver that lines up with the enemy attack in terms of total frames. That way they will finish at the same time. This also means that the player can focus on trying to Counter instead of focusing on holding the appropriate button down. Now I just have to code it. :P

- Emoticons are =D

-Done with the collision system. Now I can put Akuma on platforms and he won’t walk off like a weirdo. Since I had that installed I went ahead and made it so he only runs at you when you are on his line of sight. Otherwise he patrols back and forth. I may work out a system so that it locks the room down if the enemy sees you so you can try to sneak on by. I think that would be cool, but I’ll think about it a little before I update the AI system. After all, Errol Flynn doesn’t sneak. On the other hand, the main character is named “The Thief.”

9-23-07

Two different projects sucks, especially when they are connected. On the one hand I want to build the level editor since it is something new to do. On the other hand, I added some features to the engine and I don’t want to move on until those are all set. So today I’m doing a little of both. The Engine needs the Lunge function, and an enemy collision system. ThiefEd needs, well, everything at this point. So far I’ve set up a new window that pops up with the Ctrl key. This will eventually be the rectangle selection menu.

The other plan today is to set up a rudimentary enemy collision system. I considered using the same collision system that the PC uses, but disregarded that since it may slow the game down and make a slick system all convoluted and stuff. Now I have to figure something out. The enemy needs collision so they don’t walk off of things. That way I can put them up high on stuff and make the player fight them where it’s is more dangerous.

-A thought on the enemy collision. I could maybe set up Limits for the enemy. So they don’t fall off of things. I’ll build a test level and try that.

-I can’t stand it, I just can’t stand it. I built a test level using regular rectangles, and for some reason, when you touched them it put you on top of them automatically. So, yeah, that was stupid. To top it off, when you would touch it from the side it would make you run at it. Not grab like you’re supposed to, run. Or stand there like a retard. Turns out I did some tweaking of the collision rectangle code. Now the other levels were built using the Moving Rectangles and had it tweaked for those. Consequently, when I put regular non-moving rectangles in, it got all confused. Argh. As a side note, now I remember how I control the physics. There is a function called GroundControl that checks all of the available rectangles for collision. Now that I think of it though, there’s a much better way to do it. Using the loop, if I add +1 to the system when collision is detected, and then turn on the physics if the total is greater than 0 it would work even better and be smoother. I’ll try that real quick.

9-19-7 #2

A Second update? Yes, well I got bored and started playing around with a test for the Mouse system thinking it would take me all day to figure out. Well, I’m smarter than that, so that took all of 5 minutes. “So, now what can I do?” I ask myself. I know, a box that allows me to exit the program and figure out an overlap system. Bingo bango, I had a box that I could click, with the mouse and everything! (and it exits the program). Then I thought, what the hell, and made the Exit button change color when I could click on it. Then I got playing with the system and assigned a variable to keep track of where the mouse is and assign a variable to it. When I click it places the beginning of the rectangle, and then when I let go, it places the bottom of the rectangle, and draws a rectangle right where it is supposed to be. So, in other words, it works exactly like I wanted it to so far. Good day overall.

9-19-07

More research today. Along with some new gameplay additions that are now in the to-do list. First, the gameplay. I decided that I need a method for enemies to be smart enough not to fall off of things, so I need to create a rudimentary system for them to not run off of objects. I’m less focused on making them interact with the environment and their levels will all be pretty basic, but I do want the option to put them up on high, dangerous stuff for more gameplay challenge. If I did that now, they would walk off the edge and float, which is hardly A-game.

The other gamplay feature I want to add is a “Lunge.” With a lunge I want the player to move towards the enemy if they are far away and then attack quickly when they get there, with a random chance of doing a hit. I thought that the current system is very defensive. You would pull out your sword, wait, dodge and then attack. Or you could put away the sword, run at the enemy, try to pull out your sword and get punched in the face. The lunge feature would keep you armed and ready to fight and bring you into the combat. Errol Flynn doesn’t stand there and wait for enemies to attack him, he gets up in their faces and kicks their ass. With the lunge feature, The Thief will too. Since I’m talking about it, there will be a random chance of doing damage with the lunge. I’m thinking generating a random number (up to 10 maybe) and then subtracting the enemies skill level. That way the lunge will hit weaker enemies more frequently than hard enemies.

-Yes, I used the term A-game and I’m a little embarrassed about it.

Finally, I think I have a way to save information. It’s a little convoluted though. It works like this:

First, blitz will not let me create an all new file, but it will let me copy a blank one. So I will have a blank file in the system that I can reference when I want.

Next, when the player is all done, they will enter a code (4 digit – since it will be easier to keep track of for the map). I will then copy the blank file and name the copy the code.

Then, I will open the new file and save the information into it using the WriteFile command and then close the file. It will also work backwards for opening a file.

In the game, I have a set of variables that represent the level information. I will then load the level file into the game when you get to it. Nice and streamlined code, as well as hilarity, ensures.

The final trick is this: the levels are not going to be named 1,2,3,4 etc. Instead they will have Codes (now you see why I want only a code for the levels). That way, the Portal rectangles will have a Destination Code and a Destination X and Y. The code will tell the system what to load and where to put the player in the level when they get there. Doing that with words and text, would be a lot more difficult.

Now, I’ll start building the ThiefEd level editor since I have a goal and a plan for making it work. Smiles.

9-13-07 – No Update

Today was all about research. I learned a couple of tricky things. The first is that Blitz is capable of doing a variety of windowsy applications using a gadget system. This doesn’t do me any real good though for the level editor, nor does it allow me to (yet) create a window that I can close for the main game, but I can figure that out later. Another is the <> command. Which means “if this variable is greater than OR less than this other variable.” So I can more easily check on that. The odd bit was that there is no C++ variation that I know of that does the same thing.

I also had a look around and found the MouseX and MouseY commands, which tell me the current X and Y locations of the mouse, relative to the window. So, it is not absolute and I can put the window in funny places. OR since my resolution is nice and high, I can create the level in 600x800 in a window, and have my widgets and buttons all around the outside.

My thinking is that I can set up “Sectors” that the system will check for collision on. After all, I’m building a platform game – I know all about how to set up a collision. If a click happens on one of the Sectors it will do stuff, like erase the rectangle or select a new one or change what the editor is doing. Otherwise, it will get the mouse and set the X and Y as a point. Then the next click will set another point. I will then subtract the second X from the first X to get the Width of the rectangle and do the same with the Y’s for the height. (I may have those confused though, I keep a compass in the system to help me keep track :P ) The system will then set the X,Y,H and W as the values for the Rectangle that I have selected. I’ll add other stuff to allow me to change where the rectangle is and adjust it for playability. That’s the basic system I will use for TheifEd.

The other major challenge is saving the variables when I am done, along with experimenting on importing them into the game proper. I’ll figure that out tomorrow.

9-11-07 -3437 Rows

Yesterday I figured out a new collision system using a single background image. So, maybe for the next project. In the meantime, there are 3 things that need doing.

1)The animation reduction algorithm. Since it isn’t an engine system, it can easily wait until the end to implement when I’m Gold Plating all the code and optimizing. So I’ll skip that for now.

2)The enemy Push state. Again, the system in play works and needs animation, and a system to implement the animation…but there is no animations and it isn’t an engine system, so I can skip that one too until I have more animations to work it.

3)The staggered state. This is just candy, and not having it will have almost no effect on the final game. So I’ll add it when I have more time, and an animation. But if I don’t get that I can skip it. It may affect the timing of some speed areas, but those can be tweaked to not need it at all in the end if I want to.

So for today, I’m tweaking the combat system to allow for only 2 kinds of attacks, a high attack and a low attack. This should simplify the combat system a little and facilitate dodging. After that, I’ll try to tweak that bug that makes you duck and move.

-The combat system is easier now and it is possible to beat an enemy set to 9 without getting lucky. So that’s an improvement I think. Also tweaked the speed a little bit so now the animations are a little slower so you can see WTH before you get your ass kicked. That’s good news for players, bad new for my animator, since now the combat needs more frames to make up for the different speeds. Oh well.

-Cool, easy bug fix when I had a new viewpoint. I was getting all hung up on event handling and making my variables line up. The best way was to tell the system, “Hey, jerk. When the down and left/right are pressed, ignore the down key. Sheesh.” Now if you hold down and run you just run. As soon as you let go of the running key, you duck immediately. If you duck and then run, the run overrides the duck. So all is good in the kingdom.

-With that, the bugs are squashed and the engine features implemented. So the next project is the level editor TheifEd. So the next entries will probably all be Tests that I’m running. For TheifEd I need to learn:

-Making the mouse work and recognizing where it is.

-Making variables be stuff based on the mouse position.

-How to design a GUI that is easy to work with and isn’t oogly.

-Save it when I’m done in a format I can import into the game (maybe via the Include command).

-…and a dozen more things I don’t know how to do yet.

Then again, when I started the Engine I didn’t know what I was doing either, and I learned as I went. One day, I may consider myself to be a competent programmer. Until then, I look at code and puzzle out what does what then create test systems. Eventually, I combine these Tests into the prototype that does something and then I continue to add features to the prototype until it works. This time, I’ll try to keep it all straight. The Engine is made up of dissimilar bits of code with a variety of different naming conventions and so forth because of this prototype system (iX and iY are the player coordinates, but Rect1X, Rect1Y etc are the level coordinates. If I was consistent they would be PlayerX and PlayerY or IRect1X and IRect1Y). So I’ll try to have better practices with the new system and better commenting while I’m writing the code, not after. So now, the next bit.

-Maybe. It occurs to me that I can now build a test level, not just a single screen, but a Level. I’ll consider doing that for interviews later.hmm…

9-6-07 -3437 Rows

Today I plan to install the Push system into the Combat. The first to get it, and the plan for today is the “Throw” version of the code. The idea is to use a variation of the Wall Jump code, since it calculates and automatically moves you. So I’ll probably add that to the Doomed status. So, when you get tossed it adds the move variables (that won’t be added when you’re falling) and then the system goes to Doomed, then goes to kneel when you hit the ground. Maybe that could work, so I’ll give it a shot.

-Done. Had a problem though with the movement issue though. The system is set to default to the Fall status when nothing is going on and you’re not touching a platform. So when I kick the player up into the air it wanted to default to the Fall status, not the doomed status I set it to, so that needed some tweaking. Finally, it wouldn’t kneel when you landed, and the code is written in pieces, so I had to look in 4 different places for it. Aargh. It works for now, but without an enemy animation and only in one direction. The next step is to add Enemy Facing and tie it to that. After that, different enemies will have different pushes, so that can be implemented by Variablizing (is that even a word?) the code to accept different stuff for different enemies. Then I’ll consider creating a collision system for the enemies so that they interact with the environments. I wonder if I could use the existing collision system and add some bits to it. I’ll think about that.

The next major thing that needs doing is to convert the images to PNG’s and then consider implementing the Animation Reduction Algorithms. If it would give a performance boost I’ll do it, but otherwise I’d skip it for stability. Maybe I could add it at the end of the project during tuning. After that, I get to start the all new sub project of ThiefEd for levels.

-On a totally side note, my Rat Mittens has a tumor, a big one. I’m totally conflicted about it since it doesn’t seem to hurt her. On the one hand, I should take her into the Vet, but I worry that they’ll say “It’s too big” and put her down. On the other, I worry that it will get progressively worse, and maybe now they could still do something. This has nothing to do with the project, but I just needed a place to vent.

9-4-07 -3381 Rows

Today I installed a state where you hit the ground hard and stop in your tracks. It’s a little of a leftover from Castlevania and a replacement for the taking damage thing. This will also be useful in the next step which is the Stagger state. The only difference is the stagger forces you forward almost like a short, crappy dash. Well it will, eventually. That last sentence was in the totally wrong tense. I also created a placeholder sprite.

This will also be used for the Combat push you see. When certain enemies hit you they will throw you, which will make you go into the Doomed state (where you thrash around like a spaz) and then into the kneeled state. It should look good and do what it is supposed to. Different enemies will Stagger you to push away, which is the other half of the kneeled state effect. So I get a little glass and candy and something that is very useful later in the combat system. Two birds with one stone and all that.

-Definition : Glass and Candy

This is all the crap that isn’t useful and could be cut from the game without affecting it much. Specifically, “Glass” is all the pretty graphical tricks that don’t add anything. Transparency, ragdoll physics and crap like that don’t do anything useful. Not glass is a useful and well designed HUD, since it is important to the gameplay. “Candy” are game elements that add nothing to the overall experience like the Kneel status, or an inventory system in an action game, or most maps. In all, they’re nice, but you don’t lose anything from not having them.

This is not to say that those things are all stupid, just remember that you can’t build a house out of glass since it won’t stay up, and you can’t just eat candy without getting sick. So add them at the end of the project – or when you only have a few minutes to code and want to get something done.