January 25, 2010

continuing on

Filed under: Uncategorized — wickedworx dev clone 1 @ 11:45 am

so, I’ve made a lot of progress with Keystar Superstar! It’s basically finished, but lacking songs… and I’m working on that day by day.

I’m also working on a new XNA game… which is progressing, albeit slowly.. but I’ve got a really really good feeling about this one.

I’ve been using the Component based GameObject paradigm.. and it really works very well. It may not prove to be massively scalable, but for implementing object behaviour, it’s fantastic. I’m sure there are loads of places that have written up great explanations of how it works, so I won’t go in to it in much depth.. but being able to massively data drive everything with minimal effort is just fantastic. Of course, you always have the problem of components ‘clashing’ (two behaviours that disagree) – it’s not magic.. and of course, you’re still going to have to write some specific code to make a game… you can’t build a fun game out of generalisations, generally 😉

OK, not much else to report. Screenshots galore coming next time, ‘coz it’s been a while.

January 6, 2010


Filed under: Uncategorized — wickedworx dev clone 1 @ 2:47 pm

well – it’s snowing here, and all there is on the news is SNOW SNOW SNOW. it looks pretty fun out there tho, so i’m glad I’ve finally finished working on DEBT!

DEBT is my tigsource assemblee entry, and I’ve just finished it today. Hopefully people will like it – I’ve enjoyed making it… it’s basically a “beat your high-score” platformer with megaman, metroidvania, and similar influences. Depending on which routes you take (which order you tackle the levels, which keys you go for first, etc…) you will do better or worse… there are some risky long paths that will give you great rewards if you complete them!

DEBT was pretty much written from scratch – the level and game object system was all new. It does however, use most of the graphics and audio back-end in common with Keytar and EGV (as well as the state system, and input stuff…)… The game object system was simple, and flat structured – but not ideal for doing anything more than what it does… there was probably too much duplicated code in each enemy type, for example… it’s definitely not as flexible as the EGV system I’ve put together (scripting etc..) – but I think there are some ideas I can take from this and bring over to EGV to make that even better.

Also found some bugs with my audio code… it was even harder to track these down as the realtek HD openAL drivers seem to be faulty… forcing it to software only was the only option at that point. Either way, these are now fixed, and I can bring them over to the other games. I probably wouldn’t’ve even found these had I not unplugged by normal audio device (line6 KB), because it wasn’t affected.

Also found that some openGL implementations do the following:
glColor4d(1,1,1,0); // color is 1,1,1,0
glColor3f(1,1,1); // color is still 1,1,1,0 !??!?!
while others (mine, and every one I’ve seen before) do this:
glColor4d(1,1,1,0); // color is 1,1,1,0
glColor3f(1,1,1); // color is now 1,1,1,1 (3f means default alpha param 1)

Anyone know anything about this?! I’ve never seen this before, but on my brother’s laptop – alpha is unaffected by glColor3.. but on my PC (nVidia card), the behaviour is how I thought glColor3 was meant to work…. – it sets alpha back to 1. Which one is correct?!
Solution here is to only ever use glColor4!!

uploading a DEBT trailer to youtube as I type this… enjoy! 🙂

Blog at WordPress.com.