Variety may be the spice of life

But it sure as hell doesn't get you anywhere when it comes to a project.

What am I talking about? Well, since that last post I have 'put on hold' the POTUS game, started a top-down-zombie-shooter-tower-defense game on XNA and now, I have gone a little Hollywood.

That's right, 3D. I have also gone into Unity, which has made quite the impression on me in these super early stages.

In two hours, with great help from this dude, I have made a 3D 'cube floor' with a 3D 'evil cube' chasing me on it:

The red line is a debug line showing what the evil cube is targeting (which is poor old me!).

I wanted to go 3D and I wanted to work on writing AI, as I had little to no idea on how to do it. And voilà, two birds with one stone. Of course this is all basic stuff but any step is a good step.

The great thing about Unity is, all that took literally about five lines of code. The controls, graphics, even the targeting was all handled by Unity. All I had to say was in basic code "move evil cube to where player is" and done. As Mr Burns would say, that is simply, eeexceeleeent.

I could write more about how great Unity is but is there any need. And anyway this is not a Unity advertisement but it just goes to show as someone who is new to all this, how a widely accepted game engine like Unity, even to a newbie, immediately shows why it is widely accepted.


So, the big question - What is next? Well, I would like to actually finish one project but I can't seem to help venturing off to new exciting places. After all, this is a hobby but there is no harm in a hobby turning into a portfolio of sort I guess. Which means the plan is to finish the top-down-zombie-shooter-tower-defense game on XNA.

Speaking of which, here it is in all it's early-stage glory (programmers never were good at art):

Credit for tutorials/help to this dude

It is worth noting the back end of the top-down-zombie-shooter-tower-defense game is super tidy. It is definitely the tidiest project I have made and I am very proud of it in that aspect.

The game side of it, I will try a couple of small detail things that won't blow anyone away but hopefully will make for somewhat an intriguing experience. They might not even work well, I just want to experiment with some game design.

Anyway, I'll make a separate post for that in a while when it advances a bit more. Today's post was all about variety (or ADHD), Unity, 3D and...EVIL CUBES!

The State of things

Having a menu system built was one of my top priorities, because well, that's the first thing the game has. When I started as a complete clueless game programmer, I thought that would be one of the simplest things. After having a few mini-projects built, none of which having a menu system, showed me that it was in fact one of the harder things.

It's because the creation of menus is tied to a key component of the code and that is the key to managing the state of the game. Once I read about it and understood it (or I thought I understood it), I just couldn't apply it, there was something missing. I tried understanding Microsoft's game state management project, and even though I could do simple things within it, if someone asked me to reverse engineer that, I simply couldn't. As I didn't know the thinking behind it when building it.
And I think reverse engineering any given code is important because if you can't, it means you don't know what it's doing and most of your coding later on will be based on luck or hours of frustration until you fumble into the solution.

So I did more and more reading and finally came across this amazing tutorial. There is not much to say about it other than it walks you through the process which is amazing. And it is a process that leads to an amazingly built clean and powerful library. It still took me some time to understand his explanation but the fact I now have a state management system that I can reverse-engineer is a great boost.

This is what you end up with after following the tutorial. As simple as it looks, it has a powerful code backing it.

It does lack one thing though, it doesn't set exercises for you to make sure you understood what he is doing.  So it is worth doing few exercises on your own. Like adding a screen from scratch that he doesn't have. Having menus go into other menus, or having a Exit game showing you a "are you sure?" pop-up. By end of Part 4 I could do all that confidently which is a testament to the strength of his "show code, explain code" method.

That is another thing done. Now I really need to figure out, as mentioned in the last post, what kind of project I actually want. Otherwise it's hard to code when I don't know what I should be coding. If nothing comes to mind it'll be a collection of mini-games that are different genres, or I might emulate an existing game in full somewhere down the line.

For now though, learning continues.

Jack of all trades, master of none

I have been messing around with XNA a lot more now. Got my head around *basic* game development in general and it is nice to know when I try another engine like Unity, I am not completely clueless. Add my experience to millions of developers out there when they say, if you learn one, you can use them all.

This blog has served its purpose, it pushed me through the harsh beginnings but now I feel whenever I want to post here it's going to be a tutorial you can find 100s of out there (lots of great XNA help on the web) or it's going to be half-baked ideas/demos like the ones below.

I have done side scroller, top down mechanics [seen below] and am now working on point and click but I never get too far because I have no vision. So I need to sit down and do the pre-development phase, and get a full vision for a game before I sit down to code it. That is what I have learnt from all this. Seems obvious in hindsight but after all this started as strictly programming exercise.

I will open another blog [or post here] when I have a game in mind and it'll be much more interesting to blog a game progress instead of random programming ramblings. 

Hope to see you then.

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'.