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