I've been watching the development of this throughout its alpha/beta stages, and it's become a legit and powerful editor. Guxt modding is now 100% doable.
Also, I really think people should know about the debug menuthat was patched back into the game by @Rain . Playtesting a mod with more than one stage is insane unless you use this. Keep this executable alongside your normal pxGame.exe and use it to playtest, and activate the menu with Right-Click>Volume BEFORE you start a new game.
For the time being, I'm going to request that all discussion regarding editing the game (using the editor/enemies/etc) remain in this thread. If interests manages to pick up then I'll begin making considerations as to how much space this might need and where. There's already been a fair bit discovered about how stages and enemies behave, for any other pioneers looking to stretch their shooty chops
Now this is interesting.
I personally don't like Guxt very much but right now anybody can create a MOD that is even better than the original.
That's just great.
yeah bray seriously you did a good job, i know i wasnt the most on-track with progress of the editor but this is significantly better than the first private beta. amazing job, thanks for paving the way to guxt editing
I'm going to start a basic modding information guide in the post since everything's still a bit fragmented. More will be added over time, I won't attempt to try and fill in everything I've found right now.I've now got everything in here I initially wanted, covering the bulk of things I had to fiddle with while making my first mod. Updated again with some more bonus entity detail and notes about maps. There's some additional, more editor-specific information in the GitHub link in the first post.
-Opening a mod: "New" will require a Guxt .exe, while "Open" will load an ASE project file, which relates to the information on the right side of the initial program screen. All stage info has to be saved separately from its own screen, but "New" can still be used to open a mod and continue as normal. Stage data isn't loaded until a new playthrough is selected, meaning that if you're so inclined you can leave the game open and test stage alterations as soon as you make them.
-Important temp_guxt files: Providing a cleared.bin is necessary to have Score Attack unlocked from the start, which is essential if your mod doesn't have a standard "ending" where it would normally come from. A buttons.bin will also likely be appreciated, if you're the sort of person who finds the default layout a bit unwieldy, as will a main.screen_mode to keep the game window at the size you had it.
-File naming: Guxt reads all stage data consecutively, starting at stage 1. This includes stage-specific sprites and tilesets, maps and events, and music. All files must be replaced by name exactly in order to continue being recognised. (It is possible to edit the file extensions but I don't see a whole lot of point in doing this.) In a lot of cases it may prove to be simpler or more convenient to switch parts of stage data between each other to get them in a different order. There's no way to change how stages transition or where the game ends (properly) yet.
-Editing sprites: Select sprite from Images list, unscramble, make changes, rescramble. As in vanilla Cave Story, entity sprites need to maintain the same size and direction in order to appear appropriately, while tilesets can be adjusted a lot more freely.
-Editing music/sfx: Guxt was made using a much older version of PxTone, so you will need to update pxtone.dll if you want to use any newly created audio. This requires a patch, the details for which can be found by clicking on the "Docs" link in the first post, then going to the bottom of the "Modding 101" page. The old music should still continue working fine, and likewise will open cleanly in newer PtCollage.
-Tileset info: Stage 3 is the only one that really provides a varied tileset with multiple attributes to fiddle around with by default, while both the first two stages are very basic. This is an aspect I particularly suggest taking note of when starting a new mod, in order for us to avoid ending up with a bulk of stages constructed only from plain square tiles or black space. The tile options look the way they do because the way the game reads them just repeats indefinitely after the first 8, meaning all you really need to worry about is the first row. There isn't really a whole lot to cover compared to Cave Story, tiles can essentially be grouped into four types: Foreground and background non-solid, regular solid (the layer only affects sprite overlap) and destructible solid. Like CS, the latter will turn into the tile to their left on the spritesheet, and even more like CS can be stacked until they reach a non-solid tile! All solid tiles take up a block's worth of space and won't kill on collision, but will kill if they push the player off the bottom of the screen.
-Stage size and progression: It's technically possible to edit stage width but the game isn't programmed for dealing with it. I would suggest estimating long for the length setting as stages have to be constructed from the bottom up and it's hard to gauge how much you'll end up needing. Higher stage speeds in particular can burn through stage length very quickly (check out the default stage 5 as an example of how this can work). Stages will automatically transition to the next one in order after defeating a boss entity, there's no other way to force this insofar as I've seen.
-Resizing (and testing!!): If you do decide you need to make the stage longer/shorter, entities can be moved via bulk select fairly easily. Similarly to Cave Story, entity locations appear to be preserved even if the coordinates are outside the map, so even if you shrink the map or move them out of sight they'll still be there (although beware that this can make them difficult to relocate, especially moving them sideways). In fact, this should allow for a sort of ghetto stage testing technique where you can decrease the map size to a new starting point to save time and then add it all back when you're done! Just make sure that the "Shrink Buffer" option is turned off if you decide to try this, or otherwise all the tile data will be erased.
-Screen Preview: This handy-dandy option can be found in the View menu of the stage editor. It displays a single movable in-game screen length window, allowing the modder to see whatever will be on-screen at one time and even more importantly, the range entities will be triggered from. A zoom function exists as well using +/-, further helping to prevent strain on the eyes of the users of the Eye.
-Entity info: Entities in this game aren't just the enemies you see, they also determine everything from stage scrolling speed to which music plays to how bonus items appear. Most entities are stage-specific, meaning they will only be loaded from the stage-number-matching tileset and will appear broken if you try to use them elsewhere. The exceptions are those found in enemy_generic.pximg, which I made a lot of use of in my first mod; I suggest keeping a copy of them as a guide. There is somewhat of a workaround to this, which I'll explain in the list below. Currently there is no way to edit enemy health/damage/points/etc, some have certain unique parameters which can be modified but that's all.
More detailed notes
-Entities are typically activated when they scroll onto the top of the screen as the stage moves. This means there's about a 12-block buffer at the start of every stage in which everything will spawn instantly. Some take different amounts of time to appear properly, while certain ones will change how long it takes for them to activate based on their ExtraInfo value. There's no way to have anything activate only along the X-axis, everything is dependent on when it scrolls into view.
-Entities have double the grid coordinates that tiles do, i.e. four of them fit into one tile space. It looks in the editor as though they can be placed off the edge to the right, but in-game in centres everything properly by shaving off half of both the outermost tiles.
-In another similarity to CS, enemy bullets and projectiles also counts as their own entities, and can be spawned in individually. I won't attempt to describe them all here but it is something worth thinking about as a potential option, particularly as this is generally a fairly bullet-light game.
-Some enemies have interesting interactions with solid tiles, particularly the common spinner-type enemies which are actually coded to bounce off them (!) despite this never being used anywhere in the base game.
Powerup entities
7: Freefalling unboxed powerup
60: Shootable static powerup container
61: Open static powerup container
64: Spinning flying powerup carrier
74: Invisible shootable powerup container
75: Face asteroid (from the end of stage 2, drops a powerup when broken up)
-Entity 59 is actually the regular spinner enemy, which must share some code with the spinner powerup even though it won't work as one properly. It will appear as a powerup holder, but then disappear immediately when shot and give no powerup or even points.
-Giving one of them no value will cause them to drop an empty powerup, which if collected will bestow upon the player a Nothing Gun that can't shoot and also renders the ship almost invisible. It also seems as though there's no way to give back the starting gun after something else has been picked up.
22: The scroll speed entity
-This one is very important, as in addition to controlling how quickly the tiles and static enemies move, it also determines how quickly enemies can appear on screen. Lower setting are easier to work with because they allow more to be done in less space, but higher values are necessary to spawn things in faster succession. I recommend newcomers start with the base stage 1 value of 25, to get a feel for the timing it gives between each entity coordinate. For most "normal" stage sections I would go no lower than 15 (already very slow and any less is an absolute crawl), or higher than 50. Pixel does use some higher values for visual effect, but otherwise it makes the ground go by almost too quickly to interact with and on stages where there's little or no visual elements there's not much to distinguish anyway.
-Stages automatically stop scrolling after reaching the top of the map, but will not move on unless a boss is defeated. Setting the scroll speed to 0 otherwise is highly dubious, because there's no way for it to advance to the next tile and tell the screen to start moving again! The only exception is stage 5, where the game will automatically start moving again after the normal stage 5 boss to the TLB in Score Attack mode through some internal piece of coding.
56: The checkpoint entity
-This will set a recovery checkpoint after appearing at the top of screen in-game. Upon losing a life, the player will return to that position with the default weapon and slowest speed. Everything placed below it on the map will no longer spawn, even if it was on the screen when the checkpoint was activated. Placement of these ties heavily into powerup and score availability, and seeing as most people will probably want to keep them for regular playthroughs they can be rather tricky to implement.
Bonus entities
45: Spawns a stage bonus associated with the value in ExtraInfo-1; 0 spawns stage 1 scrolling, 1 spawns stage 2 static, all other values spawn an invisible bonus
46: Will spawn a bonus at the top of screen when two powerups are picked up in quick succession, has an extended detection range for this event of about an extra screen higher than its placement (used on stage 1)
106: Will spawn a bonus after 20 regular asteroids have been destroyed on the stage (after its placement) (used on stage 2)
121: Hidden bonus, revealed by shooting (stages 3-5, takes item reference from ExtraInfo)
-Conditional bonuses so far appear to be stage-specific, including the hidden bonuses which won't work for stages 1 or 2. Stage entity loading does allow them to work elsewhere, although I've not tested outside stage 1 yet. Regular bonus items appear to be tied directly to the stage rather than the spritesheet, and won't change once already spawned even if they're reloaded.
-The asteroid bonus/Azabonus is a little tricky to use. If multiple are placed together at once, that multiple will drop in a stack at the same time from the 20th asteroid, even though the game will still only display 200 (one assumes this is the same for the other bonuses, but they will always appear in set locations). However, if a new bonus entity is placed before reaching 20, it will reset the count and prevent the bonus dropping when it otherwise would have. Fortunately this is unlikely to be an issue for most modders, because unless they make a mod specifically based around asteroid destruction (like I did) it's unlikely for a stage to have that many in it anyway.
The special credits entities, aka Thank You Pixel For Being Creative
116: Shows the enemy credit text (of whatever's currently on screen?)
117: Poofs all current entity types matching the number in ExtraInfo
118: Loads the entity spritesheet for the stage value in ExtraInfo, allowing entities from other stages to be loaded anywhere
119: Makes the image of value EntityInfo slide across the screen horizontally
-Entity 118 obviously opens the game up incredibly, allowing enemies to be used practically anywhere without breaking. It is still somewhat limited in that it can only load in one set of sprites at once, and it will work immediately, requiring a gap between enemy waves to avoid visual scrambling. 117 can be used to despawn aerial enemies that get pushed off screen by terrain.
-Powerup and scoring notes: Weapons are an essential part of designing a Guxt stage, dictating how they play out just as much as enemy placement. Their different characteristics are mostly self-evident in terms of strength/versatility (e.g. shooting backwards), but it can be difficult to keep the design focussed over the course of a game, particularly if you want to offer multiple weapon choices at once. If you're mainly interested normal play mode, remember that lives are given out every 2000 points, and having more than that between checkpoints means that they can potentially be milked indefinitely.
Speedup usage
-The default speed is uncomfortably slow, encouraging use of at least one speedup near the start of the game, which is all fine and dandy until you realise that the same is is true of each checkpoint recovery. This makes it constantly awkward to try and design extended sections around having a certain speed level. More than likely maximum speed will be reached after surviving long enough, which combined with no tile damage leaves little downside to zipping around the screen outpacing any amount of careful enemy coordination. Fortunately even a single speedup is fairly comfortable, and it isn't overly restrictive to design an area that works at both +1 and +4. (Or +0 and +1 for that matter, remembering that speed is reset if another pickup is obtained at maximum, another likely occurrence over the course of a scoring run.)
Powerup scoring & incentivisation
-Firstly, a brief overview of how powerup bonuses work. Only powerup carrying spinners (and technically entity 7 or 75 powerups) give bonus points on collection, dependent on how quickly the powerup is grabbed after revealing it, the maximum being 100 points for < half a second-ish. The exception to this are shields, which only grant points when maxed out, and will give points for ground pickups in this case. These bonuses are likely to be one of the largest sources of scoring variation over the course of a run.
-Shields also have a non-linear progression, such that upgrading past the double layer is somewhat risky and there's no way to get back to it or remove the protector orbs aside from dying. Again much like speedups, offering replenishments (or even just beating any of the first three bosses) over the course of a game has the side effect of almost always having the orbs appear in surviving runs.
-Pixel's primary way of making use of these bonuses was to offer two main weapons on every stage, encouraging players to first grab the weapon they didn't want to use and then using it to grab the second one for a double bonus. Treating powerups essentially as secondary bonus items can create some neat/tricky scoring chances, but as ever this approach comes with caveats, namely that once a player has a strong weapon (like the Harpoon laser or the unused 3Line/3Way gun) or max speed, there's no inherent compulsion for them to ever downgrade, particularly if they're not so interested in scoring. Downgrading can even be detrimental to scoring if the new weapon can't handle the enemy frequency well enough. If you really want a section to play a specific way, the only way to guarantee it is to force a weapon pickup by making the player go through a 1-tile space with an open powerup container (or by sending a spinner down a 1-tile hallway).
-Overall though I wouldn't say there's any "wrong" way to give out weapons, my only advice would be don't offer false choices (i.e. where one option is far worse in the following area for no real reason) and make sure the player isn't chronically underequipped to deal with whatever's coming, especially after checkpoints. Lastly, do note that most weapons can be sped up by speed-tapping, particularly the base gun and the Rocket which basically require it in order to be usable.
Bonuses
-The options for actually using these are somewhat limited and awkward. Stage 1 style always falls quickly and ignores terrain, stage 2 is basically irrelevant unless you have loads of asteroids and the rest require entity loading in order to work right away. While not necessary by any means, they're the most direct kind of scoring focus/hidden secret one can utilise and can stack up very quickly compared to points from regular enemies.
Difficulty
-Oh boy here we go To give an idea of a benchmark, most people find even the original game fairly hard to beat. You can probably get away with something slightly more difficult if it's only a stage or two long. Moreso than Cave Story modding I think this is going to be a lot more dependent on personal preference, along with experience garnered from further testing as more people get involved. The basic tips I would offer are avoid sudden lurches in difficulty, take some heed of my other notes about weapon and speed balance, try to avoid a lot of dead space and playtest thoroughly!!
-Replays: So far these appear to work splendidly well for mods, but can run into issues if stage layouts cause inconsistent entity behaviour (e.g. the circling enemies from stage 1/"Kagomes" will behave buggishly if they encounter any solid tiles). Replays are auto-generated for every new game, and end upon any sort of termination, including resetting or exiting.
Ask away if you want to discuss anything else, it's what we're here for after all.
Remind me to update the docs about this later, but for now...
The .gux files do work, and saves all the info seen in the right panel of the main window.
The save button in the main window is just for the project file, it doesn't save any game files, that's what the save buttons in the stage/attribute editors are for.
I'm assuming this is referencing entity 118 "CreditLoadImg"? I have actually tested this, it works.
The "ExtraInfo" is the stage number's sprite sheet to be loaded.
To give an idea of a benchmark, most people find even the original game fairly hard to beat. You can probably get away with something slightly more difficult if it's only a stage or two long. Moreso than Cave Story modding I think this is going to be a lot more dependent on personal preference, along with experience garnered from further testing as more people get involved. The basic tips I would offer are avoid sudden lurches in difficulty, take some heed of my other notes about weapon and speed balance, try to avoid a lot of dead space and playtest thoroughly!!
