Xerra's Blog

Drunken coder ramblings

Title sequence update —

Today was a day of pretty heavy research looking into the most effective way to do the scrolling system on the title screen. As mentioned previously, I’ve tried a few different ways with varying success but the general rule appears to be to use a surface to get it done properly. This did turn out to be true.

A development system like GMS 2 works similar to Unity in regard to having a lot of power to automate aspects of your games so you don’t need to manually code them. For example, I found images of the original Paradroid scroll text which had been hacked together probably by someone else who attempted a remake of the game. It was pretty-much the easiest thing in the world to just resize these sprites to the games hard-coded resolution (as it currently as, and will likely need rethinking at some point soon before it becomes too mammoth a task to adjust it) and then set an auto move flag on them to 90. This works in a degree system so 90 = move straight up so placing them on screen and setting the speed would get them moving without any further ado. But I was not in control of what text was built into that image, making sure it was removed from memory once it was out of the bounds of the visibility window, know when the next one had to be put in place and numerous other little things that were important.

So I didn’t like it, Aaron certainly didn’t like it, and that’s 100% “got to go” from the off.

I won’t go too much into what I’m trying to achieve instead, as I’ve documented it previously, but I need the scrolling area within a certain section of the screen, and I can’t cheat and hide bits behind the background as it’s all transparent around the layout as the game is going to be. The game will use all the screen real-estate behind the static sections for level display, score and so on, but scrolling text being visible anywhere but within the window designated would just look a complete mess.

So, a surface was created, a lot of – at present – hard coded areas were setup and temporary text installed so that I could make sure I get the scrolling system in place and working, before I start thinking about the asynchronous text loading and formatting that is going to be required next. Surprisingly, after a few minor bugs crashing everything, it actually fell into place pretty quickly. I had images of multiple draw text lines every frame and then try to pixel move them which, inevitably, it transpired that I was using a surface to actually avoid this whole process.

In a draw event, I just needed to create this surface, draw the text onto it with the correct font and colour, after colouring in the background, then the step event could just be used to draw a certain section of it into the title screen where I wanted it and not have any overhang by trying to cheat. Then I just put in a rough counter to loop the system, add in the routines to colour change the background colour and text colours later on like the original game does.

To me it was a thing of beauty, but it’s probably dead simple to do for someone who’s been using GMS before, no doubt. That’s programming for you.

I’ve implemented the scrolling pause and selectable speeds without going back into the game and checking if it actually did that. For a few lines of code that took maybe 5 minutes to get in place, there’s just no reason to not really have that option. Besides, being able to pause the text is ideal for people who don’t read as fast as the youngsters. IE: Me and other visually impaired people.

So the screen above is what it actually looks like. You can’t see the colours changing, or the actual scrolling, but it does show that a certain area contains the text so I couldn’t cheat and just throw it all up from the bottom of the screen with a black rectangle to hide it, as the border is a custom graphic itself. As you can see, Aarons font is rather nice, when used at the desired size of 32.

This image demonstrates that the scrolling is literally pixel by pixel. When you increase the speed with the cursor down key it does just increment the number of pixels it moves up by, but that’s only logical in a game that’s working of a fixed FPS. It also shows that I’ve got different background colours working ok but I still have a bug in the system that’s changing the text colour. Yellow on white currently looks horrendous.

Naturally the next job is going to be getting the loading of the proper scroll text in and reloading on the fly so I can work out the formatting, due to the different char sizes in width meaning I can’t just use 20 chars per line and expect it to work ok. I have formatting codes within the text I’m using as it is so I will need a rewrite on the hard-coded number of lines the system uses at present, when writing to a surface, or I can rejig the text itself to work round that.

The text itself also needs to go around 10 pixels in on the left and right side to make it look a bit nicer. This looses me some real-estate for long sentences on one line but the trade-off will be worth it. And the other thing I need to be considering now is wether I bring in some of the large robot images that Andrew Braybrook had on his title screen sections during one of the scroll texts being displayed. It would be a lot of effort just for one page but it’s perfectly do-able as long as I can format text around it when it’s on the screen. Maybe have that on the part where the high scores are displayed. It will also give Aaron something interesting to do while getting the right image for me, because I’m sure he’s not busy working on lifts or anything …

I’m tempted to have the title screen with the paradroid logo from the original game display inbetween each scrolling page of text. It will provide a transition between each colour change for starters. If they’re going to be long sequences with all the text in place then it will be a nice break between reading pages of text, for the die-hards who are likely to do exactly that. I’ll probably have a skip key to jump straight to displaying the high score table as that’s the only screen that will ever change once the text is properly set up.

As promised in the previous entry, I have supplied not one, but two pictures of what I’m up to. You lot are just so spoiled 😉

 


Scrolling the title screen with GMS 2 —

Hands up all of you lot that remember the original Paradroid? Quite a few, I suspect, so you’d be the people remember the attention to detail that showed up in the title screen with the scrolling screens of text, use of colour, and even formatting of the scroll text, within the limits of the font size Andy was working with. It’s down to me to realistically improve on this while staying as close as practical in feel to the original.

This isn’t proving as easy as originally expected.

As I mentioned in a previous post, I had all the information screens knocked up into a set of five large sprites for the prototype, and got them up and scrolling pretty quickly as GMS 2 has options for automating a lot of background movement tasks. Using a large sprite to cover the areas of the screen that were unused for anything visual, I would just position the sprites behind the transparent hole in that image, and then let it move off so it looked just like scrolling screens of information about the game. For prototyping this was just fine, but, on reflection, a bit of a waste of time, as I was never going to actually use this system for a few reasons. One is obviously the information on these screens is subject to changes. I was scrolling the original text dumped into sprites, but high-scores are dynamic for starters, so I would have had to have some kind of clumsy system in place to draw this on screen and move along with the sprites to try and maintain the visual effect. Might just as well have all of it as scrolling text, if I’m doing that anyway.

Another flaw with that system was how the original worked. There were several areas of inactivity during the sequence of scrolling these screens of info around, mainly to let the user catch up the reading. I’d have to double check because I’m not sure at the time of writing if you could pause the scrolling while reading but for some reason I am thinking holding up on the joystick actually did that too. My problem with the sprites would be that each one is different in size so there would be the issue of counting down how long they take to work through the text and then putting in the right pauses in the right places before they switched out to start scrolling the next page. Taking into account the screen could be paused too, then it’s a bit of a faff getting all this synched in.

So the sprites as they are have been dumped and, due to Aaron pulling out several of my fingernails, I agreed to use his new font and go with the scrolling text proper option. There are a few pro’s to this, firstly. I can use formatting codes within the scroll data so I don’t need to rely on timing how long things are going to take. I’ll be loading the data in from an external .txt file initially, but maybe putting it all into text strings within the editor once the text content is finalised to make it trickier for the hacker-types. That benefit alone means it’s super-quick to just edit and reload in the scroll text on the fly, within the game, for testing and formatting purposes. And it does give me complete creative freedom to jig any of the original text for readability as well. I’ve got around 8 function keys setup to use in the title sequence for various uses, and displaying that information will be much easier as well. Hopefully I can stick a lot of that into the top of screen information box just like Andy did in the original too, however.

So far, i’ve been struggling to find decent ways of throwing this much text around with GMS2 at any kind of decent speed so there’s been a fair bit of code written and then completely ripped out to try other approaches. I’ll get something right in the end but it certainly is proving a lot more challenging than initially expected. Luckily I’m not really on a deadline at present, until the main game gets closer to completion, and I need to start on aspects of that.

I promised a screenshot or two of how things are looking but Aaron has already made a post about the graphics-side of the game today, so I’d just refer you to the link at the side of this page to have a look at that post for some retro-paradroid imagery, and hopefully some of the dark stuff at a later date, as I know he’s ripped it all out and got it into tile maps ready for inclusion in the game … somewhere.

On a final note, I did actually manage to get a tweeted response from Andrew Braybrook regarding the transfer game that doesn’t really have much information to be googled about. I requested that he does one of his blog posts about the creation of it which, if he does, will hopefully help a lot when it comes time to start work on that area.


Paradroid ongoing —

Development is going pretty well on Paradroid at present so, pretty soon, I’m going to be posting up some work in progress of both development images, and the game as it is at present, running.

GMS 2 (Game Maker Studio 2) has proven to be a pretty good system for both of us to work on individually, but we’ll both be happy when we finally actually get a Mac version of the editor to save running under emulation to develop. My machine is quite old now, and I’m unlikely to get an upgrade any time soon because, even when Paradroid is finished, we’re not going to get any money for it. So I’m working with the IDE that’s a bit sluggish as it runs through Parallels, and also has a knock-on problem that having the system up and running for more than a few hours does start to make everything chug, even Mac applications. It’s doing some pretty impressive stuff, so I can’t knock it, but usually I can keep my mac on for days on end before a restart. Maybe once a week or something similar. But now I’m almost having to reboot before every editing session just to keep things moving.

On my system I do have all sorts of other stuff going on which probably doesn’t help. My back up system was a convulted, automated mess, until I got round to rejigging all that the other day. There’s also the QNAP linked up, that i’m ferrying stuff back and forth to that also probably hogs things a bit.

But enough of the woes. I’m making this post to update on the game progress itself.

Aaron and I get together once or twice a month at his house to work through tricky code problems together on his system and we always hold what we call business meetings down at the old local pub. That probably doesn’t sound much like getting work done but we find it vital for sharing ideas and discussing what we’re both going to do next. We’re now working our tasks for Paradroid between us and keeping it all documented on a spreadsheet so there’s an instant visual clue when we need to check on each others progress without constant phone calls, or emails. From our own perspectives, we also use this to keep in mind what needs to get done next as there will be highlighted areas of the game that Aaron might colour code to show me that he’s finished to a point with some area, such as mini-map graphics, for example, and that he needs me to code them into the console display routine before he can put that part into the console control code he has. Very rough example but it helps a lot with prioritising, so he’s not waiting to do something important while I work on something that can be done at any time.

With Paradroid there’s soooo many different intrinsic little features that need to be done to get it playing like the original that I’d bore you all silly listing everything here, but I can give an idea of the stuff that’s done, or almost done. If I broke it down into a percentage then I’d probably go to 40% because the major part of the enemy robots running around hasn’t even been started as yet, and there’s a transfer mini-game that I’m holding off working on until I get the other parts of my end finished first. I do suspect that’s going to be a beast to try and clone so I’d rather be more familiar with the syntax of GMS 2 first before I dive in.

The maps are all in and 001 is happily moving around in all of them. They are actually all stored as part of one big GMS room so 001 can be shifted anywhere once he’s gone into a lift, without making things too much of a pain in the butt. There’s a lot of work still needed to control aspects of each deck itself, as they will need seperate data to keep track of what droids are still around on each one, and if the deck is cleared or not. But it has made it easier to get 001 to spawn in a random position over the first four decks which the original game does.

The front end title screen funky scrolling screens have all been prototyped and i’ve had them up and running almost like the original game. I used images for the whole text based on snapshots from the original game to build up the entire sequence, but after some lengthy discussions, Aaron decided that we could make things much nicer with our own Paradroid style font, and to build them up as actual text. This does mean that I get some freedom now to work in some changes to the original screens, even if it does mean a lot more work to build a whole new organised sequence. It also means the design of the title screen background itself is going to change but I’m keeping as much of the original text as possible. It’s just going to look better with Aaron’s new font.

One of the first decisions we made when we decided to remake Paradroid was to try and emulate the game as close as possible. We’re still going pretty close when it comes down to it but we’ve opted to negate the aspects of the game that were done in a certain way due to the hardware restrictions of the C64 itself. The most obvious one is the map viewing size. We’ve got that running over the whole display area, rather than half the screen, which it looks like Andy resigned himself to in the original, just to keep the speed up. We don’t have that issue so we’ve kept the big area with the paradroid logo, but it’s transparent in areas so you’ve got a bigger view area to look around for droids in. It makes perfect sense to do this as we can adjust the difficulty to allow for the minor player advantage this gives at the end, anyway.

The graphics for the project are mostly done. Aaron’s done most of his work on this and the tilemap system as it’s the biggest part of the game by far. The collision detection for static objects and location settings for lifts and consoles is all there ready for me to add in bits, and apart from some minor alterations on the maps to move them apart a bit, they’re all done. The only reason we have to move them is because we’re using the whole screen and there are certain areas on certain decks where you can move into a corner and see parts of other decks just creeping into view at the edge of the scroll. That’s an immersion failure right there and Aaron is far too much of a perfectionist to just let it slide. Another part of the graphics to do is minimap parts and emulating some of the look from other editions of the game that were made. Competition Paradroid for example. And there’s a lovely dark metal version out there with a modified intro screen that I want to stick in as either a hidden feature to unlock, or a random display in the title screen attract mode.

001 himself is moving around quite happily. This is probably because we haven’t got bad guys in there trying to destroy him as yet. All the collision areas have been tested and tweaked, and we’ve made it work better than the original game which sometimes moved into walls or appeared to bounce as if it had gone to far into something and had to shift back out. We shouldn’t have that in our game. Aaron has also got the horizontal and vertical doors opening and shutting perfectly. This has been carefully done so it will work with the enemy droids exactly the same so, like the original game, you’ll be able to see doors opening and shutting in visible areas of the map, but not the droids themselves unless they are actually in a location where the 001 can physically see them. This was a great system in the original game as you could know a droid was in a closed off room as the door opened/shut, but you wouldn’t know until you went in there if you were going to scrap with a 139 or a 999. That definitely made the game more exciting.

As for other changes to the original game, i’m taking the opportunity to make the game a bit more up to date with modern expectations. I’ll put in a 5 place high score table as the original game only had the best of the day, and the worst of the day to taunt you. As we can save/load data with ease, we can save this kind of data along with redefined keys, which I’m going to add in. That is mainly because Aaron’s got it running of WASD which does make sense, but for some reason I like playing this with the cursor keys. And we may as well cater for everyone on something trivial like that.

Paradroids title sequence also had options for colour corrections and some cheese mode which was for screenshotting. We’ll probably switch off the animations in pause mode anyway so screenshots won’t need anything like that. The usual options for sound/music etc will all go in too. Not that we have any media like that yet, apart from a paradroid tribute MP3 I found but I wont be using it unless I can locate the author and they let me.

As touched upon earlier, we’d like to possibly hide a few things in the game. I may expand on this but that depends if Aaron will let me. Doing something in a hard area of decks may make interesting things happen is all I’m going to say for now. But these wont be decided and implemented until the rest of the game itself is in place for sure.

Next post will have something visual, I promise. I’d have posted up a screen dump of my testing title sequence but it just didn’t look nice enough before we decided to change the whole thing anyway.

 

 


Parallels and Gamemaker Studio 2 —

Tinkering with side-projects like Mancala has taken a back seat over the last week, despite my previous raving about wanting to get back into Blitzmax once again. Aaron and I discussed the relative merits of using something huge like Unity for Paradroid and we ended up deciding that it’s overkill for the type of game we’re trying to recreate, and probably for the types of games we usually prototype or develop as well.

This isn’t a reflection on Unity but rather just more of a dislike from my side than his as he was slowly getting on with his side of the project until some test runs on GMS2 showed things could be put together much quicker. And a lot less bloated. Some day Aaron may well want to go back and tinker with it some more, but I’m more uncomfortable with it than him so I suspect I would be doing stuff other than coding if we ever both worked on the same game with it.

And so for now it’s enough of both Blitz, Unity and Mancala. We’re back to tinkering with Paradroid and both working with GMS2 installations working via Parallels, as the Mac version of Gamemaker Studio isn’t being released until 2nd quarter of 2017. This is, frankly a pain in the butt, as the program is still beta anyway, so there’s no support for running it this way, and we’ve both already lost stuff due to adapting to how we have to develop at present.

Aaron has already got “001” droid up and running on a map with the collision system working almost perfectly. He stumbled a bit when he didn’t realise that GMS automatically strips out duplicates and does other space-saving stuff on tilesets which screwed up all his original maps, but he’s over that now.

I’ve done provisional work on all the intro screens displayed on the title, including the scrolling system which broadcasts the information in several stages. Some work to do on the colour system, and it’s got some graphic glitching I need to fix, but it does work with the bodgy code that’s in place at present. Like any new programming language that you learn, a lot of time is spent hacking things together and then going back to fix them up and improve bad areas as you go. I doubt much of this code will stand up once I have a few more run-through’s on the title sequence again to try and get mine running the same way. Heaven knows how Braybrook did all this, plus the actual game, in around 54k back then.

As before the gameplay side of things is still all in Aaron’s side of the project. My end has expanded a bit into working out a way to get the sound effects. A look at the music I have for the title screen that includes the sound effects will hopefully let me strip out some of the originals later on. I’ve also got my beady eye on the transfer game because someone has got to do it, and it looks like it’s going to be murderous to code at present. I’ll definitely be looking at doing this towards the end, once I’m much more familiar with the GM language itself , and using the tools of the dev system much better.

I’d post up a few screens of the title sequence in action – minus animation obviously – but there’s a nasty graphical glitch I need to fix first before I do that. And, considering Aaron is working on an actual Paradroid font, how all this stuff is displayed may get drastically changed anyway.

And, on a final note, I’m going to implore you crazy kids out there who also try and do this game development thing like us to be careful with your data. I have a back up system that runs every night and backs up all sorts of stuff onto my Qnap drive. I also back up stuff once a week or so onto a USB drive. Every month or so I’ll put a copy of it all onto another drive and take it round my mothers house. I’ll then copy it all onto her laptop as well as keep it on the drive as a back up. I’ve got dropbox installed and stuff like my code gets put on there as well now.

You’d think I had myself pretty much covered but I got caught out last night with a little prototype I put together to show off some basic stuff that GMS 2 can do very quickly. I’ve done a couple of these over the last week or so, mainly just to copy out bits of working code I can reuse into my code snippets program. I’d estimate I was about 60% towards a workable, very basic game, including rammed in front and back end screens when parallels crashed. Not a big thing I thought at first but, due to using GMS2 in an emulated windows environment via Parallels, it looks like the system uses some kind of virtual storage system to put the stuff that’s being saved out from any Windows application and it never had a chance to dump out all the data by me exiting the application – in this case GMS2 – normally. So the game is now gone and i’m going to have to recreate it. I only had an hour or so’s worth of work into it, so it’s not a disaster, but it does make me think that I should be a lot more careful in future when it comes to saving stuff out with this system. I’m thinking of letting it just write out to the folders reserved for the PC file system within Parallels now and then copying regular across to a stick, or the Qnap,Mac drive.

Never assume you’ve got every risk covered – because you probably haven’t.

Now I’m going to rewrite this game again – mainly just to piss Aaron off 🙂

 


Polishing the blog —

I took the opportunity to do a little housekeeping on the blog today which ended up with me getting my hands dirty with some raw html again. Very basic stuff in the end, and the kind of stuff I used to do in my sleep in the mid 90’s when we had nothing else to do it all for us. But, like everything else, you forget it all, when you have everything spoon fed to you. Tools like WordPress actually make it pretty easy to do most of what you want, it was just being stubborn that made me do it the hard way to get a couple of linked images in the side bar.

I’m now linking to Aaron’s blog – as he’s finally up and running. He’s trying to discipline himself to the mentality of blogging about what he’s up to. Just like I’ve been trying to do all this time, hence the sporadic entries.

That 15 month gap between posts we can all just forget about, right?

So, on the cards for this evening is a jump back onto the Paradroid project. Aarons still knee-deep trying to rip some of the original graphics and work from them so I’m going to capture all of the droids in a play-through this evening in 2* canvas through Vice.

I’ve got a trained version of Paradroid to help me get to the upper decks a lot easier but it’s pretty tempting to try and get there myself the hard way. Having a bit more time on my hands would probably make me try that as it has been a long time since i last played right through the game.

Hopefully I can make some observations about the game itself tomorrow – once I’ve done this refresher session.

 


Putting it all on screen —

With a mocked up game board in place it’s straight onto probably the hardest part of the project, which is handling all the objects needed for the game. There are 14 holes to keep track of on the board, and 48 pegs. We need to know the hole location of each of those pegs, the x and y positions of them on screen, the status of these pegs (as they could be moving between holes) and what kind of pegs they actually are.

I’m using some basic gem graphics for the players view and they’re going to need to be shuffled around within the hole they are in so it looks like there are however many gems in that hole, even if I have a counter displayed as well. Sticking them all on one central spot is useless as it’s going to look like each hole only has one gem when it could have loads.

So my problem at present is getting a structure in space probably for the board, where it keeps track of how many pegs are in each location, a total counter, which can update dynamically as pegs hit the stash, and the actual data for each peg itself, as there is several bits of information for each object there, too.

I approached this with pseudo code first. Just writing on paper how it should work and putting it into actual code on the page as far as I could remember the syntax at the time. Naturally, with the worlds worst memory for remembering stuff like this, it wasn’t brilliant, so I dumped what I have into the editor and have to tinker around with that to display some counters and feed it some dummy move data to make sure it’s all going to work correctly as actual player movements.

The board object itself, with holes in place is also going to be needed for an AI to work out how many pegs are in each hole when it’s their move so they can react accordingly. It can be programmed to do different things depending on some kind of a user setting but , in most AI, it would be logical to almost always go for a move where you can capture five or more pegs in one go, even if the player is setting them up to get an even greater return. Only a very sharp AI should be able to work this out as most players would play that way, too.

I’ve mapped out the areas where player is going to click to choose a hole to move from as that’s going to be needed for input before I can do any of this. Some kind of visual feedback will need to go in there so player can know they have clicked and the move is taking place. Not sure how I’ll handle that from the computer playing his move as I can’t imagine any kind of AI needed being so time insensitive that there will be a delay.

Onwards…


Mancala & stepping back in time. —

Today was possibly the most productive day I’ve had programming in possibly as much as a year. If any of it is of practical benefit, apart from the pursuit of knowledge and keeping the mind sharp, I’d very much doubt, but I like to think that any time spent in front of the computer putting code together, working with development systems, and just generally plugging away at getting it right is always a good thing.

I’m not so sure that writing such long sentences is also productive, from a creativity point-of-view, but I’m going to let it go because I hate editing stuff I write when it’s a blog post, as I believe it’s meant to be straight to the point and puts your current mood across.

Initially I started the morning with an idea of getting Parallels up and running again so I could tinker some more with Visual studio 2015 on the PC and work further through my book on C# to try out at least some of the code in there. I don’t want to get too specific and work through the entire thing generating windows applications and the like but just a general feel for the syntax of C# when putting it into Unity scripts. This way it would be how to do something with Unity rather than how to get the code right and then fudge it into Unity each time I did anything more than the stuff Unity can do for you.

I’ve mumbled to pretty much anyone who’s ever been interested enough in game development – and asked me about it – my reservations of using bloated game engines or frameworks for simple games because I am not a fan at all. At present the idea of Aaron and I using Unity to recreate Paradroid is almost insulting. It feels like almost cheating in some ways with the tools we have at our disposal compared to Andrew Braybrook just having a buggy assembler and a basic debug monitor. But also it’s a burden as there’s so much you need to know just to do sometimes really basic stuff that you’ve done in other dev systems in seconds without even thinking about it.

Maybe I’m just set in my ways whereas my partner in development is a lot more open to chopping and changing technology as and when the need arrives. We’re approaching Paradroid as just an example to learn Unity in greater depth than our silly Mario projects we both created working from a book to try it out.

I’m very averse to using a 3d engine to create a top/down 2d game but aware that Unity does cater for that and it’s supposed to not be too difficult to do, even though logic screams at me to use something more 2d environment friendly for a project like this. But Unity is used by a lot of people for a lot of games now, and a lot of people thus consider it to be the way forward so you should just use it for everything. The more games you write with it then the better you’re going to get, even if it does mean they’re going to be bloated games with code in them you will never even see, let alone edit.

For me there’s a loss of control there which doesn’t appeal to me too much. But I’m digressing from what I’ve actually been up to – which is the point of this blog – so back on topic.

My idea is to create something relatively simple in gameplay and hopefully coding to work with C# and get to know the language. I wanted to use the Visual Studio on the PC environment on my Mac to do this as games need a window to run in and I want that side of things taken care of for me at this stage so i can just concentrate on the basic syntax stuff and progress up from there. I googled around for a while and finally came up with the idea I wanted to use which was Mancula.

Mancula is the African number one board game of choice apparently, and has been around for many, many years. I first came across it on my Nokia 3310 mobile phone back in 2001, where it was called Bantumi, and used to play it a lot on train journeys to and from work. I’d had an idea to develop a clone of it with Blitzmax after I finished writing the Rock/Paper/Scissors game I was doing at the time. I did finish that game but then moved onto Gravity Force before jumping over to Swift so I never got much further than a few notes back then.

So the basic idea of the game is sound and I could approach it as just being a 2 player game or maybe get clever and put a simple AI in there which, based on how the game works, shouldn’t be too tricky in code. I googled around for a while and found a web version to play for a bit just to remind myself of the rule set so it’s time for a couple of images to look at so you all know what I’m talking about.

If you look at that then you can instantly get the basic idea of the layout.

Here’s the basic rule set from my notes I jotted down as i played a few games. Just for the record I got murdered four games in a row until I got the gist again and then pulled a couple of games back. I was playing on the easy AI level as well. This is a very clever strategy game, for such a simple implementation, so I was more than keen to have a crack at it.

Starting from scratch with this as a C# project is a bit daunting for me, being completely new to it, so I then considered the idea of putting the game together with a language I do know and then approaching it as a conversion from ready-written code. This possibly isn’t that logical to some, as I will be essentially writing the same game twice, but this doesn’t really worry me as it’s all still banging out the code. And I feel I’ve been very lacking with that recently since we started looking at Unity.

My most productive coding was during my days of owning a PC and using BlitzMax along with Blide as a development environment. This was the system I used literally just before Aaron and I got together to form Dexterity Design and I was so comfortable with it by then that I knocked out Gravity Force in 30 days using my half-cocked framework to build it from. GF isn’t a great game but any game I write from start to finish I’ve always been proud of.

As I’m using parallels now for Visual studio, testing out Game Studio 2 – as there’s no Mac version yet, and ProgEd for C64 retro coding fun, it was no great hassle to get Blide back on the machine and start the new project from there. As I suspected the old framework is an absolute mess of a project but I can still use some of it to build from to save time so I did. Screenshot below of Mancala running from the framework and also the development environment of Blide with all the source files that will become the game once I’m done.

Don’t expect to see much in the screenshot of Mancala itself. That’s the frameworks code running only. Most of the code I’ve already written to support the game isn’t to do with the actual display side so that will be in the next post. I’ve got basic public domain images for the game board and pegs but I’m not at the stage where they are going to be on screen as yet. The IDE screenshot is a lot more interesting as I’m currently using a few source files from my crap framework and I’ll probably approach the C# project the same way once I finish this and start on that.

Small steps and all that.

Considering I’m using Blitz again to do the first draft here I did have a look at NG again, in the hope that it’s a bit less kludgy with it’s Xcode projects and I could work with that and put in IOS conditional code so I had the option to dump the game onto the phone again for the memories. Unfortunately, despite lots of hacking around, rebuilding modules, creating new builds of the binaries from git hub and hours of time hacking about with other stuff, I still can’t even build the project I used to build to IOS with a year ago now. It feels almost like stepping backwards with that now, which is a shame as I don’t even have any original builds of other games I used it to convert to the phone now. I’ll have to email Brucey and see if we can bang heads together and get me going again.

 


Getting the basics right —

The reason for developing our Paradroid project is primarily a learning exersize in how to “Unity”

This means, for starters, I’m going to need to have some knowledge of C#. I’m not going to need to be brilliant at it but Unity requires various amounts of raw code within a project unless you’re doing something really basic that you can bang together with just the drag and drop elements.

Paradroid is going to need a fair bit of code within it because it’s not a massive, pretty 3d project that can use dumped in particle effects, 3d landscapes and just rely on Unity cameras to do all the movement work within the limitations of what the UI lets you tinker with. And, with Unity, it’s C# or Java. I know very little about either language so i’m taking a bit of time to start getting the gist of the syntax in comparison to other languages I’ve worked in as it may save some of the inevitable headaches later on.

So I bought a book. A book on C# which has been written to work alongside Microsofts current implementation of Visual Studio (2015). All well and good, even though I work on a Mac system, as there’s a beta build of VS out for Mac now, and it should be identical in use to the Windows/PC one, right?

Wrong. It does things its own way. Probably just fine for advanced Mac users who know the product but are starting with new projects and doing things their own way. But I’m working from a book which holds your hand the entire way, and expects you to follow it pretty rigid.

My solution for this (thanks to Aaron’s suggestion) was to go the first few chapters where it’s dealing primarily with the functions of the language and outputting to console in a Unity wrapper. This means putting a basic Unity project in place, attaching a script object to it, and then outputting to the Unity output console with the results of what I’m doing.

You can see the result of that in the image below. It even shows the C# code which only logs “Hello” as is, kind of like the old Hello World program that every language ever written uses as an example to show its syntax.

 

I’ll be building all my test code which needs console output into a seperate function within that script and letting Unity give me the results rather than try digging around for a basic C# interpreter I can use in a Mac terminal window.

Could probably do that instead but it’s playing with Unity to do stuff like this that gets me used to using the thing. So why the hell not.

Here’s the script in copy/paste format for anyone who actually would find this useful apart from me.

using UnityEngine;
using System.Collections;

public class Blah : MonoBehaviour {
    void Start () {
        MyGameLog();
    }
    void MyGameLog() {
        Debug.Log (Hello);
    }
}

That will be edited a lot once I start using it as it will need to put everything into a public variable and push to the log function but it’s just shown as an illustration for now. And because I might find it amusing a few years down the line when I look at this again. And maybe know a bit more about what i’m talking about by then.

 


Project Paradroid —

When creating Paradroid back in the early eighties, Andrew Braybrook created a masterpiece. A game consistently rated as one of the greatest games ever written on the C64, and also one of the most fun to play.

From a technical point of view, it’s also a master class in how to fit a huge game into a tiny amount of memory space – around 54k when using pure machine code, but you have to have all the graphics and sound data in there too. It’s no wonder it took him around six months to write the game because you somehow have to cram everything in.

Remaking the game for the modern age is, in theory, a lot easier. We don’t have custom built development systems banged together out of cereal boxes where you’re trying to squirt raw assembled code down a serial port and hoping the damn thing doesn’t crash, for example.

We have the kind of technology for development that the programmers from that era could only dream of. They had old 64’s held together by sellotape, and often with hardware faults such as the sound chips, linked up to Atari ST’s that had just about useable assemblers piping data back and forth because you couldn’t fit a development environment into the target machine itself due to memory constraints.

We have Unity so should have the edge right?

If only it was that easy.

Unity is a new direction for us so this is a learning exersize, rather than a game we plan to get out there and have people playing in the near future. If it doesn’t pan out, or we run into trouble trying to find out if we even can release it, then it’s probably going to end up nowhere. In our favour there have been many remakes of this game over the years, all free, which have never encountered issues, so we should be ok but it’s like going back to the stone age for us, in programming terms, trying to use this massive application to write what should be just a small, 2D game.

Got to start somewhere, right?

So Aaron and I have kind of set ourselves separate paths on how we would put this game together as I’ve been mostly tinkering around with the UI side of Unity while he has been having fun with tile maps. Logically I’ll work to start with on putting together the front-end side of the game, hopefully as close to the original as possible. Aaron will work on the actual gameplay side on his own scene and, in theory, we should be able to drop our sections together in Unity and update each others project fairly easily. We opted to use this project to work through the trials and tribulations of cross-party development as for a long while we probably won’t lock horns where we would both be working on the same part causing all sorts of headaches.

As a rough idea of splitting the project, and very likely to change later on, my side will consist of doing the following tasks. If I can talk Aaron into it then maybe he can blog about his side as the problems he has getting the gameplay side together are likely to be just as interesting as mine.

Title sequence.

Here I do want the same look as the original Paradroid – right down to the same scrolling text screens giving you information about the game you’re going to play. I thought the atmospheric element of that was wonderful when I first played the original game. Heaven knows how he squeezed in so much data as well as all that game.

End game sequence.

I may diversify here depending on how it pans out. That tv sequence with the scan lines jumping around could be replicated – maybe with a particle effect – but maybe something else could be done here as well.

Static screens.

These are the pages of information you used to be able to pull up by accessing any of the computer terminals in-game. Stuff such as the detailed robot descriptions for all 24 of the droids in the game – including your 001 unit.

Lift screen UI.

It’s not just a basic up/down floor system for the lifts in Paradroid’s maps. There were different connections to different floors depending on which one you actually used, and not all lifts could access every location. There was definitely an element of strategy and learning routes needed to navigate this and clear all the floors. Took me ages to get used to it.

In-game HUD.

How well I can work this into a scene being developed by Aaron will be an interesting test of dual development. In theory I can have an isolated object for the game HUD and a pause game menu system that can be written outside of his scene and then just dropped in and linked up. The in-game HUD will be for showing the droid unit in use, it’s command operation IE:Mobile, console, Lift, Transfer or whatever, and also the score.

Audio.

We’re not musicians or sound effect masters so it’s a case of either track down the original sound effects, get sounds that are kind of similar, or rip them out of the original game, if it’s possible. The randomised robot communication thing on the original games title screen doesn’t do much for me though, so I’m using some tribute music I found instead.

Lots to think about then.

I dug up lots of old images for research purposes which will be mostly redone in a very close style for our version, rather than try to re-use. The walls of text can be recreated manually as memory constraints would be the least of our problem this time and they work on a C64 size screen which is something like 200*160. Hardly practical unless you want to put your nose to the screen every time you played the game.

The original Paradroid font was my first challenge and I did look around to see if someone had already converted it into a useable font to save some time. Having no such luck, I started converting some of the characters myself before realising that it was a mostly pointless exercise as they looked frankly terrible when sized up to something that would be drawn on screen today. After a couple of hours trying to salvage something that was respectful to the original and wouldn’t put off any modern gamers, I gave up and just found an alternative Space themed font instead.

Braybrook had also made a couple of the chars in his original letters double width to make them readable so it would have been even harder trying to build up text walls that fitted correctly when automating some kind of display from a text file I typed into Unity.

Looking at the droid information screens I am tempted to try and reuse the originals. Our intention isn’t to try and make Paradroid 2, just a tribute to the original, honouring it as best we can by copying what it did. I’ll try to upscale them to a decent size and throw them into a panel in Unity to see how they look before deciding if they stay in.

One of the beautiful things about Paradroid is that you were looking down on your player object, and said object was rendered as a simple droid because you were basically only being shown a primitive top down view using the same droid design as the others, with just the droid model number to identify other hostiles because the game plot dictated it. You’re an influence device which is on the shop interacting with these other droids, but you, as the player, are on a different ship sending in the old stunt robot to do the messy work on your behalf.

So, I don’t need all those different robot images for anything other than the static screens from the terminals. Hopefully I can keep them as I can’t draw for shit so don’t want to redo them unless I can talk Aaron into it…

I did a quick mock up test on the original Andrew Braybrook Paradroid logo screen with the music to test that I had the screen setup right in Unity for the camera view so I could also colour it and test the music plays ok. Although we’re likely not looking at putting the project onto IOS it did compile and export through Xcode ok to actually build on my phone but there were lots of ugly yellow messages that probably aren’t too good. Maybe I need to check my build of Unity. Anyway, it’s a good starting point to move on from.