Objectify the world (and running into walls, literally)

Here is a video of Ash running into walls:

Note: The lag comes from FRAPS.

This version is different from the last version of my project that was posted. You might be thinking, "duh, you went from a side scroller to a top down adventure game". While that is the obvious change, there is a much more important change hidden away at the back-end; everything is objectified. 

This is a key programming technique that most tutorials I went through to learn stuff ignored for some reason. This caused huge confusion and mess when trying to implement different aspects from different tutorials.

This confusion and mess in fact is why object-orianted programming took off. It's much easier to design, code, and manage.  

It didn't help the confusion and the mess that I didn't know 100% what was happening in those tutorial files. So I just want to take a minute to write about being careful about doing tutorials. Learn the process, don't just do it. If you don't understand the ideas behind the code, even if you understand the code itself (there IS a difference between the two), it will cause you a lot of problems in the near future.

This has happened to me the other day, I wanted to modify something in my file and ran into hours of hair ripping frustration, simply because:

1. It wasn't OO (object oriented)
2. I wasn't really sure what was going on in the code because I didn't understand the tutorials fully as I was doing them

So those are two things that stuck with me through this experience and I took my knowledge from the side scroller project to a new project that is coded better/tidier from the ground up and is in a genre I am much more interested in working with.
Other than learning through pain and transitioning to a new project, I've also been working on:

 Collision

It was a big pain and I'm glad it is out the way. It got out the way hugely thanks to this tutorial. Not only did he nicely explain the concept and the practise behind the collision engine, he also gave a source file that was OO! So, a great help there.

With the code objectified, and collision engine set-up, I can now at least design a screen, which gives me great momentum to carry on this project.

Speaking of design, everything you see is placeholder assets.

To do list
(in the order of where they are swimming around in my head):

• Animation- As you may have noticed, there is no animation. Last engine I used shown in the last post was way too messy and didn't go well with my clean OO project. Not to mention, once again, I hadn't fully grasped it. I will be implementing one that I understand and so even if it isn't neat, I can tidy it up myself.

•  Screen management- Figure out screen management system and implement it. Once implemented, it will give me a main menu, in game menus and ability to switch screens. This one is a biggie and will be another momentous push once figured out.

• Do some paper work design- This is indeed mostly a programming project, but I also want to get some paper work done on the game itself. Design screens on paper, script, some kind of back story, overall story arc, and so on.

• HUD- I am mainly thinking a mini-map but my [so far] little research lead me to believe it might be way out of reach of my current abilities, not to mention the game might not need it. If I'm convinced the game needs it, it will probably be one of the later things I build so I am better experienced by that point and the location layouts have been designed that the mini-map can copy. 

Updates have been slow, because, well, I've been slow on grasping some fundamentals of XNA, and heck, sharpening up on programming concepts in general.

Also I don't get a lot of time to work on this, what with work-work and uni work. But hopefully next update should be a good one (and less word heavy, more screens/videos), as the foundations for the game are slowly but surely building.

I like to move it move it!

Animations done! Shown in video: 'idle' animation. More to come (not silly little videos, updates...and maybe silly videos).

Day one, attempt one

It has been an hectic night/morning/day, what started as "I wonder how the XNA 4.0 tools are" ended up in an early version of a, what I assume is going to be a pretty bad (but more importantly, working!) game.

First of all, I want to start off by thanking this great site for providing all the help in getting me started. All the assets are also from that tutorial set.

In fact what you will see of this game as of now is 98% just those tutorials. I've made a couple of tweaks and added stuff here and there, also failing to add stuff here and there. But more on that later.

Let's just take a look at this game in it's current state:

So it's a wizard guy, shooting pretty fast fireballs. I will adjust movement and fire ball speed and so on to my satisfaction, once there is more objects to balance out.

You may have noticed he can also hide under his hat. I will make this a stealth part of the game. If in certain areas, enemies collide with you when you are not under your hat, an alarm will go off or your score will get a minus or whatever.

You may have also noticed that fireballs get smaller as they travel. This is a visual aid to let the player know that they get less powerful as they travel. So, standing back and sniping enemies, although still a viable option, is a weaker one. At least with the fireball.

Which leads me on to the next point: More projectiles. Thanks to the object oriented way the code is set-up, adding projectiles with unique behaviour is pretty simple and as game progresses, I will definitely add more. An obvious one would be one that contrasts the fireball (so it gets stronger as it travels).

Those are all 'to be done' based on what you've seen in the video, and are not things near the top of my to-do list (more on that at the end). Now, about those things I've tried to add but failed.
Well, there is only one so far: A menu system. You've seen it has a generic splash screen and a title screen, but no game menu. This has proved to be much harder than I've thought. I did get one running eventually but it was (as the guy who made the tutorial pointed out), a very basic one and for reasons I can't recall, it didn't fully meet my needs.
There is a great source code from Microsoft but unfortunately it's an ocean of code and after a long and tedious attempt, I've failed to implement it into my game fully. It is something I need to read more on, as I had no idea what half the things did in Microsoft's example code. Although I think I'm on the right line to learn more.


Neat things I've learnt:

• You know that 'press start' screen most games have. That's to initialise which controller player one is using. Maybe it was obvious to everyone, but it never clicked with me until I made that screen myself. I was under the impression the system passed it on to the game.
• Having used Silverlight, I was under the impression MS can't build a proper visual library. Of course, it turns out, they can when it's their focus, as XNA is very developer friendly for both PC and X360. I have also ran a even more basic code on the Windows7 Phone emulator, and that too, worked nice and easy. Kudos, Microsoft.

To do list!! In order of "me want it now!":

• Add a menu system for crying out loud!
• Get collision system working, starting with two things not going through each other and building from there, i.e: projectiles hurt you/ the enemy, test above stealth idea and so on.
• Once all that is working in current screen, learn to scroll screen with player. I can take the "easy" way out and just load a new screen when you run out of the current one, but I am going to try to have it properly scrolling with the player. Don't be surprised if I back out on this though, and go to switching static screens, and say it was a 'game design choice'.