Jump to content
IGNORED

Leprechaun Level Editor (now with load!)


EricBall

Recommended Posts

Re-announcing the Leprechaun Level Editor!

 

This will allow you to create your own Leprechaun levels. The SAVE button dynamically creates a SuperCharger binary (based on the current development release) usable by any emulator or SC compatible RAMcart. The LOAD button will allow you to reload any level previously created with the editor (including previous versions). This means any levels created using the editor can be refreshed with the current development release simply by Loading & Saving.

 

This is all part of my plan to have people create lots & lots of levels for Leprechaun, which can then be included as part of the final game.

 

Notes on the current development release (as of today):

1. RESET detection! (Note: if you die the level will restart, execpt for the time. It's supposed to wait for movement, but there's a bug.)

2. The level timer at the top of the screen is just for show. The plan is to have it count down the time you have to complete the level - unlimitted lives, limitted time. Note: the difficulty switches affects both the speed of the timer and the speed of the Players (player 1) and the Leprechauns (player 2).

3. There is no end-of-level detection. A level will be complete when all of the gold is picked up (either by the player or Leprechauns).

 

Please note: there are differences between Leprechaun and Lode Runner. In particular:

1. The size of the screen - Leprechaun is bigger.

2. Leprechauns never drop gold they pick up. (Although it's not neccessary for the player to pick up all of the gold.)

3. Leprechauns will fall through holes, same as the player. But if trapped in a hole, they won't climb out either.

4. The player cannot stand on a Leprechaun's head.

5. No trap doors or escape ladders. WYSIWYG

  • Like 1
Link to comment
Share on other sites

Hey Eric, I have a question:

 

I spent a ton of time designing Lep levels with the last level editor; it was a blast - but through testing I learned that the enemy AI is *extremely* important in level design. So, how far along is the enemy AI? Will it be improved much, or is it what it is?

 

As an example, check out this level: leplevelswitchbacks.bin

post-6060-1157042483_thumb.png

Pretty simple; not too tricky, though it should keep you on your toes, perhaps: the idea is that you have to be quick, since enemies dropped in holes are now just a few steps behind you, so you can't slow down too much. Not the greatest idea ever, but I thought that it might be halfway decent. Except the enemies are so darn dumb! It doesn't work at all, the enemies don't even chase you, more like they follow a set pattern. So anyway - I had to discard that level idea, no big loss, really - but if the enemy AI *is* going to be changed at all (improved, I hope!) that could make levels that are designed now obsolete.

Edited by vdub_bobby
Link to comment
Share on other sites

Re: Leprechaun enemy AI

 

The AI is fairly simple. Each enemy has two modes - hunt and chase. In chase mode the enemy points it's virtual joystick in the direction of the player and follows that. In chase mode it sets it's virtual joystick in a direction until it can't move and then changes the virtual joystick direction. Hunt mode becomes chase when the enemy can't move, chase mode becomes hunt when the virtual joystick is in the right direction or the enemy falls or is reborn.

 

Note: unlike Lode Runner, there is no such thing as "Mind Control" on ladders.

 

One item I want to fix is enemy-enemy collisions. Right now it's possible to have two enemies merge.

 

I'd like to discourage people creating levels which depend on the enemy AI. (Which was common in Lode Runner.) And don't forget the difficulty levels change the relative speeds (with both set to hard, the enemies move the same speed as the player).

Link to comment
Share on other sites

I'd like to discourage people creating levels which depend on the enemy AI.

I don't think it's possible to create a level which doesn't depend on enemy AI except for extremely trivial levels.

 

Almost every level I created - I created about 20 - had to be revised more or less significantly based on how the enemies reacted to different things, and I wasn't trying to make levels that depending especially on the enemy AI, my thought process was more like,

"I'll make a level with trees"

leplevelpalms.bin

post-6060-1157054072_thumb.png

leplevelbigtree.bin

post-6060-1157054093_thumb.png

or, "I'll make a big canyon"

leplevelchasm.bin

post-6060-1157054182_thumb.png

or, "I'll make a maze"

leplevelmaze.bin

post-6060-1157054157_thumb.png

Link to comment
Share on other sites

4. The player cannot stand on a Leprechaun's head.

 

This one I find annoying. I appreciate that Leprechaun is not Lode Runner, but I thought Lode Runner had a good formula where if ONE enemy was coming after you, you could easily sink him and run across, but if THREE were coming after you, you were in trouble. Here, if there's no path to outrun the emenies you'd doomed even if just one is coming after you.

Link to comment
Share on other sites

  • 2 weeks later...

I've updated the Leprechaun Level Editor with the latest WIP. Load & save to update any levels you have created.

 

There have been signficant changes to the enemy AI. It's now based more on the enemy continuing it's previous action & direction than the previous (broken) hunt/chase logic. I won't say this is the final version, the current AI climbs ladders to the top or bottom rather than getting off in the middle to chase the player.

 

I've also fixed the bug which trashed the screen when the player died, and another which could corrupt the screen if holes existed when the level was reset.

 

I also fixed the difficulty level switches. Both set to B is the easiest with the player moving much faster than the enemies. When both are set to A then player & enemy move at the same speed, but the timer counts down slower.

Edited by EricBall
Link to comment
Share on other sites

  • 2 weeks later...

Wow! This looks amazingly fun! Is there a plan to put this on a cartridge with a pile of levels?

Currently, there are no compatible bankswitching cartridges, although it might be possible to create something based on supercat's 4A50 (mainly due to it's magic write capabilities) or mos6507's Chimera. But my current focus is on the SuperCharger version.

Link to comment
Share on other sites

Wow! This looks amazingly fun! Is there a plan to put this on a cartridge with a pile of levels?

Currently, there are no compatible bankswitching cartridges, although it might be possible to create something based on supercat's 4A50 (mainly due to it's magic write capabilities) or mos6507's Chimera. But my current focus is on the SuperCharger version.

 

Chimera is a compatible bankswitch cartridge. I've been successfully running multiload games like Survival Island on it this weekend. While it has special features, at its core it's still a Supercharger. There is nothing wrong with releasing a game on Chimera that conforms to the Supercharger's limitations. It doesn't really change the economics one way or the other. We've actually been developing the cart specifically for titles such as Leprechaun and Prince of Persia. If you'd like to see the game come out in a labelled cart where the loading is instantaneous, we can do that for you. If you intend to just release the BINs, then those without Superchargers will be able to pick up blank Chimeras instead of having to track down used Superchargers or Cuttle Carts.

 

We should be ready to offer Chimeras around the same time you are done with your game.

Edited by mos6507
Link to comment
Share on other sites

Chimera is a compatible bankswitch cartridge. I've been successfully running multiload games like Survival Island on it this weekend. While it has special features, at its core it's still a Supercharger.

Yeah, I knew your original plans were for Chimera to be SC compatible. I just didn't know how far you had strayed down the DPC path.

 

There is nothing wrong with releasing a game on Chimera that conforms to the Supercharger's limitations. It doesn't really change the economics one way or the other. We've actually been developing the cart specifically for titles such as Leprechaun and Prince of Persia. If you'd like to see the game come out in a labelled cart where the loading is instantaneous, we can do that for you. If you intend to just release the BINs, then those without Superchargers will be able to pick up blank Chimeras instead of having to track down used Superchargers or Cuttle Carts. We should be ready to offer Chimeras around the same time you are done with your game.

Done is a subjective term :roll: (Although I'd like to think I've learned from my Skeleton/Skeleton+ experience.) The question will be how many loads you will be able to store on the cart. (In SC format each level is 5 pages + header info; 3 pages in 4A50 with space to store at least 85 levels.)

 

But, although people have shown interest in Leprechaun on a cart, my current focus is on the SC version. There are also no deadlines or release targets. (Though I'm hoping to get it out before Duke Nukem Forever :D ) I'll also be leaning heavily on the community to create levels for the project. (Which brings in all kinds of issues regarding permission & recognition for anything other than a free release.)

Link to comment
Share on other sites

I'll also be leaning heavily on the community to create levels for the project. (Which brings in all kinds of issues regarding permission & recognition for anything other than a free release.)

I don't think that should be a problem. Have a level contest like what was done for Combat Redux
Link to comment
Share on other sites

Yeah, I knew your original plans were for Chimera to be SC compatible. I just didn't know how far you had strayed down the DPC path.

 

We're not really changing the way things are done that much. Just adding things. The final Chimera-native cart spec should feel like a natural evolution of the Supercharger. A programmer familiar with the Supercharger should be able to ease into Chimera coding without having to learn a whole new way of doing things. The cart should be able to configure itself automatically depending on the game type. When running Supercharger games, it will behave like a stock supercharger with the exception of game loads being done via flash (like CC2) or serial, but not audio. It's just important to know that even though a Chimera board may seem like overkill to host a Supercharger game, we've not been able to come up with a theoretical cart that scales down to only doing the Supercharger part that is significantly cheaper. So Chimera should be as economical a solution as anyone is likely to come up with for even single load Supercharger homebrews.

 

As for capacity, we should be able to offer a 2MB flash chip for homebrews without inflating the cost that much. Since Lode Runner on the XEGS was something like 128K, I'm thinking Leprechaun should have no trouble fitting even with 255 loads on board.

Edited by mos6507
Link to comment
Share on other sites

It's just important to know that even though a Chimera board may seem like overkill to host a Supercharger game, we've not been able to come up with a theoretical cart that scales down to only doing the Supercharger part that is significantly cheaper. So Chimera should be as economical a solution as anyone is likely to come up with for even single load Supercharger homebrews.

 

The 4A50 board could run SuperCharger games if the XC9536XL were replaced with an XC9572XL; the problem with the 36 is that it doesn't have quite enough registers to count five address changes (it would have no trouble counting five cycles, but a real SuperCharger won't count a cycle to the same address as the previous one). The 4A50 board offers a lot more power than the SuperCharger, and is simpler than the Chimera. Now I just need to get some software written for the thing. :)

Link to comment
Share on other sites

Supporting the Supercharger RAM banking and memory writes is all well and good, but I doubt your board would stay simpler (or cheaper) than Chimera after adding in all the extra components necessary to make it host reprogrammable multiload games. Maybe it would work for a fixed single-load game in EPROM, but then you have a cart that can't be used to run all the existing Supercharger games or 2K or 4K BINs.

Edited by mos6507
Link to comment
Share on other sites

I just wanted to throw in my two cent about the complexity of the Chimera cart. Although, the physical design, the inclusion of the ARM and its software, the shared 128K SRAM, the CPLD and its reconfigurable nature, and all the rest of the carts features, are all extremely complex, the interface that a VCS programmer would use to manipulate all these 'extras' is being designed to be simple.

 

Using serial ports as an example. The vcs software would write a couple configuration bytes to a hotspot to setup the port (port number, speed, handshaking, etc.). After that its a simple matter of reading a status hotspot to see if you are ok to transmit or there are bytes to receive. One hotspot is the transmit, one is the receive, I cant imagine it being any easier.

 

Same thing for queues. There is a seek hotspot and there is a read/write hotspot. Its that easy. Set the location with seek and then stream data into the queue. Later seek to a location and stream the data out. This is as easy as it gets. No pointers to move and track. Just write it then read it.

 

For the SD file system, it will be a little more complex by the nature of the file system, but hardly difficult. You would open a file for reading. Seek to a location, read bytes out. All through a couple hotspots. Close the file and open another file for writing maybe, stream data into it, close the file when your done. The same steps you would take if you were programming for your PC.

 

An understanding of the low level functioning of the Chimera is not required to take advantage of the carts features. The VCS programmer is shielded from the inner working of the cart.

 

The point of the cartridge is, I believe, is two fold. One is to make programming for the VCS easier and faster. The second is to give the VCS the ability to expand outside of itself, something that it hasnt really been able to do. We are offering a 'generic' expansion bus of sorts. New types of once impossible tasks will become possible. Internet play, disk access, serial ports, new types of contollers, and whatever else can be squeezed through the serial, spi, I2C, or I/O ports available on the expansion header.

 

Costs are low and the designs and code will be free, by far the best part of the whole package, in my opinion.

 

Vern

Edited by Delicon
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...