ULSG V14 is underway! Slowly, but surely…!

Before I start with the ACTUAL topic of this post, I recently finished the trailer for Katu Toka, so I might as well post it here, for your viewing pleasure. Here you go:

Extreme professionalism, right there. 😉 Anyhoo…

Yes, I’ve started working on ULSG V14, thanks to me running out of things to play. 😛 I’d love to say I’ve done a ton of stuff and show you some prototype gameplay, but sadly, since this is XNA and I’m coding in a proper language, the “progress curve” is the exact opposite of when I’m using Multimedia Fusion. MMF projects can be prototyped retardedly quickly, but it gets insanely difficult to manage when the game gets too large. An XNA project is REALLY hard to get off the ground when you’re working from scratch, but it speeds up over time. 🙂

The reason for this is because MMF literally GIVES you everything. If you don’t have something, you can probably download an extension for it and start using it right away. The XNA framework, on the other hand, does gives you a very nice set of classes, but the functionality is quite basic, really. You don’t get animation or game state management – you’ve got to do those yourself. You get something that can help with saving data, but the implementation is up to you. Same with input and sound. This might be a pain, but it’s a hell of a lot more flexible and powerful than MMF. Plus, when the basics of the JetSquirrel Engine are done, I won’t have to do them again, so any future projects will have a much faster setup. And as JetSquirrel evolves, games will get easier to make. 🙂

So, aye, there is technical progress, but nothing I can really show. I’m at almost the same visible point I was about 3 months ago:

The only differences are that there’s now flashy text that says “Press any button!”, “Press a button like you MEAN it!” or some other phrase along those lines, there are two new classes, one for input and one for saving data, and the audio class is fixed. So just imagine that’s there in that video, and we’re all on the same page. 😉

The biggest problem I can see so far is the fact that XNA doesn’t support game controllers that aren’t Xbox controllers. That’s alright for me, and a lot of people I know (not like they’ll play the damn game or even test it), but some people don’t like them. I was going to forget it and just suggest people with other controllers download an Xbox controller emulator, but that’s such a massive pain for them – if I were them, I probably couldn’t be bothered to do it either. 😛 So, I’ve gotta look for a solution to that. Hopefully I can find one. 🙂

Other than that, it’s all going pretty smoothly! 😀 I’ll keep working on it, and I’ll update when I make some visible progress. 😉

So, it’s official…

I’ve been using Lua for a while now at my placement, and it’s quite a nice language. I’ve learned from it, and I’ve even learned a few things from Corona, even though it’s a hateful SDK with a ton of problems. 😛

This weekend, though, I returned to C# for the first time since the end of second year. I was just wondering if I could make a start on the little engine I’ve been planning on making for a while… well, not really a full-blown engine, more like a code base to make it even easier to develop games with XNA. Classes to easily handle audio, graphics, networking, and so on. 🙂 I call it “JetSquirrel”, a tribute to the team project I worked on in second year:

Haha, it wasn’t actually called Jet-Powered Squirrel – that was just a crazy idea I thought up for fun when we didn’t have a name for our game. 😉 It was named “Fluidity” in the end, but I kept “Project Jet-Powered Squirrel” as the solution name, partly because it was funny, but mainly because I was afraid to change it just in case I messed everything up. 😛

But anyway, ya, this weekend, I returned to C# to make a start on the JetSquirrel Engine. And oh God, how I’ve missed C#, and XNA, and Visual Studio. 😀 It’s so nice working in a proper IDE again. It tells you what’s wrong as you write your code, if there’s a bug, you can use breakpoints to pause the game at any time and inspect properties, and when the game has an exception, it stops and tells you where it went wrong instead of just trying to continue without telling you much… oh yes. 😀 A bazillion times better than Corona will ever be. 😀

There’s a good reason for me deciding to work on the JetSquirrel Engine this weekend instead of heading to Multimedia Fusion 2 and continuing work on ULSG V13 or the ULSG V14 prototype. This is because… well… unfortunately, Multimedia Fusion and I have had a bit of a fall out. 😛

I worked on a prototype of V14 in MMF. The process was pretty quick – I got a lot done in very little time. I posted about it, actually.  🙂 However… when the time came to try and get a second player in, everything fell apart, and I suddenly realised that MMF is not good enough for my needs any more.

I’d been using these things called “Behaviours” in MMF – I assumed them to be kinda like “local code”. I thought that each instance of an object would run this code for themselves, like how a class works. Sadly, that’s really not how it worked. In fact, I fail to understand the point of these “behaviours” entirely – the code is just run as if it was written in the Event Editor… only it seems to run it X times, X being the number of objects of that type there are.

What happened was I had an object called “ULS”, the Ultimate Lame Ship. In the object, there was an alterable value (an integer or double(if you’re lucky and MMF isn’t an idiot about it), you’re only allowed 26 of them per object – another MMF limitation) to identify which player was controlling the ship, and a behaviour which moved the ship by looking at the player’s input device. One of these objects in the scene? No problem. Works perfectly. Add another instance of the same object… BOOM. Player 1’s ship moves at double the speed and seems to break all the rules I set about maximum speed. Player 2’s ship doesn’t move at all. If one of the ships is destroyed, the other ship moves normally again. Yes, I’m giving each ship a unique player number, and yes, the code says that each ship should only respond to its own input device. Yet still only one ship moves… incorrectly.

Because of the progress I was making, this REALLY irritated me – this stupid idiot limitation of MMF. You want to make a player ship that will work in any mode for any player? No, you can’t, MMF doesn’t allow it. You have to make separate objects for each player which contain basically the same code. And hence, if you find a bug in the movement, you have to fix it FOUR TIMES, once for each player. You’ve also got to create separate S.P.A.R.T.A Drones for each player… and separate Balls of Steel… and so on. Yeah, not my idea of fun. 😛

In C#, you can create 4 players from the exact same class, give each of them a player number, and then each player ship runs separately, looking at its OWN values. “Oh, my player number is 2, and there’s been no input from player 2’s controller. So I’m going to stay still.” Not “oh, I’m player 1 and there’s been input from player 1’s controller so I’m going to run my code and player 2’s movement code for no reason WHEEEEEEE” and “I’m player 2 and there’s no input to my controller but player 1’s dead so I should take over player 1’s controller ahahahah” NO NO NO SCREW YOU.

I NEED to go further, and I can’t with MMF2. I’ve reached the program’s limit, and the only way for me to get better and make ULSG better is to take XNA as my tool of choice. So… as the blog title says, it’s official. I’m no longer using MMF. It’s been great using it all these years, and I’d still massively recommend it if you’re interested in games development and want somewhere to start, but for me, it’s time to move on.

If I can bear to wade through the mess of checkmarks that is V13, I’ll finish it off. It won’t have multiplayer, and may have features I planned to put in missing. But all my other projects will be done in C# using XNA – ULSG V14, Dragon Storm, and anything else. And over time, JetSquirrel will get better, so things will be easier to make. 🙂

This weekend, then, I managed to do this in XNA:

(Don’t mind the FPS counter (if you can see it ;)) – the FRAPS recording was making it go crazy for some reason. :P)

It’s not much to look at, but on the programming side, there’s a simple but fully functional game state manager called JetDirector, which is the most important component so far. You create class files for each of your game “scenes”, such as main menu, splash screen, etc., and JetDirector can switch between them. There’s also a SFX class called JetSound, and a graphics helper called JetGraphics. 🙂 All works pretty well so far! 😀

I’ll have to try and find more time to work on it during the week, since I’m at my parents’ next weekend without a computer to use. :/ I’m aiming to get it to this stage as soon as possible:

That’s as far as I got with MMF, until the limitations reared their ugly heads. 😛 Might take a little while, since I’m going with a higher resolution, so I’ll have to redo the HUD and the menu graphics.

But ya, it’s good to be back with XNA again. 😀 When I’ve gotten far enough with it, I’ll make the V14 blog. 🙂

I think that’s all for now… apart from the Shoot ‘Em Up Kit being one of the worst game development tools I’ve ever used – on par with Torque and The 3D Game Maker. 😛 Anyhoo, back to work tomorrow, and we should have our first games on the Android Market and Apple App Store this week – woot! 😀

See ya later. 🙂