⚂ But do the random phrases cache
Above: in-game view. Below: taken screenshot of entire room
Fairly big, fairly maze-y, has some rooms, and takes little time to generate
This is a small update to my 2010 dungeon generator example.
The main change is that it now treats high values of "cut dead end" parameters correctly, no longer placing unconnected rooms even if there's enough space to allow that.
Also there's now a small demo on how to use the resulting data, placing some walls and a player to wander around as.
Update: Also see this post about this approach to dungeon generation.
In some cases, a moment comes when you need to display specific content in a area smaller than itself, thus requiring scrolling.
GameMaker does not support 'clip rectangle' type of command for its reasons, however it is easy to 'clip' area to be drawn by using an 'buffer' surface to draw content in, before drawing that to screen.
Attached example illustrates sample implementation of such.
Most often, content of such would be text. And maybe an image. Or two.
Since images would require a bit more code, example does simple and efficient - long long text is rendered into a surface, which is later drawn into an other 'buffer' surface to display it as part of window on screen.
Also there is a scrollbar, which obviously can be improved, if it needs to serve purposes other than displaying position of 'window'.
Can be seen as a part of those block-building games
So, today comes with an example of collision between point, box, and line versus a 3d array.
3d array is presented as ds_list (z) with ds_grid's (xy).
Functions include management of this 3d array (creation, destruction, modification - no memory leaks included) and actual functions to check for different collisions.
All of these also include error handling, so attempting to check for collision outside the 'map' will threat area as 'air' (0) and not crash the game.
Also note that no optimization was applied to process of block rendering - you'd likely have to change that if basing game with large level on this example.
As you might have noticed, process of making nice-looking isometric games can be tricky.
Especially that part when you want your terrain look like actual terrain rather than arrangement of isometric images.
Common approach to this is to use alpha channel mask(s) to smooth edges of tiles.
Here I've made a script that applies such mask to given sprite, handling all additional actions needed.
While working with GameMaker, you might have noticed that all collision_ functions return only first instance to intersect given collision shape, while in some cases you'd want to get all instances that collide with one.
This set of simple scripts adds such missing functionality...
You might have met such situations where you need to find nearest coordinate at object's edge towards a point, or find actual (non-bounding box) distance between objects, or other things of this kind. If so, you may find this example useful.
Used method is relatively simple - first find approximate distance with distance_to_point function, and then 'fix precision' by using a 'while not position_meeting' loop.
This way maximum amount of calculations will be limited to cP * iR + dP, where
cP is time needed to check object for collision against a single point
iR is instance 'radius' (maximum distance from origin to corner of bounding box)
dP is time needed to find distance between object's bounding box and point
So it should be acceptable for many cases of usage. If you need to reduce amount of calculations further, could alter distance decrementation 'rate' in two while loops. Removing while() loops entirely would give rather approximate distance calculation.
Image: Those awesome futuristic tiles by Morphosis, now in a single aligned image.
I've always found standard resource packs that can be downloaded from site of YoYoGames, however rarely ever used something from them because it took multiple minutes to simply look through everything in there in attempt to find something matching.
So, decision was made to improve the situation a little bit, at least for myself.
Changes include graphics being sorted into categorized folders nicely, transparent background color in graphics, relevant tilesets being merged into larger images, and more. Overall, if you've ever considered using original pack, you might find this useful as well.
See ReadMe for more information.
In some rare cases, you may need executable to 'vanish' (delete itself) upon shutdown.
The most trivial case for such behavior would be updating (when never version of game is downloaded, and there is no reason to keep old one).
Less common cases include removing game under specific conditions (note: this is not an appropriate way of stopping user from playing it) and single-use utilities (which user will never need to run again for sure)
However, as you may noticed, executable's cannot delete themselves while running.
So, some tricks are needed.
The easiest one is to have second executable to run afterwards and delete the first one.
To illustrate source of such 'clean-up' program, I have used language that provides smallest output file size, while still keeping it readable. In this case, it's C++.
#include "windows.h" #include <tchar.h> int APIENTRY _tWinMain(HINSTANCE ii, HINSTANCE pi, LPTSTR lpCmdLine, int ncs) { for (;;) { if (DeleteFile(lpCmdLine)) return 0; Sleep(100); } }
(you can download compiled version of this code here)
Structure of code is quite simple, as you could notice - we include two required headers (windows.h for used functions and tchar.h to allow main function definition to be written this way); main function itself consists of a perfectly infinite loop (heard of these?) in which program attempts to delete file given by command line and quits on success, or waits 0.1 second and tries again.
Integration on GameMaker side is simple as well - all you have to do is to run program described above just before game ends with game's executable location as a single argument. Fortunately function parameter_string(0) can be called to retrieve mentioned location, so code can be minimized to
execute_program('DeleteThat.exe', parameter_string(0), false)
Obviously, this way you will have a secondary executable remaining upon success of all operations, which user will have to delete manually (or not delete at all, in case of use in updater).
To save user from potential wondering about purpose of small executable that appeared after game's end, it can be unpacked into game's temporary folder.
Example illustrates typical setup for such game: secondary executable is included inside of game, and is unpacked & launched at game end. To test it, compile game into executable file, run it (in this case it's just a placeholder window) and close it by pressing Escape or window button - executable will vanish in moments after process termination.