Speedy Update

Had a weirdly busy day, so here's just a quick update, mostly in video format.

Worked a bit on the pong game today, but didn't make a whole lot of headway.  Spent most of my day at the studio, trying to help kids with their forms and get a workout in too.

First up: Here's what the OLD version of my pong game looked like (Fair warning: It's not pretty, but keep in mind I was about 12 when I made this)

And here's what the new(er) game looks like at the end of Day 2 (Going for a 7 day development... most likely will fail but we'll see, its a test of my SpriteObject and Camera classes)

Nothing changed much between day 1 and day 2, Day 2 was just getting buildings up, bullets in and ships, but beyond appearance they aren't yet very functional.

...aaaand doodle time.
Night world.
enjoy

But before I forget, my wonderful mother wished to be mentioned in my blog.  I would go over the ways in which she has helped me achieve much more than I had ever hoped for myself, but that list would have here all night, and I'm exhausted!


Suffice to say, she is amazing.  She let me doodle during school, so you have her to thank for these doodles.
Doodle time.

It's a draw

Randomness

Between a rock and a hard place

- Kev

Gravity Sucks

Which is why we should all have jetpacks.

As a forewarning, I'm running out of doodles from my notebooks, because, SURPRISE, I'm not in class!

Which means I don't always have paper sitting in front of me, and I'm not always doodling.  Funny that summer would stem my doodling behavior...

Rest assured I spent some time on the tablet this afternoon so your loyalty will be rewarded with some goodies!

What is this madness?

 The video is - basically - what I did today.  Played Sir-Issac-Newton and wrestled with gravitational equations.  Ended up being (again) a very simple solution that took me far to long to realize.  Now I know it currently looks pretty meh, but trust me, with a few more days of work that space scene is gonna look pretty hectic!

DISCLAIMER - It recorded the music I was listening too.  Oops, but too lazy to fix it!

I'll find my old game and put up a video of it to give you an idea of what I'm going for.

Anyway, in terms of the other game David is still trying to port the system to enable dual-platform development.  Not that we'd really develop on two platforms independently of each other or even simultaneously, but it's good to have the system ported so when we finish the game on one platform in one language it can be easily shifted over to another for more awesomeness.

Yeah, my vocabulary just kind of ran out on me there.  Don't hate.

Believe it or not, tickle fights can be powerful motivation for exercise.

That's... actually it for now.  It's 12:30 and I'm pretty tired, and I didn't even do much today.  Maybe part of my exhaustion is coming from eating that whole pizza.  Probably not one of the best of my ideas...
I was doing well eating healthily.  Oh well.

Will keep you all posted on further developments with my week-game and the original project.  Hope it goes well.  In the meantime, if you want to hear a Pro talk about some of the same things I am discussing, check this out, David showed it to me.

On the one hand, discouranging, on the other, fascinating and inspiring.  And don't tell me how it ends, I haven't finished it yet.
Another Dev Blog, but Better

Deuces,

Just because you can, doesn't mean you should.

- Kev

I did it!

I did it, everybody.  I finally got a YouTube account, and got the free version of fraps.  Which apparently only lets me record up to 30 seconds.  Drat, but its enough to show you how the camera system has developed (the camera area is the blue rectangle, it might be hard to see because of the quality, but I didn't realize that at the time) and that it actually works, instead of just spewing words out.
This is only a temporary stand-in update, more to come later, I just wanted to get the video up to prove that, indeed I have developed something!  And something viable, as well!

- Kev

One small leap for Kevin, one giant leap for...?

A late night update!  Which means what?
Well it means I was too darn something-or-other to update this afternoon.  I have successfully finished the last touches on my Camera object!

I'm so hood.  Good, I mean good.  Please don't shoot me.

Now the camera object, bear in mind, is not a new concept in games and different versions of 2D cameras have been created probably thousands of times by programmers far more adept than I am, and they probably did it in half the time, if not a quarter of it.  However I stubbornly refused to turn to the internet (safe for Microsoft's reference pages, which just tells me what a particular method does, since XNA itself has very little in-dev-kit documentation) for any of my solutions which means a few things:

a) I figured this stuff out on my own, using brains and trial-and-error.  Okay, so mostly I used trial-and-error, sue me.
b) I probably did it in all the wrong, wrong ways that better coders would cry to witness.

Or shoot me with a missile, as I devour a sub.  You know, whichever is easier at the given moment.

But I got it done, and hopefully I learned much in the process.  I'm still not entirely sure of what I've done or how I accomplished it, but it works and tomorrow I'll go back over everything to see just how I got all this crazy stuff to work, and try to streamline the process or make it more efficient.
BAHAHA.  Who am I kidding, efficiency just isn't my thing.

WHAT IS THAT? IS THAT EFFICIENCY? OH GOSH KILL IT NOW!

If remember, or care enough to skim through my previous post, the last problem I was having was with image rotation and having a nice clean rectangular cut off of the image rotation so I could have a 2D camera with any given bounds on my screen.  My problem came in when XNA drew a segment of an image based on a rectangle and THEN rotated it, which means I couldn't just cut off an image at a certain point to match up with the edges of my camera because after the edge was determined, then the image would be rotated, ruining that perfect edge that I had before.

My solution?  (warning: this is a pretty crazy solution).
If the rotation wasn't 0 (normal image) then my program gets color information (pixel-by-pixel RGBA information, Red-Green-Blue and Alpha bits of info, respectively) from the specific frame of the image I wanted to draw, and then using a transform matrix (remember matrices? yeah those things come in handy apparently!  Luckily XNA does most of the work for me) that is formed using the rotation amount that we are looking for in the image and creates x and y "steps"

Pic Unrelated

I myself am kind of fuzzy on how all this functions, but I'll describe it in the best way I can.  I create a new blank image of the appropriate size, and then the "step" x and y from the first image, a pixel-by-pixel break down of the colors are transformed on top of this new blank images, and the step x and y are used to go through the rows of the rotated image pixel -by-pixel and row-by-row.

Now I have to do this because even with this new fancy transform my old image is still a rotated rectangle with pointy edges where there should be nice vertical and horizontal lines.  So over the new blank image I extract the color points from the old rotated image (only my new blank image is nice and square)

This works fantastically except for one thing: the step x and y are integer values, or whole numbers.  Numbers such as 1, 2, 3, 4, 1712, and 813,145,845,993,2452 (though that would be too much information to hold as an integer value in C#, that could also exceed a long int too, but I'm too lazy to check.  I believe it does, but don't quote me) which means when I rotate the points using a transform matrix well at certain angles I get blank spots, or pixels that are skipped over simply because of the lack of precision when being forced to stick with whole-number values.  From my knowledge there is no way around this, you can't  have .5 of a pixel, that's not possible, but as I stated that means I have blank pixels in my new rotated image.

To solve that I simply used a handy-dandy color interpolation function, using the color values of the two pixels to the left and right of the blank pixel to form a new color in-between the old.  It works well enough, and since these rotation functions are only called when at the edge of the screen (where a part of the sprite is "off-screen") it should not be enough to be noticeable or to detract from the atheistic of the game.

And with that, I have a complete camera class that can display the game world from any position, with any zoom factor, and that can take up any rectangular space on the screen without having images "spill over" it's bounds.

The game that I'm working on with David now doesn't need half, or really any, of that functionality, but David will be happy to know the Camera class can now handle his awesome menu idea.

Rock on,

"But not too hard" - Clergy

- Kev

Tastes Like Chicken.

My fried brains, that is.

/Plug for Aston Kutcher's new show... Tazed'

I had what felt like an epic two-day wrestling (or wrass-lin' depending upon your location in the good ol' US) match with my camera object class.  My Goal?  To be able to re-size my camera, have different dimensions, and be able to have multiple camera's running at once.

Wrass-lin'!

The Good news: After two days I have locked down what were relatively simple bugs and have cleaned them out for good!
The Bad news: I'm not done yet.
I still need to find a way to account for rotation.

So let me give you (y'all?) some background on the situation.  XNA, being the lovely system that it is, allows me to draw textures using some lovely built in functions, namely the SpriteBatch method Draw().

I hope you are not THIS confused by the following paragraphs...

SpriteBatch is XNA doing two things: Making life easier by eliminating the need for me to work directly with buffers, and making life harder by eliminating the flexibility that comes from working directly with buffers.  Confused?  Well then hold on to your britches and kiss your buttocks goodbye, and for your sake I hope you wiped last time you used the restroom.

All jokes aside, buffers are simply how the computer draws.  All the images that are to be drawn in the next frame are sent to what is called the back buffer, and upon the next cycle of the program's main loop the back buffer and front buffer (the display area) are "flipped," the front buffer is cleared, the elements on the back buffer are sent to the front and a new back buffer is set up.  Essentially a computer draws every frame twice, at least from my understanding.

The disclaimer to this blog is that I could very easily be completely wrong, but from the limited experience I've had working with buffers this is my understanding of their functionality.  If you know more about buffers (As in, you actually know about buffers and not I-looked-these-up-on-wiki-peida-and-I-want-to-look-smrat*) please, contact me and teach me!

*smrat: Close to smart, but obviously not.  If you do something like this, then I will send my robot minions after you.

Anyway, Getting back to my original point...
 SpriteBatch's draw function takes the following parameters in order to draw your images (or this is the function I use)
Draw( Texture, Position, SourceRectangle, Color Tint, Rotation Factor (Radians), Origin (Center), Scale Factor, SpriteEffects (this is irrelevant), and finally Depth)

Now relax, calm down, and take a breather, this is all pseudo-code, you haven't caught Nerd-Cooties, your coolness factor remains the same.  Just the same, maybe if you are worried about such things, don't tell your cool friends that you read my blog.

I swear I'm (almost) done with the jokes.  Back to the point, Texture is simply the 2D image that we want to draw, and Position is where to draw this image, after that it gets pretty tricky.  SourceRectangle is the hard part, but also the great part of the Draw function.  It asks for a rectangle area in the 2D image to draw. 

This is really cool because it allows me to take one big image full what seems to be a jumble of drawings or art assets, and divide them into pieces or frames that can then be cycled through to create animation.

This really sucks  because it makes me specify a rectangle, which as awesome of a shape as it is, has its drawbacks.
Namely the fact that AFTER I specify my rectangle, I specify my Rotation (which is measured in Radians, and not those pesky degrees).

This doesn't appear to be a problem (I thought nothing of it at first) until you realize it rotates the rectangle as well.  Now what happens if you take a square or a rectangle and turn it 45 degrees?  It looks more like, well a diamond now.

Which, when I go back to my Camera class I'm working on, if I want my camera only to display within a certain area on my screen, instead of on the entire screen, I need all of my images to have vertical/horizontal cut-off lines.  If I rotate my images... well then no dice, I end up with a diamond-shaped (or worse) image that juts out beyond my camera boundaries.

...But that's not all! (Shout-out to Professor Ash at DePaul.  And none of you will ever get this reference)  If you look back to the pseudo-code, after rotation then the origin is given, and the Scaling factor is given.  Which means AFTER rotation then we also scale the image.  This normally isn't a problem, but in terms of the Camera when half of an image is cut off, I only want to display half of the normal frame of that image, so for the SourceRectangle I only grab half, but the position and the origin (center) are that of the full image, which means when the scaling happens, the entire image scales towards the co-ordinate (0,0) which in programming terms is towards the top-left of the screen.

Long story short, when I scale half of my original frame, it also changes the "actual" position of the image.

exactly

What does this all mean?

Well it means I had to account for the change in position that takes place while scaling ahead of time.  I had to do this by giving the Draw function the modified position ahead of the actual scaling.  WHAAAAAT?!

That's some crazy stuff, yo.

But as of yet I haven't figured out how to anticipate the rotation of my image ahead of time too.  That is the final 10% of my camera object that remains to be finished off.  And then probably handed to David who is gonna fly out to CA just to slap me for the mess I hand him.

And if you are wondering: I have little to no idea how I'd ever get the rotation to work, considering no matter how many ways you try it, I have to assign the rectangle ahead of time, and THEN rotate it, and a rectangle rotated 45 degrees will always be a diamond.

I'm this much screwed.

And my cat wanted to be in a blog, apparently.
World: here is Toffee, hear him meow?

Ninja cat? Who doesn't like camera-flash.

- Kev

Success!

Another Mid-day update! You know what that means, I've actually been working today!
I've gotten the level and the phase systems working!  Now I know I said I may want to overhaul the phase system in the near future, and I might, but for the moment the base systems of the game are all in place and working.

The next step are developing enemies and levels/patterns that are fun, and doing things like tweaking controls for enjoyability, and crafting a HUD and etc.  This will be the time when David and I begin to get a feel for what makes a fun game, instead of what physically (..or virtually? Hmm...) makes a game.  We are in the process of learning how to take fun and break it down into math, numbers and logic.

If you told me that this is what I would be doing when I "grew up" a few years prior to this, I would have laughed at you.  There is no process for making math fun, or making fun into math in a sure-fire fashion.  A sense of fun will always be something that designers will have to be "born with" and it requires constant refining through trial and error, experimentation and adaptation, but when it all comes down to making the game happen, it's finding the balance between the fun envisioned and developed by the designer, and the logic and programming capabilities of the programmer.

Fun stuff!

Almost as fun as an anteater riding a motorcycle

So, until next time, those are the kind of updates you can be looking forward too!  There will still be plenty of technical fun, don't you worry, I'll still be working with my camera classes and side-projects, so rest assured, anybody who may actually like hearing about the technical side of making games, you will see more of the technical aspect!

TECHNICALITIES!

Back to development!

CHAAAARRRGE!

- Kev

One Fish Two Fish, Red Fish... Dude Fish?

Dumb things can sometimes be the downfall of my programming.

So David went ahead and overhauled some of the current programming structuring, esp. for my sprite object class which was sorely, sorely, sorely needed.  It now reads more like a dictionary of methods instead of the inane ramblings of an amateur programmer.  David: 1 Kevin: 0

And introducing, on the right hand side... oh. Nevermind

So the SpriteObject class I've been babying got it's first minor overhaul, and I must say it looks much nicer, and the plus side is David now, more or less, understands how to use my baby for gameplay purposes.  The only downside is he changed the names of some of the functions so now I get confused sometimes, but the added organization and naming protocols more than make up for the lack of familiarity I now have with the names.  I must admit, my naming conventions got pretty bad at some points.

Almost as bad as this doodle

David's clean-up aside, what have I been working on?  Finishing up patterns and level implementation.  I added a few minor points of functionality for enemy patterns (the ability to flip the patterns horizontally, and the ability to set patterns to looping or non-looping, again, minor points of some limited flexibility) and then spent the better half of my evening trying to figure out why Bill wouldn't go and sit as his freaking assigned target point.

(At this point, I'm working with four enemies sharing a same target pattern with different target offsets, or they all share the same set of points to go to, but they start at different points on the path.  I've named them each.  Bob, Brett, Bill, and Ronald)

I have fixed the bug, but I'm still not entirely sure why Bill kept skipping his target and trying to go to Ronald's before Ronald even had a chance to arrive at his own target.  Needless to say, this is not good and warrant's some more attention... that I shall give at a later date.

Ah, Procrastination

Once I get the levels working, which simply consist of multiple phases built onto one another, the game framework should be finished and me and David should be able to simply add on to the game from here until we have a complete product.

Indeed.

However I'm not entirely sure that I won't just scrap the whole damn pattern/phase system half way through the project in exchange for something more powerful, robust, and flexible.

I toss the term flexibility around often when I discuss code, to me flexibility is a piece of code's ability to handle many different situations and preform more in fewer functions.  Not fewer lines of code, optimization is not my strong suit, but simply give a few pieces of code that do lots of good, juicy work.  The more I look at the current pattern/phase system I've developed, the more I'm convinced that a new system will have to be created, and this time I'll have to really sit down and think through what I want the system to do well in advance of the start of my coding. 

or not.

...That's funny, it seems like somebody has given me similiar advice before....
Oh, right.  My professor.
Turns out I should listen to College Professors, who knew?!  My great enthusiasm to begin a project does not protect me from poor spur-of-the-moment implementation! (Though sometimes that is honestly when I am at my best)

Regardless, The system I have works, I just don't know if it will be able to handle all that David and I will want it to crank out, I designed the system, unintentionally, to be independent, each enemy has their own patterns that aren't known to others which in some instances can be great, but may need to end up changing.  In such an event some may say the current code I have can be salvaged but... Well let's just say it would be probably easier to devise a new system.

Which may make me do this.

It will probably be for the best though, help with my understanding of crucial elements of gameplay.

And how to make my code look as purdy as David's.

Until next time!

How will this end?

Oh.

-Kev

I'm a Loser Baby, so why don't you kill me?

Not much got done today.  Fixed a few things in the camera class that allows it to operate how I'd like for it too.  Which means the next steps are: A. Getting back to David and My's game, and then overhauling the failed game to be something I'd like.  I don't have a whole lot of time to dedicate to games it seems in the past few days.  Maybe I'll get better, but tomorrow I'm actually sleeping in and then at some point in the afternoon opening up for the TKD studio and wrangle a massive amount of young children attempting to preform martial arts.  They are all great kids.  Just a massive handful.  Imagine granting every child's (well, most male children's) wish to have permission to pretend to fight in a manner similar to what they see in the movies.  Now try to get them to listen to you and follow directions.

If you are a kid person maybe you'd relish this task.  I'm not against kids, I think they are great, I was one once.  Some argue I still am a kid, but I'm okay with that.  It's just getting them to do martial arts is always a fun and exhausting experience.  There may have been slight sarcasm in that.

So actually there's not a whole lot of game-update in this segment.  I'll try for more progress tomorrow that's relevant/updateable.  In the meantime I'll just... spew random thoughts?

Also: be on the lookout for a blog by me and my best friend Terrence, who knows if it will be anything serious.  At the moment all that will be on it when it gets up and running is about an hour of our conversation.  I think it's hilarious, but that's up to the listener to determine, I guess.

Rawr

- Kev

Camera Controls!

Good evening, everybody!

WHAT'S SO GOOD ABOUT IT?!

I didn't get a whole lot of work done today, aside from realizing I sent David on a wild goose chase in our game... because of an uncapitalized letter.
Oops.

My B, dude. srsly.

Aside from that I didn't get a whole heck of a lot done.  I fiddled around with the idea of a 2d "Camera" object that lets me essentially view the game world from any "position" and "zoom"

So far, the system works flawlessly (...depending on what you want it to do)  The camera can track an object or a point and it can zoom in and out.  What's so special about this may you ask?

Well, considering it's been done a thousand times before in countless games, nothing.  But the fact that I did it myself in about a day is something I am just a bit proud of.  So sue me.  What you don't realize about cameras (in games) until you start making games is how in the blue blazes do I get all of these objects to change their positions/sizes and rotations based on where my "camera" is supposed to be?

Well, it's actually much simpler than that, I create one object, a camera, that calls its own drawing function.  The game engine (not that you can call it an engine at this point... but humor me) is still doing all of it's calculations and movement with original sprite locations and sizes, but the Camera object calls a draw function that simply draws the objects using their location as relevant to the camera and at the appropriate size based on the camera's zoom factor and does a quick equation that adjust's the distances of sprites between each other based on the zoom factor, and then draws the sprites accordingly.

So, "physically" speaking the objects remain unchanged, but they are just being drawn on the screen in a manner that represents them being viewed from a certain position/height.

Did anyone follow that?

What?! No! I didn't, just shut up or I'll SHOOT.

I included nothing coding-specific there, it's mostly an exercise in conceptual thinking at that point.  I've got the system mostly working.  It handles zooming in and out perfectly, and movement.  Next is handling camera rotation (Why?! I don't know I like flexibility in my code, OKAY?!) then being able to "limit" my camera, so it doesn't go outside certain bounds and won't follow a player off of the map if he escapes, etc.

And I need to take some more pictures of more doodles, I think I've exhausted my current digital supply!  Or I can't tell what's been used and what hasn't at this point.  I apologize for any re-posts.

All that is man?

Silicone Upper-Body suits.  With funny-looking pecs.  Oops.

I could draw comics! (LOL NOPE)

A cool new hat?

The face of a programmer.  I just look like this for hours at a time at the computer.

- Kev

Home run!

This is how full I feel right now

I'm at home!  Finally!  I have (almost) no obligations now!  Well, except for work and chores and stuff.  But I'm finally home, and right now I'm way too freaking full.  Tomorrow I have to go for a run, shoulder injury or no shoulder injury.  I need to get back to working out.

Crippling self-image issues aside, I actually got a tiny bit done today, amazingly.  I had my youngest brother, Brian, playtest a game.  I gave him the controls and then let him play and tried to pick up on what I was doing right and what I was doing wrong in terms of the game.  This is one thing I actually learned at my year at DePaul was how to playtest your games.

You do what I just went through: set them down in front of your game, explain the controls and then don't direct their experience.  As much as you want to say "Look at this cool thing you can do!" you have to hold your tongue and see if they actually find that cool thing!  If they don't then you dun screwed up, and you have to go back to your design and see what can make this really cool thing
a) more obvious
b) more cool
or c) worthwhile.

Perhaps that really cool thing you made isn't actually cool and serves no purpose aside from soothing your ego.

not as awesome as first thought.

So that was an important lesson for me to learn.  I gained a few things from watching  Brian's playthrough: the access to turrets and mines was not considered a priority (this is the space-game that failed to actually be submitted... :(!  ) even though it was designed and thought out to be by me a rather critical element of game play.  So now I'm doing away with the two-click interface and instead switching to a one-button press method of purchasing turrets and mines that might make them as important to gameplay as I hoped they would be, and planned on them being.

I also fixed some dumb mistakes with my sprite object class (yet again) today.  On the agenda tomorrow: Doctor's appointment, come home, run and/or bike for at least and hour to work off all the crap I've eaten, come home, eat crap, play with Brian and work on the game.  I'm going to fiddle for this one for a while, mostly using it as a testing ground to find bugs and other issues (Brian actually helped me find one today.  I had made a major mistake with one section of my collision detection code that remarkably didn't show until I had 8 enemies on the screen (why 8? Who knows) but I also got that fixed too.

It basically was just the fact that I was checking pixel-by-pixel for collisions even when the sprite objects weren't close enough to even collide.  What you are supposed to do is take the bounding rectangles, or bounding circles or whatnot and see of the two image's easy-to-compute bounding shapes collide.

If they do, then check for pixel-based collision.  I knew that, and I had it implemented in all my collision detection methods.. except one!  I had just forgotten it earlier, so I went back in and fixed it up, now everything is running smoothly! HURRAH!

I will get back to the original game that started all of this, mine and David's project, now that we are both free and have time and all those wonderful things, but a side-project never hurt.  This project is no where I will build and tweak the rest of the Sprite Object class and test out some other "technologies" that may help us in the long run.  We shall see.

Oh yeah, I should go and comment everything so other human beings can use these classes and not just me..
hmmmmmmmmmmm...

TLDR

Until next time my fair lady(s) (and gentlemen)

- Kev