Introduction:
Hello Keeners,
For my next keen project I am planning to do a minimalist keen1 mod. a very short and basic level pack with some small graphical changes. But I am also planning to experiment a bit with patching. Now my plan is while I am doing this to also write a tutorial for keen 1-3 modding. Now don't get me wrong, a lot of things have been documented fairly well already. But I still think some things might be overwhelming for beginners and I may be able to give some tips that aren't documented yet. I will probably also skip some stuff and simply refer to existing tutorials instead. For those who already know how to mod this might not be that interesting (at least initially). And I know there might not actually be that many new people discovering keen. I guess I am doing this for potential newcomers but also to practice my writing skills I guess. Or to document these things for my own use later. But hopefully when I get to the part where I will show examples of applying the existing patches and presenting them in a levelpack/mod this will interest some people that also enjoy keen modding and we can exchange ideas. I also plan to share different versions of my project as I am editing it. That way someone can see from the beginning what everything does and what was added for what and so on.
Chapter 1. extracting the graphics and level editing
Level editor: Mindbelt
The basis in keen modding is level editing. So if you are planning to make a keen mod it makes sense to first make a few levels. The level editor I recommend using is Mindbelt by CK Guy. Now I know there have been a few other level editors. I can't say for sure if they are or aren't better than Mindbelt but Mindbelt can do pretty much everything you would want for modding keen 1-3 so I think it is a good place to start.
The only noteworthy flaw if you can call it that is that you need to extract the keen graphics in order to use it. Of course if you are planning to mod the graphics you need to do this anyway, so it is not really a downside. However it means you have to do this before you can level edit. This is not very difficult but it can be slightly intimidating if you haven't done it before.
Graphics editor: Modkeen
So the first thing we'll do is use Modkeen to extract the graphics from keen1. First you need to acquire a copy of keen1. Obviously you will want to keep a backup of this before you start to edit it. Since you need Dosbox to run keen you probably want to put it in a directory that is easily accessible. For example make a folder c:\games\keen and put a copy of keen1 and rename it to keen1mod or something of your choosing. The only reason it matters where you put it is because you will have to type the directory every time you run Dosbox.
Take a look at the files in your copy of keen 1. If your version includes any files except keen1.exe that don't have the .ck1 extension feel free to delete them because you don't need them. And you will probably be adding extra files in this same folder as you continue modding so get rid of any junk files that may distract you.
Now acquire Modkeen from the keen wiki. Put modkeen.exe together with the rest of the game files. Now to run Modkeen to extract the graphics. The Modkeen help file and the tutorial on the keen wiki instruct you to use command prompt.
However if you are running a 64 bit version of windows it will not run. The solution is to run Modkeen through Dosbox just like how you run the game itself. There is also another reason to do it this way.
Open Dosbox and type: mount c c:\games\keen\keen1mod. Then run Modkeen (since we put modkeen.exe in the same map with the rest of the game).
Okay but we are not ready yet. to run Modkeen we need to type in a few commands to specify what we want. In fact if we only run modkeen.exe directly the program will specify that we need to give additional commands.
Now before we go on I should note that even after we have figured out everything we need to type. It is slightly inconvenient to type these specifications every time we need to run Modkeen. Now we only need to export the graphics one time in theory but even so there is an easier way to do this and also importing the graphics after you have edited them, that you may want to repeat many times during a project. and importing works very similar. And there is another reason you might want to automate the export command also.
The command we would have to type to export the graphics is:
modkeen -export -episode=1 -bmpdir="GRAPHICS"
There are three variables here. first typing -export specifies that we want to export the graphics rather than import. -episode=1 specifies that we are looking for keen 1 files. and -bmpdir="GRAPHICS" specifies in what folder we want the graphics files that we exported to be copied to.
Now in order to avoid having to type this whole string of text every time we have to use Modkeen I think it can be very beneficial to create a .bat file. Later if you want to use patching for your mod you will also have to make a .bat file to run keen. So why not make a .bat file to run Modkeen?
Open a notepad and copy on the first line the command we would otherwise have to type:
modkeen -export -episode=1 -bmpdir="GRAPHICS"
Then use save file as and save it as export1.bat. Take note that you have to specify the "save as type" option as "all files". Otherwise windows will ignore that you intended it to be saved as a .bat type file and will make it export1.bat.txt (a text file).
make sure that you put your .bat file with the rest of your keen files
Now go back to Dosbox and go to your game. You can now run the .bat file by typing its name "export1" and it will run by running Modkeen in turn with the specified commands
CWSDPMI.exe
Now running Modkeen with these commands (with a .bat or manually) Modkeen will tell us that we need the file CWSDPMI.exe to run Modkeen. So that is what we must do. Download this on the keen wiki or somewhere else and put it together with the rest of the game files.
Now there is one more error that can occur. Modkeen will not be able to open the GRAPHICS folder if it doesn't exist yet. so before you run Modkeen make an (empty) folder within the folder of the game. (I think you can also put a command in your .bat file to create the folder on your current directory but I don't know how)
( c:\games\keen\keen1mod\GRAPHICS)
Now if you have done these things and you run the "export1.bat" Modkeen should export all the game's graphics. This means you can now use the level editor Mindbelt and edit levels since it needs these files to function.
But first I should also explain that you can use Modkeen the same way to import the graphics again after you edited them. It goes much the same way. But we should now make a second .bat file for importing the graphics.
Now open the .bat file you already made export.bat in Notepad. Note that you can't just double click a .bat file in windows to open it because then windows will attempt to run it. So open Notepad some other way and choose "open" in the options. You have to specify that you are looking for any file type (and not just txt) or you will only be able to see .txt files. open export.bat. Alternatively if you right click a .bat and click edit this should also open it.
Now change:
modkeen -export -episode=1 -bmpdir="GRAPHICS"
to
modkeen -import -episode=1 -bmpdir="GRAPHICS"
And save it as import1.bat (remember to specify file type to all files)
Now the reason I suggest naming it export1 and import1 is because you may want to use these same bat files to use on keen 2 and 3. Just change the episode number. You may want to be able to distinguish for what episode your .bat files work if you make multiple versions for different episodes.
Now that you know how to export the graphics of keen1. Note that you can use the exact same method to export the graphics of any (keen1) mod. copy to any keen1 mod folder:
the export1.bat file
modkeen.exe
CWSDPMI
an (empty) "GRAPHICS" folder
and run export1 in dosbox. You can then borrow graphics from other mods if you don't want to make your own or simply look at how they have done certain things. Or even use the graphics to make a levelpack specifically for that mod.
The first version of this project will have all the things described as in this chapter. That means there are no modifications yet but a folder with the graphics is included and a means to import and export the graphics with a .bat file
mod001
I'm working on a new keen 1-3 modding tutorial
I'm working on a new keen 1-3 modding tutorial
Last edited by Vortlike on Fri Apr 25, 2025 12:08, edited 2 times in total.
Re: Planning to write a new keen 1-3 modding tutorial
Great idea! I started work on something like this more than 20 years ago but didn't finish it. Story of my life!
What format is this going to take? Will you host your own website? Downloadable pdf? Podcast?
Intrigued to see what form the minimalist mod takes, too.
What format is this going to take? Will you host your own website? Downloadable pdf? Podcast?
Intrigued to see what form the minimalist mod takes, too.
So important. In this era where the spectre of AI threatens us all, you have to strive for nonferiority, and then hope that your humanness delivers an edge of superiority where it really matters.practice my writing skills
Re: Planning to write a new keen 1-3 modding tutorial
Sometimes it is also better to just abandon a project if you aren't feeling it anymore. I also have done that before.Great idea! I started work on something like this more than 20 years ago but didn't finish it. Story of my life!
Not really. I will just post it here on the forum and link my project with a dropbox link. If other people do find it valuable it may be nice if it gets uploaded to the keen wiki. But maybe before that maybe some things can be improved first.What format is this going to take? Will you host your own website? Downloadable pdf? Podcast?
Depending on how far I get I will probably show off some patches. For example will make the yorp kill and show that you can swap some of these properties at will. Then I will probably reverse that and make them push again but change a few other things like speed. Level will probably be based on the original and to demonstrate the new possible gameplay. Either way they will likely be relatively short and straightforward.Intrigued to see what form the minimalist mod takes, too.
Not sure about that. I'm not that convinced that AI is that close to actually being intelligent. It may be important by the way that there are enough keen modding articles on the web if we want chatgpt to be able to explain how to make a mod.So important. In this era where the spectre of AI threatens us all, you have to strive for nonferiority, and then hope that your humanness delivers an edge of superiority where it really matters.
Re: Planning to write a new keen 1-3 modding tutorial
Chapter 2: Changing graphics and levels
Now that we have set up Modkeen to import and export graphics as needed we are now ready to actually change the levels and graphics.
Level editing
First we are going to start with opening level01.ck1 in mindbelt. Once you have clicked to open it mindbelt will probably ask to use "C:\games\keen\keen1mod\graphics\1TIL0000.bmp" for graphics? You can say yes but keep in mind if you are working with different projects sometimes Mindbelt will wrongly "guess". In that case you will have to manually select the correct 1TIL0000.bmp file.
1TIL0000.bmp is the bitmap that has all of the keen tiles. the blocks that levels are made off. However Mindbelt also uses the graphics for the sprites, that is the yorps gargs and so on from their respective files in the GRAPHICS map. Now the fact that mindbelt works this way is pretty useful once you start to edit the graphics. As you can already see/use the new graphics in the level editor.
Mindbelt works quite intuitively and has its own help file. The way that keen levels work is that there are basically 2 layers. Tiles and sprites. There can only be one tile on one space or one sprite spawn in one place and sprites are placed on top of the tiles.
You can zoom in and out with the + and - button. You can use the left mouse button to draw things. But you are either in tiles placement mode or sprite placement mode. To toggle to drawing tiles if you aren't already you can press the "T" button. Now you see the entire tileset. here you can also click on the tile you want to use. When you press T again you will exit the tileset mode and can draw tiles in the level by clicking the mouse. Or you can right click a tile that is already placed to make that the tile you want to draw with. If you want to switch to placing sprites press "S" choose a sprites number 1-10, 255 or any custom number. You now switched to that sprite but also to sprite mode. You can now also right click existing sprites in the level to make that the sprite you are now drawing. Sprite "0" is interpreted as "no sprite". When you are in sprite mode you can right click a tile with no sprite. You can now "draw" with an eraser to remove unwanted sprites.
There are more things that may be worth learning but it is probably best found out by trying it out or it will be mentioned later but under the tools tap there are a few useful things you can use.
For this project I am going to edit the first level a little bit. I am gonna put a vorticon right in the beginning and some ammo. I make most of the level inaccessible since there isn't any new content anyway and I am going to put the exit much further to the beginning. This is all just to demonstrate we have a slightly new level. Now you could build the exit door tile by tile exactly as it is now. But instead I am going to use the copy past function of mindbelt. To use it press c once. now click where you want it and drag a square area that you want to select and click again. You now have that part of the level stored in memory. Now press "P" and you will see that part of the level appear. click to place it. This can be quite useful, in this case I use it to move the door closer to the beginning of the level. Just to be sure I also block the player from getting access to the later part of the level. I wouldn't want someone to play this and think that there is new content there when it is just the old keen 1 level would I? So out of respect for the people that may test this I might as well seal it off. in fact, it may be a good idea now to open the map level. click file, open, and open level80.ck1. Should someone play the first level and finish it they may go and explore the rest of the mod and look for new content only to be disappointed that I didn't change anything else. Perhaps it is better to avoid this for for now I will just block the way after level 1. This means the game is incompletable for now, but that is fine. Note that you can have multiple levels open in Mindbelt at the same time. You can the toggle between them in the levels tap. You can even use the copy paste method between different levels.
Modifying the graphics
When you know how to import and export using Modkeen, changing the graphics is pretty straightforward. You can edit the graphics in a drawing program and save them again in the same format (16 color bit). Then run the import .bat file.
There is one problem though. Don't use paint of the latests windows versions. It will mess up the colors. I dunno why it was considered acceptable to have this happen. Probably because 16 color bit isn't used that much anymore. Either way you have to find another program to edit the graphics. I personally recommend downloading the old windows xp version. It works just as well in windows 10 and it is just a small 1 file program that you don't need to install to work. On the keen wiki it is mentioned "Some modders use programs such as GIMP or PhotoShop.". I am sure there are many options. Just stay clear of the latest versions of ms paint.
Now for this project I have designed some blocks. Really they are recolored blocks from keen 1, but still. I also made a "dark" version of them that is meant to be a background version of them very much like is also used in keen 3.
I want this block and background tile in my keen mod. So I need to replace one of the existing tiles for each of these. To have my new blocking tile I am going to replace one of the existing pink blocks. If you open Mindbelt and you select a tile it actually tells you the tile number. So to be specific I am going to replace the pink tile 272 with my new blocking tiles. I know from my experience playing keen that this tile is blocking so it will work. This will change the appearance of all the levels that have used this tile so I have to keep that in mind in case I want to use the original levels in the future I may have to change them also or accept that they now look like this.
For my background tile I will use tile 220.
Make sure you know how to zoom in enough in your graphics editor program to make the changes you want pixel perfectly. You may have to go into the custom settings or even go so far as changing your screen's resolution. I can currently handle it in my old version of ms paint if I zoom in to 800%.
I will now edit 1TIL0000. Then run the import .bat file
Now I will go to mindbelt again and change my level a bit more. I am gonna remove some more of the original level and build a little keen 3 style house.
Level 1 already used the pink blocks that I changed. You can't access that part of the level anymore but if you look in Mindbelt you can already see it's different.
This part of the tutorial will conclude a version of the game that has the changes as described here building on the previous version.
mod002
Now that we have set up Modkeen to import and export graphics as needed we are now ready to actually change the levels and graphics.
Level editing
First we are going to start with opening level01.ck1 in mindbelt. Once you have clicked to open it mindbelt will probably ask to use "C:\games\keen\keen1mod\graphics\1TIL0000.bmp" for graphics? You can say yes but keep in mind if you are working with different projects sometimes Mindbelt will wrongly "guess". In that case you will have to manually select the correct 1TIL0000.bmp file.
1TIL0000.bmp is the bitmap that has all of the keen tiles. the blocks that levels are made off. However Mindbelt also uses the graphics for the sprites, that is the yorps gargs and so on from their respective files in the GRAPHICS map. Now the fact that mindbelt works this way is pretty useful once you start to edit the graphics. As you can already see/use the new graphics in the level editor.
Mindbelt works quite intuitively and has its own help file. The way that keen levels work is that there are basically 2 layers. Tiles and sprites. There can only be one tile on one space or one sprite spawn in one place and sprites are placed on top of the tiles.
You can zoom in and out with the + and - button. You can use the left mouse button to draw things. But you are either in tiles placement mode or sprite placement mode. To toggle to drawing tiles if you aren't already you can press the "T" button. Now you see the entire tileset. here you can also click on the tile you want to use. When you press T again you will exit the tileset mode and can draw tiles in the level by clicking the mouse. Or you can right click a tile that is already placed to make that the tile you want to draw with. If you want to switch to placing sprites press "S" choose a sprites number 1-10, 255 or any custom number. You now switched to that sprite but also to sprite mode. You can now also right click existing sprites in the level to make that the sprite you are now drawing. Sprite "0" is interpreted as "no sprite". When you are in sprite mode you can right click a tile with no sprite. You can now "draw" with an eraser to remove unwanted sprites.
There are more things that may be worth learning but it is probably best found out by trying it out or it will be mentioned later but under the tools tap there are a few useful things you can use.
For this project I am going to edit the first level a little bit. I am gonna put a vorticon right in the beginning and some ammo. I make most of the level inaccessible since there isn't any new content anyway and I am going to put the exit much further to the beginning. This is all just to demonstrate we have a slightly new level. Now you could build the exit door tile by tile exactly as it is now. But instead I am going to use the copy past function of mindbelt. To use it press c once. now click where you want it and drag a square area that you want to select and click again. You now have that part of the level stored in memory. Now press "P" and you will see that part of the level appear. click to place it. This can be quite useful, in this case I use it to move the door closer to the beginning of the level. Just to be sure I also block the player from getting access to the later part of the level. I wouldn't want someone to play this and think that there is new content there when it is just the old keen 1 level would I? So out of respect for the people that may test this I might as well seal it off. in fact, it may be a good idea now to open the map level. click file, open, and open level80.ck1. Should someone play the first level and finish it they may go and explore the rest of the mod and look for new content only to be disappointed that I didn't change anything else. Perhaps it is better to avoid this for for now I will just block the way after level 1. This means the game is incompletable for now, but that is fine. Note that you can have multiple levels open in Mindbelt at the same time. You can the toggle between them in the levels tap. You can even use the copy paste method between different levels.
Modifying the graphics
When you know how to import and export using Modkeen, changing the graphics is pretty straightforward. You can edit the graphics in a drawing program and save them again in the same format (16 color bit). Then run the import .bat file.
There is one problem though. Don't use paint of the latests windows versions. It will mess up the colors. I dunno why it was considered acceptable to have this happen. Probably because 16 color bit isn't used that much anymore. Either way you have to find another program to edit the graphics. I personally recommend downloading the old windows xp version. It works just as well in windows 10 and it is just a small 1 file program that you don't need to install to work. On the keen wiki it is mentioned "Some modders use programs such as GIMP or PhotoShop.". I am sure there are many options. Just stay clear of the latest versions of ms paint.
Now for this project I have designed some blocks. Really they are recolored blocks from keen 1, but still. I also made a "dark" version of them that is meant to be a background version of them very much like is also used in keen 3.
I want this block and background tile in my keen mod. So I need to replace one of the existing tiles for each of these. To have my new blocking tile I am going to replace one of the existing pink blocks. If you open Mindbelt and you select a tile it actually tells you the tile number. So to be specific I am going to replace the pink tile 272 with my new blocking tiles. I know from my experience playing keen that this tile is blocking so it will work. This will change the appearance of all the levels that have used this tile so I have to keep that in mind in case I want to use the original levels in the future I may have to change them also or accept that they now look like this.
For my background tile I will use tile 220.
Make sure you know how to zoom in enough in your graphics editor program to make the changes you want pixel perfectly. You may have to go into the custom settings or even go so far as changing your screen's resolution. I can currently handle it in my old version of ms paint if I zoom in to 800%.
I will now edit 1TIL0000. Then run the import .bat file
Now I will go to mindbelt again and change my level a bit more. I am gonna remove some more of the original level and build a little keen 3 style house.
Level 1 already used the pink blocks that I changed. You can't access that part of the level anymore but if you look in Mindbelt you can already see it's different.
This part of the tutorial will conclude a version of the game that has the changes as described here building on the previous version.
mod002
Re: Planning to write a new keen 1-3 modding tutorial
Chapter 3: Patching with CKpatch and using tileinfo
We now already know how to change a lot of the game. We can build completely new levels. With the existing graphics or change it to entirely your own. Note that all these changes we can achieve without any patching. We didn't actually patch the game itself yet. We only modified the games files. The file level01.ck1 is modified. and modkeen modifies the graphics files I think these are EGAHEAD.ck1 EGALATCH.ck1 and EGASPRIT.ck1. I guess these are external files and in a way sort of separate from the actual application keen.exe. That is why up to this point we could run keen1.exe to run our mod. without relying on what you see in most mods where you have to run a .bat file to launch it.
But to make more changes we may want to change how keen1.exe works. To do this we need a program called CKPatch.
Once you have CKPatch set up to work with your mod you should be able to use any of the patches that have been posted on the keen forums or the keen wiki. As well as using patches that you may find by looking at the patch files of other existing mods.
However first we are going to set up a program called tileinfo. This program allows you to change the properties of tiles. Which tiles block, kill keen or are pickups and so on.
tileinfo requires CKPatch to work. But regardless of if you were going to use CKPatch anyway it may be a good thing to start with tileinfo. And for most mod projects you are probably going to want to use tileinfo although as in the example shows before you could make due with just recoloring the existing tiles. Using Tileinfo will give you much more flexibility. Tileinfo will also automatically generate a patch file that you can then use and expand upon.
UNLZEXE
In order to use tileinfo you also need to use a program called UNLZEXE. So download it from the keen wiki. In order to run UNLZEXE you need to drag the keen1.exe file with your mouse on top of UNLZEXE. The program will then generate for you a new version of keen1.exe called KEEN1.EXENEW and places it in the same folder. You now need to delete the original keen1.exe (you have a backup anyway right) and manually rename your new file to keen1.exe that you will use from now on. Now you are done with this part.
Note: keen2 and keen3 mods are distributed without the keen2.exe/keen3.exe. meaning you have to provide them yourself. Often mods will not run unless you provide your own keenexe that must also be unlzexe-ed for the mod to work. So knowing how to use UNLZEXE is also useful for being able to play mods as well as for modding keen yourself.
Note: should dragging the keen1.exe on unlzexe not work for some reason an alternative way is to do it in command prompt. (dosbox will not work in this case)
Rephrasing from a previous tutorial: If you are using the 32 bit version of UNLZEXE, open command prompt. Go to that folder and enter UNLZEXE KEEN1.EXE to unpack it.
CKPATCH
Also go ahead and download CKPatch from the keen wiki. There is actually a separate CKPatch for each episode. For this project we only need CK1PATCH.EXE. So copy it into your mod folder.
TILEINFO
Now that we have unlzexe-ed our keen1.exe and have CKPATCH ready we can create our patch files. The easiest way is to let Tileinfo generate it automatically for us. So let's run tileinfo. First we need to load the graphics just like with Mindbelt so click Load Tiles. find and select 1TIL0000.BMP. Now you can see all the tiles and can select them and we can see the option for properties that they can have. However what we want to do is import all the default tile properties from the original game before we start editing them. To do this click the import button. go to the map with your keen1.exe and select it. Note that if you didn't unlzexe your keen1.exe that this would not work and tileinfo will actually give you an error.
What you can notice now is that if you click on the tiles now you can see the properties of the tiles they are supposed to have. Take a look through all the available options under general behavior.
Previously I already changed 2 tiles with Modkeen. But I want to do something a little bit more crazy this time. But also I am reluctant to change too much of the existing tileset because I might still want to use some of the original levels (with some changes) for the player to, um roam. If I change too many of the existing graphics it will be too hard and too much work to adapt all the levels to my new tileset.
So the change I am going to make this time will be to a tile that I think has been unused currently. If we look at tile 498 we see it is the first of several black tiles. probably not in use. Even Though I haven't changed the graphic for this tile yet. I am going to go ahead and change the property to 100 points. You can also see in which direction the tile is blocking. The top says nothing and the sides are "unpressed" meaning it does not block at all.
Now that we made our change, we want to somehow save this new tileset so that we can use it. We save it into our mod folder. Tileinfo specifies that it will generate a .tli file. This will be useful to remember later. Anyway for now we will call the file TILES. TILES.tli
Now if we want to come back to this at a later time all we have to do is open Tileinfo and select 1TIL0000.BMP again and then this time click the open button and open TILES.tli. Then you can continue where you left off.
Take a look at your mod's files. tielinfo has generated not only TILES.tli but also TILES.pat.
The .pat file is what will contain most of your patching content. You need it to use the new tileset properties.
You also need a .pat file for any future patches you might add. You should open it in notepad and see that it has the correct format.
#Tile info patching script for Keen 1
%ext ck1
%version 1.1
%patchfile 0x131F8 TILES.tli
%version 1.31
%patchfile 0x130F8 TILES.tli
%end
Any line that starts with a "#" is ignored by the program. Useful for note taking.
Apparently tileinfo made 2 patches for different versions of keen. Since I know I am using 1.31 I could delete the part with version 1.1. However I might as well not bother.
Any patches that you will want to use must be put between %ext ck1 and %end
This includes the patch tileinfo generated for us. it refers to the Tiles/tli file that we just saved. If you open it in Notepad you will see it contains a bunch of computer language (or something). The new tile properties are saved there ofcourse.
RUNNING CKPATCH
It is now time to run keen1 through CKPatch and use these files to get our new tileset.
Before I do this I will also edit the graphics of my new tile (a 100 points tile). Import the new graphics and place a few copies of this new tile into the first level.
open a notepad and type on the first line:
ck1patch TILES.pat
Now save as "play.bat"
If we now run this bat file it will essentially run CKPatch that will then run keen1.exe and then before running it properly do all the changes to it that we specified in the .pat file.
After running play.bat keen1 launched as normal. I entered the first level to see my new item that I put on tile 498. I picked it up to see that it really has the new property of being a 100 point tile. It does, I do get one small side effect though. Instead of the normal light grey tile that appears when you pick up an item another tile appears. I recognize the tile as tile number 276. It is part of the sign in the "holy pogo stick" level. Incidentally in keen 2 tile 276 is the dark teal background tile. Apparently keen 1 has 2 backgrounds by default just like keen 2 (though you need tileinfo to ever see it)
We can discuss a patch that exists for the backgrounds later. For now I will just "brute force" a solution by painting tile 276 light grey too. We don't need the sign for the pogo stick anymore for this mod.
After these changes it works as I want it. We now have 2 different 100 points tiles. Not possible without tileinfo. But ofcourse you can now change anything into everything. Do note that some tiles are special. A good example are the "Done" signs. These tiles you probably don't want to change except into your own version of them.
If you now run keen1.exe the mod will still run fine but without the patch. The player might not notice his mistake right away until he tries to pick up the chocolate and finds out it is just a normal background.
I want to make absolutely certain that players play the correct version. So I am going to make it impossible to proceed without using the patch. Why do this effort you may ask? Well partly just because we can.
Tile 51 is blocking by default. I'm going to turn that in a "ground" tile for the map.
Tile 336 is killing by default. I'm going to turn that into a background tile.
Now I will change the graphics with Modkeen. the tile properties in tileinfo to make them non-blocking and non-killing.
Surround keens starting position with the "blocking" tile in level 80
Surround keens starting position with the "killing" tile in level 01
If the player now runs keen1 instead of play he won't come far, haha. First you will be blocked on the map. Then if you use godmode to go to level 1 you will die instantly. The player now has no choice but to use play.bat. And if he picked the wrong one at least he should notice something is wrong right away.
PATCHING
Now that we have made a patch with tileinfo that works. Note that we can now use any patch and add it to our patch file. Depending on what kind of patch it can be literally as simple as copy pasting the patch someone else already made. For now I am going to add one more patch. On the keen wiki I found a patch for infinite lives.
https://keenwiki.shikadi.net/wiki/Patch:Lives
#Infinite lives - Don't decrease lives -Keen 1
%patch $8041 $90 $90 $90 $90
I am going to copy this into the .pat file that we have. Paste it below the patch we already have but before %end
In fact as long as it is between %ext ck1 and %end the order of the patches should not matter.
remember the # will be ignored by the program so leaving this description is most useful for later.
Now go ahead and test it. Actually I will add a few danger tiles to the level so the vorticon isn't the only thing that can kill you. To test the new patch that was added.
Now take note: if you want to use tileinfo again, and you probably will. If you save TILES.tli again then tileinfo will also generate a new .pat file again. And override the current .pat file that we put our new patch in!
To solve that it is better to make a copy of the .pat file. rename it to patch.pat.
modify play.bat and change: ck1patch TILES.pat to ck1patch patch.pat
Now next time we save TILES.tli it will make a new .pat file that we can simply ignore for now (and delete, eventually). Our copy of the .pat file will not be overwritten and can still read the new updated .tli file just fine.
This part of the tutorial will conclude a version of the game that has the changes as described here building on the previous version.
mod003
We now already know how to change a lot of the game. We can build completely new levels. With the existing graphics or change it to entirely your own. Note that all these changes we can achieve without any patching. We didn't actually patch the game itself yet. We only modified the games files. The file level01.ck1 is modified. and modkeen modifies the graphics files I think these are EGAHEAD.ck1 EGALATCH.ck1 and EGASPRIT.ck1. I guess these are external files and in a way sort of separate from the actual application keen.exe. That is why up to this point we could run keen1.exe to run our mod. without relying on what you see in most mods where you have to run a .bat file to launch it.
But to make more changes we may want to change how keen1.exe works. To do this we need a program called CKPatch.
Once you have CKPatch set up to work with your mod you should be able to use any of the patches that have been posted on the keen forums or the keen wiki. As well as using patches that you may find by looking at the patch files of other existing mods.
However first we are going to set up a program called tileinfo. This program allows you to change the properties of tiles. Which tiles block, kill keen or are pickups and so on.
tileinfo requires CKPatch to work. But regardless of if you were going to use CKPatch anyway it may be a good thing to start with tileinfo. And for most mod projects you are probably going to want to use tileinfo although as in the example shows before you could make due with just recoloring the existing tiles. Using Tileinfo will give you much more flexibility. Tileinfo will also automatically generate a patch file that you can then use and expand upon.
UNLZEXE
In order to use tileinfo you also need to use a program called UNLZEXE. So download it from the keen wiki. In order to run UNLZEXE you need to drag the keen1.exe file with your mouse on top of UNLZEXE. The program will then generate for you a new version of keen1.exe called KEEN1.EXENEW and places it in the same folder. You now need to delete the original keen1.exe (you have a backup anyway right) and manually rename your new file to keen1.exe that you will use from now on. Now you are done with this part.
Note: keen2 and keen3 mods are distributed without the keen2.exe/keen3.exe. meaning you have to provide them yourself. Often mods will not run unless you provide your own keenexe that must also be unlzexe-ed for the mod to work. So knowing how to use UNLZEXE is also useful for being able to play mods as well as for modding keen yourself.
Note: should dragging the keen1.exe on unlzexe not work for some reason an alternative way is to do it in command prompt. (dosbox will not work in this case)
Rephrasing from a previous tutorial: If you are using the 32 bit version of UNLZEXE, open command prompt. Go to that folder and enter UNLZEXE KEEN1.EXE to unpack it.
CKPATCH
Also go ahead and download CKPatch from the keen wiki. There is actually a separate CKPatch for each episode. For this project we only need CK1PATCH.EXE. So copy it into your mod folder.
TILEINFO
Now that we have unlzexe-ed our keen1.exe and have CKPATCH ready we can create our patch files. The easiest way is to let Tileinfo generate it automatically for us. So let's run tileinfo. First we need to load the graphics just like with Mindbelt so click Load Tiles. find and select 1TIL0000.BMP. Now you can see all the tiles and can select them and we can see the option for properties that they can have. However what we want to do is import all the default tile properties from the original game before we start editing them. To do this click the import button. go to the map with your keen1.exe and select it. Note that if you didn't unlzexe your keen1.exe that this would not work and tileinfo will actually give you an error.
What you can notice now is that if you click on the tiles now you can see the properties of the tiles they are supposed to have. Take a look through all the available options under general behavior.
Previously I already changed 2 tiles with Modkeen. But I want to do something a little bit more crazy this time. But also I am reluctant to change too much of the existing tileset because I might still want to use some of the original levels (with some changes) for the player to, um roam. If I change too many of the existing graphics it will be too hard and too much work to adapt all the levels to my new tileset.
So the change I am going to make this time will be to a tile that I think has been unused currently. If we look at tile 498 we see it is the first of several black tiles. probably not in use. Even Though I haven't changed the graphic for this tile yet. I am going to go ahead and change the property to 100 points. You can also see in which direction the tile is blocking. The top says nothing and the sides are "unpressed" meaning it does not block at all.
Now that we made our change, we want to somehow save this new tileset so that we can use it. We save it into our mod folder. Tileinfo specifies that it will generate a .tli file. This will be useful to remember later. Anyway for now we will call the file TILES. TILES.tli
Now if we want to come back to this at a later time all we have to do is open Tileinfo and select 1TIL0000.BMP again and then this time click the open button and open TILES.tli. Then you can continue where you left off.
Take a look at your mod's files. tielinfo has generated not only TILES.tli but also TILES.pat.
The .pat file is what will contain most of your patching content. You need it to use the new tileset properties.
You also need a .pat file for any future patches you might add. You should open it in notepad and see that it has the correct format.
#Tile info patching script for Keen 1
%ext ck1
%version 1.1
%patchfile 0x131F8 TILES.tli
%version 1.31
%patchfile 0x130F8 TILES.tli
%end
Any line that starts with a "#" is ignored by the program. Useful for note taking.
Apparently tileinfo made 2 patches for different versions of keen. Since I know I am using 1.31 I could delete the part with version 1.1. However I might as well not bother.
Any patches that you will want to use must be put between %ext ck1 and %end
This includes the patch tileinfo generated for us. it refers to the Tiles/tli file that we just saved. If you open it in Notepad you will see it contains a bunch of computer language (or something). The new tile properties are saved there ofcourse.
RUNNING CKPATCH
It is now time to run keen1 through CKPatch and use these files to get our new tileset.
Before I do this I will also edit the graphics of my new tile (a 100 points tile). Import the new graphics and place a few copies of this new tile into the first level.
open a notepad and type on the first line:
ck1patch TILES.pat
Now save as "play.bat"
If we now run this bat file it will essentially run CKPatch that will then run keen1.exe and then before running it properly do all the changes to it that we specified in the .pat file.
After running play.bat keen1 launched as normal. I entered the first level to see my new item that I put on tile 498. I picked it up to see that it really has the new property of being a 100 point tile. It does, I do get one small side effect though. Instead of the normal light grey tile that appears when you pick up an item another tile appears. I recognize the tile as tile number 276. It is part of the sign in the "holy pogo stick" level. Incidentally in keen 2 tile 276 is the dark teal background tile. Apparently keen 1 has 2 backgrounds by default just like keen 2 (though you need tileinfo to ever see it)
We can discuss a patch that exists for the backgrounds later. For now I will just "brute force" a solution by painting tile 276 light grey too. We don't need the sign for the pogo stick anymore for this mod.
After these changes it works as I want it. We now have 2 different 100 points tiles. Not possible without tileinfo. But ofcourse you can now change anything into everything. Do note that some tiles are special. A good example are the "Done" signs. These tiles you probably don't want to change except into your own version of them.
If you now run keen1.exe the mod will still run fine but without the patch. The player might not notice his mistake right away until he tries to pick up the chocolate and finds out it is just a normal background.
I want to make absolutely certain that players play the correct version. So I am going to make it impossible to proceed without using the patch. Why do this effort you may ask? Well partly just because we can.
Tile 51 is blocking by default. I'm going to turn that in a "ground" tile for the map.
Tile 336 is killing by default. I'm going to turn that into a background tile.
Now I will change the graphics with Modkeen. the tile properties in tileinfo to make them non-blocking and non-killing.
Surround keens starting position with the "blocking" tile in level 80
Surround keens starting position with the "killing" tile in level 01
If the player now runs keen1 instead of play he won't come far, haha. First you will be blocked on the map. Then if you use godmode to go to level 1 you will die instantly. The player now has no choice but to use play.bat. And if he picked the wrong one at least he should notice something is wrong right away.
PATCHING
Now that we have made a patch with tileinfo that works. Note that we can now use any patch and add it to our patch file. Depending on what kind of patch it can be literally as simple as copy pasting the patch someone else already made. For now I am going to add one more patch. On the keen wiki I found a patch for infinite lives.
https://keenwiki.shikadi.net/wiki/Patch:Lives
#Infinite lives - Don't decrease lives -Keen 1
%patch $8041 $90 $90 $90 $90
I am going to copy this into the .pat file that we have. Paste it below the patch we already have but before %end
In fact as long as it is between %ext ck1 and %end the order of the patches should not matter.
remember the # will be ignored by the program so leaving this description is most useful for later.
Now go ahead and test it. Actually I will add a few danger tiles to the level so the vorticon isn't the only thing that can kill you. To test the new patch that was added.
Now take note: if you want to use tileinfo again, and you probably will. If you save TILES.tli again then tileinfo will also generate a new .pat file again. And override the current .pat file that we put our new patch in!
To solve that it is better to make a copy of the .pat file. rename it to patch.pat.
modify play.bat and change: ck1patch TILES.pat to ck1patch patch.pat
Now next time we save TILES.tli it will make a new .pat file that we can simply ignore for now (and delete, eventually). Our copy of the .pat file will not be overwritten and can still read the new updated .tli file just fine.
This part of the tutorial will conclude a version of the game that has the changes as described here building on the previous version.
mod003
Re: Planning to write a new keen 1-3 modding tutorial
Chapter 4 Some more patches bridges and more
We have now set up the most important modding tools we would need to create a keen mod. Now that we know how to use CKPatch it has become relatively easy to add any keen patch we want to our mod project. Patches fall more or less in three categories. 1. patches that you can simply copy and paste into your patch file. 2 patches that are still easy to use but to make them work the way you want to you need to modify a number value a certain way. And 3 patches that are slightly more complex and may need some time to figure out what you can do with them and how. I intend to try to modify some of the more complex patches at some point. For now I should mention one more pre-made patch that is ready to use.
multiple background patch
It is the multiple background patch that exists for keen 1 and 2. It makes it so that any pick up is replaced by the first tile of that row. This allows you to have as many different backgrounds as you want. At least more than you probably would ever want.
https://keenwiki.shikadi.net/wiki/Patch:Tiles
We can copy this entire text into our patch:
###Keen 1 background tiles behave like Keen 3:
#Change item tiles to use tiles at the end of each row ($0D) of tiles
%patch $4409 $26 $8B $07 $B6 [$0D] $F6 $FE
%patch $4410 $F6 $EE $26 $89 $07 $E9 $60 $01
#Change keys, items, etc to use point tiles instead
%patch $4482 $E9 $74 $FF #Affect ship parts
%patch $44BA $E9 $3C $FF #Affect raygun, pogo
%patch $4513 $E9 $E3 $FE #Affect keycards
#Change doors
%patch $28EC $26 $8B $07 $B6
%patch $28F0 [$0D] $F6 $FE $F6 $EE $26 $89 $07
%patch $28F8 $03 $1E $08 $6C $03 $1E $08 $6C
%patch $2900 $26 $89 $07 $90 $90 $90 $90 $90
However notice on two places the code is surrounded by brackets [$0D]
This is not actually part of the patch. These need to be removed before the patch will work. CKPatch will give an error in fact. The maker of the patch added the brackets there to place special emphasis on those values. Changing these values changes the way the patch works. Now you may wonder why I call this a value. It's because it is a number. 0D is 13 in Hexadecimal.
Right now we don't actually want to change this value but for other patches we might want to change their variables. If you want to change a value that is written in Hexadecimal you can use a program to translate that into decimal numbers and back.
You could google hex to decimal. When I do it always brings me to this site:
https://www.rapidtables.com/convert/num ... cimal.html
It works very well for me. For now try it and copy 0D and click convert and see how it changes into 13. If we wanted to change the value of 13 for this patch to say 26. click on "swap" to make it translate decimal number to decimal. type or copy 26 and click convert. we see that we would get 1A
But for now for this patch we don’t actually need to change this value. Just recognize that the patch maker placed the brackets there to put in the description that these are values that could be changed. For now leave them the same but remove the brackets at the two locations the patch should now look like this:
###Keen 1 background tiles behave like Keen 3:
#Change item tiles to use tiles at the end of each row ($0D) of tiles
%patch $4409 $26 $8B $07 $B6 $0D $F6 $FE
%patch $4410 $F6 $EE $26 $89 $07 $E9 $60 $01
#Change keys, items, etc to use point tiles instead
%patch $4482 $E9 $74 $FF #Affect ship parts
%patch $44BA $E9 $3C $FF #Affect raygun, pogo
%patch $4513 $E9 $E3 $FE #Affect keycards
#Change doors
%patch $28EC $26 $8B $07 $B6
%patch $28F0 $0D $F6 $FE $F6 $EE $26 $89 $07
%patch $28F8 $03 $1E $08 $6C $03 $1E $08 $6C
%patch $2900 $26 $89 $07 $90 $90 $90 $90 $90
Now that we have enabled this patch. If we run our mod now it will have completely changed how the game determines what kind of background tile spawn when an item is picked up.
We already know how the patch is supposed to work based on the description. But it can nonetheless be fun to see how the patch currently affects the mod. Since the tileset wasn't designed around the idea that the first tile of each row would be the replacement tile. It will likely completely mess up our pick ups. We could also predict this from looking out our tileset and looking at what the first tile of each row is.
If we enter our first level and pick up the raygun we see that a danger tile replaces it and kills us.
Obviously with our current tileset the background patch has broken our mod. Though it is interesting to note that you can in fact have the new tile that is revealed have all the normal properties and not just background.
If we want we can use god mode for now to get past the raygun replacement and pick up the new chocolate tile.
It is replaced by a teleporter tile that brings us to the secret level.
The lollipop is replaced by a red door. it's funny that if you jump in the top row of lollipops in the house it can push you to the left when you jump inside a door that you don't have the card for.
If we compare the tiles that were replaced in our test with our tileset. we can see that the tiles that are replaced are indeed the first in each row. The danger tile and teleporter are animated so we can't tell for sure which of the 4 animated tiles it is but it is safe to assume it is the first one as the description of the patch tells us.
We do want to continue to use this patch from now on. It works as we want to, it's just that we now need to rearrange the tileset to make the intended background appear for each pickup.
Before the end of this chapter I will update the tileset to make it compatible with this patch. Therefore if you want to test the buggy experience with this patch as I just described you could start with the previous version of this mod and do the same steps as described.
With this patch from now on every pickup will spawn the background of the first row. But that means that after every background tile there are only 12 tiles that can be pickups for that background tile.
But there is a simple workaround. Just make another duplicate of that background tile on another row. This does waste one more tile for each row you do this for. For most projects this loss will probably be negligible. Considering also that you don't need every background that can have items on it to have all possible pickups that can exist in the game.
But it is probably worth mentioning that the variable in this patch we mentioned before can be changed to make it work differently.
The default value of 13 makes it that every 13 tiles (or actually every multiple of 13 so that includes the first tile 0) becomes a background tile like this.
So if we change that value to 26 as we mentioned earlier. It will make it so that every second row becomes a background tile. That means 25 tiles that can be pickups for that background. A slightly more efficient use of your tileset.
When testing this with the current mod it makes that background for the raygun the lamp tile tile 156. exactly as we would predict.
Perhaps 39, every third row would be even better if you have that many pickups. For optimum efficiency.
However for the rest of this project we will use the default value 13 just because it is easier to use. Still it is nice to know we can change a variable and that the patch will still work.
Now that I am committed to using this patch. It is becoming harder and harder to make our mod compatible with the original levels. Depending on the kind of project you want to do it may be good to abandon that notion entirely right away or at some point. If I want some of the original levels to still be playable I would need to replace all the collectable items with new versions that I must now make with modkeen and tileinfo. What I will do now is make new pickup tiles on the empty rows with black tiles. The original collectable tiles I will leave in the tileset for now but I will paint some of their colors pink so you can recognize them as "non working" tiles to indicate that really they need to be replaced with the new pickup tiles.
This is perhaps as much a warning not to pick up those tiles when playtesting as a visual clue this tile needs to be updated when editing levels in Mindbelt.
The teddy bear in the title screen will already be affected by this. We can fix this but I'll leave it for now.
I will also make 4 extra backgrounds that can now be used in this mod. Note that all the new pickups will need to be defined and given the required property in tileinfo. This can be quite a chore if you want to make a lot of backgrounds at once. But remember you don't have to make too many. I won't give all backgrounds all the options for pickups. There is also a trick to make this work faster. When I change one tile and click to set it to 100 points and then go to another tile the field "general behavior" is already selected. Now I can just type 1 and it will toggle to 100 points faster than clicking. For the book you can toggle 1 twice and it will toggle to 1000 points and so on. It works similarly with other properties. For example to make a tile blocking to the left click the left border of the tile. If you now want to do the same for another tile click that tile and press space to change it the same way. This way you can do all tiles of a similar type together faster.
One of the backgrounds I added is the light blue tile or light teal rather. This is to simulate a general feeling of being outdoors just like in keen 3. This is just to show what is possible for now. I don't know how heavily I want to commit to the outdoors theme but I do want to do so a little bit. To increase the feeling of being outdoors -I want clouds-.
You may think this does not fit with the Mars theme. Well maybe Mars has an atmosphere now or this isn't Mars.
I'm actually going to -borrow- a cloud graphic from the patchwork mod because I like them more than the ones from keen 3.
To make (part of) our first level compatible with being outdoors I will also add more tiles that have a light teal background instead of grey. But when they aren't pickups it doesn't matter where on the tileset they are placed.
When adding all this I have overwritten or overdrawn some of the graphics used in the ending sequence. But I don’t care about that now.
I will also edit the first level a bit more so that it now has an outdoor area and then transition into indoor areas with the different backgrounds working. We need to replace all the old pickup tiles and replace them with the new ones. I will replace or remove all of the original pickups in level 01 .
The level exit works in a particular way that makes it harder to make it compatible with more backgrounds so for now we will just only place the exit on light grey background.
We will also move the exit as we have now more things to show off in our first level. As you can see, having more backgrounds gives more options for creative expression. Although technically points with more backgrounds doesn't seem that impressive perhaps but it can make a big difference for the feel of the game.
Bridges
Next I will explain how to enable bridges that are normally exclusive to keen2 in keen1. The same also works in keen 3. But the way to make them possible is by first giving a tile the bridge switch property "switch on" and another "switch off" using tileinfo. But for the bridge to work correctly you also have to use the same tiles as are used for them in keen 2. Because the bridge switch tile is coded to change into its alternative flipped version. Tile 480 needs to be changed to switch on and 493 needs to be changed to switch off. (there is also a patch that makes the switch work correctly for other tile numbers if you patch them but I don't see the advantage of that compared to using the default tile numbers at least for now)
Also the bridge tile itself is coded to be 270 and also already has the bridge graphics by default in keen1. Keen1 actually has a few more keen 2 graphics in its tileset.
I need a custom graphics for a switch tile that can be used on multiple backgrounds so I will lend a tile from the patchwork mod2 (a keen2 mod) and use a slightly edited version of that so I don't have to draw a new one now.
For a bridge to work you need to place a sprite on the switch to determine where the bridge will appear. it's based on the relative coordinates of the appearing bridge to the switch.
The logic how to calculate this is written in the keen wiki. However Mindbelt has a built in function to calculate this automatically so the best is probably to use this.
Just for completeness sake I will copy here the methods to get the sprite number manually:
Quote:"
The location of a switches bridge depends on the value of the sprite placed over the switch. The switch is seen as 0,0 and an 'unsprited' switch will simply turn into a bridge tile. Every tile right counts as +1 and every row down as +256 (Left -1, up -256) This means bridges are 'limited' to +-256 tiles in all directions. This also means that moving a switch moves the bridge too. (As with all hex numbers, a negative value is 65536 - value.) A simple example is a value of 513 ($201) will make a bridge at Keen's feet, 1 tile right of the switch.
"End quote
This comment about negative values being 65536 - value may actually be useful to remember for later if we have to deal with negative numbers in patching but for now we can ignore this and just use the automated feature of mindbelt.
It is maybe also interesting to note that the way the bridge works means if you place a bridge just a few tiles to the right of the switch without it being at least a tile higher or lower. Placing the sprite will also spawn an enemy or creature. As the sprite number 1-10 and so on are already in use. But the bridge will still work.
To make bridges in Mindbelt. select the "tools" tab. then choose out of the options "link". Then first click the switch location. Then second click the location you want the bridge to spawn.
A bridge will generally expand from left to right until it encounters a tile that is different from the tile it starts on.
To make a bridge that extends to the left instead make it so that there is only a same tile in that direction as the starting position but not to the right.
Note that you can make bridges over animated tiles. But only if they all start with the same frame. that is the tile that is placed in the level. So they will all have to be animated synchronously.
If more than one switch is linked to the same bridge position it will still work. If the bridge was activated by the first one the second one will deactivate them again as normal. It does not matter if a switch is on "on" or "off" animation. It's only that they will change into each other with each flip.
There is another useful feature in Mindbelt. If you click the tap settings and select "show links mode". It will show you the sprites that can be interpreted as a "link" and also show you a red line from their position to the coordinate they will link to.
I placed a bunch of bridges in my first level as a demonstration. In fact a few are necessary now to complete the level. A few of my bridges start next to a tile with smooth corners. Visually this is not ideal and could be considered a graphical glitch. However I am fine with it for some reason. But for a completed version of a project it could be worth considering something else.
Teleporters in-level patch
The next patch I want to discuss here and showcase in this mod is the Teleporters in-level patch. This patch changes what the in level teleporter tile does. Normally the teleporter transports keen out of the level and to the map level to the secret level. You could leave this unpatched and use the teleporter the same as in keen 1. But if you feel that in level teleporting is a nice feature it is quite a small sacrifice to include the patch. As usual the patch can be found on the keen wiki:
https://keenwiki.shikadi.net/wiki/Patch:Teleporter
The patch can be copied into the patch file without needed any changes:
#Change the teleporter so it works within the level
%patch $8919 $89 $F0 $F7 $2E $08 $6C $01
$F8 $D1 $E0 $C4 $1E $4C $6C $01 $C3 $26 $8B $07 $50 $88 $E0 $98
$99 $01 $F0 $83 $D2 $00 $B1 $0C $E8 $16 $58 $89 $16 $E4 $6E $A3
$E2 $6E $05 $00 $B0 $83 $D2 $FF $A3 $D4 $6E $89 $16 $D6 $6E $58
$98 $99 $01 $F8 $83 $D2 $00 $B1 $0C $E8 $F5 $57 $89 $16 $E0 $6E
$A3 $DE $6E $05 $00 $70 $83 $D2 $FF $A3 $D0 $6E $89 $16 $D2 $6E
$C3
%patch $4572 $E8 $A4 $43 $EB $13 $90
However for it to work properly You have to also place a sprite on top of the teleporter tiles. It works exactly as the bridge. place the sprite to create the relative coordinates and for that you can once again use the "Link" tool in Mindbelt.
My preferred way of using the teleporter is not using them as actual teleporters thematically but using them as doors to give the player the sense of moving in the third dimension. In reality the player will be teleported to an entirely different part of the level with a means to go back.
This is not a new idea of course. Many 2d platformers seem to work that way. That is that moving through a door actually just teleports you. And it has already been done in the keen 1 mod: Dangerous Keen in The Haunted Mansion. But nonetheless there is no reason to not do something similar in other keen 1 mods. It's best if it is done in a way that causes as little problems as possible.
In order to put the teleporter in my mod in a way that I like I have acquired a 2x3 picture of a door. I also edited it slightly to make an alternative "mirrored" version. I got the original from shadowkeen 1. But I think it is also borrowed from some other game.
Only the middle two tiles are given the property of teleporter. The others are background. Except the top is blocking on top or one way up. (you could also check in tileinfo how I did that)
Now in order to make them work properly first we make the left middle tile teleport the player to the right side of the other side of the door (elsewhere in the level). And the right side of the door will teleport the player to the left side of the target door. Then the new "target" door will do the exact same thing. 2 teleporter tiles that send the player to the opposite side of the original door.
To create a new part of the level where the player can be teleported to we are going to expand the level.
Mindbelt allows you to make the level larger by adding either a "pillar" (vertical row) or "Row" (horizontal row)
I will add rows on the top of the level to make some more room and under to make room for the new door and target teleporter area (indoor)
The way the camera works at the start of the level is a little bit different now because you are no longer so close to the bottom of the level. You could avoid this by making the extra level part above the rest of the level instead of under. But I think it's fine to leave it this way.
I will put 3 teleporter doors in this level. (or 6 if you count the way back doors as another one)
The first one you can approach from 2 sides. The second you can only go through in one way. arguably this is the most proper way. The third door is more of an example of what you probably want to avoid. Minor epilepsy caution when approaching that door.
When you play test note that the first teleporting door does not glitch or anything no matter what. What is important to make it work well is that when the player is going right then when he comes out of the teleporter he will also be going right. Avoid any situation where the player would walk into another teleport right away and be teleported back.
The only flaw with how it is now is that keen makes a fall sound when going through the teleporter. Also it would be nice if you can walk past the door and ignore it and only go in as you press up or alt or some button. It can seem awkward that there is a door like this that you can't go past without going through unless you jump over it. A way to avoid this awkwardness is to only place doors in dead ends as the second example. In that case you should always teleport the player to the same side no matter what tile you touch. The second teleporter of these doors is unreachable now but Just in case I gave it the same coordinates too. Teleporters without a link sprite will teleport keen onto themselves infinitely. Should the player by some unforeseen means get there anyway it is better just to avoid that glitch as much as possible.
The third teleporter doesn't work properly unless you walk into it very carefully. I suggest to avoid placing teleporters that can do this in your levels. But in this version I will leave it in to show it.
Remember also you can use the "show links mode" in Mindbelt to see how teleporters are linked currently just like with bridges.
before finishing this version I will delete the unlzexe file from the mod folder as we don't need it again since the keen1exe only needs to be unlzexe-ed once.
This part of the tutorial will inconclude a version of the game that has the changes as described here building on the previous version.
mod004
We have now set up the most important modding tools we would need to create a keen mod. Now that we know how to use CKPatch it has become relatively easy to add any keen patch we want to our mod project. Patches fall more or less in three categories. 1. patches that you can simply copy and paste into your patch file. 2 patches that are still easy to use but to make them work the way you want to you need to modify a number value a certain way. And 3 patches that are slightly more complex and may need some time to figure out what you can do with them and how. I intend to try to modify some of the more complex patches at some point. For now I should mention one more pre-made patch that is ready to use.
multiple background patch
It is the multiple background patch that exists for keen 1 and 2. It makes it so that any pick up is replaced by the first tile of that row. This allows you to have as many different backgrounds as you want. At least more than you probably would ever want.
https://keenwiki.shikadi.net/wiki/Patch:Tiles
We can copy this entire text into our patch:
###Keen 1 background tiles behave like Keen 3:
#Change item tiles to use tiles at the end of each row ($0D) of tiles
%patch $4409 $26 $8B $07 $B6 [$0D] $F6 $FE
%patch $4410 $F6 $EE $26 $89 $07 $E9 $60 $01
#Change keys, items, etc to use point tiles instead
%patch $4482 $E9 $74 $FF #Affect ship parts
%patch $44BA $E9 $3C $FF #Affect raygun, pogo
%patch $4513 $E9 $E3 $FE #Affect keycards
#Change doors
%patch $28EC $26 $8B $07 $B6
%patch $28F0 [$0D] $F6 $FE $F6 $EE $26 $89 $07
%patch $28F8 $03 $1E $08 $6C $03 $1E $08 $6C
%patch $2900 $26 $89 $07 $90 $90 $90 $90 $90
However notice on two places the code is surrounded by brackets [$0D]
This is not actually part of the patch. These need to be removed before the patch will work. CKPatch will give an error in fact. The maker of the patch added the brackets there to place special emphasis on those values. Changing these values changes the way the patch works. Now you may wonder why I call this a value. It's because it is a number. 0D is 13 in Hexadecimal.
Right now we don't actually want to change this value but for other patches we might want to change their variables. If you want to change a value that is written in Hexadecimal you can use a program to translate that into decimal numbers and back.
You could google hex to decimal. When I do it always brings me to this site:
https://www.rapidtables.com/convert/num ... cimal.html
It works very well for me. For now try it and copy 0D and click convert and see how it changes into 13. If we wanted to change the value of 13 for this patch to say 26. click on "swap" to make it translate decimal number to decimal. type or copy 26 and click convert. we see that we would get 1A
But for now for this patch we don’t actually need to change this value. Just recognize that the patch maker placed the brackets there to put in the description that these are values that could be changed. For now leave them the same but remove the brackets at the two locations the patch should now look like this:
###Keen 1 background tiles behave like Keen 3:
#Change item tiles to use tiles at the end of each row ($0D) of tiles
%patch $4409 $26 $8B $07 $B6 $0D $F6 $FE
%patch $4410 $F6 $EE $26 $89 $07 $E9 $60 $01
#Change keys, items, etc to use point tiles instead
%patch $4482 $E9 $74 $FF #Affect ship parts
%patch $44BA $E9 $3C $FF #Affect raygun, pogo
%patch $4513 $E9 $E3 $FE #Affect keycards
#Change doors
%patch $28EC $26 $8B $07 $B6
%patch $28F0 $0D $F6 $FE $F6 $EE $26 $89 $07
%patch $28F8 $03 $1E $08 $6C $03 $1E $08 $6C
%patch $2900 $26 $89 $07 $90 $90 $90 $90 $90
Now that we have enabled this patch. If we run our mod now it will have completely changed how the game determines what kind of background tile spawn when an item is picked up.
We already know how the patch is supposed to work based on the description. But it can nonetheless be fun to see how the patch currently affects the mod. Since the tileset wasn't designed around the idea that the first tile of each row would be the replacement tile. It will likely completely mess up our pick ups. We could also predict this from looking out our tileset and looking at what the first tile of each row is.
If we enter our first level and pick up the raygun we see that a danger tile replaces it and kills us.
Obviously with our current tileset the background patch has broken our mod. Though it is interesting to note that you can in fact have the new tile that is revealed have all the normal properties and not just background.
If we want we can use god mode for now to get past the raygun replacement and pick up the new chocolate tile.
It is replaced by a teleporter tile that brings us to the secret level.
The lollipop is replaced by a red door. it's funny that if you jump in the top row of lollipops in the house it can push you to the left when you jump inside a door that you don't have the card for.
If we compare the tiles that were replaced in our test with our tileset. we can see that the tiles that are replaced are indeed the first in each row. The danger tile and teleporter are animated so we can't tell for sure which of the 4 animated tiles it is but it is safe to assume it is the first one as the description of the patch tells us.
We do want to continue to use this patch from now on. It works as we want to, it's just that we now need to rearrange the tileset to make the intended background appear for each pickup.
Before the end of this chapter I will update the tileset to make it compatible with this patch. Therefore if you want to test the buggy experience with this patch as I just described you could start with the previous version of this mod and do the same steps as described.
With this patch from now on every pickup will spawn the background of the first row. But that means that after every background tile there are only 12 tiles that can be pickups for that background tile.
But there is a simple workaround. Just make another duplicate of that background tile on another row. This does waste one more tile for each row you do this for. For most projects this loss will probably be negligible. Considering also that you don't need every background that can have items on it to have all possible pickups that can exist in the game.
But it is probably worth mentioning that the variable in this patch we mentioned before can be changed to make it work differently.
The default value of 13 makes it that every 13 tiles (or actually every multiple of 13 so that includes the first tile 0) becomes a background tile like this.
So if we change that value to 26 as we mentioned earlier. It will make it so that every second row becomes a background tile. That means 25 tiles that can be pickups for that background. A slightly more efficient use of your tileset.
When testing this with the current mod it makes that background for the raygun the lamp tile tile 156. exactly as we would predict.
Perhaps 39, every third row would be even better if you have that many pickups. For optimum efficiency.
However for the rest of this project we will use the default value 13 just because it is easier to use. Still it is nice to know we can change a variable and that the patch will still work.
Now that I am committed to using this patch. It is becoming harder and harder to make our mod compatible with the original levels. Depending on the kind of project you want to do it may be good to abandon that notion entirely right away or at some point. If I want some of the original levels to still be playable I would need to replace all the collectable items with new versions that I must now make with modkeen and tileinfo. What I will do now is make new pickup tiles on the empty rows with black tiles. The original collectable tiles I will leave in the tileset for now but I will paint some of their colors pink so you can recognize them as "non working" tiles to indicate that really they need to be replaced with the new pickup tiles.
This is perhaps as much a warning not to pick up those tiles when playtesting as a visual clue this tile needs to be updated when editing levels in Mindbelt.
The teddy bear in the title screen will already be affected by this. We can fix this but I'll leave it for now.
I will also make 4 extra backgrounds that can now be used in this mod. Note that all the new pickups will need to be defined and given the required property in tileinfo. This can be quite a chore if you want to make a lot of backgrounds at once. But remember you don't have to make too many. I won't give all backgrounds all the options for pickups. There is also a trick to make this work faster. When I change one tile and click to set it to 100 points and then go to another tile the field "general behavior" is already selected. Now I can just type 1 and it will toggle to 100 points faster than clicking. For the book you can toggle 1 twice and it will toggle to 1000 points and so on. It works similarly with other properties. For example to make a tile blocking to the left click the left border of the tile. If you now want to do the same for another tile click that tile and press space to change it the same way. This way you can do all tiles of a similar type together faster.
One of the backgrounds I added is the light blue tile or light teal rather. This is to simulate a general feeling of being outdoors just like in keen 3. This is just to show what is possible for now. I don't know how heavily I want to commit to the outdoors theme but I do want to do so a little bit. To increase the feeling of being outdoors -I want clouds-.
You may think this does not fit with the Mars theme. Well maybe Mars has an atmosphere now or this isn't Mars.
I'm actually going to -borrow- a cloud graphic from the patchwork mod because I like them more than the ones from keen 3.
To make (part of) our first level compatible with being outdoors I will also add more tiles that have a light teal background instead of grey. But when they aren't pickups it doesn't matter where on the tileset they are placed.
When adding all this I have overwritten or overdrawn some of the graphics used in the ending sequence. But I don’t care about that now.
I will also edit the first level a bit more so that it now has an outdoor area and then transition into indoor areas with the different backgrounds working. We need to replace all the old pickup tiles and replace them with the new ones. I will replace or remove all of the original pickups in level 01 .
The level exit works in a particular way that makes it harder to make it compatible with more backgrounds so for now we will just only place the exit on light grey background.
We will also move the exit as we have now more things to show off in our first level. As you can see, having more backgrounds gives more options for creative expression. Although technically points with more backgrounds doesn't seem that impressive perhaps but it can make a big difference for the feel of the game.
Bridges
Next I will explain how to enable bridges that are normally exclusive to keen2 in keen1. The same also works in keen 3. But the way to make them possible is by first giving a tile the bridge switch property "switch on" and another "switch off" using tileinfo. But for the bridge to work correctly you also have to use the same tiles as are used for them in keen 2. Because the bridge switch tile is coded to change into its alternative flipped version. Tile 480 needs to be changed to switch on and 493 needs to be changed to switch off. (there is also a patch that makes the switch work correctly for other tile numbers if you patch them but I don't see the advantage of that compared to using the default tile numbers at least for now)
Also the bridge tile itself is coded to be 270 and also already has the bridge graphics by default in keen1. Keen1 actually has a few more keen 2 graphics in its tileset.
I need a custom graphics for a switch tile that can be used on multiple backgrounds so I will lend a tile from the patchwork mod2 (a keen2 mod) and use a slightly edited version of that so I don't have to draw a new one now.
For a bridge to work you need to place a sprite on the switch to determine where the bridge will appear. it's based on the relative coordinates of the appearing bridge to the switch.
The logic how to calculate this is written in the keen wiki. However Mindbelt has a built in function to calculate this automatically so the best is probably to use this.
Just for completeness sake I will copy here the methods to get the sprite number manually:
Quote:"
The location of a switches bridge depends on the value of the sprite placed over the switch. The switch is seen as 0,0 and an 'unsprited' switch will simply turn into a bridge tile. Every tile right counts as +1 and every row down as +256 (Left -1, up -256) This means bridges are 'limited' to +-256 tiles in all directions. This also means that moving a switch moves the bridge too. (As with all hex numbers, a negative value is 65536 - value.) A simple example is a value of 513 ($201) will make a bridge at Keen's feet, 1 tile right of the switch.
"End quote
This comment about negative values being 65536 - value may actually be useful to remember for later if we have to deal with negative numbers in patching but for now we can ignore this and just use the automated feature of mindbelt.
It is maybe also interesting to note that the way the bridge works means if you place a bridge just a few tiles to the right of the switch without it being at least a tile higher or lower. Placing the sprite will also spawn an enemy or creature. As the sprite number 1-10 and so on are already in use. But the bridge will still work.
To make bridges in Mindbelt. select the "tools" tab. then choose out of the options "link". Then first click the switch location. Then second click the location you want the bridge to spawn.
A bridge will generally expand from left to right until it encounters a tile that is different from the tile it starts on.
To make a bridge that extends to the left instead make it so that there is only a same tile in that direction as the starting position but not to the right.
Note that you can make bridges over animated tiles. But only if they all start with the same frame. that is the tile that is placed in the level. So they will all have to be animated synchronously.
If more than one switch is linked to the same bridge position it will still work. If the bridge was activated by the first one the second one will deactivate them again as normal. It does not matter if a switch is on "on" or "off" animation. It's only that they will change into each other with each flip.
There is another useful feature in Mindbelt. If you click the tap settings and select "show links mode". It will show you the sprites that can be interpreted as a "link" and also show you a red line from their position to the coordinate they will link to.
I placed a bunch of bridges in my first level as a demonstration. In fact a few are necessary now to complete the level. A few of my bridges start next to a tile with smooth corners. Visually this is not ideal and could be considered a graphical glitch. However I am fine with it for some reason. But for a completed version of a project it could be worth considering something else.
Teleporters in-level patch
The next patch I want to discuss here and showcase in this mod is the Teleporters in-level patch. This patch changes what the in level teleporter tile does. Normally the teleporter transports keen out of the level and to the map level to the secret level. You could leave this unpatched and use the teleporter the same as in keen 1. But if you feel that in level teleporting is a nice feature it is quite a small sacrifice to include the patch. As usual the patch can be found on the keen wiki:
https://keenwiki.shikadi.net/wiki/Patch:Teleporter
The patch can be copied into the patch file without needed any changes:
#Change the teleporter so it works within the level
%patch $8919 $89 $F0 $F7 $2E $08 $6C $01
$F8 $D1 $E0 $C4 $1E $4C $6C $01 $C3 $26 $8B $07 $50 $88 $E0 $98
$99 $01 $F0 $83 $D2 $00 $B1 $0C $E8 $16 $58 $89 $16 $E4 $6E $A3
$E2 $6E $05 $00 $B0 $83 $D2 $FF $A3 $D4 $6E $89 $16 $D6 $6E $58
$98 $99 $01 $F8 $83 $D2 $00 $B1 $0C $E8 $F5 $57 $89 $16 $E0 $6E
$A3 $DE $6E $05 $00 $70 $83 $D2 $FF $A3 $D0 $6E $89 $16 $D2 $6E
$C3
%patch $4572 $E8 $A4 $43 $EB $13 $90
However for it to work properly You have to also place a sprite on top of the teleporter tiles. It works exactly as the bridge. place the sprite to create the relative coordinates and for that you can once again use the "Link" tool in Mindbelt.
My preferred way of using the teleporter is not using them as actual teleporters thematically but using them as doors to give the player the sense of moving in the third dimension. In reality the player will be teleported to an entirely different part of the level with a means to go back.
This is not a new idea of course. Many 2d platformers seem to work that way. That is that moving through a door actually just teleports you. And it has already been done in the keen 1 mod: Dangerous Keen in The Haunted Mansion. But nonetheless there is no reason to not do something similar in other keen 1 mods. It's best if it is done in a way that causes as little problems as possible.
In order to put the teleporter in my mod in a way that I like I have acquired a 2x3 picture of a door. I also edited it slightly to make an alternative "mirrored" version. I got the original from shadowkeen 1. But I think it is also borrowed from some other game.
Only the middle two tiles are given the property of teleporter. The others are background. Except the top is blocking on top or one way up. (you could also check in tileinfo how I did that)
Now in order to make them work properly first we make the left middle tile teleport the player to the right side of the other side of the door (elsewhere in the level). And the right side of the door will teleport the player to the left side of the target door. Then the new "target" door will do the exact same thing. 2 teleporter tiles that send the player to the opposite side of the original door.
To create a new part of the level where the player can be teleported to we are going to expand the level.
Mindbelt allows you to make the level larger by adding either a "pillar" (vertical row) or "Row" (horizontal row)
I will add rows on the top of the level to make some more room and under to make room for the new door and target teleporter area (indoor)
The way the camera works at the start of the level is a little bit different now because you are no longer so close to the bottom of the level. You could avoid this by making the extra level part above the rest of the level instead of under. But I think it's fine to leave it this way.
I will put 3 teleporter doors in this level. (or 6 if you count the way back doors as another one)
The first one you can approach from 2 sides. The second you can only go through in one way. arguably this is the most proper way. The third door is more of an example of what you probably want to avoid. Minor epilepsy caution when approaching that door.
When you play test note that the first teleporting door does not glitch or anything no matter what. What is important to make it work well is that when the player is going right then when he comes out of the teleporter he will also be going right. Avoid any situation where the player would walk into another teleport right away and be teleported back.
The only flaw with how it is now is that keen makes a fall sound when going through the teleporter. Also it would be nice if you can walk past the door and ignore it and only go in as you press up or alt or some button. It can seem awkward that there is a door like this that you can't go past without going through unless you jump over it. A way to avoid this awkwardness is to only place doors in dead ends as the second example. In that case you should always teleport the player to the same side no matter what tile you touch. The second teleporter of these doors is unreachable now but Just in case I gave it the same coordinates too. Teleporters without a link sprite will teleport keen onto themselves infinitely. Should the player by some unforeseen means get there anyway it is better just to avoid that glitch as much as possible.
The third teleporter doesn't work properly unless you walk into it very carefully. I suggest to avoid placing teleporters that can do this in your levels. But in this version I will leave it in to show it.
Remember also you can use the "show links mode" in Mindbelt to see how teleporters are linked currently just like with bridges.
before finishing this version I will delete the unlzexe file from the mod folder as we don't need it again since the keen1exe only needs to be unlzexe-ed once.
This part of the tutorial will inconclude a version of the game that has the changes as described here building on the previous version.
mod004
Re: Planning to write a new keen 1-3 modding tutorial
Chapter 5 Changing speeds, negative values and more patches
I mentioned in the previous chapter that patches could be categorized based on how difficult they are to use. So in this chapter I will explain how to use some of the slightly harder to use patches. Some patches to work require you to change some variables (numbers) before they do what you want. This is pretty easy once you know how it goes. It is more that it is slightly more work than that I'd say it's really difficult.
But you will usually have to calculate the values from and to hexadecimal.
Some values in the keen engine are negative. This is the case with the values for movement speed for a lot of the sprites in keen. When moving right, enemies have a positive speed (value). But when moving to the left they may have a negative speed because they are moving in the opposite direction.
That's easy enough to understand but it can get confusing to understand how negative values are calculated or used in keen.
luckily there is a way to avoid the confusion or difficulty. that is letting an app do the calculating for you. The good thing is these apps exist and will likely remain available for the foreseeable future. It's just that you have to find the right app or method of calculating to make your number values compatible with keen.
Changing the Yorp speed.
In this chapter we will be changing the speed of the yorp. To change the speed of the yorp we need to find a patch that does this. If we go to:
https://keenwiki.shikadi.net
and go to "patches" we can choose out of different subcategories. If we choose "Keen 1 patches" we get a long list of pages related to keen 1 patches. If we look at the "Y" section we see a page called "Patch:Yorp"
https://keenwiki.shikadi.net/wiki/Patch:Yorp
This page contains a wealth of information. What we are looking for now is section 3 Speed and Jump Height. What we find is 2 patches under starting speed and 8 more under "in level". These are the patches we are looking for. So copy these.
%patch $18CD [$003CW] #If left of Keen (Move right)
%patch $18D4 [$FFC4W] #If right of Keen (Move left)
%patch $1A1C [$FFC4W] #If right of Keen after searching (Move left)
%patch $1A14 [$003CW] #If left of Keen after searching (Move right)
%patch $19CE [$003CW] #If hits left wall (Move right)
%patch $19C2 [$FFC4W] #If hits right wall (Move left)
%patch $19DA [$0000W] #When looking for Keen (Stand still)
%patch $1A5E [$0000W] #When stomped (Stand still)
%patch $1964 [$0080W] #Jump height
%patch $1A99 [$FFB0] #Jump height when shot
What we can notice here is that 2 behaviors that have to do with standing still have a speed associated with them. The default value that is provided with this patch is 0000. We don't need to translate hex to decimal that 0000 is also zero in decimal numbers. It's interesting that this can be patched also. But for now we don't want to use this so we will delete it from our copy. Also jump height and Jump height when shot we will leave out for now.
%patch $18CD [$003CW] #If left of Keen (Move right)
%patch $18D4 [$FFC4W] #If right of Keen (Move left)
%patch $1A1C [$FFC4W] #If right of Keen after searching (Move left)
%patch $1A14 [$003CW] #If left of Keen after searching (Move right)
%patch $19CE [$003CW] #If hits left wall (Move right)
%patch $19C2 [$FFC4W] #If hits right wall (Move left)
These 6 patches we will work with now. If we look at the top one #If left of Keen (Move right). Notice how part of the patch has brackets around it [$003CW]. This is the part of the patch that has the variable that we can change. $ and W seem to be part of the format or something. They should remain intact and unaltered. 003C is the number (in hexadecimal) that can be changed. Also the brackets have to be removed before the patch will work.
Taking a look at these patches you can see that we have 3 patches for moving right and 3 for moving left. And we can also see that all three of each type have the same value. Even if we don't calculate it into decimal we can see that they are identical. Maybe it is easier to work with if we put all of the same type together.
%patch $18CD [$003CW] #If left of Keen (Move right)
%patch $1A14 [$003CW] #If left of Keen after searching (Move right)
%patch $19CE [$003CW] #If hits left wall (Move right)
%patch $18D4 [$FFC4W] #If right of Keen (Move left)
%patch $1A1C [$FFC4W] #If right of Keen after searching (Move left)
%patch $19C2 [$FFC4W] #If hits right wall (Move left)
The description provided with the patch informs us what each of the speeds is. The current values of the variables should be identical to the default values in the unmodded game. If these three speeds for each direction are the same in the original then you probably also want that in a mod. But if we wanted to we could give the yorp a different speed in these three different situations. If we don't want that we just patch all 3 speed values to the new speed.
If we now go ahead and copy 003C into a hexadecimal to decimal converter like:
https://www.rapidtables.com/convert/num ... cimal.html
We get the result that 003C is 60. So 60 is the default speed of yorps. 60 what you might ask? I'm not sure but you can see 60 as 100% of a normal yorp. So if we want to boost the speed of yorps to say 2 times as fast then we patch the 60 to 120 and see if we like the results.
So I use rapidtables.com to convert 120 to hexadecimal. The result is 78. Now if we take a look at the results this website gives us we see that we also get a second option: Hex signed 2's complement (4 digits)
The results there is 0078. By the way this is actually what we need. Just like that default value was 003C we need to put our new values in the patch with 4 digits. Obviously we could add the 2 zeros ourself. That is not hard right. But this format may be important to remember
“Hex signed 2's complement”
Because if we can't do it on this website we might have to find some other app that can. Because when dealing with negative values it may be more difficult without it.
For now let's prepare the first part of our patch. Put in our new value 0078. remove the brackets and leave everything else intact
%patch $18CD $0078W #If left of Keen (Move right)
%patch $1A14 $0078W #If left of Keen after searching (Move right)
%patch $19CE $0078W #If hits left wall (Move right)
Now we already know that the default speed of the yorp is 60. So how do we express 60 in negative? Let's take a look at what happens if we convert the default value of the patch for moving left. "FFC4". The result is 65476. This is a really high number. So how is this 60 or -60? It looks as though really high numbers become negative after a certain point. The method described earlier 65536 - value actually does work here. 65536 - 60 = 65476,
There is some system or logic behind this that you could research if you want to fully understand it. but the easiest way to deal with it is to let a program do the calculating for you.
But let's take a look at the results on our website. we got the result 65476 also. but the site offers us a second result.
Decimal from signed 2's complement (2 digits)
And the result is -60. They knew! The website knew what I wanted and gave it to me before I even asked. It's probably because hexadecimal is only used for computer related things. Anyway we have our answer right. Actually, let's try to get -120 now. so click swap again and type -120. The result is -78. But that is not what we want right. We want some ridiculously high seemingly arbitrary number that somehow by some method can be translated back to a much lower but negative number. We can just scroll down to the next answer.
Hex signed 2's complement (4 digits). There it is again and the result is: FF88.
What we could also do is use the trick 65536 - value again. 65536 -120 = 65416. Calculate that back to hexadecimal and we get FF88 also.
Let's put this in our patch then:
%patch $18D4 $FF88W #If right of Keen (Move left)
%patch $1A1C $FF88W #If right of Keen after searching (Move left)
%patch $19C2 $FF88W #If hits right wall (Move left)
And copy all 6 into our patch file like this:
%patch $18CD $0078W #If left of Keen (Move right)
%patch $1A14 $0078W #If left of Keen after searching (Move right)
%patch $19CE $0078W #If hits left wall (Move right)
%patch $18D4 $FF88W #If right of Keen (Move left)
%patch $1A1C $FF88W #If right of Keen after searching (Move left)
%patch $19C2 $FF88W #If hits right wall (Move left)
It is time to test our mod. Yes it does work and the yorps are fast now, almost too fast.
In fact. After playtesting it for a while I come to the conclusion that the speed increase is too much for the yorp to still be a fun enemy. At least in the way that I have them in my level now. It's not that it is too hard but the rapid fast movement results in a kind of motion sickness or something similar after a while. I will change the speed to 90 instead. It is a slightly more subtle difference but not as obvious that something was changed. As I conclude this version of the project I will make a duplicate of the .pat file with the yorp still having the 120 speed. Call it test1.pat and make it runnable with test1.bat so you can still test it with the 120 speed change if you run test1.bat instead of play.bat.
It's an interesting design choice that you have as a modder. How much do I change the things that I can? It also may seem odd to have the yorp be faster than normal. But remember that it makes more sense to change the speed if you also make your own sprite to make it entirely a new creature. Even a small change to the speed might contribute to giving it a new feel, making it slightly harder or easier and so on.
Two's complement
If you are still wondering what that business with negative numbers was all about. It's a method computers use where negative numbers are saved as positive numbers. Then by some method it is determined if it is to be interpreted as negative or not and how. If you want to understand what is going on. First you'd have to translate the number to binary, that's what the system is based on. Then if the first number is a 1 it is interpreted as negative. That means positive numbers start with a 0. Usually a 0 like that is omitted in non-computer communication, but here it does matter. Anyway if the first number is a 1 then a method is used to determine its (negative) value. If you want to know it, it is probably better explained elsewhere. But the method is called Hex signed 2's complement or Two's complement. There is a video on youtube that does a fairly good job at explaining it if you do want to know it. "How Negative Numbers Work In Binary "
https://www.youtube.com/watch?v=a2F_DewyXKg
Now that you know how to change the speed of the yorp. Other enemies or creatures in keen also have a similar patch for them that can be found on the keen wiki.
Patching the score system and game balance
previously I added the infinite lives patch to this project. It's useful for testing that you don't need to worry about lives. But even for a finished mod it is worth considering leaving this patch in. The lives system is generally considered to be a leftover from arcade games that doesn't really work that well in this way. Do you really want the player to restart the games because they run out of lives? Players can already save between levels to prevent a game over and it is unclear if this is considered cheating and if it is does anyone care?
You can use the point system to earn back lives as in the original. That way the player has an option to not take advantage of abusing saves and trying to earn back lives instead. But this is more of an optional additional challenge and not a realistic way that people play. It is also hard to balance. Either you get less than a life per attempted level and go game over if you get stuck somewhere. Or you can collect more than 1 life per level and can therefore "farm" more and more lives making the lives system irrelevant after a certain point. And it encourages and rewards repetitive player behavior that I think is a game design flaw if it can be avoided.
There are arguments for keeping the old system as it is in keen 1-3. But there are also compelling reasons to decide to use infinite lives. For this project I intend to keep infinite lives.
The argument being that it saves the player the effort of having to load their save every failed level attempt. Alternatively if you somehow expect the player to not "abuse" that mechanism. Now it is probably too hard to avoid a game over.
Adding infinite lives does have a side effect that it makes the score system pointless. You could argue that the score system is already close to meaningless since you can pick up the same points again and again after dying. In the original game you can only do this repeatedly infinitely as long as you collect 20.000 points every time. But even if you do this only unintentionally the score does not represent the performance of the player. So long as you don't go game over, a higher score could represent having to repeat a level many times and finishing a level in one attempt would net you fewer points.
Infinite lives only makes this problem bigger or occur faster.
There is a patch that makes it so that the score reset when keen dies. This completely prevents players from collecting a point twice. Making high scores meaningful again.
Therefore I will implement this in this mod.
The only exception is if you leave a level with the teleporter you would still be able to farm that level repeatedly for points still, even with this patch. However we use the teleporter for the in level teleport patch so this is not a problem.
###RESET SCORE UPON DEATH
#Reset score on death A
%patch $427D $66 $81 $06 $E2 $6E $0800W $0000W $66 $A1 $AF00W $66 $A3 $AACAW $90 $90
#Reset score on death B
#%patch $42BB $66 $81 $06 $E2 $6E $0800W $0000W $66 $A1 $AF00W $66 $A3 $AACAW $90 $90
#Save score on level load
%patch $4BAE $66 $A1 $AACAW $66 $A3 $AF00W $66 $33 $C0 $66 $A3 $5135W $66
$A3 $563EW $A3 $5B14W $90
I am not sure what death A and death B means exactly in this patch. but both are part of the patch and it works as is.
Now that we have infinite lives, getting an extra life at every 20000 points does not matter anymore. It may be better to remove it now that we have that.
#Disable EKA (Free $0D76-$0DAF)
%patch $0D74 $5D $C3
Ammo balance
Just like the infinite lives patch allows the player to farm the levels repeatedly for points this also applies to ammo. If a player picks up ammo at the start of the level then dies and reattempts the level he now gets to keep the ammo he just collected. So depending on the situation the player gets rewarded for failure intentionally or otherwise. This is less of a problem without infinite lives because the player can only do that a finite amount of times. Though if a player can farm levels for more than 1 lives he can then trade those lives for more ammo in levels where it is available.
You could argue that this can be a fun mechanic in the original game or unpatched level packs. Especially if initially there is some skill expression required to grind to the point where you have enough lives and ammo.
However you could also make the point that if you allow players to grind to get 100 1000 10000 ammo or as many as the players wishes. Then you could also argue that maybe it would be okay to give the player infinite ammo right away.
An alternative could be that a patch was made that resets the ammo every time you die just like there is for the score now.
There might also be a patch that resets the ammo to 0 when dying. But this may be considered unfair or unfun or not an intuitive mechanic.
But right now I will solve this problem by just giving the player infinite ammo:
#Infinite ammo (keen1)
%patch $3E2B $EB $05
%patch $3E3B $90 $90 $90 $90
The first line makes it so that keen can shoot even when he has 0 bullets. The second line stops the ammo count from going down when shooting.
Note: I found this on the wiki page:
https://keenwiki.shikadi.net/wiki/Patch ... Vorticons)
Now that we have infinite ammo enabled we should probably remove all the raygun items from our levels to prevent the game from uselessly counting up ammo score. It won't affect the gameplay but it feels silly to have a counter that goes up for no reason.
But what we can do instead is set the amount of ammo the raygun tile gives to 0. You can use the same patch to make it any amount you want ofcourse but now we already have infinite ammo.
the patch:
#What raygun gives Keen
%patch $44A2 {$AAC8W} [$05]
we need to remove the (curly) brackets again. 05 is the default value. It is in hexadecimal but a number under 10 is indistinguishable from decimal numbers. So we don't need a calculator to change it to 0.
#What raygun gives Keen
%patch $44A2 $AAC8W $00
Right now keen will shoot even with 0 bullets. But let's set keens starting ammo to 1 to make it less confusing. Or the player might not even try to shoot. It would still be better to make it so there is an infinity symbol there somehow
#Shots Keen has at game start
%patch $9008 [$0000W]
We don't need a calculator to know that 1 is also 1 in hexadecimal
#Shots Keen has at game start
%patch $9008 $0001W
Keen now has one shot that will never go down when shooting. I guess it could be interpreted as having one gun now (with incidentally infinite ammo). Or one shot that instantly recharges itself.
At Least the player is more likely to try to use their one bullet and discover he doesn't run out.
An argument could be made that infinite ammo doesn’t make keen more fun because you are more incentivized to shoot everything. If we don’t like it we could always reverse the decision.
I am going to add a second level and put it close to the start position. This level will mainly be used for testing the sprites when they are modded. So in this case it is a place to look for the yorps to see the new speed. Eventually this level may grow into a real level if I end up adding more to it. I will use level02.ck1 for this and will delete the original level. I'm also editing level 1 a bit removing some of the things that were used as an example in the previous version. Don't worry the buggy third teleporter is now fixed.
I'm also editing level90.ck1. The title screen part still had a pink bear. I also changed it more. The same level contains more aspects of the title screen options. One of the parts contained the bean with bacon megarocket but I painted over those graphics for my new tiles so now I remove it entirely from that "level" or page.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod005
I mentioned in the previous chapter that patches could be categorized based on how difficult they are to use. So in this chapter I will explain how to use some of the slightly harder to use patches. Some patches to work require you to change some variables (numbers) before they do what you want. This is pretty easy once you know how it goes. It is more that it is slightly more work than that I'd say it's really difficult.
But you will usually have to calculate the values from and to hexadecimal.
Some values in the keen engine are negative. This is the case with the values for movement speed for a lot of the sprites in keen. When moving right, enemies have a positive speed (value). But when moving to the left they may have a negative speed because they are moving in the opposite direction.
That's easy enough to understand but it can get confusing to understand how negative values are calculated or used in keen.
luckily there is a way to avoid the confusion or difficulty. that is letting an app do the calculating for you. The good thing is these apps exist and will likely remain available for the foreseeable future. It's just that you have to find the right app or method of calculating to make your number values compatible with keen.
Changing the Yorp speed.
In this chapter we will be changing the speed of the yorp. To change the speed of the yorp we need to find a patch that does this. If we go to:
https://keenwiki.shikadi.net
and go to "patches" we can choose out of different subcategories. If we choose "Keen 1 patches" we get a long list of pages related to keen 1 patches. If we look at the "Y" section we see a page called "Patch:Yorp"
https://keenwiki.shikadi.net/wiki/Patch:Yorp
This page contains a wealth of information. What we are looking for now is section 3 Speed and Jump Height. What we find is 2 patches under starting speed and 8 more under "in level". These are the patches we are looking for. So copy these.
%patch $18CD [$003CW] #If left of Keen (Move right)
%patch $18D4 [$FFC4W] #If right of Keen (Move left)
%patch $1A1C [$FFC4W] #If right of Keen after searching (Move left)
%patch $1A14 [$003CW] #If left of Keen after searching (Move right)
%patch $19CE [$003CW] #If hits left wall (Move right)
%patch $19C2 [$FFC4W] #If hits right wall (Move left)
%patch $19DA [$0000W] #When looking for Keen (Stand still)
%patch $1A5E [$0000W] #When stomped (Stand still)
%patch $1964 [$0080W] #Jump height
%patch $1A99 [$FFB0] #Jump height when shot
What we can notice here is that 2 behaviors that have to do with standing still have a speed associated with them. The default value that is provided with this patch is 0000. We don't need to translate hex to decimal that 0000 is also zero in decimal numbers. It's interesting that this can be patched also. But for now we don't want to use this so we will delete it from our copy. Also jump height and Jump height when shot we will leave out for now.
%patch $18CD [$003CW] #If left of Keen (Move right)
%patch $18D4 [$FFC4W] #If right of Keen (Move left)
%patch $1A1C [$FFC4W] #If right of Keen after searching (Move left)
%patch $1A14 [$003CW] #If left of Keen after searching (Move right)
%patch $19CE [$003CW] #If hits left wall (Move right)
%patch $19C2 [$FFC4W] #If hits right wall (Move left)
These 6 patches we will work with now. If we look at the top one #If left of Keen (Move right). Notice how part of the patch has brackets around it [$003CW]. This is the part of the patch that has the variable that we can change. $ and W seem to be part of the format or something. They should remain intact and unaltered. 003C is the number (in hexadecimal) that can be changed. Also the brackets have to be removed before the patch will work.
Taking a look at these patches you can see that we have 3 patches for moving right and 3 for moving left. And we can also see that all three of each type have the same value. Even if we don't calculate it into decimal we can see that they are identical. Maybe it is easier to work with if we put all of the same type together.
%patch $18CD [$003CW] #If left of Keen (Move right)
%patch $1A14 [$003CW] #If left of Keen after searching (Move right)
%patch $19CE [$003CW] #If hits left wall (Move right)
%patch $18D4 [$FFC4W] #If right of Keen (Move left)
%patch $1A1C [$FFC4W] #If right of Keen after searching (Move left)
%patch $19C2 [$FFC4W] #If hits right wall (Move left)
The description provided with the patch informs us what each of the speeds is. The current values of the variables should be identical to the default values in the unmodded game. If these three speeds for each direction are the same in the original then you probably also want that in a mod. But if we wanted to we could give the yorp a different speed in these three different situations. If we don't want that we just patch all 3 speed values to the new speed.
If we now go ahead and copy 003C into a hexadecimal to decimal converter like:
https://www.rapidtables.com/convert/num ... cimal.html
We get the result that 003C is 60. So 60 is the default speed of yorps. 60 what you might ask? I'm not sure but you can see 60 as 100% of a normal yorp. So if we want to boost the speed of yorps to say 2 times as fast then we patch the 60 to 120 and see if we like the results.
So I use rapidtables.com to convert 120 to hexadecimal. The result is 78. Now if we take a look at the results this website gives us we see that we also get a second option: Hex signed 2's complement (4 digits)
The results there is 0078. By the way this is actually what we need. Just like that default value was 003C we need to put our new values in the patch with 4 digits. Obviously we could add the 2 zeros ourself. That is not hard right. But this format may be important to remember
“Hex signed 2's complement”
Because if we can't do it on this website we might have to find some other app that can. Because when dealing with negative values it may be more difficult without it.
For now let's prepare the first part of our patch. Put in our new value 0078. remove the brackets and leave everything else intact
%patch $18CD $0078W #If left of Keen (Move right)
%patch $1A14 $0078W #If left of Keen after searching (Move right)
%patch $19CE $0078W #If hits left wall (Move right)
Now we already know that the default speed of the yorp is 60. So how do we express 60 in negative? Let's take a look at what happens if we convert the default value of the patch for moving left. "FFC4". The result is 65476. This is a really high number. So how is this 60 or -60? It looks as though really high numbers become negative after a certain point. The method described earlier 65536 - value actually does work here. 65536 - 60 = 65476,
There is some system or logic behind this that you could research if you want to fully understand it. but the easiest way to deal with it is to let a program do the calculating for you.
But let's take a look at the results on our website. we got the result 65476 also. but the site offers us a second result.
Decimal from signed 2's complement (2 digits)
And the result is -60. They knew! The website knew what I wanted and gave it to me before I even asked. It's probably because hexadecimal is only used for computer related things. Anyway we have our answer right. Actually, let's try to get -120 now. so click swap again and type -120. The result is -78. But that is not what we want right. We want some ridiculously high seemingly arbitrary number that somehow by some method can be translated back to a much lower but negative number. We can just scroll down to the next answer.
Hex signed 2's complement (4 digits). There it is again and the result is: FF88.
What we could also do is use the trick 65536 - value again. 65536 -120 = 65416. Calculate that back to hexadecimal and we get FF88 also.
Let's put this in our patch then:
%patch $18D4 $FF88W #If right of Keen (Move left)
%patch $1A1C $FF88W #If right of Keen after searching (Move left)
%patch $19C2 $FF88W #If hits right wall (Move left)
And copy all 6 into our patch file like this:
%patch $18CD $0078W #If left of Keen (Move right)
%patch $1A14 $0078W #If left of Keen after searching (Move right)
%patch $19CE $0078W #If hits left wall (Move right)
%patch $18D4 $FF88W #If right of Keen (Move left)
%patch $1A1C $FF88W #If right of Keen after searching (Move left)
%patch $19C2 $FF88W #If hits right wall (Move left)
It is time to test our mod. Yes it does work and the yorps are fast now, almost too fast.
In fact. After playtesting it for a while I come to the conclusion that the speed increase is too much for the yorp to still be a fun enemy. At least in the way that I have them in my level now. It's not that it is too hard but the rapid fast movement results in a kind of motion sickness or something similar after a while. I will change the speed to 90 instead. It is a slightly more subtle difference but not as obvious that something was changed. As I conclude this version of the project I will make a duplicate of the .pat file with the yorp still having the 120 speed. Call it test1.pat and make it runnable with test1.bat so you can still test it with the 120 speed change if you run test1.bat instead of play.bat.
It's an interesting design choice that you have as a modder. How much do I change the things that I can? It also may seem odd to have the yorp be faster than normal. But remember that it makes more sense to change the speed if you also make your own sprite to make it entirely a new creature. Even a small change to the speed might contribute to giving it a new feel, making it slightly harder or easier and so on.
Two's complement
If you are still wondering what that business with negative numbers was all about. It's a method computers use where negative numbers are saved as positive numbers. Then by some method it is determined if it is to be interpreted as negative or not and how. If you want to understand what is going on. First you'd have to translate the number to binary, that's what the system is based on. Then if the first number is a 1 it is interpreted as negative. That means positive numbers start with a 0. Usually a 0 like that is omitted in non-computer communication, but here it does matter. Anyway if the first number is a 1 then a method is used to determine its (negative) value. If you want to know it, it is probably better explained elsewhere. But the method is called Hex signed 2's complement or Two's complement. There is a video on youtube that does a fairly good job at explaining it if you do want to know it. "How Negative Numbers Work In Binary "
https://www.youtube.com/watch?v=a2F_DewyXKg
Now that you know how to change the speed of the yorp. Other enemies or creatures in keen also have a similar patch for them that can be found on the keen wiki.
Patching the score system and game balance
previously I added the infinite lives patch to this project. It's useful for testing that you don't need to worry about lives. But even for a finished mod it is worth considering leaving this patch in. The lives system is generally considered to be a leftover from arcade games that doesn't really work that well in this way. Do you really want the player to restart the games because they run out of lives? Players can already save between levels to prevent a game over and it is unclear if this is considered cheating and if it is does anyone care?
You can use the point system to earn back lives as in the original. That way the player has an option to not take advantage of abusing saves and trying to earn back lives instead. But this is more of an optional additional challenge and not a realistic way that people play. It is also hard to balance. Either you get less than a life per attempted level and go game over if you get stuck somewhere. Or you can collect more than 1 life per level and can therefore "farm" more and more lives making the lives system irrelevant after a certain point. And it encourages and rewards repetitive player behavior that I think is a game design flaw if it can be avoided.
There are arguments for keeping the old system as it is in keen 1-3. But there are also compelling reasons to decide to use infinite lives. For this project I intend to keep infinite lives.
The argument being that it saves the player the effort of having to load their save every failed level attempt. Alternatively if you somehow expect the player to not "abuse" that mechanism. Now it is probably too hard to avoid a game over.
Adding infinite lives does have a side effect that it makes the score system pointless. You could argue that the score system is already close to meaningless since you can pick up the same points again and again after dying. In the original game you can only do this repeatedly infinitely as long as you collect 20.000 points every time. But even if you do this only unintentionally the score does not represent the performance of the player. So long as you don't go game over, a higher score could represent having to repeat a level many times and finishing a level in one attempt would net you fewer points.
Infinite lives only makes this problem bigger or occur faster.
There is a patch that makes it so that the score reset when keen dies. This completely prevents players from collecting a point twice. Making high scores meaningful again.
Therefore I will implement this in this mod.
The only exception is if you leave a level with the teleporter you would still be able to farm that level repeatedly for points still, even with this patch. However we use the teleporter for the in level teleport patch so this is not a problem.
###RESET SCORE UPON DEATH
#Reset score on death A
%patch $427D $66 $81 $06 $E2 $6E $0800W $0000W $66 $A1 $AF00W $66 $A3 $AACAW $90 $90
#Reset score on death B
#%patch $42BB $66 $81 $06 $E2 $6E $0800W $0000W $66 $A1 $AF00W $66 $A3 $AACAW $90 $90
#Save score on level load
%patch $4BAE $66 $A1 $AACAW $66 $A3 $AF00W $66 $33 $C0 $66 $A3 $5135W $66
$A3 $563EW $A3 $5B14W $90
I am not sure what death A and death B means exactly in this patch. but both are part of the patch and it works as is.
Now that we have infinite lives, getting an extra life at every 20000 points does not matter anymore. It may be better to remove it now that we have that.
#Disable EKA (Free $0D76-$0DAF)
%patch $0D74 $5D $C3
Ammo balance
Just like the infinite lives patch allows the player to farm the levels repeatedly for points this also applies to ammo. If a player picks up ammo at the start of the level then dies and reattempts the level he now gets to keep the ammo he just collected. So depending on the situation the player gets rewarded for failure intentionally or otherwise. This is less of a problem without infinite lives because the player can only do that a finite amount of times. Though if a player can farm levels for more than 1 lives he can then trade those lives for more ammo in levels where it is available.
You could argue that this can be a fun mechanic in the original game or unpatched level packs. Especially if initially there is some skill expression required to grind to the point where you have enough lives and ammo.
However you could also make the point that if you allow players to grind to get 100 1000 10000 ammo or as many as the players wishes. Then you could also argue that maybe it would be okay to give the player infinite ammo right away.
An alternative could be that a patch was made that resets the ammo every time you die just like there is for the score now.
There might also be a patch that resets the ammo to 0 when dying. But this may be considered unfair or unfun or not an intuitive mechanic.
But right now I will solve this problem by just giving the player infinite ammo:
#Infinite ammo (keen1)
%patch $3E2B $EB $05
%patch $3E3B $90 $90 $90 $90
The first line makes it so that keen can shoot even when he has 0 bullets. The second line stops the ammo count from going down when shooting.
Note: I found this on the wiki page:
https://keenwiki.shikadi.net/wiki/Patch ... Vorticons)
Now that we have infinite ammo enabled we should probably remove all the raygun items from our levels to prevent the game from uselessly counting up ammo score. It won't affect the gameplay but it feels silly to have a counter that goes up for no reason.
But what we can do instead is set the amount of ammo the raygun tile gives to 0. You can use the same patch to make it any amount you want ofcourse but now we already have infinite ammo.
the patch:
#What raygun gives Keen
%patch $44A2 {$AAC8W} [$05]
we need to remove the (curly) brackets again. 05 is the default value. It is in hexadecimal but a number under 10 is indistinguishable from decimal numbers. So we don't need a calculator to change it to 0.
#What raygun gives Keen
%patch $44A2 $AAC8W $00
Right now keen will shoot even with 0 bullets. But let's set keens starting ammo to 1 to make it less confusing. Or the player might not even try to shoot. It would still be better to make it so there is an infinity symbol there somehow
#Shots Keen has at game start
%patch $9008 [$0000W]
We don't need a calculator to know that 1 is also 1 in hexadecimal
#Shots Keen has at game start
%patch $9008 $0001W
Keen now has one shot that will never go down when shooting. I guess it could be interpreted as having one gun now (with incidentally infinite ammo). Or one shot that instantly recharges itself.
At Least the player is more likely to try to use their one bullet and discover he doesn't run out.
An argument could be made that infinite ammo doesn’t make keen more fun because you are more incentivized to shoot everything. If we don’t like it we could always reverse the decision.
I am going to add a second level and put it close to the start position. This level will mainly be used for testing the sprites when they are modded. So in this case it is a place to look for the yorps to see the new speed. Eventually this level may grow into a real level if I end up adding more to it. I will use level02.ck1 for this and will delete the original level. I'm also editing level 1 a bit removing some of the things that were used as an example in the previous version. Don't worry the buggy third teleporter is now fixed.
I'm also editing level90.ck1. The title screen part still had a pink bear. I also changed it more. The same level contains more aspects of the title screen options. One of the parts contained the bean with bacon megarocket but I painted over those graphics for my new tiles so now I remove it entirely from that "level" or page.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod005
Re: I'm working on a new keen 1-3 modding tutorial
Chapter 6: Patching options for enemy traits. Sprite type
In Keen, enemy sprites, or NPCs in the case of yorps and others have certain traits that define how they interact with the player (keen). For example gargs kill keen on touch but yorps, butler bots and tank bots only push keen. It is possible to change some of these traits in order to create (somewhat) new enemies or non-enemy creatures.
One of the most simple but also quite impactful examples of this is that you can change the yorp to kill keen on touch just like the garg. You could make it so that both the garg kills keen and the yorp. But you can also make the garg push keen in the same way as a yorp. Aside from that they will still behave the same way (without further patching). So this could be a relatively easy way to create new gameplay for your mod.
Sprites such as a yorp have their own relatively complex behavior that could be patches with relevant patching, including speed as mentioned earlier.
Sprite type and collision
Sprites or creatures in keen have a trait that has been called "sprite type" in other tutorials and patch descriptions.
They also have a trait that has been called "collision" on other tutorials and patch descriptions.
Sprite type in this context generally determines what happens if the keen character interacts (collides) with the other sprite (such as a yorp).
The collision trait in this context is what happens if keens bullet interacts (collides) with the other sprite (such as a yorp).
This can be slightly confusing because the trait called sprite type is also a kind of collision. but they are completely separate. I guess it doesn't matter what you call it as long as you know what you are talking about.
The collision trait also determines what happens if an enemy shot (tank bot) hits that sprite.
Changing what happens when the yorp touches you does not change what happens if they are shot and vice versa.
Generally you could say that sprite type mostly determines what a sprite does to other sprites (keen in particular). And collision determines what happens to them when another sprite interacts with them (mostly keens and the tank bots shots).
Changing the sprite type
If we want to change what happens if a yorp touches you we can do so by giving it the same sprite type of another enemy. For example that of the garg. To do that we need a patch that does this. Let's take a look at the yorp patches page on the keen wiki. What we find is the following:
Quote:
Sprite Type
Yorps use sprite type 2 which means they push Keen about but don't hurt him, and if Keen lands on top of them, a stunned Yorp sprite is produced. Using any other sprite type means a Yorp cannot be stunned. There are some subtleties in the stunned behavior revealed in the behaviors section.
End Quote
#Yorp sprite type:
%patch $188B $02
We have a patch for the yorp with the value 2 (in hexadecimal). Note that just like the speed patches this doesn't do anything unless we change it to another value. So what value do we need to have the sprite type of the garg? Let's look at the garg page. We find:
#Garg sprite type:
%patch $184E $03
We have what we need here. So now we want to make the yorp kill like a garg and the garg push like a yorp. So let's give both the value of the other and test it.
#Yorp sprite type changed to 3
%patch $188B $03
#Garg sprite type changed to 2
%patch $184E $02
Let's put this in our patch file and run it. Run test1.bat of the mod version that is part of this chapter to test this.
Note that it works. The yorps now kill keen on touch and the gargs only push you. It may be very confusing to the player that the yorps now kill but remember that you can change the graphics into something that looks dangerous. You can also, such as in this tutorial, warn the player what will happen. It also helps if the player is introduced to the various enemies early in the game like in the beginning of the first level.
Notice with this patch that yorps and gargs still change into a dead yorp and garg respectively when shot. Because we only changed the property sprite type. What happen to them when they are shot is determined by their collision trait
Notice that our patch has a side effect. Because the gargs now push like yorps they also are stompable like yorps.
The fact that yorps being stompable is determined by their sprite type is an exception to the principle that the sprite type determines what a sprite does to other sprites. In this case the sprite type of the yorp determines both what can happen to them and what they can do to keen (push). Depending on how you look at it, the sprite type also could have been named collision. You could say that there are 2 kinds of collisions that interact.
When they are stomped they change into the stunned yorp animation. When they become unstomped they also turn back into a yorp instead of a garg. But notice that they do not become killing like the yorps that spawned as yorps!
It is not always obvious why patches work the way that they do. Testing them is important. It is probably the case that yorps or gargs get their traits (like the sprite type) assigned to them when they spawn in the level. When the garg gets stunned it uses the yorp’s stunned behavior routine that also changes them back into a yorp. But the trait that makes them push or kill, the sprite type, is assigned only in their initial spawn in the level. The same appears to be true for their collision trait. That is even if our gargs turn into a yorp when they become stunned if they die they spawn a dead garg.
We may be able to use this mechanic to make enemies other than the yorp stunnable in a way that makes sense. But for now we want to fix this bug. What we can do instead is give the gargs the pushing behavior of the butler robot instead.
the patch is:
#Butler Bot sprite type:
%patch $1782 $05
So we now put in our patch file:
#Yorp sprite type changed to 3
%patch $188B $03
#Garg sprite type changed to 5
%patch $184E $05
run test2 to test this
It now works bug free. The gargs push keen and cannot be stomped. The gargs can share this property with the butler robot without it affecting the butler robot itself. The garg is obviously less dangerous now but his charge could still be pretty dangerous when it can push you into danger tiles. A completely new type of gameplay could emerge from this if levels for it are made. And maybe you would want new graphics first for the gargs and yorps too.
The yorps and the gargs or butlers aren't the only enemies in keen 1. The others could be changed the same way. All of them could be given the traits of all others. Not all of the options work bug free initially such as the garg becoming a stunned yorp in the previous example. You could search the keen wiki for the other pages for the other spite types but they are also summarized on this page:
https://keenwiki.shikadi.net/wiki/Patch:Sprite_type
You find the existing sprite types that could be used.
Keen 1:
0 Don't appear
1 Keen (All sprites pass through sprite)
2 Yorp (when stood on becomes stomped Yorp)
3 Garg (Kill Keen)
4 Vorticon (Kill Keen, die when chain is shot)
5 Butler bot (Push Keen)
6 Tank bot (Push Keen, ignore enemy shot type sprite)
8 Chain (Shots hit sprite)
10 Keen's shot (Kill sprites that react to it)
11 Enemy shot (Kill enemies that react to it, and Keen.)
12 Icecubetter (Do nothing)
13 Zap-zot (Shots hit sprite)
14 Chain zap-zot (Same as 13)
15 Icecube (Freeze Keen)
However You might still want to find the page for the patch for how to change any particular enemy into another sprite type though.
A good example of what is possible is if you want to you could make any sprite such as the yorp freeze keen on touch. Whether this is a good idea depends on the type of mod you want to make. Also care would have to be taken to prevent keen from getting stuck indefinitely. Right now I will give an example of making the butler robot freeze keen. we need the patch from the butler robot page:
#Butler Bot sprite type:
%patch $1782 $05
and change it to sprite 15 (0F)
%patch $1782 $0F
There is one problem though. With this patch sprites with the sprite type of the ice cubes will disappear offscreen. Thus they will never appear unless spawned at the start of the level and then disappear as soon as they are out of sight.
I guess this is another example of how sprite types can affect more things than just what happens when they touch keen or other sprites.
Luckily a patch for this already exists. When we search the page for ice cubes we find:
https://keenwiki.shikadi.net/wiki/Patch:Icecubes
Quote:
Freeze-type sprites don't vanish when offscreen
This patch allows icecubes to continue existing even when offscreen; this means they can be more troublesome for Keen and is best used with the above patch. It also fixes the problem noted in the behavior section, where any sprite of type 15 vanishes when offscreen. This allows things like freezing Yorps.
#Existing freeze sprites continue existing even offscreen
%patch $3340 $83 $3E $20 $82 $09 $7C $13 $83 $3E $20 $82 $0F $74 $0C $90
End quote
thus we put this in our patch file
This can be tested with test3.bat
The freeze effect also pushes keen and makes him slide. Or rather you could say keen acquires the speed of the freezing sprite and as an icecube he will then slide. Depending on how the butler bots are placed, keen will or will not be at risk of being stuck indefinitely. Take care of this when designing your levels.
What we can also do is make the tank robot's shot freeze keen. This stops the tank from being able to kill yorps and gargs too. Shots will simply be blocked by them but they won't die.
It may not be obvious at first that yorps can still block tankbot bullets when they have the freezing sprite type but this is how it appears to work. My guess is that it is the yorps sprite type that determines the tank shot zap/zots into it. But it is only the tank shot's default sprite type or keen shot that makes the yorp "die". In this case the yorp still has the garg's sprite type. If a tank bot shoots a garg normally the bullet should also bounce off of him, or zap/zot, with the tankbot's default sprite type the garg would die at the same time.
The tank's shot is its own sprite with its own traits. There is a page for that as well on the keen wiki
https://keenwiki.shikadi.net/wiki/Patch ... ot_Patches
this patch:
#Tank shot sprite type:
%patch $48E9 [$0B]
can be changed to sprite type 15 as well as we did earlier:
#Tank shot sprite type changed to 15
%patch $48E9 $0F
Previously we added the patch for "Existing freeze sprites continue existing even offscreen"
Now that we gave this property to the tank's shot, leaving this in may sometimes give questionable results. But for now we will risk the possible bugs. But you may want to make a choice between having enemies that freeze on touch that don't disappear off screen. Or having the tank's bullets freeze but not using the patch that prevents sprites with the freeze property to disappear offscreen.
The previous patches can be tested with test3.bat
There are a few more things that can be done.
Another sprite type we could use is sprite number 8. It doesn't really do anything except block shots. So if we give that property to a yorp keen can walk right through him too. This seems like a useless waste of an enemy/npc. But the yorp could still be vulnerable to enemy shots as well as keen shots. And thus blocking those and affecting strategy.
Note that we could also use the zap/zot sprite property for this. However then they disappear when they are offscreen. But the chain will remain. You can also give a yorp or garg the property of keen's shot or the tanks shots. Unfortunately if you do this they will disappear when off screen just like an unpatched ice cube. Maybe this could be an interesting patch to request though. Particularly if it is done for the tank's shot and not keen's. Because you could leave the tank bot out of the mod or stop it from shooting to avoid complications. Or only let them shoot where their shots cannot go offscreen.
Test this with test4.bat
Smooth pushing
There is another patch I would like to mention here. There is a patch that makes the butler robots and tank bots push smoothly instead of jerky.
#Butler/Tank bots push keen smoothly
%patch $4646 $57 $56 $E8 $EB92W $59 $59 $B8 [$0002W] $EB [$41]
Quote
This path lets the Butler and Tank push Keen smoothly, like the Meep in Keen 3, rather then in jerks as they usually do. Here sound 2 is played on contact (While the bot is pushing Keen) to not play any sound, change the last byte ($41) to $47 (helpful if you don't like annoying noises.)
Endquote
We will be removing the pushing sound when using this patch:
%patch $4646 $57 $56 $E8 $EB92W $59 $59 $B8 $0002W $EB $47
It will affect the butler and tank bot or any sprite that has their sprite type. But not the yorp. Although it could be given to the yorp then they would lose the ability (or weakness) of being stompable. Right now the butler freezes keen but it will affect the tank bot. The gargs already use the butler's push trait so it will affect them too. This is actually more interesting I think, to have a charging garg push you in this way. It probably makes it less hard but that is not necessarily a bad thing. I think it also makes it look somewhat less buggy. that is in the case of when a garg pushes you while moving faster than pushing enemies normally do. Actually it may in some way make it harder. You cannot pass a blocking enemy that is walking in the same direction as you anymore by going through them. On the other hand if you are pushed you don't change direction automatically anymore. It is also no longer possible to "jump through" pushing enemies. Normally you can kind of glitch through yorps and butler bots when you make a little jump. It is even easier with the running garg but with the smooth pushing this appears no longer possible.
Test this with test5.bat
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod006
In Keen, enemy sprites, or NPCs in the case of yorps and others have certain traits that define how they interact with the player (keen). For example gargs kill keen on touch but yorps, butler bots and tank bots only push keen. It is possible to change some of these traits in order to create (somewhat) new enemies or non-enemy creatures.
One of the most simple but also quite impactful examples of this is that you can change the yorp to kill keen on touch just like the garg. You could make it so that both the garg kills keen and the yorp. But you can also make the garg push keen in the same way as a yorp. Aside from that they will still behave the same way (without further patching). So this could be a relatively easy way to create new gameplay for your mod.
Sprites such as a yorp have their own relatively complex behavior that could be patches with relevant patching, including speed as mentioned earlier.
Sprite type and collision
Sprites or creatures in keen have a trait that has been called "sprite type" in other tutorials and patch descriptions.
They also have a trait that has been called "collision" on other tutorials and patch descriptions.
Sprite type in this context generally determines what happens if the keen character interacts (collides) with the other sprite (such as a yorp).
The collision trait in this context is what happens if keens bullet interacts (collides) with the other sprite (such as a yorp).
This can be slightly confusing because the trait called sprite type is also a kind of collision. but they are completely separate. I guess it doesn't matter what you call it as long as you know what you are talking about.
The collision trait also determines what happens if an enemy shot (tank bot) hits that sprite.
Changing what happens when the yorp touches you does not change what happens if they are shot and vice versa.
Generally you could say that sprite type mostly determines what a sprite does to other sprites (keen in particular). And collision determines what happens to them when another sprite interacts with them (mostly keens and the tank bots shots).
Changing the sprite type
If we want to change what happens if a yorp touches you we can do so by giving it the same sprite type of another enemy. For example that of the garg. To do that we need a patch that does this. Let's take a look at the yorp patches page on the keen wiki. What we find is the following:
Quote:
Sprite Type
Yorps use sprite type 2 which means they push Keen about but don't hurt him, and if Keen lands on top of them, a stunned Yorp sprite is produced. Using any other sprite type means a Yorp cannot be stunned. There are some subtleties in the stunned behavior revealed in the behaviors section.
End Quote
#Yorp sprite type:
%patch $188B $02
We have a patch for the yorp with the value 2 (in hexadecimal). Note that just like the speed patches this doesn't do anything unless we change it to another value. So what value do we need to have the sprite type of the garg? Let's look at the garg page. We find:
#Garg sprite type:
%patch $184E $03
We have what we need here. So now we want to make the yorp kill like a garg and the garg push like a yorp. So let's give both the value of the other and test it.
#Yorp sprite type changed to 3
%patch $188B $03
#Garg sprite type changed to 2
%patch $184E $02
Let's put this in our patch file and run it. Run test1.bat of the mod version that is part of this chapter to test this.
Note that it works. The yorps now kill keen on touch and the gargs only push you. It may be very confusing to the player that the yorps now kill but remember that you can change the graphics into something that looks dangerous. You can also, such as in this tutorial, warn the player what will happen. It also helps if the player is introduced to the various enemies early in the game like in the beginning of the first level.
Notice with this patch that yorps and gargs still change into a dead yorp and garg respectively when shot. Because we only changed the property sprite type. What happen to them when they are shot is determined by their collision trait
Notice that our patch has a side effect. Because the gargs now push like yorps they also are stompable like yorps.
The fact that yorps being stompable is determined by their sprite type is an exception to the principle that the sprite type determines what a sprite does to other sprites. In this case the sprite type of the yorp determines both what can happen to them and what they can do to keen (push). Depending on how you look at it, the sprite type also could have been named collision. You could say that there are 2 kinds of collisions that interact.
When they are stomped they change into the stunned yorp animation. When they become unstomped they also turn back into a yorp instead of a garg. But notice that they do not become killing like the yorps that spawned as yorps!
It is not always obvious why patches work the way that they do. Testing them is important. It is probably the case that yorps or gargs get their traits (like the sprite type) assigned to them when they spawn in the level. When the garg gets stunned it uses the yorp’s stunned behavior routine that also changes them back into a yorp. But the trait that makes them push or kill, the sprite type, is assigned only in their initial spawn in the level. The same appears to be true for their collision trait. That is even if our gargs turn into a yorp when they become stunned if they die they spawn a dead garg.
We may be able to use this mechanic to make enemies other than the yorp stunnable in a way that makes sense. But for now we want to fix this bug. What we can do instead is give the gargs the pushing behavior of the butler robot instead.
the patch is:
#Butler Bot sprite type:
%patch $1782 $05
So we now put in our patch file:
#Yorp sprite type changed to 3
%patch $188B $03
#Garg sprite type changed to 5
%patch $184E $05
run test2 to test this
It now works bug free. The gargs push keen and cannot be stomped. The gargs can share this property with the butler robot without it affecting the butler robot itself. The garg is obviously less dangerous now but his charge could still be pretty dangerous when it can push you into danger tiles. A completely new type of gameplay could emerge from this if levels for it are made. And maybe you would want new graphics first for the gargs and yorps too.
The yorps and the gargs or butlers aren't the only enemies in keen 1. The others could be changed the same way. All of them could be given the traits of all others. Not all of the options work bug free initially such as the garg becoming a stunned yorp in the previous example. You could search the keen wiki for the other pages for the other spite types but they are also summarized on this page:
https://keenwiki.shikadi.net/wiki/Patch:Sprite_type
You find the existing sprite types that could be used.
Keen 1:
0 Don't appear
1 Keen (All sprites pass through sprite)
2 Yorp (when stood on becomes stomped Yorp)
3 Garg (Kill Keen)
4 Vorticon (Kill Keen, die when chain is shot)
5 Butler bot (Push Keen)
6 Tank bot (Push Keen, ignore enemy shot type sprite)
8 Chain (Shots hit sprite)
10 Keen's shot (Kill sprites that react to it)
11 Enemy shot (Kill enemies that react to it, and Keen.)
12 Icecubetter (Do nothing)
13 Zap-zot (Shots hit sprite)
14 Chain zap-zot (Same as 13)
15 Icecube (Freeze Keen)
However You might still want to find the page for the patch for how to change any particular enemy into another sprite type though.
A good example of what is possible is if you want to you could make any sprite such as the yorp freeze keen on touch. Whether this is a good idea depends on the type of mod you want to make. Also care would have to be taken to prevent keen from getting stuck indefinitely. Right now I will give an example of making the butler robot freeze keen. we need the patch from the butler robot page:
#Butler Bot sprite type:
%patch $1782 $05
and change it to sprite 15 (0F)
%patch $1782 $0F
There is one problem though. With this patch sprites with the sprite type of the ice cubes will disappear offscreen. Thus they will never appear unless spawned at the start of the level and then disappear as soon as they are out of sight.
I guess this is another example of how sprite types can affect more things than just what happens when they touch keen or other sprites.
Luckily a patch for this already exists. When we search the page for ice cubes we find:
https://keenwiki.shikadi.net/wiki/Patch:Icecubes
Quote:
Freeze-type sprites don't vanish when offscreen
This patch allows icecubes to continue existing even when offscreen; this means they can be more troublesome for Keen and is best used with the above patch. It also fixes the problem noted in the behavior section, where any sprite of type 15 vanishes when offscreen. This allows things like freezing Yorps.
#Existing freeze sprites continue existing even offscreen
%patch $3340 $83 $3E $20 $82 $09 $7C $13 $83 $3E $20 $82 $0F $74 $0C $90
End quote
thus we put this in our patch file
This can be tested with test3.bat
The freeze effect also pushes keen and makes him slide. Or rather you could say keen acquires the speed of the freezing sprite and as an icecube he will then slide. Depending on how the butler bots are placed, keen will or will not be at risk of being stuck indefinitely. Take care of this when designing your levels.
What we can also do is make the tank robot's shot freeze keen. This stops the tank from being able to kill yorps and gargs too. Shots will simply be blocked by them but they won't die.
It may not be obvious at first that yorps can still block tankbot bullets when they have the freezing sprite type but this is how it appears to work. My guess is that it is the yorps sprite type that determines the tank shot zap/zots into it. But it is only the tank shot's default sprite type or keen shot that makes the yorp "die". In this case the yorp still has the garg's sprite type. If a tank bot shoots a garg normally the bullet should also bounce off of him, or zap/zot, with the tankbot's default sprite type the garg would die at the same time.
The tank's shot is its own sprite with its own traits. There is a page for that as well on the keen wiki
https://keenwiki.shikadi.net/wiki/Patch ... ot_Patches
this patch:
#Tank shot sprite type:
%patch $48E9 [$0B]
can be changed to sprite type 15 as well as we did earlier:
#Tank shot sprite type changed to 15
%patch $48E9 $0F
Previously we added the patch for "Existing freeze sprites continue existing even offscreen"
Now that we gave this property to the tank's shot, leaving this in may sometimes give questionable results. But for now we will risk the possible bugs. But you may want to make a choice between having enemies that freeze on touch that don't disappear off screen. Or having the tank's bullets freeze but not using the patch that prevents sprites with the freeze property to disappear offscreen.
The previous patches can be tested with test3.bat
There are a few more things that can be done.
Another sprite type we could use is sprite number 8. It doesn't really do anything except block shots. So if we give that property to a yorp keen can walk right through him too. This seems like a useless waste of an enemy/npc. But the yorp could still be vulnerable to enemy shots as well as keen shots. And thus blocking those and affecting strategy.
Note that we could also use the zap/zot sprite property for this. However then they disappear when they are offscreen. But the chain will remain. You can also give a yorp or garg the property of keen's shot or the tanks shots. Unfortunately if you do this they will disappear when off screen just like an unpatched ice cube. Maybe this could be an interesting patch to request though. Particularly if it is done for the tank's shot and not keen's. Because you could leave the tank bot out of the mod or stop it from shooting to avoid complications. Or only let them shoot where their shots cannot go offscreen.
Test this with test4.bat
Smooth pushing
There is another patch I would like to mention here. There is a patch that makes the butler robots and tank bots push smoothly instead of jerky.
#Butler/Tank bots push keen smoothly
%patch $4646 $57 $56 $E8 $EB92W $59 $59 $B8 [$0002W] $EB [$41]
Quote
This path lets the Butler and Tank push Keen smoothly, like the Meep in Keen 3, rather then in jerks as they usually do. Here sound 2 is played on contact (While the bot is pushing Keen) to not play any sound, change the last byte ($41) to $47 (helpful if you don't like annoying noises.)
Endquote
We will be removing the pushing sound when using this patch:
%patch $4646 $57 $56 $E8 $EB92W $59 $59 $B8 $0002W $EB $47
It will affect the butler and tank bot or any sprite that has their sprite type. But not the yorp. Although it could be given to the yorp then they would lose the ability (or weakness) of being stompable. Right now the butler freezes keen but it will affect the tank bot. The gargs already use the butler's push trait so it will affect them too. This is actually more interesting I think, to have a charging garg push you in this way. It probably makes it less hard but that is not necessarily a bad thing. I think it also makes it look somewhat less buggy. that is in the case of when a garg pushes you while moving faster than pushing enemies normally do. Actually it may in some way make it harder. You cannot pass a blocking enemy that is walking in the same direction as you anymore by going through them. On the other hand if you are pushed you don't change direction automatically anymore. It is also no longer possible to "jump through" pushing enemies. Normally you can kind of glitch through yorps and butler bots when you make a little jump. It is even easier with the running garg but with the smooth pushing this appears no longer possible.
Test this with test5.bat
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod006
Re: I'm working on a new keen 1-3 modding tutorial
Chapter 7 Patching options for enemy traits. collision. Using neural stunner and changing text
In the previous chapter I talked about changing the sprite type of sprites/enemies/npcs. In this chapter I will explain the collision trait. By patching the collision trait of an enemy and giving it the trait originally belonging to another you can make it behave or react in the same way. So collision determines what happens if an enemy is shot by keen or the tank bot. For a yorp or garg this means spawning a dead yorp or garg (and disappearing themselves). But a butler robot and tank robot don't react to it at all, they are indestructible.
So one of the most meaningful examples of a change you could do is make a butler robot shootable and spawn a dead yorp. Or make one of the sprites that are originally shootable immortal or indestructible. Such as the yorp by giving it the collision trait of the butler robot or tank bot.
If you keep in mind the final product of a mod you might want to make, it might not make sense to have a yorp and a butler robot both spawn a dead yorp. But there could be some kind of explanation storywise or in the graphics that they look the same when dying/dead.
Another solution is that if you make the butler robot shootable by giving him the yorp dying animation, if you then make the yorp indestructible you can use the death animation of the yorp exclusively for the butler robot. If you change the graphics the player will have no idea. Or rather the player might understand how you patched it but it will make sense.
Another solution is to make the dying animation a sort of ball of fire and have the dead enemy be invisible and therefore disappear. That way multiple enemies can share the dying animation.
For now let's change the collision trait for a number of enemies and test it.
I want the garg, the butler robot, the tank bot and the vorticon all to share the collision trait belonging to the yorp. I already know this will have side effects especially on the tank bot but for now let's just test it.
First we must find the collision trait of the yorp.
https://keenwiki.shikadi.net/wiki/Patch:Yorp
what we find is this:
%patch $18D9 {$1A68W} #Yorp collision
%patch $1A74 $3D $0A #Yorp killed by Keen's shot
%patch $1A79 $3D $0B #Yorp killed by robot's shot
%patch $1A8F {$489DW} #Dead Yorp behavior
%patch $1A94 {$3360W} #Dead Yorp collision
%patch $1A99 [$FFB0] #Jump height when shot
It is a number of patches put together that I'm not sure of what each of them can do exactly. However for what we need we only need this:
%patch $18D9 {$1A68W} #Yorp collision
Just like with sprite type or speed this patch basically says: "Set the yorp collision to that of the yorp"
If we want to make changes we need a new value to set it to. What we wanted is to change the garg collision, so let's find the garg collision patch too.
https://keenwiki.shikadi.net/wiki/Patch:Garg
We find:
%patch $1876 {$1BCEW} #Garg collision
Based on the patches I saw about collision it seems to be associated with behavior but it seems to me to function more like a "trait" just like sprite type. If that makes any difference.
So let's give the garg the collision of the yorp with these 2 patches:
%patch $18D9 {$1A68W} #Yorp collision
%patch $1876 {$1BCEW} #Garg collision
combine them to make this patch:
%patch $1876 $1A68W #Set the Garg collision to that of a yorp
Remove the brackets also. I wanted to do the same with the butler robot, tank robot and vorticon. so we need the collision patch for these too, I found this:
%patch $17CB {$1E94W} #Butler Robot collision
%patch $176D {$2045W} #Tank Robot collision (Do nothing)
%patch $1808 {$1D6EW} #Vorticon collision
Changed them all to that of the yorp:
%patch $17CB $1A68W #Butler Robot collision changed to yorp
%patch $176D $1A68W #Tank Robot collision changed to yorp
%patch $1808 $1A68W #Vorticon collision changed to yorp
Now put the the 4 new patches into our patch file"
%patch $1876 $1A68W #Set the Garg collision to that of a yorp
%patch $17CB $1A68W #Butler Robot collision changed to yorp
%patch $176D $1A68W #Tank Robot collision changed to yorp
%patch $1808 $1A68W #Vorticon collision changed to yorp
Run test1 to test this
Note: I changed back all the changes to the sprite types demonstrated in the previous chapter. But they can be used together with these patches also.
All these sprites now spawn a dead yorp when shot. The butler robot works the best. It is now shootable. The garg works fine too but it is not as impressive that they only use another sprite and sound. The tank robot does not seem to work very well, when it shoots it dies from its own bullet now that it has the yorp collision. Let's see if we can fix that.
We can use this patch:
#robot's shots kill Keen but not other enemies
%patch $48E9 $04 $00
What it does is change the sprite type of the tank bot bullet and sets it to type 4. That of the vorticon. Vorticons do not kill yorps or other sprites when they touch (collide) but only keen.
Note that this may give a side effect because shots normally disappear off screen but vorticons do not. So a tankbot may shoot right and disappear but be "remembered" if keen takes a long way round he might find it again. You could avoid this bug by placing only tank bots that can't shoot off screen or atleast build the level so that you can't go to that place from the other direction. (I’m at this point not sure if this kind of side effect is more than rarely noticeable)
If you are confused about the extra zero's they do not need to be there and could be removed.
#robot's shots kill Keen but not other enemies
%patch $48E9 $04
We also may have noticed that the vorticon with the sprite collision only takes one shot. Maybe we should try giving the yorp the vorticon collision. let's take these 2 patches:
%patch $1808 {$1D6EW} #Vorticon collision
%patch $18D9 {$1A68W} #Yorp collision
and combine them into this:
%patch $18D9 $1D6EW #Yorp collision set to that of the vorticon.
Let's make a new test patch file with these 2 patches added:
#robot's shots kill Keen but not other enemies
%patch $48E9 $04
#Yorp collision set to that of the vorticon.
%patch $18D9 $1D6EW
And run test2 to test it.
As you can see the tankbot no longer dies everytime it shoots. It could be considered a more fun enemy now that it is no longer invulnerable.
The yorp now spawns a dead vorticon when shot. However it does not take 4 shots as a vorticon normally does. Not sure how this works exactly but having a strength, like taking 4 shots is probably the result of both the collision trait and some other traits of the vorticon.
It seems that only the vorticon can have a strength of more than one in keen 1. But maybe if we wanted a yorp that takes 4 shots or more it might still be possible somehow in a slightly more complicated way involving the enemy behavior.
Some of the enemies now spawn death animations that fall into the ground. This is because the hitbox of the dying animation they now use is larger than they are. But this can be fixed by changing the size of the bitmap that sprite uses to make it compatible.
Note that you can have more options for changing sprite collision than I have talked about here. There is a page on the keen wiki that has a list.
https://keenwiki.shikadi.net/wiki/Patch ... _collision
Keen 1:
$1A68W #Yorp collision
$1BCEW #Garg collision
$1D6EW #Vorticon collision
$1E94W #Butler Bot collision (Shots hit, keeps going)
$2045W #Tank Bot collision (Shots hit, keeps going)
$22A6W #Icecube collision
$22BBW #Chain collision (Make falling block)
$3360W #Do nothing
$47E8W #Sit and vanish (Zap\zot)
$4849W #Zap against not-Keen sprites (Keen's shot)
$4A00W #Tank bot's shot
But you might still want to find the page for each of the enemies/sprites to find the patch to change that sprite into another collision.
Some of the options available may not exactly work bug free. One of the more interesting options is giving a sprite the collision of the Chain. As described it will produce a falling block on the location of the sprite. Maybe there is a way to use that that makes sense.
The Neural Stunner
I want to mention another keen modding tool that you can use and that I recommend. It's called the neural stunner by Mink. You can download it on the keen wiki. I may not have tried all of its features but from what I have, it seems to work well and is not hard to use. If you run it you have to choose the episode, so choose keen1. Now click on sprite properties. The sprite option decides for what sprite the patch is for. For this example choose Yorp. Property refers to sprite type as we talked about earlier, it gets set to the default yorp sprite type by default, leave this. The “when shot” option refers to collision, set this to spawn a dead vorticon. The application generates a patch for us that we put in our own patch file. This is what we get:
#Yorp properties
%patch $188B $02 $00 #Push Keen, make a stomped Yorp when stomped (Yorp)
%patch $18D9 $6E $1D #Create shot Vorticon (Vorticon)
The first part does not change anything as it is but it is similar to what we found on the yorp patch page:
#Yorp sprite type:
%patch $188B $02
The neural stunner gives us two extra zeros. But the patch does the same.
%patch $188B $02
is the same as:
%patch $188B $02 $00
Which should also be the same as $0002W apparently
.
Let's look at the second part
%patch $18D9 $6E $1D #Create shot Vorticon (Vorticon)
and compare it to the patch I recombined earlier
%patch $18D9 $1D6EW #Yorp collision set to that of the vorticon.
It should do the same and it also almost looks the same.
$6E $1D is just an alternative way to write $1D6EW apparently. Note how the first 2 digits get reversed. If you ask me $1D6EW is less confusing. Which is just the number 1D6E (7534 in hex). The other way involves reversing the position of the first 2 and last 2 digits. It may be slightly more convenient when it is a number of less than 2 digits and the second 2 zero's can be omitted this way and are.
Anyway, despite having a slightly different format we can see that the neural stunner can generate these types of patches for us automatically. And it is much easier. So why did I even bother to explain how to do it in the first way? I guess the reason could be that this way you know how to change values in patches "manually" so that you also can experiment with patches that are not automated with a program like neural stunner.
By the way if someone wanted to make another program like neural stunner or update it. It might also be a good idea to make a way to automatically generate the patches that change the speed of sprites too.
I'm just saying an app could be made to automate that too. But if you know how to do it manually then that's just a nice to have.
But since we have neural stunner it is quite useful to patch collision and sprite type. And also it works well for making text patches.
Changing the texts in keen
Aside from changing the texts in the external text files STORYTXT.ck1, HELPTEXT.ck1 and ENDTEXT.ck1. Changing the texts in keen 1 requires patching.
A way to do it is by searching the patches pages in the keen wiki. For example the yorp messages we find here:
https://keenwiki.shikadi.net/wiki/Patch:Yorp_Messages
We can for instance find:
#First Yorp message: (Level 2) -7 lines
%patch $15080 "You hear in your " $0A $00
%patch $15096 "mind: " $0A $00
%patch $150AC " " $0A $00
%patch $150C2 "It is too bad that " $0A $00
%patch $150D8 "you cannot read the " $0A $00
%patch $150EE "Standard Galactic " $0A $00
%patch $15104 "Alphabet, Human. " $0A $00
We can change this into our own message, however we need to use the exact same number of characters including the "space" characters. This can be tedious. So let's just change one word to test it.
%patch $15104 "Alphabet, keen. " $0A $00
I changed human to keen. But because keen is one fewer character I also added an extra "space" character after it.
Let's test this in test3.bat
It's doable this way but the neural stunner app makes this much easier. Just click hints. then select level2. you see the old message you replace. You can see how many characters each line has and you can just type. Okay I will make a new message.
#Hint level 2
%patch $15080 "You hear in your "
%patch $15096 "mind: "
%patch $150AC "Hello keen. Mortimer"
%patch $150C2 "here. I'm still "
%patch $150D8 "alive and the "
%patch $150EE "vorticons are still "
%patch $15104 "under my control. "
Run test4.bat to test this.
Okay, I couldn't come up with something better. You are still limited in the amount of characters, but using neural stunner is much easier than doing it more manually. So I definitely recommend using that. Just like with the sprite types and collision it also saves you from having to find the relevant patches on the keen wiki or wherever else.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod007
In the previous chapter I talked about changing the sprite type of sprites/enemies/npcs. In this chapter I will explain the collision trait. By patching the collision trait of an enemy and giving it the trait originally belonging to another you can make it behave or react in the same way. So collision determines what happens if an enemy is shot by keen or the tank bot. For a yorp or garg this means spawning a dead yorp or garg (and disappearing themselves). But a butler robot and tank robot don't react to it at all, they are indestructible.
So one of the most meaningful examples of a change you could do is make a butler robot shootable and spawn a dead yorp. Or make one of the sprites that are originally shootable immortal or indestructible. Such as the yorp by giving it the collision trait of the butler robot or tank bot.
If you keep in mind the final product of a mod you might want to make, it might not make sense to have a yorp and a butler robot both spawn a dead yorp. But there could be some kind of explanation storywise or in the graphics that they look the same when dying/dead.
Another solution is that if you make the butler robot shootable by giving him the yorp dying animation, if you then make the yorp indestructible you can use the death animation of the yorp exclusively for the butler robot. If you change the graphics the player will have no idea. Or rather the player might understand how you patched it but it will make sense.
Another solution is to make the dying animation a sort of ball of fire and have the dead enemy be invisible and therefore disappear. That way multiple enemies can share the dying animation.
For now let's change the collision trait for a number of enemies and test it.
I want the garg, the butler robot, the tank bot and the vorticon all to share the collision trait belonging to the yorp. I already know this will have side effects especially on the tank bot but for now let's just test it.
First we must find the collision trait of the yorp.
https://keenwiki.shikadi.net/wiki/Patch:Yorp
what we find is this:
%patch $18D9 {$1A68W} #Yorp collision
%patch $1A74 $3D $0A #Yorp killed by Keen's shot
%patch $1A79 $3D $0B #Yorp killed by robot's shot
%patch $1A8F {$489DW} #Dead Yorp behavior
%patch $1A94 {$3360W} #Dead Yorp collision
%patch $1A99 [$FFB0] #Jump height when shot
It is a number of patches put together that I'm not sure of what each of them can do exactly. However for what we need we only need this:
%patch $18D9 {$1A68W} #Yorp collision
Just like with sprite type or speed this patch basically says: "Set the yorp collision to that of the yorp"
If we want to make changes we need a new value to set it to. What we wanted is to change the garg collision, so let's find the garg collision patch too.
https://keenwiki.shikadi.net/wiki/Patch:Garg
We find:
%patch $1876 {$1BCEW} #Garg collision
Based on the patches I saw about collision it seems to be associated with behavior but it seems to me to function more like a "trait" just like sprite type. If that makes any difference.
So let's give the garg the collision of the yorp with these 2 patches:
%patch $18D9 {$1A68W} #Yorp collision
%patch $1876 {$1BCEW} #Garg collision
combine them to make this patch:
%patch $1876 $1A68W #Set the Garg collision to that of a yorp
Remove the brackets also. I wanted to do the same with the butler robot, tank robot and vorticon. so we need the collision patch for these too, I found this:
%patch $17CB {$1E94W} #Butler Robot collision
%patch $176D {$2045W} #Tank Robot collision (Do nothing)
%patch $1808 {$1D6EW} #Vorticon collision
Changed them all to that of the yorp:
%patch $17CB $1A68W #Butler Robot collision changed to yorp
%patch $176D $1A68W #Tank Robot collision changed to yorp
%patch $1808 $1A68W #Vorticon collision changed to yorp
Now put the the 4 new patches into our patch file"
%patch $1876 $1A68W #Set the Garg collision to that of a yorp
%patch $17CB $1A68W #Butler Robot collision changed to yorp
%patch $176D $1A68W #Tank Robot collision changed to yorp
%patch $1808 $1A68W #Vorticon collision changed to yorp
Run test1 to test this
Note: I changed back all the changes to the sprite types demonstrated in the previous chapter. But they can be used together with these patches also.
All these sprites now spawn a dead yorp when shot. The butler robot works the best. It is now shootable. The garg works fine too but it is not as impressive that they only use another sprite and sound. The tank robot does not seem to work very well, when it shoots it dies from its own bullet now that it has the yorp collision. Let's see if we can fix that.
We can use this patch:
#robot's shots kill Keen but not other enemies
%patch $48E9 $04 $00
What it does is change the sprite type of the tank bot bullet and sets it to type 4. That of the vorticon. Vorticons do not kill yorps or other sprites when they touch (collide) but only keen.
Note that this may give a side effect because shots normally disappear off screen but vorticons do not. So a tankbot may shoot right and disappear but be "remembered" if keen takes a long way round he might find it again. You could avoid this bug by placing only tank bots that can't shoot off screen or atleast build the level so that you can't go to that place from the other direction. (I’m at this point not sure if this kind of side effect is more than rarely noticeable)
If you are confused about the extra zero's they do not need to be there and could be removed.
#robot's shots kill Keen but not other enemies
%patch $48E9 $04
We also may have noticed that the vorticon with the sprite collision only takes one shot. Maybe we should try giving the yorp the vorticon collision. let's take these 2 patches:
%patch $1808 {$1D6EW} #Vorticon collision
%patch $18D9 {$1A68W} #Yorp collision
and combine them into this:
%patch $18D9 $1D6EW #Yorp collision set to that of the vorticon.
Let's make a new test patch file with these 2 patches added:
#robot's shots kill Keen but not other enemies
%patch $48E9 $04
#Yorp collision set to that of the vorticon.
%patch $18D9 $1D6EW
And run test2 to test it.
As you can see the tankbot no longer dies everytime it shoots. It could be considered a more fun enemy now that it is no longer invulnerable.
The yorp now spawns a dead vorticon when shot. However it does not take 4 shots as a vorticon normally does. Not sure how this works exactly but having a strength, like taking 4 shots is probably the result of both the collision trait and some other traits of the vorticon.
It seems that only the vorticon can have a strength of more than one in keen 1. But maybe if we wanted a yorp that takes 4 shots or more it might still be possible somehow in a slightly more complicated way involving the enemy behavior.
Some of the enemies now spawn death animations that fall into the ground. This is because the hitbox of the dying animation they now use is larger than they are. But this can be fixed by changing the size of the bitmap that sprite uses to make it compatible.
Note that you can have more options for changing sprite collision than I have talked about here. There is a page on the keen wiki that has a list.
https://keenwiki.shikadi.net/wiki/Patch ... _collision
Keen 1:
$1A68W #Yorp collision
$1BCEW #Garg collision
$1D6EW #Vorticon collision
$1E94W #Butler Bot collision (Shots hit, keeps going)
$2045W #Tank Bot collision (Shots hit, keeps going)
$22A6W #Icecube collision
$22BBW #Chain collision (Make falling block)
$3360W #Do nothing
$47E8W #Sit and vanish (Zap\zot)
$4849W #Zap against not-Keen sprites (Keen's shot)
$4A00W #Tank bot's shot
But you might still want to find the page for each of the enemies/sprites to find the patch to change that sprite into another collision.
Some of the options available may not exactly work bug free. One of the more interesting options is giving a sprite the collision of the Chain. As described it will produce a falling block on the location of the sprite. Maybe there is a way to use that that makes sense.
The Neural Stunner
I want to mention another keen modding tool that you can use and that I recommend. It's called the neural stunner by Mink. You can download it on the keen wiki. I may not have tried all of its features but from what I have, it seems to work well and is not hard to use. If you run it you have to choose the episode, so choose keen1. Now click on sprite properties. The sprite option decides for what sprite the patch is for. For this example choose Yorp. Property refers to sprite type as we talked about earlier, it gets set to the default yorp sprite type by default, leave this. The “when shot” option refers to collision, set this to spawn a dead vorticon. The application generates a patch for us that we put in our own patch file. This is what we get:
#Yorp properties
%patch $188B $02 $00 #Push Keen, make a stomped Yorp when stomped (Yorp)
%patch $18D9 $6E $1D #Create shot Vorticon (Vorticon)
The first part does not change anything as it is but it is similar to what we found on the yorp patch page:
#Yorp sprite type:
%patch $188B $02
The neural stunner gives us two extra zeros. But the patch does the same.
%patch $188B $02
is the same as:
%patch $188B $02 $00
Which should also be the same as $0002W apparently
.
Let's look at the second part
%patch $18D9 $6E $1D #Create shot Vorticon (Vorticon)
and compare it to the patch I recombined earlier
%patch $18D9 $1D6EW #Yorp collision set to that of the vorticon.
It should do the same and it also almost looks the same.
$6E $1D is just an alternative way to write $1D6EW apparently. Note how the first 2 digits get reversed. If you ask me $1D6EW is less confusing. Which is just the number 1D6E (7534 in hex). The other way involves reversing the position of the first 2 and last 2 digits. It may be slightly more convenient when it is a number of less than 2 digits and the second 2 zero's can be omitted this way and are.
Anyway, despite having a slightly different format we can see that the neural stunner can generate these types of patches for us automatically. And it is much easier. So why did I even bother to explain how to do it in the first way? I guess the reason could be that this way you know how to change values in patches "manually" so that you also can experiment with patches that are not automated with a program like neural stunner.
By the way if someone wanted to make another program like neural stunner or update it. It might also be a good idea to make a way to automatically generate the patches that change the speed of sprites too.
I'm just saying an app could be made to automate that too. But if you know how to do it manually then that's just a nice to have.
But since we have neural stunner it is quite useful to patch collision and sprite type. And also it works well for making text patches.
Changing the texts in keen
Aside from changing the texts in the external text files STORYTXT.ck1, HELPTEXT.ck1 and ENDTEXT.ck1. Changing the texts in keen 1 requires patching.
A way to do it is by searching the patches pages in the keen wiki. For example the yorp messages we find here:
https://keenwiki.shikadi.net/wiki/Patch:Yorp_Messages
We can for instance find:
#First Yorp message: (Level 2) -7 lines
%patch $15080 "You hear in your " $0A $00
%patch $15096 "mind: " $0A $00
%patch $150AC " " $0A $00
%patch $150C2 "It is too bad that " $0A $00
%patch $150D8 "you cannot read the " $0A $00
%patch $150EE "Standard Galactic " $0A $00
%patch $15104 "Alphabet, Human. " $0A $00
We can change this into our own message, however we need to use the exact same number of characters including the "space" characters. This can be tedious. So let's just change one word to test it.
%patch $15104 "Alphabet, keen. " $0A $00
I changed human to keen. But because keen is one fewer character I also added an extra "space" character after it.
Let's test this in test3.bat
It's doable this way but the neural stunner app makes this much easier. Just click hints. then select level2. you see the old message you replace. You can see how many characters each line has and you can just type. Okay I will make a new message.
#Hint level 2
%patch $15080 "You hear in your "
%patch $15096 "mind: "
%patch $150AC "Hello keen. Mortimer"
%patch $150C2 "here. I'm still "
%patch $150D8 "alive and the "
%patch $150EE "vorticons are still "
%patch $15104 "under my control. "
Run test4.bat to test this.
Okay, I couldn't come up with something better. You are still limited in the amount of characters, but using neural stunner is much easier than doing it more manually. So I definitely recommend using that. Just like with the sprite types and collision it also saves you from having to find the relevant patches on the keen wiki or wherever else.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod007
Re: I'm working on a new keen 1-3 modding tutorial
Chapter 8 Patching enemy behavior.
In this chapter I will give some examples of what you can do with patching enemy behavior. Enemy behavior is relatively complex. And even if it is not that complex, figuring out how it works is not always simple. However there are a couple of key points where you can make impactful changes.
Enemies start with a behavior. Behaviors generally are cyclical. In the case of the yorp they will walk, search and walk again. They go from one behavior to another but they always go back to the beginning. Icecubes on the other hand do not cycle or loop that way but disappear at the end of their cycle, but most of the sprites have a cycle.
One thing worth noting may be that sprites can use behaviors that originally belong to other sprites. Temporarily or permanently. In the case of the garg with the sprite type of a yorp, when stunned it changed to the behavior routine of the yorp. Once it is there it continues to use it because the yorp routine just keeps cycling to other yorp behaviors. More specifically, a stunned yorp changes back into an unstunned yorp.
Sprites have a behavior that they start with. Then they generally stay in that behavior loop. But it is possible to have a sprite use the behavior routine of another sprite. Then they behave and look exactly as the sprite they borrowed their behavior from.
You may be confused as to why that might be useful. Previously we found out that you cannot give other enemies the -take 4 shots to kill- trait that the vorticon has. What if we wanted a Yorp that takes 4 shots to kill instead of the vorticon? What we could try is giving the vorticon the yorp behavior. Then we give the yorp the behavior of the vorticon so the vorticon isn't wasted but instead now takes 1 shot to kill.
The yorp and Vorticon page on the keen wiki have a part about sprite behavior and a patch for "when spawned"
https://keenwiki.shikadi.net/wiki/Patch:Yorp
https://keenwiki.shikadi.net/wiki/Patch ... n_(Keen_1)
#vorticon when spawned:
#%patch $1803 {$1C0EW}
#yorp when spawned:
#%patch $18B4 {$194FW}
Just like the patches for sprite type and collision. This says "set the Yorp behavior of the yorp to that of the yorp when spawning in the level" And the same for the vorticon.
Now reverse it:
# vorticon behaves as yorp
%patch $1803 $194FW
# yorp behaves as vorticon
%patch $18B4 $1C0EW
Run test1.bat to test this.
If you didn't realise what happened, the vorticon now behaves (and looks) like a yorp. It does still kill you and spawns a dead vorticon. But if we want to we can make it not kill by changing the sprite type as explained previously.
Stunnable vorticon
The yorp now behaves like the vorticon and pushes rather than kills. Also he is once again stompable.
We have another side effect similar to what we had before. if we stun the yorp that acts like a vorticon, it goes back to the yorp routine and never goes back to the vorticon behavior that we gave it.
But what if we wanted to make a stunnable vorticon, or rather a stunnable sprite that behaves like a vorticon without that side effect?
We could take a look at the patch for the behavior of the yorp
https://keenwiki.shikadi.net/wiki/Patch:Yorp
When spawned
%patch $18B4 {$194FW}
In level
%patch $1A22 {$194FW} #After looking for Keen
%patch $1980 {$19D3W} #Do this randomly when walking
%patch $1A58 {$19D3W} #After being stunned
%patch $45E5 {$1A2CW} #This behavior of type-2 sprite not stompable
$75
%patch $462A {$1A2CW} #What Yorp becomes when stunned
%patch $4D9C {$1A2CW} #If offscreen and using this behavior then...
%patch $4DA4 {$19D3W} #...become this
%patch $18D9 {$1A68W} #Yorp collision
This seems to be the yorp routine that it keeps cycling through. You can see that when spawned the value is $194FW. The same value is used "After looking for Keen". There are all kinds of things you could tweak here. For now take a look at "After being stunned" not to be confused with "What Yorp becomes when stunned". I know that normally the yorp starts searching or looking after being stunned. They also do this randomly. That's why the line above "Do this randomly when walking" leads to the same value $19D3W.
So this is what the program does when a yorp that is stunned turns back into an awake yorp.
But what if we want to have a vorticon be stunnable? What if we could change it (back) into a vorticon. We need to learn one of the vorticon behaviors for this. We take this part of the patch:
%patch $1A58 {$19D3W} #After being stunned
Actually we also need to do the same with this:
%patch $4DA4 {$19D3W} #...become this
As this is the same thing but this is what happens when the yorp is stunned offscreen
We now need one of the vorticon behaviors from the vorticon routine to make the stunned yorp a vorticon again. Let's see what options we have:
https://keenwiki.shikadi.net/wiki/Patch ... n_(Keen_1)
Vorticon behaviors:
%patch $1C5A {$1CC8W} #Randomly used to make 'high' jumps
%patch $1CF2 {$1D15W} #After jumping high
%patch $1A58 {$1C0EW} #After 'looking' for Keen
I think that all these 3 might work. but the "after jumping high" is probably the best. Because I think that after jumping high and landing the vorticon does a little search for keen routine just like the yorp and garg and it would fit well after waking up from being stunned.
So let's make:
%patch $1A58 $1D15W #Yorp after being stunned becomes a vorticon instead of yorp
and
%patch $4DA4 $1D15W #Yorp after being stunned and off screen becomes a vorticon instead of yorp
run test2.bat to test this.
As we have seen before, the sprite size of the vorticon is larger than the yorp. Therefore when the stunned yorp changes into a vorticon it glitches into the ground. This can be fixed by changing the size of the bitmaps used.
patch experiment: charging vorticon
As mentioned, sprites can use the routine of other sprites if they are set to their behavior or if something like being stunned morphs them into that behavior routine.
But something you can do is make sprites transform to another sprite’s routine as a part of their primary routine.
Then when they have the other sprite routine they can, at some point change back. And they will cycle back and forth between those 2 routines
Obviously if you do that these 2 sprites behave the same way apart from other sprite traits such as sprite type and collision
But basically you have to use 2 enemies to make one new one. You don't necessarily want to do that for every mod. But it is something you could do if you think having one fewer enemy type is worth it.
One example of what could be done is make the vorticon change into a searching garg every now and then. Make it charge (only if it sees keen, normally). then at some point turn back into a vorticon.
Therefore it will mostly behave like a regular vorticon but every now and then it will charge at keen, like a garg.
Therefore you lose the garg as an enemy but have a more dangerous vorticon. First let's look at the vorticon behaviors. we use this:
%patch $1CF2 {$1D15W} #After jumping high (vorticon)
and combine it with this
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking
into this:
%patch $1CF2 $1B51W #After jumping high (vorticon) set to #Look for Keen after charging into walls, randomly during walking (garg)
Then to change it back at some point after the garg charged use this:
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking (garg)
and combine it with this:
%patch $1CF2 {$1D15W} #After jumping high
into this:
%patch $1AD0 $1D15W #Look for Keen after charging into walls, randomly during walking (garg) set to #After jumping high (vorticon)
run test3.bat to test this.
patch experiment: keen becomes a charging garg
I know there have been some mods where the player character is replaced by another keen character or creature such as a yorp or garg. Although I generally prefer mods where keen or someone similar to keen is the player character, this can be quite fun too. So I had the idea of trying to change keen into a charging garg temporarily. Maybe make it so that you can't jump as high without a charge.
When keen shoots and then goes back to a normal standing keen. That's where I want him to change into a charging garg. The fun part is that you actually lose control in that moment. then not long after hitting a wall the garg could change back into keen.
we find on this page:
https://keenwiki.shikadi.net/wiki/Patch ... Vorticons)
#Keen's shooting behavior code
%patch $3E12 $55 $8B $EC $A1 $824AW $03 $06 $5B14W $A3 $824AW $83 $3E {$824CW}
[$00] {$75} $40 $3D [$0001W] {$7E} $3B $83 $3E {$AAC8W} [$00] {$74} $25
$B8 [$000CW] $50 $E8 $80BAW $44 $44 $FF $0E {$AAC8W} $FF $36 $822AW
$FF $36 $8228W $FF $36 $8226W $FF $36 $24 $82 $E8 $0868W
$83 $C4 $08 $EB $09 $B8 [$0024W] $50 $E8 $8095W $44 $44 $C7 $06
{$824CW} [$0001W] $83 $3E {$824AW} [$1E] {$7E} $14 $83 $3E {$7FCCW} [$00]
{$75} $0D $83 $3E {$7FCEW} [$00] {$75} $06 $C7 $06 $8252W {$3867W} $83
$3E {$8240W} [$00] {$7E} $18 $B8 [$FFFFW] $50 $E8 $ED0BW $44 $44 $83
$3E {$8240W} [$00] {$7D} $25 $C7 $06 {$8240W} [$0000W] $EB $1D $83 $3E
{$8240W} [$00] {$7D} $16 $B8 [$0001W] $50 $E8 $ECECW $44 $44 $83 $3E
{$8240W} [$00] {$7E} $06 $C7 $06 {$8240W} [$0000W] $E8 $ED6AW $E8
$EDAAW $E8 $F49FW $5D $C3
we see in the patch description: If they are, nothing happens otherwise Keen returns to standing (Behavior $3867W).
So that is what we want to change into the charging garg.
from this patch:
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking(garg)
take $1B51W and put it into the patch above replacing the $3867W
Then to change keen back we also use this patch:
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking
and change it into $3867W. $3867W was mentioned before to change back into standing keen:
%patch $1AD0 $3867W #Look for Keen after charging into walls, randomly during walking. changed into keen returns to standing
we also want to add this patch:
#Gargs anywhere will charge toward Keen after looking around
%patch $1B93 $90 $90 $90 $90 $90 $90
So that keen will actually charge.
Keen will fall into the ground when shooting because of the different hitbox sizes so to really test it jump shoot and release before landing so you can make the garg properly charge.
Notice a weird side effect also, the gargs now change into keen (predictably) you can then actually control them.
Keen only has a single bullet now. It must be because the shooting patch is incompatible with the infinite ammo patch. we don't really need keen to shoot here but even so, this is probably the reason
The way it is now the garg always seems to charge right. I am not sure if there is a way to fix that or how.
run test4.bat to test this.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod008
In this chapter I will give some examples of what you can do with patching enemy behavior. Enemy behavior is relatively complex. And even if it is not that complex, figuring out how it works is not always simple. However there are a couple of key points where you can make impactful changes.
Enemies start with a behavior. Behaviors generally are cyclical. In the case of the yorp they will walk, search and walk again. They go from one behavior to another but they always go back to the beginning. Icecubes on the other hand do not cycle or loop that way but disappear at the end of their cycle, but most of the sprites have a cycle.
One thing worth noting may be that sprites can use behaviors that originally belong to other sprites. Temporarily or permanently. In the case of the garg with the sprite type of a yorp, when stunned it changed to the behavior routine of the yorp. Once it is there it continues to use it because the yorp routine just keeps cycling to other yorp behaviors. More specifically, a stunned yorp changes back into an unstunned yorp.
Sprites have a behavior that they start with. Then they generally stay in that behavior loop. But it is possible to have a sprite use the behavior routine of another sprite. Then they behave and look exactly as the sprite they borrowed their behavior from.
You may be confused as to why that might be useful. Previously we found out that you cannot give other enemies the -take 4 shots to kill- trait that the vorticon has. What if we wanted a Yorp that takes 4 shots to kill instead of the vorticon? What we could try is giving the vorticon the yorp behavior. Then we give the yorp the behavior of the vorticon so the vorticon isn't wasted but instead now takes 1 shot to kill.
The yorp and Vorticon page on the keen wiki have a part about sprite behavior and a patch for "when spawned"
https://keenwiki.shikadi.net/wiki/Patch:Yorp
https://keenwiki.shikadi.net/wiki/Patch ... n_(Keen_1)
#vorticon when spawned:
#%patch $1803 {$1C0EW}
#yorp when spawned:
#%patch $18B4 {$194FW}
Just like the patches for sprite type and collision. This says "set the Yorp behavior of the yorp to that of the yorp when spawning in the level" And the same for the vorticon.
Now reverse it:
# vorticon behaves as yorp
%patch $1803 $194FW
# yorp behaves as vorticon
%patch $18B4 $1C0EW
Run test1.bat to test this.
If you didn't realise what happened, the vorticon now behaves (and looks) like a yorp. It does still kill you and spawns a dead vorticon. But if we want to we can make it not kill by changing the sprite type as explained previously.
Stunnable vorticon
The yorp now behaves like the vorticon and pushes rather than kills. Also he is once again stompable.
We have another side effect similar to what we had before. if we stun the yorp that acts like a vorticon, it goes back to the yorp routine and never goes back to the vorticon behavior that we gave it.
But what if we wanted to make a stunnable vorticon, or rather a stunnable sprite that behaves like a vorticon without that side effect?
We could take a look at the patch for the behavior of the yorp
https://keenwiki.shikadi.net/wiki/Patch:Yorp
When spawned
%patch $18B4 {$194FW}
In level
%patch $1A22 {$194FW} #After looking for Keen
%patch $1980 {$19D3W} #Do this randomly when walking
%patch $1A58 {$19D3W} #After being stunned
%patch $45E5 {$1A2CW} #This behavior of type-2 sprite not stompable
$75
%patch $462A {$1A2CW} #What Yorp becomes when stunned
%patch $4D9C {$1A2CW} #If offscreen and using this behavior then...
%patch $4DA4 {$19D3W} #...become this
%patch $18D9 {$1A68W} #Yorp collision
This seems to be the yorp routine that it keeps cycling through. You can see that when spawned the value is $194FW. The same value is used "After looking for Keen". There are all kinds of things you could tweak here. For now take a look at "After being stunned" not to be confused with "What Yorp becomes when stunned". I know that normally the yorp starts searching or looking after being stunned. They also do this randomly. That's why the line above "Do this randomly when walking" leads to the same value $19D3W.
So this is what the program does when a yorp that is stunned turns back into an awake yorp.
But what if we want to have a vorticon be stunnable? What if we could change it (back) into a vorticon. We need to learn one of the vorticon behaviors for this. We take this part of the patch:
%patch $1A58 {$19D3W} #After being stunned
Actually we also need to do the same with this:
%patch $4DA4 {$19D3W} #...become this
As this is the same thing but this is what happens when the yorp is stunned offscreen
We now need one of the vorticon behaviors from the vorticon routine to make the stunned yorp a vorticon again. Let's see what options we have:
https://keenwiki.shikadi.net/wiki/Patch ... n_(Keen_1)
Vorticon behaviors:
%patch $1C5A {$1CC8W} #Randomly used to make 'high' jumps
%patch $1CF2 {$1D15W} #After jumping high
%patch $1A58 {$1C0EW} #After 'looking' for Keen
I think that all these 3 might work. but the "after jumping high" is probably the best. Because I think that after jumping high and landing the vorticon does a little search for keen routine just like the yorp and garg and it would fit well after waking up from being stunned.
So let's make:
%patch $1A58 $1D15W #Yorp after being stunned becomes a vorticon instead of yorp
and
%patch $4DA4 $1D15W #Yorp after being stunned and off screen becomes a vorticon instead of yorp
run test2.bat to test this.
As we have seen before, the sprite size of the vorticon is larger than the yorp. Therefore when the stunned yorp changes into a vorticon it glitches into the ground. This can be fixed by changing the size of the bitmaps used.
patch experiment: charging vorticon
As mentioned, sprites can use the routine of other sprites if they are set to their behavior or if something like being stunned morphs them into that behavior routine.
But something you can do is make sprites transform to another sprite’s routine as a part of their primary routine.
Then when they have the other sprite routine they can, at some point change back. And they will cycle back and forth between those 2 routines
Obviously if you do that these 2 sprites behave the same way apart from other sprite traits such as sprite type and collision
But basically you have to use 2 enemies to make one new one. You don't necessarily want to do that for every mod. But it is something you could do if you think having one fewer enemy type is worth it.
One example of what could be done is make the vorticon change into a searching garg every now and then. Make it charge (only if it sees keen, normally). then at some point turn back into a vorticon.
Therefore it will mostly behave like a regular vorticon but every now and then it will charge at keen, like a garg.
Therefore you lose the garg as an enemy but have a more dangerous vorticon. First let's look at the vorticon behaviors. we use this:
%patch $1CF2 {$1D15W} #After jumping high (vorticon)
and combine it with this
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking
into this:
%patch $1CF2 $1B51W #After jumping high (vorticon) set to #Look for Keen after charging into walls, randomly during walking (garg)
Then to change it back at some point after the garg charged use this:
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking (garg)
and combine it with this:
%patch $1CF2 {$1D15W} #After jumping high
into this:
%patch $1AD0 $1D15W #Look for Keen after charging into walls, randomly during walking (garg) set to #After jumping high (vorticon)
run test3.bat to test this.
patch experiment: keen becomes a charging garg
I know there have been some mods where the player character is replaced by another keen character or creature such as a yorp or garg. Although I generally prefer mods where keen or someone similar to keen is the player character, this can be quite fun too. So I had the idea of trying to change keen into a charging garg temporarily. Maybe make it so that you can't jump as high without a charge.
When keen shoots and then goes back to a normal standing keen. That's where I want him to change into a charging garg. The fun part is that you actually lose control in that moment. then not long after hitting a wall the garg could change back into keen.
we find on this page:
https://keenwiki.shikadi.net/wiki/Patch ... Vorticons)
#Keen's shooting behavior code
%patch $3E12 $55 $8B $EC $A1 $824AW $03 $06 $5B14W $A3 $824AW $83 $3E {$824CW}
[$00] {$75} $40 $3D [$0001W] {$7E} $3B $83 $3E {$AAC8W} [$00] {$74} $25
$B8 [$000CW] $50 $E8 $80BAW $44 $44 $FF $0E {$AAC8W} $FF $36 $822AW
$FF $36 $8228W $FF $36 $8226W $FF $36 $24 $82 $E8 $0868W
$83 $C4 $08 $EB $09 $B8 [$0024W] $50 $E8 $8095W $44 $44 $C7 $06
{$824CW} [$0001W] $83 $3E {$824AW} [$1E] {$7E} $14 $83 $3E {$7FCCW} [$00]
{$75} $0D $83 $3E {$7FCEW} [$00] {$75} $06 $C7 $06 $8252W {$3867W} $83
$3E {$8240W} [$00] {$7E} $18 $B8 [$FFFFW] $50 $E8 $ED0BW $44 $44 $83
$3E {$8240W} [$00] {$7D} $25 $C7 $06 {$8240W} [$0000W] $EB $1D $83 $3E
{$8240W} [$00] {$7D} $16 $B8 [$0001W] $50 $E8 $ECECW $44 $44 $83 $3E
{$8240W} [$00] {$7E} $06 $C7 $06 {$8240W} [$0000W] $E8 $ED6AW $E8
$EDAAW $E8 $F49FW $5D $C3
we see in the patch description: If they are, nothing happens otherwise Keen returns to standing (Behavior $3867W).
So that is what we want to change into the charging garg.
from this patch:
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking(garg)
take $1B51W and put it into the patch above replacing the $3867W
Then to change keen back we also use this patch:
%patch $1AD0 {$1B51W} #Look for Keen after charging into walls, randomly during walking
and change it into $3867W. $3867W was mentioned before to change back into standing keen:
%patch $1AD0 $3867W #Look for Keen after charging into walls, randomly during walking. changed into keen returns to standing
we also want to add this patch:
#Gargs anywhere will charge toward Keen after looking around
%patch $1B93 $90 $90 $90 $90 $90 $90
So that keen will actually charge.
Keen will fall into the ground when shooting because of the different hitbox sizes so to really test it jump shoot and release before landing so you can make the garg properly charge.
Notice a weird side effect also, the gargs now change into keen (predictably) you can then actually control them.
Keen only has a single bullet now. It must be because the shooting patch is incompatible with the infinite ammo patch. we don't really need keen to shoot here but even so, this is probably the reason
The way it is now the garg always seems to charge right. I am not sure if there is a way to fix that or how.
run test4.bat to test this.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod008
-
Keening_Product
- Kuliwho?
- Posts: 2176
- Joined: Fri Jan 20, 2012 7:02
- Location: Tied up in the Oracle Chamber's basement
- Contact:
Re: I'm working on a new keen 1-3 modding tutorial
This is neat.
Can I suggest we move this topic into Unofficial Keen Games? Would hate for it to get lost in misc's garg, and I feel that's a better fit anyway.
Can I suggest we move this topic into Unofficial Keen Games? Would hate for it to get lost in misc's garg, and I feel that's a better fit anyway.
Keening_Product was defeated before the game.
"Wise words. One day I may even understand what they mean." - Levellass
"Wise words. One day I may even understand what they mean." - Levellass
Re: I'm working on a new keen 1-3 modding tutorial
Thanks, I am considering opening another topic for this project when the mod is a little further in development. To discus the actual mod rather than the tutorial. I hope it won't be considered double posting, I guess I could first add more content before posting it there, then it technically isn't.
Re: I'm working on a new keen 1-3 modding tutorial
Chapter 9 Changing sprite size and hitbox management
We have already seen that by using patches you can make it so that sprites when shot create another dying animation then they normally do. And sprites other than the yorp can spawn a stunned yorp animation. But changing these features without changing the graphic files involved can cause glitches, namely sprites will spawn into the ground or walls when changing into a sprite larger than they were before.
We can change the vorticon to create a stunned yorp when you jump on it by giving it the yorp sprite type. It will change back into a yorp again by default. So to stop that we must also patch the stunned yorp behavior to change (back) into a vorticon. Then we must also stop the original yorp from being stompable for example by giving it the sprite type of the butler robot that makes them push but not be stompable. See the previous chapters of this tutorial for how to set up these patches.
#set the vorticon sprite type to that of a yorp (2)
%patch $17E0 $02
#set the yorp sprite type to that of a butler robot (5)
%patch $188B $05
#stunned yorp changes back into a vorticon
%patch $1A58 $1D15W #Yorp after being stunned becomes a vorticon instead of yorp
%patch $4DA4 $1D15W #Yorp after being stunned and off screen becomes a vorticon instead of a yorp
We now have the stunned behavior of the yorp exclusively for the vorticon. The only problem is that it still looks like a stunned yorp and that the stunned yorp animation is smaller than the vorticon, causing it to glitch into the ground when changing back to an unstunned vorticon.
So to solve this problem we will change the graphics of the stunned yorp to look like a vorticon and give it the exact same size of the vorticon. Take a look in the GRAPHICS folder. Aside from 1TIL0000.BMP there are many graphic files here that are used for the sprites such as the yorp and vorticon. All sprite graphic files seem to start with the name 1SPR followed by a number.
The stunned yorp appears to be 1SPR0056.BMP and 1SPR0057.BMP. Usually your computer's setting should give you a preview of the graphic file even without opening them. If you don't have this by default it's probably worth enabling this somehow.
You probably want to understand the format of the graphics files before changing them. The keen engine interprets the BMP files by splitting them up into three equal parts. The most left part is the actual graphics. The middle part determines what part is transparent, the white part will be see-through and the black part is not. The right most part will not impact the appearance but determines the hitbox. The light red part is the hitbox that can interact with other sprites and the environment (typically blocking tiles) and the dark grey part is the part that is not part of the hitbox. The hitbox should always be a rectangular shape for it to work just like the total bitmap. Some sprite's hitboxes are completely red, in that case the entire sprite is the hitbox.
There are also limits to how big a sprite can be and still work. And there may be more rules for the format than is immediately apparent. For example the width of a picture must not be an uneven pixel number. Maybe it must even be divisible by 4,8 or even 16. The same could apply to the height. At this point I'm not sure what the exact rules or limits are but a good idea is to always test a certain size out or pick one of the sizes other existing sprites already use. You can even make your actual sprite a bit smaller by changing up the hitbox a bit.
For this example we want to make the stunned yorp the exact same size of the vorticon. So we can basically just open one of the vorticon's bitmap, select all, copy, open the stunned yorp bitmap and copy the picture and save it as a larger bitmap.
Ofcourse we also would like to creature a somewhat believable stunned vorticon animation. So we want to work with the vorticon graphic. But all the sprite graphics are saved on a black background. To get the picture including the black border we need to sort of "reconstruct" it. In paint there is a fairly easy way to do this. You have to use the "pick color" tool. Then right click on the black color to make it the "background" color. Now if we select the most left rectangle and drag it over the masked part and deselect under the image tap "Draw Opaque" all the black should become transparent and if you drag the image over the masked "silhouette" the true image should appear. You can then edit this and afterwards you will convert it back to the required format, refill the black background in the first part and make a new silhouette in the second.
Anyway, I have now created a stunned vorticon sprite (2) that have the same size as the other vorticon sprites and changed the stunned yorp sprites into them. I also made the vorticon pink just like in the keen mod "Keen Is At It Again!". But mine is slightly different, can you tell?
Oh and the vorticon having the yorp sprite type means they can't kill you. But wouldn't it be fun if the vorticon is stompable but can still kill keen?
Yes.
But how? Well, there is a patch to make yorps kill keen but still stunnable. In practice this means as long as keen is falling on top of it keen won't die but will stun it and when stunned it won't kill keen either until it wakes up. This is from the yorp page on the keen wiki:
https://keenwiki.shikadi.net/wiki/Patch:Yorp
#Yorp kills Keen but can be stomped
%patch $460B $EB $68
We already changed the yorp itself to the sprite type of the butler robot. So it won't affect the actual yorps anymore. But it will affect the vorticon since we gave it the yorp sprite type.
So there we have it. A stunnable vorticon that can still kill keen. When you run play.bat you will see that it works. The only problem is that the player might not know that you can do this. The solution could be to provide the player with hints or make it so that stunning them is entirely optional. It also could be considered unkeenish, since you can't do this in the original. You could explain this somehow, like maybe keen trained with the vortininja's after vorticon VI was freed from the grand intellect. Yet now somehow the vorticons, or these vorticons are enslaved again.
Now that we have changed the vorticon and gave him a weakness it didn't have before maybe it also makes sense to make him somewhat stronger in another way. By making him take 6 shots instead of 4. From the keen wik we find this patch
%patch $180D [$0003W] #Strength of regular Vorticon -1
The description is "strength -1" meaning it is actually one shot stronger than the value it is set to. So three becomes four. 6-1=5 so we set it to:
%patch $180D $0005W #Strength of regular Vorticon -1. set to 6
Changing the sprite size to influence gameplay
You want the sprite sizes to match when enemies go from one behavior to another so they don't glitch into the ground or walls. But also, the size of the sprites and also their hitbox will influence how they will move through the level and interact with other sprites. A notable example is that the butler robots are less than 1 tile high and so are able to move through 1 tile high entrances whereas keen and other sprites cannot. Also vorticons can not fall through 1 tile wide gaps but keen can. Making 1 tile wide gaps accessible for keen, yet keen will be completely safe from a vorticon walking over such a one tile gap above him.
You can indeed change a vorticon to be small enough to enter all such places, in fact the vorticon will probably only become more dangerous if you make it smaller like that for that reason.
I am actually going to change the size, and in fact more specifically the hitbox size of the yorp in that way to make it able to walk through all 1 tile high spaces.
I will also use another set of graphics for the yorp. I will actually use the yorp replacement of the Patchwork Mod I. We learned in chapter 1 of this tutorial that you can extract the graphics of any existing keen 1 mod. So this is also the method I used to get the graphics for the yorp replacement of that mod. It's already in the correct format so I only need to copy the relevant sprite files to my own mod folder and import them.
Oh yea, and the reason I do this is because I don't have the talent or patience to make much of my own graphics at this time. If I had my own artists that would be willing to collab with me (for free) that would be another story.
A patch to make keen able to stand on sprites in keen 1 like in keen 2.
Apparently there is a patch that makes keen able to stand on certain sprites like keen can stand on scrubs and platforms in keen 2. I didn't see this on the keen wiki yet. But in the keen 1 mod Swan Song by Shikadi there are butler robots featured that keen can stand on just like in keen 2.
https://keenwiki.shikadi.net/wiki/Swan_Song
I think it was explained somewhere that the patch uses existing code that is made for keen 2 but can be found in the keen1 exe also. Just like bridges can be made to work in keen 1 too.
So what we can do is download the mod Swan Song and see if we can open the .pat file of that mod and see if the creator of that mod was kind enough to leave a description with their patches to see if we can find the patch that makes keen able to stand on butler robots. Just in case we cannot find it anywhere else.
start.pat seems to be the patch file of this mod. reading through it we find this part with a patch and description:
### butler robot###
#Butler bots point to stand code
%patch $46A4 $6907W
#Keen can stand on Butler Bots code
%patch $6907 $57 $56 $E8 $C730W $59 $59 $5F $5E $5D $C3
It seems to consist of two parts. I guess one part contains the code (or activates it?) And the other part makes it so that the butler robot now uses it.
We can try to copy this into our own patch file and see if it makes the butler robot behave the same (have the same trait).
It does.
Also we could experiment if we can give the same trait to other sprites by setting that sprite's sprite type also to that of the butler robot.
We already did that with the yorp to make them unstunnable. It's just a matter of testing now if this patch also works on the yorp.
It does work by the way. I think it is a nice idea that you can stand on the yorp replacement now, since you can't stun it anymore anyway.
The yorp replacement that I will borrow from patchworkmod I is more or less 1 tile high. The actual picture is actually 1 pixel higher than that. But I can change the hitbox to be exactly 1 tile high. We also want it to be broad enough that it isn't too hard for keen to stand on it.
The sprite files I got from patchwork mod have a taller and less broad hitbox. But I want it to be able to fit through 1 tile high places and be broad enough for keen to stand on comfortably. So I will edit the hitbox for this purpose.
I made the hitbox the exact same height as a tile. This seems like it would be enough for keen to stand on it and not be hit when it walks over a danger tile. But it seems it isn't. This is somewhat unexpected and probably could not have been predicted without testing.
The exact same thing applies to the scrub in keen 2 by the way. The scrub is exactly 1 tile high yet keen still can't survive standing on it when it walks through a danger tile. Keen seems to stand 1 pixel lower than its actual hitbox.
If we wanna make a sprite that can carry keen over danger tiles it would have to be somewhat bigger than a tile high apparently.
But how it is they can fit through tight spaces that keen cannot.
Keen can stand on them, this means they might be able to help keen access
places higher than he normally can. This is even more so the case when a yorp jumps when you stand on it and keen then jumps from there.
In fact let's go ahead and make the yorp jump higher. From the yorp page on the keen wiki:
#yorp:
%patch $1964 [$0080W] #Jump height
Let's change it from the original number 128 to three times as much (384)
#yorp jump height changed from 128 to 384
%patch $1964 $0180W
After testing this the increase in jump height seems more dramatic than I originally anticipated. I wonder how it actually works. Normally the yorps only rarely jump more than 1 tile high. But after increasing the jump height to three times its original value they seem to fairly often jump much higher than 3 tiles. I wonder if the number 128 is the amount of pixels it can jump. 128 divided by 16 is 8. That would mean that the original yorp has a maximum jump of 8 tiles! That seems not right. Although it is possible that the way the yorp works is that it takes a random number of 1-128 pixels and then jumps that high. An 8 tile high jump might actually be possible but statistically extremely unlikely. I'm not sure if that's how it is but if so that would be mind blowing (to me). It's also possible that the keen engine creates a random number of 1-128 and then subtracts a number of it and then if it is more than zero the yorp jumps that many pixels.
Although the increase appears to be more than three times as much as the original average jump I think the change is fine. We could modify that number later if we want to. The yorp seems more dangerous and annoying now that it can jump higher. But also potentially more useful if you can jump off it when it jumps to reach higher parts of the level. It might also jump more often now, or fewer of their jumps are micro jumps as they were with a smaller maximum jump height.
I will make a new folder in the subfolder resources and put there a copy of some of the graphics I have borrowed from other mods. In this case I will put a folder of the yorp replacement from the patchwork mod before I edited it to fit my own project. As a bonus I will put some graphics from the game that sprite originates from.
It's Krusty's Super Fun House / Krusty World and you can also find it here:
https://www.spriters-resource.com/snes/ ... et/110936/
You may also be able to find other game resources on that site that you may be able to use for a keen mod.
This chapter could maybe be considered the last chapter of the first part of this tutorial. Because I think most of the basics have been covered. After this it will be more specific examples of things.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod009
We have already seen that by using patches you can make it so that sprites when shot create another dying animation then they normally do. And sprites other than the yorp can spawn a stunned yorp animation. But changing these features without changing the graphic files involved can cause glitches, namely sprites will spawn into the ground or walls when changing into a sprite larger than they were before.
We can change the vorticon to create a stunned yorp when you jump on it by giving it the yorp sprite type. It will change back into a yorp again by default. So to stop that we must also patch the stunned yorp behavior to change (back) into a vorticon. Then we must also stop the original yorp from being stompable for example by giving it the sprite type of the butler robot that makes them push but not be stompable. See the previous chapters of this tutorial for how to set up these patches.
#set the vorticon sprite type to that of a yorp (2)
%patch $17E0 $02
#set the yorp sprite type to that of a butler robot (5)
%patch $188B $05
#stunned yorp changes back into a vorticon
%patch $1A58 $1D15W #Yorp after being stunned becomes a vorticon instead of yorp
%patch $4DA4 $1D15W #Yorp after being stunned and off screen becomes a vorticon instead of a yorp
We now have the stunned behavior of the yorp exclusively for the vorticon. The only problem is that it still looks like a stunned yorp and that the stunned yorp animation is smaller than the vorticon, causing it to glitch into the ground when changing back to an unstunned vorticon.
So to solve this problem we will change the graphics of the stunned yorp to look like a vorticon and give it the exact same size of the vorticon. Take a look in the GRAPHICS folder. Aside from 1TIL0000.BMP there are many graphic files here that are used for the sprites such as the yorp and vorticon. All sprite graphic files seem to start with the name 1SPR followed by a number.
The stunned yorp appears to be 1SPR0056.BMP and 1SPR0057.BMP. Usually your computer's setting should give you a preview of the graphic file even without opening them. If you don't have this by default it's probably worth enabling this somehow.
You probably want to understand the format of the graphics files before changing them. The keen engine interprets the BMP files by splitting them up into three equal parts. The most left part is the actual graphics. The middle part determines what part is transparent, the white part will be see-through and the black part is not. The right most part will not impact the appearance but determines the hitbox. The light red part is the hitbox that can interact with other sprites and the environment (typically blocking tiles) and the dark grey part is the part that is not part of the hitbox. The hitbox should always be a rectangular shape for it to work just like the total bitmap. Some sprite's hitboxes are completely red, in that case the entire sprite is the hitbox.
There are also limits to how big a sprite can be and still work. And there may be more rules for the format than is immediately apparent. For example the width of a picture must not be an uneven pixel number. Maybe it must even be divisible by 4,8 or even 16. The same could apply to the height. At this point I'm not sure what the exact rules or limits are but a good idea is to always test a certain size out or pick one of the sizes other existing sprites already use. You can even make your actual sprite a bit smaller by changing up the hitbox a bit.
For this example we want to make the stunned yorp the exact same size of the vorticon. So we can basically just open one of the vorticon's bitmap, select all, copy, open the stunned yorp bitmap and copy the picture and save it as a larger bitmap.
Ofcourse we also would like to creature a somewhat believable stunned vorticon animation. So we want to work with the vorticon graphic. But all the sprite graphics are saved on a black background. To get the picture including the black border we need to sort of "reconstruct" it. In paint there is a fairly easy way to do this. You have to use the "pick color" tool. Then right click on the black color to make it the "background" color. Now if we select the most left rectangle and drag it over the masked part and deselect under the image tap "Draw Opaque" all the black should become transparent and if you drag the image over the masked "silhouette" the true image should appear. You can then edit this and afterwards you will convert it back to the required format, refill the black background in the first part and make a new silhouette in the second.
Anyway, I have now created a stunned vorticon sprite (2) that have the same size as the other vorticon sprites and changed the stunned yorp sprites into them. I also made the vorticon pink just like in the keen mod "Keen Is At It Again!". But mine is slightly different, can you tell?
Oh and the vorticon having the yorp sprite type means they can't kill you. But wouldn't it be fun if the vorticon is stompable but can still kill keen?
Yes.
But how? Well, there is a patch to make yorps kill keen but still stunnable. In practice this means as long as keen is falling on top of it keen won't die but will stun it and when stunned it won't kill keen either until it wakes up. This is from the yorp page on the keen wiki:
https://keenwiki.shikadi.net/wiki/Patch:Yorp
#Yorp kills Keen but can be stomped
%patch $460B $EB $68
We already changed the yorp itself to the sprite type of the butler robot. So it won't affect the actual yorps anymore. But it will affect the vorticon since we gave it the yorp sprite type.
So there we have it. A stunnable vorticon that can still kill keen. When you run play.bat you will see that it works. The only problem is that the player might not know that you can do this. The solution could be to provide the player with hints or make it so that stunning them is entirely optional. It also could be considered unkeenish, since you can't do this in the original. You could explain this somehow, like maybe keen trained with the vortininja's after vorticon VI was freed from the grand intellect. Yet now somehow the vorticons, or these vorticons are enslaved again.
Now that we have changed the vorticon and gave him a weakness it didn't have before maybe it also makes sense to make him somewhat stronger in another way. By making him take 6 shots instead of 4. From the keen wik we find this patch
%patch $180D [$0003W] #Strength of regular Vorticon -1
The description is "strength -1" meaning it is actually one shot stronger than the value it is set to. So three becomes four. 6-1=5 so we set it to:
%patch $180D $0005W #Strength of regular Vorticon -1. set to 6
Changing the sprite size to influence gameplay
You want the sprite sizes to match when enemies go from one behavior to another so they don't glitch into the ground or walls. But also, the size of the sprites and also their hitbox will influence how they will move through the level and interact with other sprites. A notable example is that the butler robots are less than 1 tile high and so are able to move through 1 tile high entrances whereas keen and other sprites cannot. Also vorticons can not fall through 1 tile wide gaps but keen can. Making 1 tile wide gaps accessible for keen, yet keen will be completely safe from a vorticon walking over such a one tile gap above him.
You can indeed change a vorticon to be small enough to enter all such places, in fact the vorticon will probably only become more dangerous if you make it smaller like that for that reason.
I am actually going to change the size, and in fact more specifically the hitbox size of the yorp in that way to make it able to walk through all 1 tile high spaces.
I will also use another set of graphics for the yorp. I will actually use the yorp replacement of the Patchwork Mod I. We learned in chapter 1 of this tutorial that you can extract the graphics of any existing keen 1 mod. So this is also the method I used to get the graphics for the yorp replacement of that mod. It's already in the correct format so I only need to copy the relevant sprite files to my own mod folder and import them.
Oh yea, and the reason I do this is because I don't have the talent or patience to make much of my own graphics at this time. If I had my own artists that would be willing to collab with me (for free) that would be another story.
A patch to make keen able to stand on sprites in keen 1 like in keen 2.
Apparently there is a patch that makes keen able to stand on certain sprites like keen can stand on scrubs and platforms in keen 2. I didn't see this on the keen wiki yet. But in the keen 1 mod Swan Song by Shikadi there are butler robots featured that keen can stand on just like in keen 2.
https://keenwiki.shikadi.net/wiki/Swan_Song
I think it was explained somewhere that the patch uses existing code that is made for keen 2 but can be found in the keen1 exe also. Just like bridges can be made to work in keen 1 too.
So what we can do is download the mod Swan Song and see if we can open the .pat file of that mod and see if the creator of that mod was kind enough to leave a description with their patches to see if we can find the patch that makes keen able to stand on butler robots. Just in case we cannot find it anywhere else.
start.pat seems to be the patch file of this mod. reading through it we find this part with a patch and description:
### butler robot###
#Butler bots point to stand code
%patch $46A4 $6907W
#Keen can stand on Butler Bots code
%patch $6907 $57 $56 $E8 $C730W $59 $59 $5F $5E $5D $C3
It seems to consist of two parts. I guess one part contains the code (or activates it?) And the other part makes it so that the butler robot now uses it.
We can try to copy this into our own patch file and see if it makes the butler robot behave the same (have the same trait).
It does.
Also we could experiment if we can give the same trait to other sprites by setting that sprite's sprite type also to that of the butler robot.
We already did that with the yorp to make them unstunnable. It's just a matter of testing now if this patch also works on the yorp.
It does work by the way. I think it is a nice idea that you can stand on the yorp replacement now, since you can't stun it anymore anyway.
The yorp replacement that I will borrow from patchworkmod I is more or less 1 tile high. The actual picture is actually 1 pixel higher than that. But I can change the hitbox to be exactly 1 tile high. We also want it to be broad enough that it isn't too hard for keen to stand on it.
The sprite files I got from patchwork mod have a taller and less broad hitbox. But I want it to be able to fit through 1 tile high places and be broad enough for keen to stand on comfortably. So I will edit the hitbox for this purpose.
I made the hitbox the exact same height as a tile. This seems like it would be enough for keen to stand on it and not be hit when it walks over a danger tile. But it seems it isn't. This is somewhat unexpected and probably could not have been predicted without testing.
The exact same thing applies to the scrub in keen 2 by the way. The scrub is exactly 1 tile high yet keen still can't survive standing on it when it walks through a danger tile. Keen seems to stand 1 pixel lower than its actual hitbox.
If we wanna make a sprite that can carry keen over danger tiles it would have to be somewhat bigger than a tile high apparently.
But how it is they can fit through tight spaces that keen cannot.
Keen can stand on them, this means they might be able to help keen access
places higher than he normally can. This is even more so the case when a yorp jumps when you stand on it and keen then jumps from there.
In fact let's go ahead and make the yorp jump higher. From the yorp page on the keen wiki:
#yorp:
%patch $1964 [$0080W] #Jump height
Let's change it from the original number 128 to three times as much (384)
#yorp jump height changed from 128 to 384
%patch $1964 $0180W
After testing this the increase in jump height seems more dramatic than I originally anticipated. I wonder how it actually works. Normally the yorps only rarely jump more than 1 tile high. But after increasing the jump height to three times its original value they seem to fairly often jump much higher than 3 tiles. I wonder if the number 128 is the amount of pixels it can jump. 128 divided by 16 is 8. That would mean that the original yorp has a maximum jump of 8 tiles! That seems not right. Although it is possible that the way the yorp works is that it takes a random number of 1-128 pixels and then jumps that high. An 8 tile high jump might actually be possible but statistically extremely unlikely. I'm not sure if that's how it is but if so that would be mind blowing (to me). It's also possible that the keen engine creates a random number of 1-128 and then subtracts a number of it and then if it is more than zero the yorp jumps that many pixels.
Although the increase appears to be more than three times as much as the original average jump I think the change is fine. We could modify that number later if we want to. The yorp seems more dangerous and annoying now that it can jump higher. But also potentially more useful if you can jump off it when it jumps to reach higher parts of the level. It might also jump more often now, or fewer of their jumps are micro jumps as they were with a smaller maximum jump height.
I will make a new folder in the subfolder resources and put there a copy of some of the graphics I have borrowed from other mods. In this case I will put a folder of the yorp replacement from the patchwork mod before I edited it to fit my own project. As a bonus I will put some graphics from the game that sprite originates from.
It's Krusty's Super Fun House / Krusty World and you can also find it here:
https://www.spriters-resource.com/snes/ ... et/110936/
You may also be able to find other game resources on that site that you may be able to use for a keen mod.
This chapter could maybe be considered the last chapter of the first part of this tutorial. Because I think most of the basics have been covered. After this it will be more specific examples of things.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod009
Re: I'm working on a new keen 1-3 modding tutorial
The end game
One of the important principles of level design is that for a level to be good it has to be winnable. The same also applies to a level pack or mod. If there isn't a finish line then playing it is less fun. Although each level when completed works as such a milestone. There should also be a point where the pack or mod is done as a whole.
In the original keen games there is an ending sequence that is triggered when you reach a certain goal followed by a game over screen. It is probably a good idea to include this in your mod or level pack before considering it completed.
The easiest way to do this is by recreating the same conditions as in the original game. That is in keen 1 you need to get 4 parts and then exist the level.
You should note that the ship parts are tied to the level they are originally in. If you die in that level keen loses that ship part even if he collected it in another level.
Therefore always put ship parts in the same level number as the original game
You can also patch to stop this from happening:
#Keen won't lose the ship parts if he dies in a level
%patch $4F82 $90 $90 $90 $90 $90 $90 #Joystick
%patch $4F8A $90 $90 $90 $90 $90 $90 #Battery
%patch $4F92 $90 $90 $90 $90 $90 $90 #Vacum
%patch $4F9A $90 $90 $90 $90 $90 $90 #everclear
However you may still want to use the original level number. That is level04.ck1 for the joystick for example, and not use the above patch. Because if keen does die and he doesn't lose the part then there can be a situation where keen has 4 parts but is still not winning the game. You still have to play a level and go through the exit to trigger the ending sequence.
You might say this is a minor bug that will hardly affect anyone and doesn't matter. I guess it depends on how much you care about details like that.
It's even more important to place the ship parts in such a way that you can't finish the level without it. Like in the original by literally putting it in front of the exit so you can't avoid it.
Also there is no rule that you can't have more versions of a ship part in multiple levels. The "buggy" aspect of being able to collect it without completing a level might still apply then.
Unless you trap the player so he can not die but can only go through the exit with the item, but that seems a bit forced.
Patching the ending condition
Having to collect 4 items just like in keen 1 might seem a bit stale though. Just because it is a keen 1 mod doesn't mean you have to let everything be the same. Well, it's still a pretty decent choice and many mods have done it that way. One of the reasons to do it like that is that it doesn't require patching.
There is a patch however, or patches depending on how you look at it, to change the requirement for triggering the ending sequence.
By default the four parts are needed. this is checked when exiting a level. Literally the game checks if the value for the ship parts is 1 or more or non-zero.
This can in fact be patched to check for other things. But also you can make it so that all four win conditions check for the same thing. Therefore you can not only change what it is that you need to win the game but you can also make it so that fewer parts or less than four things are needed.
On the keen wiki we find the following patch:
https://keenwiki.shikadi.net/wiki/Patch:Ship_Parts
Patch description:
What is needed to win the game
This is what is required to trigger the ending sequence when Keen exits a level. By default Keen must have all four Ship Parts, that is, the value for these game stats must not be 0. (See also Patch:Jump conditions.) To make a part unnecessary simply replace $74 with $90 $90. If all four parts are treated this way, Keen will win the game on exiting any level.
Keen 1
#What we need before we can win: (Default: win if all 4 NOT 0)
%patch $8022 [$AA94W] {$00} [$74] #Joystick
%patch $8029 [$AA9CW] {$00} [$74] #Battery
%patch $8030 [$AA96W] {$00} [$74] #Vacuum
%patch $8037 [$AA98W] {$00} [$74] #Whiskey
The description says to replace $74 with $90 $90 to make a part not needed to win. So let's do this for all items except the Joystick:
#What we need before we can win: (Default: win if all 4 NOT 0)
#%patch $8022 [$AA94W] {$00} [$74] #Joystick
%patch $8029 $AA9CW $00 $90 $90 #Battery
%patch $8030 $AA96W $00 $90 $90 #Vacuum
%patch $8037 $AA98W $00 $90 $90 #Whiskey
The first part I don't include (render inactive with the "#" symbol) because we don't need to change it.
Using the patch this way works.
Instead of using the $90 $90 as shown above you could also patch all four win condition checks to check for the same thing like this:
#All four win conditions check of the joystick
%patch $8022 $AA94W $00 $74 #Joystick
%patch $8029 $AA94W $00 $74 #Joystick
%patch $8030 $AA94W $00 $74 #Joystick
%patch $8037 $AA94W $00 $74 #Joystick
Now all four checks check for the joystick value (AA94). If you have more than 0 joysticks all four conditions will be considered achieved. Note also just like before the first line of the patch could have been omitted, as nothing is changed from the default values.
You can also change the value of what is checked for to be something other than the ship parts. such as the pogo, ammo or lives. But also whether you have completed any particular level. So you can make a mod where just like in keen 3 you need to beat one specific level to win and don't need any ship parts.
If the value is ammo you need to have at least 1 bullet when exiting the level. On the wiki page:
https://keenwiki.shikadi.net/wiki/Patch:Game_stats
You can find this section:
Vorticons values are quite simple. These are the values for versions 1.31 of all three games:
Keen 1:
$5DAAW: God mode
$6EC2W: Extra keen at
$AA94W: Joystick $AA96W: Vacuum $AA98W: Whiskey $AA9AW: Pogo
$AA9CW: Battery $AA9EW: Yellow card $AAA0W: Red card $AAA2W: Green card
$AAA4W: Blue card $AAA6W: Level 1 $AAA8W: Level 2 $AAAAW: Level 3
$AAACW: Level 4 $AAAEW: Level 5 $AAB0W: Level 6 $AAB2W: Level 7
$AAB4W: Level 8 $AAB6W: Level 9 $AAB8W: Level 10 $AABAW: Level 11
$AABCW: Level 12 $AABEW: Level 13 $AAC0W: Level 14 $AAC2W: Level 15
$AAC4W: Level 16 $AAC6W: Lives $AAC8W: Ammo $AACAW: Points
$AACCW: Points * 65536
As you can see the ship parts are among them. And match the default values of the previously mentioned patch.
So you can ofcourse use the above values to insert into the patch mentioned. And make completing one of the levels a or the win condition. That is because apparently the value for the levels are 0 when not completed and I assume 1 when they are completed. Testing if something works as intended is important though. For example, using the keycards did not work when I tried it, probably because you lose them when exiting a level and apparently before the victory check is done. It might still work though if you also use a patch that stops keen from losing the keycards when exiting a level.
Ship parts in the high score and status bar and ship message.
The keen engine uses special fixed tiles to display whether you have certain parts or not in the status bar and ship message. And also on the high score page it will display how many parts a player collected by using the default tiles used for the ship parts.
You can use tileinfo to make any tile you want into a ship part. But it may be good advice to keep the default tiles reserved to look like the ship part in case they are used to display them on the high score page.
Ship part animation
By default the ship parts are animated. That means they are animated on the high score page as well. If you want them to not be animated you can change this property in tileinfo and it will affect the high score page as well.
However, by default they are animated and the way the high score page works is that to make the animation asynchronous every second and third line and so on will use another frame i.e. use the tile next to it to be displayed instead. To stop this from happening we need to use this patch:
https://keenwiki.shikadi.net/wiki/Patch ... Vorticons)
Ship parts tiles don't animate
This patch stops the ship parts tiles from animating, though they will still appear.
Keen 1
#Stop the high score items animating
%patch $9929 $B8 #Joystick
%patch $995C $B8 #Battery
%patch $998F $B8 #Vacuum
%patch $99C2 $B8 #Whiskey
I think this patch is a little under explained and technically not correct. I hope my further explanation was slightly better. I will be using this. This will save me 3 tiles per ship part if I don't want them to be animated.
The end sequence
Once keen has collected all four parts. Or one in the case we patched it to only needing one, the end sequence is played.
This is slightly a problem for me because I used all the tiles that are used for the picture for mars and earth.
I also don't want to do a lot of work making art for an end sequence that doesn't seem that interesting to me.
There is some opportunity for story telling here for those willing to do the work. Though the format is a bit constrained because you basically have the same sequence of events as in keen1. Though the text can be changed of course.
There are also patches to skip certain parts. That can be helpful if you want to use some parts and not others. I also don't want the player to have to wait the whole time just because they have won. Or me when testing it for that matter.
You can make the game over screen appear immediately after collecting the required amount of ship parts.
https://keenwiki.shikadi.net/wiki/Patch ... e_(Keen_1)
#Ignore ending sequence, go to game over\high scores
%patch $803D $EC0AW
Or instead you can skip certain parts. I will make keen return to his mega ship. Then skip to game over.
patch description:
Skip flight to Earth and Keen's house sequences (Go from Mars to Endtext)
This patch takes Keen directly from the Mars map textbox sequence to the endtext sequence, skipping the flight to Earth and house sequences. As a side effect the endtext, and game over (and enter high score name box if the player gets a high score) will appear over the Mars map. Also the duration of the mars map sequence is altered, so this is included with the patch as an optional extra.
Keen 1
#Go directly from Mars map sequence to Endtext (Frees $8256-$88D1)
%patch $8252 $E9 $067DW
#How long Mars textbox waits
%patch $88D3 [$0190W]
Setting the second part of the patch to zero seems to cause the game to freeze indefinitely. But setting it to 0001 seems the fastest I can get it to work. Useful because I left some of the text blanc, which also takes extra time already.
Keen 1
#Text writing speed
%patch $8173 [$0006W]
Text writing speed is also something you can play with so the player doesn't have to wait around as long. I will however leave this unchanged.
There is another patch that stops the delay after finishing the final level where a black screen remains for a few seconds. I think the delay is not needed and removing it is an improvement.
No black screen pause
This patch removes the black screen pause entirely, instead a simple fade-out\fade-in changes the screen to the map level.
Keen 1
#No black screen pause before ending sequence
%patch $820C $EB $07
Using doors in this mod
previously I have changed the yorps property so you can stand on it and it pushes differently. A side effect is that now, depending how the levels are build yorps can push keen through a locked door. It may only happen if you manoeuvre a certain way (make a little jump). however this could make it possible to circumvent having to collect a key or even getting stuck behind a locked door. To prevent it I have built doors in such a way that normally yorps do not approach them horizontally. But since yorps can jump (high) there is still a chance of this bug occuring, though it should be statistically unlikely now.
Ripped graphics
I have used more graphics from other sources for the current version of this mod. I have put some of the sources in the ripped graphics folder. I may have also borrowed from keen mods and have not kept track of where everything is from. This isn't intended to hide the source though.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod010
One of the important principles of level design is that for a level to be good it has to be winnable. The same also applies to a level pack or mod. If there isn't a finish line then playing it is less fun. Although each level when completed works as such a milestone. There should also be a point where the pack or mod is done as a whole.
In the original keen games there is an ending sequence that is triggered when you reach a certain goal followed by a game over screen. It is probably a good idea to include this in your mod or level pack before considering it completed.
The easiest way to do this is by recreating the same conditions as in the original game. That is in keen 1 you need to get 4 parts and then exist the level.
You should note that the ship parts are tied to the level they are originally in. If you die in that level keen loses that ship part even if he collected it in another level.
Therefore always put ship parts in the same level number as the original game
You can also patch to stop this from happening:
#Keen won't lose the ship parts if he dies in a level
%patch $4F82 $90 $90 $90 $90 $90 $90 #Joystick
%patch $4F8A $90 $90 $90 $90 $90 $90 #Battery
%patch $4F92 $90 $90 $90 $90 $90 $90 #Vacum
%patch $4F9A $90 $90 $90 $90 $90 $90 #everclear
However you may still want to use the original level number. That is level04.ck1 for the joystick for example, and not use the above patch. Because if keen does die and he doesn't lose the part then there can be a situation where keen has 4 parts but is still not winning the game. You still have to play a level and go through the exit to trigger the ending sequence.
You might say this is a minor bug that will hardly affect anyone and doesn't matter. I guess it depends on how much you care about details like that.
It's even more important to place the ship parts in such a way that you can't finish the level without it. Like in the original by literally putting it in front of the exit so you can't avoid it.
Also there is no rule that you can't have more versions of a ship part in multiple levels. The "buggy" aspect of being able to collect it without completing a level might still apply then.
Unless you trap the player so he can not die but can only go through the exit with the item, but that seems a bit forced.
Patching the ending condition
Having to collect 4 items just like in keen 1 might seem a bit stale though. Just because it is a keen 1 mod doesn't mean you have to let everything be the same. Well, it's still a pretty decent choice and many mods have done it that way. One of the reasons to do it like that is that it doesn't require patching.
There is a patch however, or patches depending on how you look at it, to change the requirement for triggering the ending sequence.
By default the four parts are needed. this is checked when exiting a level. Literally the game checks if the value for the ship parts is 1 or more or non-zero.
This can in fact be patched to check for other things. But also you can make it so that all four win conditions check for the same thing. Therefore you can not only change what it is that you need to win the game but you can also make it so that fewer parts or less than four things are needed.
On the keen wiki we find the following patch:
https://keenwiki.shikadi.net/wiki/Patch:Ship_Parts
Patch description:
What is needed to win the game
This is what is required to trigger the ending sequence when Keen exits a level. By default Keen must have all four Ship Parts, that is, the value for these game stats must not be 0. (See also Patch:Jump conditions.) To make a part unnecessary simply replace $74 with $90 $90. If all four parts are treated this way, Keen will win the game on exiting any level.
Keen 1
#What we need before we can win: (Default: win if all 4 NOT 0)
%patch $8022 [$AA94W] {$00} [$74] #Joystick
%patch $8029 [$AA9CW] {$00} [$74] #Battery
%patch $8030 [$AA96W] {$00} [$74] #Vacuum
%patch $8037 [$AA98W] {$00} [$74] #Whiskey
The description says to replace $74 with $90 $90 to make a part not needed to win. So let's do this for all items except the Joystick:
#What we need before we can win: (Default: win if all 4 NOT 0)
#%patch $8022 [$AA94W] {$00} [$74] #Joystick
%patch $8029 $AA9CW $00 $90 $90 #Battery
%patch $8030 $AA96W $00 $90 $90 #Vacuum
%patch $8037 $AA98W $00 $90 $90 #Whiskey
The first part I don't include (render inactive with the "#" symbol) because we don't need to change it.
Using the patch this way works.
Instead of using the $90 $90 as shown above you could also patch all four win condition checks to check for the same thing like this:
#All four win conditions check of the joystick
%patch $8022 $AA94W $00 $74 #Joystick
%patch $8029 $AA94W $00 $74 #Joystick
%patch $8030 $AA94W $00 $74 #Joystick
%patch $8037 $AA94W $00 $74 #Joystick
Now all four checks check for the joystick value (AA94). If you have more than 0 joysticks all four conditions will be considered achieved. Note also just like before the first line of the patch could have been omitted, as nothing is changed from the default values.
You can also change the value of what is checked for to be something other than the ship parts. such as the pogo, ammo or lives. But also whether you have completed any particular level. So you can make a mod where just like in keen 3 you need to beat one specific level to win and don't need any ship parts.
If the value is ammo you need to have at least 1 bullet when exiting the level. On the wiki page:
https://keenwiki.shikadi.net/wiki/Patch:Game_stats
You can find this section:
Vorticons values are quite simple. These are the values for versions 1.31 of all three games:
Keen 1:
$5DAAW: God mode
$6EC2W: Extra keen at
$AA94W: Joystick $AA96W: Vacuum $AA98W: Whiskey $AA9AW: Pogo
$AA9CW: Battery $AA9EW: Yellow card $AAA0W: Red card $AAA2W: Green card
$AAA4W: Blue card $AAA6W: Level 1 $AAA8W: Level 2 $AAAAW: Level 3
$AAACW: Level 4 $AAAEW: Level 5 $AAB0W: Level 6 $AAB2W: Level 7
$AAB4W: Level 8 $AAB6W: Level 9 $AAB8W: Level 10 $AABAW: Level 11
$AABCW: Level 12 $AABEW: Level 13 $AAC0W: Level 14 $AAC2W: Level 15
$AAC4W: Level 16 $AAC6W: Lives $AAC8W: Ammo $AACAW: Points
$AACCW: Points * 65536
As you can see the ship parts are among them. And match the default values of the previously mentioned patch.
So you can ofcourse use the above values to insert into the patch mentioned. And make completing one of the levels a or the win condition. That is because apparently the value for the levels are 0 when not completed and I assume 1 when they are completed. Testing if something works as intended is important though. For example, using the keycards did not work when I tried it, probably because you lose them when exiting a level and apparently before the victory check is done. It might still work though if you also use a patch that stops keen from losing the keycards when exiting a level.
Ship parts in the high score and status bar and ship message.
The keen engine uses special fixed tiles to display whether you have certain parts or not in the status bar and ship message. And also on the high score page it will display how many parts a player collected by using the default tiles used for the ship parts.
You can use tileinfo to make any tile you want into a ship part. But it may be good advice to keep the default tiles reserved to look like the ship part in case they are used to display them on the high score page.
Ship part animation
By default the ship parts are animated. That means they are animated on the high score page as well. If you want them to not be animated you can change this property in tileinfo and it will affect the high score page as well.
However, by default they are animated and the way the high score page works is that to make the animation asynchronous every second and third line and so on will use another frame i.e. use the tile next to it to be displayed instead. To stop this from happening we need to use this patch:
https://keenwiki.shikadi.net/wiki/Patch ... Vorticons)
Ship parts tiles don't animate
This patch stops the ship parts tiles from animating, though they will still appear.
Keen 1
#Stop the high score items animating
%patch $9929 $B8 #Joystick
%patch $995C $B8 #Battery
%patch $998F $B8 #Vacuum
%patch $99C2 $B8 #Whiskey
I think this patch is a little under explained and technically not correct. I hope my further explanation was slightly better. I will be using this. This will save me 3 tiles per ship part if I don't want them to be animated.
The end sequence
Once keen has collected all four parts. Or one in the case we patched it to only needing one, the end sequence is played.
This is slightly a problem for me because I used all the tiles that are used for the picture for mars and earth.
I also don't want to do a lot of work making art for an end sequence that doesn't seem that interesting to me.
There is some opportunity for story telling here for those willing to do the work. Though the format is a bit constrained because you basically have the same sequence of events as in keen1. Though the text can be changed of course.
There are also patches to skip certain parts. That can be helpful if you want to use some parts and not others. I also don't want the player to have to wait the whole time just because they have won. Or me when testing it for that matter.
You can make the game over screen appear immediately after collecting the required amount of ship parts.
https://keenwiki.shikadi.net/wiki/Patch ... e_(Keen_1)
#Ignore ending sequence, go to game over\high scores
%patch $803D $EC0AW
Or instead you can skip certain parts. I will make keen return to his mega ship. Then skip to game over.
patch description:
Skip flight to Earth and Keen's house sequences (Go from Mars to Endtext)
This patch takes Keen directly from the Mars map textbox sequence to the endtext sequence, skipping the flight to Earth and house sequences. As a side effect the endtext, and game over (and enter high score name box if the player gets a high score) will appear over the Mars map. Also the duration of the mars map sequence is altered, so this is included with the patch as an optional extra.
Keen 1
#Go directly from Mars map sequence to Endtext (Frees $8256-$88D1)
%patch $8252 $E9 $067DW
#How long Mars textbox waits
%patch $88D3 [$0190W]
Setting the second part of the patch to zero seems to cause the game to freeze indefinitely. But setting it to 0001 seems the fastest I can get it to work. Useful because I left some of the text blanc, which also takes extra time already.
Keen 1
#Text writing speed
%patch $8173 [$0006W]
Text writing speed is also something you can play with so the player doesn't have to wait around as long. I will however leave this unchanged.
There is another patch that stops the delay after finishing the final level where a black screen remains for a few seconds. I think the delay is not needed and removing it is an improvement.
No black screen pause
This patch removes the black screen pause entirely, instead a simple fade-out\fade-in changes the screen to the map level.
Keen 1
#No black screen pause before ending sequence
%patch $820C $EB $07
Using doors in this mod
previously I have changed the yorps property so you can stand on it and it pushes differently. A side effect is that now, depending how the levels are build yorps can push keen through a locked door. It may only happen if you manoeuvre a certain way (make a little jump). however this could make it possible to circumvent having to collect a key or even getting stuck behind a locked door. To prevent it I have built doors in such a way that normally yorps do not approach them horizontally. But since yorps can jump (high) there is still a chance of this bug occuring, though it should be statistically unlikely now.
Ripped graphics
I have used more graphics from other sources for the current version of this mod. I have put some of the sources in the ripped graphics folder. I may have also borrowed from keen mods and have not kept track of where everything is from. This isn't intended to hide the source though.
This part of the tutorial will include a version of the game that has the changes as described here building on the previous version.
mod010