It’s meant to be my main character’s adorable sprite image… almost. All these C compilers written after the 1980s have left me spoiled — It’s probably not a good idea to write hundreds of lines of code at a time without testing when you’re using TurboC (1988).
I think I found an error in one of the compiler-made error message I got.
Never gotten this one before — I guess we’re not going to have super massive levels. Writing any streaming-from-disk-levels-cleverness using 16bit DOS probably isn’t the best idea given the time constraint.
Not 100% happy with the walk cycle, animating a 1bit sprite is surprisingly hard to get right.
Sprite loading all over again, trying to get tilemaps to work. Hard to imagine how we had computer software in the 1980s — then again, this is far more fun than a segfault.
Aw yeah. Got the tilemap loading / drawing / collision working! This is all the main tedious parts out the way. I managed to write the worlds smallest (and worst) .TMX loader so I can just load the Tiled level files right into the game. It felt a bit funny using tech from the 80s to load XML, a format which wouldn’t be invented for another 8 years.
I think the game is going to end up needing a Pentium at the very least, I doubt I’ll get it running well on a 486 given the time constraints. The sparse colour palette was a stylistic choice, I could display up to 256 colours — more colours will probably come into play later.
Submitted the “game” last night, but I was too tired to make a post about it. Game is over here.
I unfortunately didn’t didn’t get a chance to finish it, so it’s very short. That being said, I’m rather happy with the results. I was using a very old 16bit DOS compiler (turboC, 1988), I had to run it with warnings disabled as it wouldn’t shut up and no amount of brackets and casting could make it understand that I meant to do something a certain way — the lack of useful warnings was a massive contrast to how I’d run GCC, with -Wall. This lead to a lot of bugs, glitches and issues throughout.
I’m also convinced that as you approached the 64kb global/static memory limit in TurboC that some variables would begin to overlap or something to that effect. I did a little reading and discovered TurboC was prone to a lot of weirdness, so it doesn’t seem out of the question. Knowing the compiler would be less forgiving in terms of warnings I specifically approached the code with the intent of avoiding malloc (I did use it for allocating memory for the images, though), I only discovered later on about the global/static memory limit. Despite turboC’s 64k limit there was something quite nice about only using the stack and global/static memory, as if you get a much clearer idea of exactly how much memory you’re using and don’t need to worry about memory leaks or other memory issues, everything has a preset upper bound. This has made me consider writing a game that doesn’t use malloc at all in the future, although I’d have to use a different compiler.
I may do a longer write up on the technical aspects of the game and its code, but I question how relevant the information might be in 2013 😉
Looking forward to trying out some of the other entries, I saw some impressive screenshots being posted. I’ll hopefully get a chance to give them a go this evening.
Another Ludum Dare, another fancy preloader.
I had success using Haxe + NME last Ludum Dare, so I’m planning to use the same combination again, I’ll also be using much of the same base code. In addition to this I’ve derived some base code from parts of my LD#27 entry which will give me some basic flixel-like functionality, I may not use all the code but I’m announcing it here in case I do.
You can download all the base code from here. An overview of the LD#27 base code I’ll be re-using can be found here, the new additions consist of the following:
ld.Entity
An object which exists in the game, can be text, a single image or an animated sprite. Has very basic collision detection and very simple collision resolution.
ld.Group
Can contain a number of entities. Handles the updating of each of its child entities’ logic, their collision, and the drawing of the entities each frame.
ld.Tilemap
A basic tilemap implementation. Handles loading a tilemap and displaying it on the screen, handles collision with an entity based on the tiles it could be overlapping with.
ld.Tmx
Parses Tiled CSV files (.tmx) into an object. This makes loading all the objects and the tilemap from a .tmx file a lot easier.
Someone has a spring in their step…
Brrrrr
Coo, coo
18This entry was posted on Saturday, December 14th, 2013 at 9:46 am and is filed under LD #28. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
That took way too long to get working.
That’s the end of day one, the cat is stuck again (notice it doesn’t follow the player). Time to sleep I think…
MenuState -> PlayState over-exposure-ish-fade-in (you’ll have to excuse the banding from the GIF’s limited palette)
I may or may not have added day/night cycles, too..
Lets try not to leave the gameplay and plot down to the last 2hours like usual…
I’ve compiled a table of every entry from this Ludum Dare. Click here or on the image to check it out.
The collaborative effort for MiniLD48 between me and bitslap is coming along well, I think.
5This entry was posted on Friday, January 10th, 2014 at 5:12 pm and is filed under MiniLD #48. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Added the ability for the player to interact with things + map swapping = Working doors!
Submitted the collaboration between bitslap and me for MiniLD48. Entry page is over here or click the screenshot above.
This is how it looks right now, hopefully this will improve…
Still trying to settle on a game idea, I’m uncertain whether “mole people” is the way to go.
Animated swaying grass.
You would have thought I’d learnt my lesson of not wasting time on weird little visual things before actually making the game… Nope.
