Homebrew The Making of.. RetroRaider : Dark Secrets

[Jayenkai]

Hello all!
My name's Jayenkai. Well, it's not.. My name's James Gamble, but you can't google that very well, 'cos some really old dead guy made some soap, or something..
So, instead, they call me Jayenkai.
If you want to google that, you'll find out oodles of stuff, and a bucketload of games.

Normally, I create games at a rate of AGameAWeek. You can have a nosey at my progress at the aptly named AGameAWeek.com website.
It's been a while since I last tackled Nintendo DS Homebrew, though. Creating DS specific code doesn't naturally snuggle in amongst all the other chaos that AGameAWeek tends to bring.

Over the course of July, I've decided to create a brand new RetroRaider adventure, and since I'm giving myself a whole month in which to tackle the project, I've opted to dig out my old DS Homebrew Devkit stuff, and try simul-coding the game, in two different languages, together.
Both versions will share graphics, levels, sounds and more.

One will be coded using DevkitPro and PALib, and will run on DS.
The other will be coded using Monkey (MonkeyCoder.co.nz) and will run on Windows, Android and more.

This topic will act as a sort of development blog, and I'll probably be asking folk to chip in ideas and things as I go along.
If you're lucky, you might get a couple of beta versions thrown in, too, but it depends how fast I can get things working.

Either way, I've preset a primary release of July 30th 2013, so with any luck I should be done by then!
Wish me luck!!

-=-=-

Identical Layout

Since both the DS and Windows/etc editions will be using the same level code, it'd be a good idea to have both versions looking pretty much the same.
For this reason, the initial coding has been focused on getting the same identical output on both targets.



After a couple of days of tweaks and fumbles, I've finally got a simple sprite/background function set, which replicates identical looking scenes on either version of the code.
The actual code is significantly different, showing the differences between Monkey's basic-like structure, and DevKit/PALib's C syntax. The contents of the internal functions are even more complex, with the Monkey edition handling all sorts of resolution scaling, and the DS edition having to keep track of sprite numbers.
But the actual code for drawing the sprites is as simple as can be, and results in identical looking scenes, which is the intended purpose.

Now that I know I can achieve exact layouts, I'll have to start figuring out the best format for the level layouts.
That'll be the next job.

-=-=-

Helping Hand
If you'd like to help a little, head over to this topic and help if you can.

 

[Another World]

i can't wait to see where this ends up, what new things get added, etc. Do you have plans to enter the final DS build into the neo flash coding compo?

-another world

 

[Jayenkai]

Hadn't considered it, but having looked at the rules, there doesn't appear to be a "Only For Us" rule.. (The sort where your game has to debut in the compo, and can't exist anywhere else)
That rule tends to put me off entering these sorts of things, but since it's not there, I might chuck the end result in, and see where it gets me. Plenty of time before the deadline, anyway!
We'll see!!

 

[spinal_cord]

+1 FOR THE NEOFLASH THING

 

[Jayenkai]

One of the things I love about my games is that you can typically hit "Load!", then "Start", and be playing within a fraction of a second.
Having a "This is a game wot i entered into a compitishun!" screen in between is kinda annoying.
Even more annoying is that the compo gets instant recognition, whereas I and AGameAWeek gets second footing.
Always hated that sort of thing..

.. but it seems I could chuck in a simpler screen, fit for purpose, and perhaps have a compo-centric edition or something..
It'll be looked into.
Seems there's a whole lot of things to think about, this time around. Can I actually manage to cram it into the space of a month?! I hope so!!

 

[raystriker]

Yeah, can't wait to see what you cook up!

 

[Jayenkai]

Nothing major, just a test to see that the engine's running the same speed in the different versions.
The browser contains the HTML5 edition, and the DeSmuME is obviously the DS edition.
Vine Clip
Both are smooth and silky (with hoppity skipping due to my laptop having to cope with a HTML5 game and a DS game simultaneously!! You should see all the programs currently running, on my taskbar!!)

I need to start thinking about control schemes, now. For the most-part it should be pretty simple, but I also need to account for Touchscreen-Android controls, too.. Could be a little more difficult than I originally contemplated.. hmmm..

 

[Foxi4]

Nobody mentioned it yet so I'm going to - PALib is no longer a supported library and if the development isn't in an advanced stage, it is recommended that you move to NightFox Lib - the inner workings of the library are similar, but it gives the coder more flexibility - do consider it.

 

[Jayenkai]

Just because something is unsupported, doesn't necessarily mean it doesn't work anymore.
I don't know WHY people get so obsessed about upgrading their toolkits, when the old tools work perfectly fine.

If you can show me an example of any of my old game no longer working where they should, I'll make the change. Otherwise, the tool isn't a problem.

 

[Jayenkai]

Today's been one of those "mostly guesswork" sorts of days.
I can see, in my head, how I'd like the Level Data to be structured, but trying to wrangle that data into both versions is proving to be difficult. .. especially when I've not actually made any levels, yet, so everything is currently untestable!
Is this "screen full of nothing" the correct "screen full of nothing", or is it reading the thing in completely the wrong way?

.. But, in theory, the things that I'm fiddling with should be working.
I hope!

More tomorrow.

 

[newo]

Just put the level in a plain text file. Probably multiple files if possible.

 

[Foxi4]

Just because something is unsupported, doesn't necessarily mean it doesn't work anymore.
I don't know WHY people get so obsessed about upgrading their toolkits, when the old tools work perfectly fine.

If you can show me an example of any of my old game no longer working where they should, I'll make the change. Otherwise, the tool isn't a problem.

Not to look too far, NightFox Lib supports GPU-powered sprite mechanics, scaling in real time and so-on and so-forth - everything PALib does poorly.

 

[Jayenkai]

I guarantee, if you're expecting a game that does anything you've listed, you're going to be severely disappointed by RetroRaider.

.. Back to the levels.. the file format will be a single string, compressed using my ever faithful JNKrunch technique. That bit's easy! The complexity is how to store it all in memory, whilst allowing for both screen resetting and more permanent events within the levels.. For example, if you run in and out of a room, it's a good idea to reset the creatures, so they don't start right next to the entrance. .. But on the other hand, if you kill one of the creatures, it oughta stay dead. Pickups should stay collected, and doors should remain unlocked..

I've more or less worked out a technique to handle all of that, or at least I have it worked out in my head, it's whether or not it's actually working correctly in the engine that needs testing. Time to move onto making some sort of editor, methinks..

 

[Jayenkai]

OK, I'm pretty sure I now have a working level loader.
The same single-string of data is being loaded into both versions, decompressed, and padded out, to form the great big "map[]" array..
A 7x7 grid of rooms, holding the current level.



(For those wondering, the level is purely random data at the minute since there's no level editor, but it's the same on both systems, and it displaying the same random backgrounds, at the same random offsets, along with the same random set of random laras, splattered at the same random locations.. This is a successful test!!)

Next up, I need to start working on the Editor side of things, and then I'll get to work on figuring out how to get the controls working. (Easy to do on DS.. Much much harder when working with Android's lack of buttons..)

 

[Normmatt]

OK, I'm pretty sure I now have a working level loader.
The same single-string of data is being loaded into both versions, decompressed, and padded out, to form the great big "map[]" array..
A 7x7 grid of rooms, holding the current level.



(For those wondering, the level is purely random data at the minute since there's no level editor, but it's the same on both systems, and it displaying the same random backgrounds, at the same random offsets, along with the same random set of random laras, splattered at the same random locations.. This is a successful test!!)

Next up, I need to start working on the Editor side of things, and then I'll get to work on figuring out how to get the controls working. (Easy to do on DS.. Much much harder when working with Android's lack of buttons..)

If both versions are starting at the same Random locations then I really wouldn't call them RANDOM.

 

[Jayenkai]

If both versions are starting at the same Random locations then I really wouldn't call them RANDOM.

By "Random" I don't mean truly random.. What I mean is that the "Level Data" is, quite literally, a completely random string!!
That completely random string is then loaded into the engine and interpreted by the game, as if it's "real" level data.
Since both versions are giving the exact same output, it's safe to assume that both engines are accurately interpreting this random string in the same way, which is a good thing, because it means that levels built for one will run exactly the same in the other..

(Or, I can lie in bed and make levels on my iPad, then stick them into the DS one, later... MMMmmm...!!)

 

[Jayenkai]

Today's progress has been on the basic controls.

FauxLara hasn't yet earned a fire button, but does at least have simple left and right buttons, as well as a currently useless jump button.
Although it seems easy enough to have these controls, trying to get them to work on an Android device is tricky at the best of times.
Touchscreens aren't exactly well suited to having old-skool control schemes.
*sigh* This project may be tricker than intended!

Anyway, I got simple left and right working, so I popped in a bit of ScreenFlipping code, and the rooms appear to be displaying in the correct format. I can walk from the far left of the level, through to the far right, and back, with the engine coping admirably.
It currently takes about 12 seconds to run the entire length of the level, and FauxLara does her standard Pitfall-inspired "Diggity-Diggity" bounce against the edge of the level. \o/yeay\o/

So far so good, and both engines are still working identically. (ie, I ain't broke it yet!)

 

[Jayenkai]

Looking a teensy bit more presentable, now!
I haven't done much, if I'm honest, but I have gone back to my oldskool roots of having a giant list of Ascii Values, each with pre-determined block values, then a great big switch/select list that converts from block numbers to ascii values and back, as required.. (apologies if this line of text goes over your head!!)

I've started to compile my list of blocks, and am beginning to code functionality into them.
Lots of work to be getting on with!

 

[Jayenkai]

Hmmm..

I seem to have lost quite a bit of momentum on this project.
I'm not entirely sure what part of the project has caused this, but there does seem to be an awful lot of faffing about with files, and that's starting to get annoying.

I'll keep trying, but.. .. It's not looking good.

 

[Another World]

when in doubt compile just for the ds =)

-another world