Started off today's session with a brief look through the Brush code to see how I'd structured the data, and I reached one of those points where the code ceased to make sense - I'd reserved an array to hold the Brush X and Y dimensions, but for some reason this wasn't being used. That left the question, how on Earth could the routine possibly work? After a little detective work, it turns out I'd been too efficient, storing the dimensions along with the actual Brush data, rather than the X/Y array. Doh!
The main task for today, however, was to tackle the Mini-Map, which shows a miniature version of the current layer. This was implemented some time ago, but never finished due to the fact that other routines needed to be finalised.
My first task was to alter the routine to allow the user to move the Highlight cursor (which shows the User which part of the map they are looking at) by using the mouse - this was relatively painless, and speeds up map navigation exponentially.
With this in place, I adjusted the Tabber and Canvas routines to allow the Mini-Map to cater for maps larger than the Mini-Map window; the scrolling took a little while to get right, but needs further thought regarding how this will be integrated with the mouse control, i.e. does the cursor stay in the centre of the window and the map scroll around it?
Thursday, January 27, 2005
Saturday, January 15, 2005
Saturday 15th
A scribbled note on my To-Do list which said "clipboard" got me thinking about Brush functionality today. Currently the user can grab a brush up to the size of the current map and store this in one of 8 reserved buffers. I wasn't sure, however, if it was worth adding the facility to copy the Brush to a clipboard for quick recall. However, the Editor also allows you to grab a Brush, switch to another drawing mode, then return to Brush mode with the previous Brush - saved or not - still in the buffer. With that in mind, I cast aside my clipboard-orientated thoughts and set about more pressing issues.
I did a little bit of work on some new icons for the toolbar, as I want to ensure that all pertinent functions are accommodated thereon. This brief foray into PhotoShop yielded some iffy results, so I postponed my toolbar session until a later date, and produced some placeholder icons instead.
I finished off by implementing a proper "Dropper" mode, which, once activated, allows the user to grab tiles using the Left/Right mouse buttons (the user can assign a different tile to each button, thus making it easier to edit maps). In all other drawing modes, the user still has limited Dropper functionality, and can assign a tile to the Left button by clicking the Middle mouse button.
The next task in hand involved I/O (Input / Output), currently a grey area for me and not one of my particular favourites - which is ironic, as all my I/O routines so far have been painless to write and debug.
I started off by tidying up the existing Load / Save functions, allowing the user to save any layer as a .MAP file, then load that back in to any layer. For clarity, I added the filename of the current layer in the title bar of the Editor window, and added some extra checks to ensure that the Editor performs a "Save As" as opposed to a normal "Save" if the current layer hasn't been saved previously or loaded from a file.
I then expanded these routines to implement the Project Load / Save functions, which bundles all of the maps into one file. This currently just holds map data and dumps it directly to the Layers; I need to add further modifications so that map dimensions are stored, along with file locations for associated tilesets, a header section with a checksum, as well as any Brushes the user has stored.
I finished up by taking a few screenshots of various menus from other editors, just as a point of reference to see the best way to organise common features; that done, I set about revamping the menus as they'd been somewhat neglected, and added all the I/O, Grid, Brush, and Dump functionality. Not an awe-inspiring task, but the Editor is slowly starting to look like a finished product.
I did a little bit of work on some new icons for the toolbar, as I want to ensure that all pertinent functions are accommodated thereon. This brief foray into PhotoShop yielded some iffy results, so I postponed my toolbar session until a later date, and produced some placeholder icons instead.
I finished off by implementing a proper "Dropper" mode, which, once activated, allows the user to grab tiles using the Left/Right mouse buttons (the user can assign a different tile to each button, thus making it easier to edit maps). In all other drawing modes, the user still has limited Dropper functionality, and can assign a tile to the Left button by clicking the Middle mouse button.
The next task in hand involved I/O (Input / Output), currently a grey area for me and not one of my particular favourites - which is ironic, as all my I/O routines so far have been painless to write and debug.
I started off by tidying up the existing Load / Save functions, allowing the user to save any layer as a .MAP file, then load that back in to any layer. For clarity, I added the filename of the current layer in the title bar of the Editor window, and added some extra checks to ensure that the Editor performs a "Save As" as opposed to a normal "Save" if the current layer hasn't been saved previously or loaded from a file.
I then expanded these routines to implement the Project Load / Save functions, which bundles all of the maps into one file. This currently just holds map data and dumps it directly to the Layers; I need to add further modifications so that map dimensions are stored, along with file locations for associated tilesets, a header section with a checksum, as well as any Brushes the user has stored.
I finished up by taking a few screenshots of various menus from other editors, just as a point of reference to see the best way to organise common features; that done, I set about revamping the menus as they'd been somewhat neglected, and added all the I/O, Grid, Brush, and Dump functionality. Not an awe-inspiring task, but the Editor is slowly starting to look like a finished product.
Friday, January 14, 2005
Friday 14th
Started chugging through my To-Do list for the Editor, and kicked off by fixing a small bug in my input routine; with that fixed, the user can now manually specify the size of the Grid, which comes in handy if you, well, like a bit of variety in the grid department. This should work well alongside the Brush Grid which, if you remember, resizes itself automatically to suit the current Brush.
The bulk of the day's work was taken up with the Dump functions (no sniggering at the back!). The first routine was a simple function to dump the current Editor view to a BMP file; I've used an editor in the past which had this function, and it came in useful when reporting errors to artists (such as tiles not lining up properly).
The second routine, and one which took a lot longer to debug than I expected, was intended to dump the entire map to a BMP. This was trickier than it sounds, mainly because the maps only exist in memory as a string of data, which are rendered to the screen to produce the current Editor view. In order to dump a map to a BMP file, therefore, the map needs to be rendered to a huge canvas 'behind the scenes'.
Thus, the second routine has to create a new canvas, render the map to it, produce the file, then dispose of the canvas cleanly so as not to hog memory. After much tinkering, however, the routine was in and working beautifully. Currently the routine only dumps out the current layer (if you recall, the Editor supports multiple layers for parallax, collision, and so forth), but I may add a tweak to output the "merged" layers as a BMP, too.
The bulk of the day's work was taken up with the Dump functions (no sniggering at the back!). The first routine was a simple function to dump the current Editor view to a BMP file; I've used an editor in the past which had this function, and it came in useful when reporting errors to artists (such as tiles not lining up properly).
The second routine, and one which took a lot longer to debug than I expected, was intended to dump the entire map to a BMP. This was trickier than it sounds, mainly because the maps only exist in memory as a string of data, which are rendered to the screen to produce the current Editor view. In order to dump a map to a BMP file, therefore, the map needs to be rendered to a huge canvas 'behind the scenes'.
Thus, the second routine has to create a new canvas, render the map to it, produce the file, then dispose of the canvas cleanly so as not to hog memory. After much tinkering, however, the routine was in and working beautifully. Currently the routine only dumps out the current layer (if you recall, the Editor supports multiple layers for parallax, collision, and so forth), but I may add a tweak to output the "merged" layers as a BMP, too.
Thursday, January 13, 2005
Thursday 13th
After struggling with the scrolling routine bugs towards the end of last week, and trying - and failing - to implement a new graphics library, I turned my attention to the Editor again, as it's been some months since I'd made any updates or changes.
The reason for this came from an unexpected development; the Editor had been suffering from a distinct lack of usability due to the fact that some of the gadgets - Tabbers and check boxes - hadn't been working properly. After a brief chat on IRC with a fellow programmer, I took time out to send him a cut-down version of the program to see if he could spot any errors.
More often than not, the best way to debug complex code is to step through it methodically; it's not always the most appealing task and thus, not always the first thing you try, but it does work. And, lo and behold, a mere 5 minutes after sending off the code, the problem suddenly dawned on me. Ten seconds later, everything was working properly :)
Flushed with today's success, I spent a little bit of time this evening getting reacquainted with the Editor and its various features, jotting down any obvious changes or improvements I need to add. I also took the liberty of fixing the Mouse Wheel functionality, which had never worked properly since its addition.
The reason for this came from an unexpected development; the Editor had been suffering from a distinct lack of usability due to the fact that some of the gadgets - Tabbers and check boxes - hadn't been working properly. After a brief chat on IRC with a fellow programmer, I took time out to send him a cut-down version of the program to see if he could spot any errors.
More often than not, the best way to debug complex code is to step through it methodically; it's not always the most appealing task and thus, not always the first thing you try, but it does work. And, lo and behold, a mere 5 minutes after sending off the code, the problem suddenly dawned on me. Ten seconds later, everything was working properly :)
Flushed with today's success, I spent a little bit of time this evening getting reacquainted with the Editor and its various features, jotting down any obvious changes or improvements I need to add. I also took the liberty of fixing the Mouse Wheel functionality, which had never worked properly since its addition.
Thursday, January 6, 2005
Thursday 6th
After more than a little noggin scratching, yesterday I managed to resolve the problem with Monitor's erratic screen position, so today I could plough ahead and write the collision routine. While collision may seem to be rather complex, map collisions are relatively simple to check for.
I started off by creating a routine that tracked the mouse position (purely to make the routine easier to test), and made it highlight the tile beneath the pointer. Once this was done, I added the tweaks to ensure the highlight aligned itself properly to tiles even when the screen was being scrolled.
Next, the routine was adapted to highlight the tiles directly adjacent to the main tile (apart from diagonals - Monitor can only move in four directions). Finally, I added a tweak to check these adjacent tiles to see if they are solid walls and, if so, change the highlight colour from green to red.
Once the routine was complete, I tweaked the routine to get its X and Y information from Monitor, as opposed to the mouse, and tweaked the movement routine to utilise the collision data. The upshot of all this tinkering is that the tiles directly adjacent to Monitor are now checked to see if they are solid and, if so, the player is prevented from moving to them.
I now have the bulk of the background collision system in place - this will require a few tweaks tomorrow when I finalise the movement routine to make Monitor move a whole tile at a time, as opposed to pixel-by-pixel.
The collision system in action, with wall tiles highlighted in red...
I started off by creating a routine that tracked the mouse position (purely to make the routine easier to test), and made it highlight the tile beneath the pointer. Once this was done, I added the tweaks to ensure the highlight aligned itself properly to tiles even when the screen was being scrolled.
Next, the routine was adapted to highlight the tiles directly adjacent to the main tile (apart from diagonals - Monitor can only move in four directions). Finally, I added a tweak to check these adjacent tiles to see if they are solid walls and, if so, change the highlight colour from green to red.
Once the routine was complete, I tweaked the routine to get its X and Y information from Monitor, as opposed to the mouse, and tweaked the movement routine to utilise the collision data. The upshot of all this tinkering is that the tiles directly adjacent to Monitor are now checked to see if they are solid and, if so, the player is prevented from moving to them.
I now have the bulk of the background collision system in place - this will require a few tweaks tomorrow when I finalise the movement routine to make Monitor move a whole tile at a time, as opposed to pixel-by-pixel.
The collision system in action, with wall tiles highlighted in red...
Monday, January 3, 2005
Monday 3rd
While I was putting together the screenshot for yesterday's entry, I took the liberty of increasing the tile size to 64x64 (as opposed to 32x32 as it was previously), and doubling the size of Monitor and its bullets. Combined with the new HUD and screen resolution, I was suitably enthused, and today I decided to plough ahead and write the map display and scrolling routines.
As is often the case, I tend to look at tutorials and other people's code to see how they approach the task in hand (very rarely does cutting & pasting someone else's code prove useful - after all, if you've no idea how it works, you can't fix it when it doesn't work or make amendments if you want to expand its capabilities).
After a little light reading, I started off by copying across the map display variables and routines from my Map Editor (technically speaking I should have made the original code modular enough to use seamlessly across a number of applications, but that's a valuable lesson for future projects). With very little effort I had the map up on screen in no time.
After this began the tricky task of implementing a "fine scroll" routine to compliment the "coarse scroll" routine already in place (the latter scrolls the map an entire tile at a time; the former allows the map to be scrolled pixel by pixel).
This proved easier than expected, so the bulk of the afternoon was spent tidying up the routines to make them more modular (for instance, rather than have a routine to read the keyboard then adjust the scroll position, the keyboard routine merely set flags which are then used by the game engine to set other flags which drive the scroller). It also allows me to "detach" control of the scroller from the player's ship, for reasons which will become apparent much later. ;)
One thing that became apparent was the ugly nature of the 800x600 resolution - 64x64 blocks don't sit neatly within the screen any more, which looks a little messy on occasion. I've made a mental note to address this by using a Viewport, which will allow me to render the map inside a 768x576 window within the actual 800x600 screen; this will not only neaten up the tile layout, but will also give me a small black border around the playing area which will compliment the HUD very nicely indeed.
The day was rounded off by a little tweaking and bug fixing. There are a couple of quirks in the control routine at present, which causes Monitor's position to jump alarmingly near the edges of the map, and I still have to implement the collision detection, but these tasks are better tackled after a night's sleep. :)
As is often the case, I tend to look at tutorials and other people's code to see how they approach the task in hand (very rarely does cutting & pasting someone else's code prove useful - after all, if you've no idea how it works, you can't fix it when it doesn't work or make amendments if you want to expand its capabilities).
After a little light reading, I started off by copying across the map display variables and routines from my Map Editor (technically speaking I should have made the original code modular enough to use seamlessly across a number of applications, but that's a valuable lesson for future projects). With very little effort I had the map up on screen in no time.
After this began the tricky task of implementing a "fine scroll" routine to compliment the "coarse scroll" routine already in place (the latter scrolls the map an entire tile at a time; the former allows the map to be scrolled pixel by pixel).
This proved easier than expected, so the bulk of the afternoon was spent tidying up the routines to make them more modular (for instance, rather than have a routine to read the keyboard then adjust the scroll position, the keyboard routine merely set flags which are then used by the game engine to set other flags which drive the scroller). It also allows me to "detach" control of the scroller from the player's ship, for reasons which will become apparent much later. ;)
One thing that became apparent was the ugly nature of the 800x600 resolution - 64x64 blocks don't sit neatly within the screen any more, which looks a little messy on occasion. I've made a mental note to address this by using a Viewport, which will allow me to render the map inside a 768x576 window within the actual 800x600 screen; this will not only neaten up the tile layout, but will also give me a small black border around the playing area which will compliment the HUD very nicely indeed.
The day was rounded off by a little tweaking and bug fixing. There are a couple of quirks in the control routine at present, which causes Monitor's position to jump alarmingly near the edges of the map, and I still have to implement the collision detection, but these tasks are better tackled after a night's sleep. :)
Sunday, January 2, 2005
Sunday 2nd
With my head suitably bursting with ideas I wanted to try, today's first task was to produce a rough mockup of the HUD. After working out the rough dimensions, I created a PhotoShop template and proceeded to stare at the screen for a good 30 minutes wondering if I had the ability to realise the vision in my head. Thankfully, I was able to knock up a fairly decent HUD within an hour.
As is usually the case, I then spent another hour tinkering with the design and, specifically, finalising how the pertinent information will be displayed; I like the idea of numerical values for certain items (e.g ammunition), but prefer bars for other commodities (such as energy).
With this in mind, the two displays at the top left/right of the screen will display weapons and items, and will feature both numerical displays and representative bars. In contrast, the display at the bottom-right of the screen will have just representative bars, including the player's energy level and the Drone's energy level (the player, as per the C64 version, will be able to capture and control other mechanical Drones during the game).
A bi-product of all the tinkering was the idea to have different colour schemes for the HUD; on the C64 version, each Monitor craft came in a different colour (to give the player the impression they were controlling a new craft after their previous one was destroyed). I've always liked this idea, and I hit upon the idea that each new Monitor craft could come with a HUD colour scheme to match the ship colour. Hmmm!
After a couple of suggestions on the Llamasoft forum, my thoughts returned to yesterday's conundrum: do I restrict the player to the centre of the screen, or allow them to roam freely and - occasionally - disappear behind the HUD? After careful consideration, I decided on the latter. To compensate for situations where this might not be user-friendly, I hit on the idea of using the final HUD area at the bottom-left of the screen as a radar/scanner, which will show the location of key objects/enemies.
My final task for the night was to integrate the new HUD graphics, which seemed to shrink the playing area considerably (or should that be alarmingly?). This was more than a minor bugbear, particularly as I was extremely pleased with the look and feel of the HUD so far. The obvious answer was to expand the screen to 800x600, and after tweaking a few variables and the HUD layout, everything was in, working, and looking pretty dapper.
I rounded off the night by creating a bitmap version of the HUD font and tied this in to the mouse wheel function; now the player can use the wheel to choose a weapon and see the change reflected in the HUD. Though not a permanent addition to the game (I have some ambitious plans for the HUD, specifically some nice animation and movement effects), these simple additions are starting to help a very basic shell feel more like a game.
As is usually the case, I then spent another hour tinkering with the design and, specifically, finalising how the pertinent information will be displayed; I like the idea of numerical values for certain items (e.g ammunition), but prefer bars for other commodities (such as energy).
With this in mind, the two displays at the top left/right of the screen will display weapons and items, and will feature both numerical displays and representative bars. In contrast, the display at the bottom-right of the screen will have just representative bars, including the player's energy level and the Drone's energy level (the player, as per the C64 version, will be able to capture and control other mechanical Drones during the game).
A bi-product of all the tinkering was the idea to have different colour schemes for the HUD; on the C64 version, each Monitor craft came in a different colour (to give the player the impression they were controlling a new craft after their previous one was destroyed). I've always liked this idea, and I hit upon the idea that each new Monitor craft could come with a HUD colour scheme to match the ship colour. Hmmm!
After a couple of suggestions on the Llamasoft forum, my thoughts returned to yesterday's conundrum: do I restrict the player to the centre of the screen, or allow them to roam freely and - occasionally - disappear behind the HUD? After careful consideration, I decided on the latter. To compensate for situations where this might not be user-friendly, I hit on the idea of using the final HUD area at the bottom-left of the screen as a radar/scanner, which will show the location of key objects/enemies.
My final task for the night was to integrate the new HUD graphics, which seemed to shrink the playing area considerably (or should that be alarmingly?). This was more than a minor bugbear, particularly as I was extremely pleased with the look and feel of the HUD so far. The obvious answer was to expand the screen to 800x600, and after tweaking a few variables and the HUD layout, everything was in, working, and looking pretty dapper.
I rounded off the night by creating a bitmap version of the HUD font and tied this in to the mouse wheel function; now the player can use the wheel to choose a weapon and see the change reflected in the HUD. Though not a permanent addition to the game (I have some ambitious plans for the HUD, specifically some nice animation and movement effects), these simple additions are starting to help a very basic shell feel more like a game.
The new-look status panel, along with Monitor spewing bullets...
Saturday, January 1, 2005
Saturday 1st
Cripes! My first entry in almost three months! Progress has been slow due to my 2 month trip to Canada, but hopefully things should pick up a little, as I'm determined to make some headway on Citadel whenever I can.
The main motivating factor to don my magic coding pants once again has been an online Blitz remake of Alien Breed; everything is being done by a group of Blitz enthusiasts, and it's encouraging to see how small acorns can grow. Plus, it's pretty interesting looking at other people's code in the context of a game to see how various elements - such as scrolling routines and enemy sequencers - might be tackled.
Suitably enthused, yesterday I booted up Blitz for the first time in a long time to discover that, thankfully, I hadn't forgotten everything I'd learned in previous months. I started messing with the mouse wheel, as I like the idea of using it to select the current weapon, and tonight I implemented a specific routine to do just that.
This got me thinking about the Status display (or HUD, as I'll refer to it from now on); I worked on a game design a number of years ago, which will probably never see the light of day, and I remember that the HUD design was pretty cool, even if I do say so myself. This led me to have a quick dabble in PhotoShop to see if I could recreate the design and, more importantly, if it would suit the game and be able to accommodate the required information.
After a little scribbling and head-scratching, I had the design roughed-out and even added a little bit of code to display this on screen. This got me thinking about a couple of important factors, the first being screen size. Currently, the game is running in a 640x480 window (the final game will be full-screen). I was a little concerned that the HUD might look fairly crude in this resolution, but after a little bit of tinkering to run the game in full-screen mode, my fears were alleviated.
The second issue concerns how intrusive the HUD could potentially be. I had originally envisaged the scrolling system to work the same as the C64, i.e. Monitor remains in the centre of the screen until it reaches the edge of the map - at this point, the map ceases scrolling and the Monitor craft is allowed to move right up to the boundary.
This wasn't an issue on the C64, as the status panel was tucked away at the top of the screen. My HUD idea, however, is overlaid onto the playing area, and sits nicely in the corners of the screen; if I implement the C64's scrolling system as-is, there's the potential for the Monitor craft to get lost behind the HUD. I sense much head-scratching on the horizon... :)
The main motivating factor to don my magic coding pants once again has been an online Blitz remake of Alien Breed; everything is being done by a group of Blitz enthusiasts, and it's encouraging to see how small acorns can grow. Plus, it's pretty interesting looking at other people's code in the context of a game to see how various elements - such as scrolling routines and enemy sequencers - might be tackled.
Suitably enthused, yesterday I booted up Blitz for the first time in a long time to discover that, thankfully, I hadn't forgotten everything I'd learned in previous months. I started messing with the mouse wheel, as I like the idea of using it to select the current weapon, and tonight I implemented a specific routine to do just that.
This got me thinking about the Status display (or HUD, as I'll refer to it from now on); I worked on a game design a number of years ago, which will probably never see the light of day, and I remember that the HUD design was pretty cool, even if I do say so myself. This led me to have a quick dabble in PhotoShop to see if I could recreate the design and, more importantly, if it would suit the game and be able to accommodate the required information.
After a little scribbling and head-scratching, I had the design roughed-out and even added a little bit of code to display this on screen. This got me thinking about a couple of important factors, the first being screen size. Currently, the game is running in a 640x480 window (the final game will be full-screen). I was a little concerned that the HUD might look fairly crude in this resolution, but after a little bit of tinkering to run the game in full-screen mode, my fears were alleviated.
The second issue concerns how intrusive the HUD could potentially be. I had originally envisaged the scrolling system to work the same as the C64, i.e. Monitor remains in the centre of the screen until it reaches the edge of the map - at this point, the map ceases scrolling and the Monitor craft is allowed to move right up to the boundary.
This wasn't an issue on the C64, as the status panel was tucked away at the top of the screen. My HUD idea, however, is overlaid onto the playing area, and sits nicely in the corners of the screen; if I implement the C64's scrolling system as-is, there's the potential for the Monitor craft to get lost behind the HUD. I sense much head-scratching on the horizon... :)
Subscribe to:
Posts (Atom)
