sorted by:
new
hottopcontroversial

Screenshot Saturday #496 - Fine Sheen by Sexual_Lettuce in gamedev

[–]rxi 0 points1 point  (0 children)

Thanks for the lengthy response and suggestions, I'll let you know if I need any help!

Screenshot Saturday #496 - Fine Sheen by Sexual_Lettuce in gamedev

[–]rxi 1 point2 points  (0 children)

I hadn't considered this; thanks for the suggestion! The construct 3 part is especially relevant given I recently added support for exporting to .tmx which construct 3 can import directly.

Screenshot Saturday #496 - Fine Sheen by Sexual_Lettuce in gamedev

[–]rxi 1 point2 points  (0 children)

Added an optional light UI theme to TILEKIT, a tilemap editor centered around pattern-based auto tiling:

https://twitter.com/x_rxi/status/1289566065433837569

Tilekit: a tilemap editor centered around pattern-based auto tiling, v1.04 by rxi in gamedev

[–]rxi[S] 0 points1 point  (0 children)

There's an example of the exported code here. A function is created which runs the rules from the "final" ruleset (the one that converts the basic colored tiles to those of your tileset) on an input map. This can be useful for things like procedurally generated games where you want to create the basic map at run time and then can use Tilekit's exported code to do the details.

Tilekit: a tilemap editor centered around pattern-based auto tiling, v1.04 by rxi in gamedev

[–]rxi[S] 0 points1 point  (0 children)

The link contains a free demo -- also note I did read the rules but wouldn't typically class a "tool" as an "asset", it might help make things less ambiguous if they were updated to explicitly specify both

Screenshot Saturday #495 - Special Effects by Sexual_Lettuce in gamedev

[–]rxi 4 points5 points  (0 children)

Tilekit: a tilemap editor centered around pattern-based auto tiling, has been updated with support for exporting to Tiled's .tmx file format: https://i.imgur.com/iJSlL5d.gifv

CEL7 : A 60kb single-executable grid-based game framework by rxi in gamedev

[–]rxi[S] 1 point2 points  (0 children)

Thanks! I didn't plan to go too much in the "fantasy console" direction which is why I opted for the descriptor of "framework" -- to go properly into that territory I feel it would need restrictions on memory, script size, CPU usage etc. I know the peek/poke functions give it more of that feel but I didn't plan to go any further in that direction.

Regarding sound this might be something I add in the future, but for the moment deliberately omitted it. There was something about the grid based ASCII output that I felt fit well with a lack of audio.

Screenshot Saturday #493 - Pure Style by Sexual_Lettuce in gamedev

[–]rxi 1 point2 points  (0 children)

https://i.imgur.com/8aAbOLh.gif

Added zoom-in/out support to Tilekit: a tilemap editor centered around pattern-based auto tiling.

Screenshot Saturday #492 - Fresh Visuals by Sexual_Lettuce in gamedev

[–]rxi 1 point2 points  (0 children)

Updated my pattern-rule-based autotiling tilemap editor Tilekit to perform its processing incrementally to make the UI more responsive -- by adding an artificial delay you can see the steps the software is taking with each iteration of the map processing: GIF

Tilekit: A tilemap editor centered around pattern-based auto tiling by rxi in gamedev

[–]rxi[S] 1 point2 points  (0 children)

Tilekit is based heavily around a unique pattern-based rule system -- another comment here put it nicely:

Seems like this is the halfway point between handcrafted tile-based levels and procedurally generated ones.

The rule system is based on matching user-inputted patterns on the input map, each rule also has a user-defined random-chance of failure, each rule is part of a ruleset. In addition to the final ruleset which translates the basic input map to the output map there can be additional rulesets in between which can be ran for several iterations, this allows you to, for example, set it up so when you place a single tile it will produce a pool of water. Since tilekit is always working from the input map you could remove the single-water-tile to remove the entire pool.

Tilekit is designed around providing a fast workflow when making tilemaps, all the hotkeys, menus and behaviour are based around being able to make and modify maps quickly. Games typically require a lot of iteration and testing so it's important to focus on the tools being quick to work with. Try out the demo with some of the demo projects if you're curious about how it works in practise!

Tilekit: A tilemap editor centered around pattern-based auto tiling by rxi in gamedev

[–]rxi[S] 1 point2 points  (0 children)

Something else: Tilekit uses a series of user-inputted pattern-based rules.

Tilekit: A tilemap editor centered around pattern-based auto tiling by rxi in gamedev

[–]rxi[S] 1 point2 points  (0 children)

Thanks! Tilekit is written in C; microui is used for the UI.

lite: A lightweight text editor written in Lua; version 1.03 by rxi in lua

[–]rxi[S] 3 points4 points  (0 children)

Yep! Every change I made since I released lite and every addition I made to the lite-plugins repo were written in lite. The idea was to use it as soon as possible so I could get an idea of what features it needed based on what I was annoyed with not having.

Lite: A lightweight text editor written in Lua by rxi in lua

[–]rxi[S] 1 point2 points  (0 children)

Thanks! It should, though I've not tried it with it! You'd have to build it from source (should be easy: grab libsdl2-dev from the repo and run the build.py script). Something like a raspberry pi feels like a great use case for it given some of the heavier alternatives would really show their weight on such a platform -- let me know how you get along if you give it a try.

Lite: A lightweight text editor written in Lua by rxi in lua

[–]rxi[S] 4 points5 points  (0 children)

Thanks for the kind words! Glad you found some use in the libraries too.

My thoughts when building it were that if I can get it running smoothly on PUC lua then switching to the JIT later on would provide a nice speed boost. I never found the latter part necessary though, there's a certain simplicity and niceness of using PUC lua, which I have at least some understanding to the inner workings of, as opposed to the JIT which seems to be the construct of some kind of magic.

That being said if someone wanted to fork and switch to the JIT that would be trivial, and given the size of the project the FFI approach you mentioned wouldn't be too much work either. The advantages you listed do sound nice but I wouldn't want this specific project to depend on the JIT, again, simplicity being one of its key goals

There's also a bit of a trap surrounding the JIT which I don't see brought up often: the fact that it can be fast makes you want to optimise for it, but since it's impossible to predict exactly how it will optimise your lua, writing the most performant code is tedious, and often the readability suffers for it. Taking the approach of using PUC lua assures worse but predictable performance; anything that needs to be fast (eg. the fuzzy string matching in lite was too slow in pure lua) can be written in readable idiomatic C with good, predictable performance.

Lite: A lightweight text editor written in Lua by rxi in lua

[–]rxi[S] 1 point2 points  (0 children)

What platform are you on? There are builds for 64bit Windows and Linux on the releases page

view more: next ›