A few lumps and bumps

This post is just a quick discussion of the various issues we have had so far whilst developing Parchment and the ways in which we have overcome them.
One of the first problems we had whilst developing was the choice of tile size.  Being that we had created level designs in a rough form, we then had to work out how to transfer that to our screens without losing the sort of proportions and shapes we had set in place.  All this, whilst also managing to get the right viewport size to fit the amount of information we wanted i.e. horizontal scrolling.  The way that we overcame this was to use our very first prototype of the level designs we had created to try to work out what sizes were appropriate to our design.  This obviously required a bit of trial and error in Dame and then also porting this change to our code.  However it did not take too ling to find an appropriate size - 35 x 35 and once this was found we could begin dealing with the game development properly.

The next issue we had off the back of this was the character control.  Our character needed to be able to move around in the 35 x 35 environment but whilst also acting appropriately for our level design.  The main issue in particular was based on jumping height and distance.  This therefore required some more precise coding toward the characters jumping mechanism, as well as using trial and error to find the correct values for this problem to be solved. Similarly to this we also initially had issues with the character collisions as the character image size meant that our character would look like he was floating in mid air when on the edge of ledges.  With a quick bit of research into the pre-built Flixel classes however this was quickly solved.

In wanting to deal with the background sprites in Dame this provided us with our next major issue: getting the exported code given out by Dame into Flixel in a functional format.  The code that Dame could provide us did not include the images directly but instead relied on each having their own classes.  However it did provide us with x and y positions.  Therefore the quickest way we felt to deal with this was to take these positions out of the code and build our own custom array that had all the required data for each image we needed to add into the game.  This turned out to be a longer process that we initially imagined, but did however prove successful.  In hindsight it may have been better to work out a way of working with the original Dame classes rather than working around them, although it seems that would still have required creating separate classes for each image element that included the embedded image, its width and height.