any chance of an update to kHuds

Lavenblade wrote:

An engine is only as 'powerful' as the programmer.

A internal combustion engine is only as powerful as the mechanic.

Flick wrote:

Well, it's a start. Getting it to work the way I want is going to require rewriting pretty much the entire generation routine.

All I can see is Barney the dinosaur's leaky butthole.

You might want to back up a bit...

Been working on something in super top secret conditions.

All resemblance to Dragon Warrior I for the NES is completely intended. This isn't going to be released as a game, but the final example product for a tutorial. (Noncommercial educational purposes = Fair use, motherfucker.)

I'd like to show off a neat technique that if you were paying attention to Snippet Sunday #2 and #3, you'd have seen coming.

Not a single NPC in the game is hard-coded. They are all instanced objects created using the map editor and a very tiny scripting language that is extremely easy to write.



This is the Tantegel castle throne room.

Chests are loaded with items by playing an item instance on top of them. The items will automatically detect what is beneath them and update responsive objects accordingly upon world creation. When we edit an item, these are the properties we care about:



The important ones are "respawn", "searchable", "amount", and "amount range". Amount/range allow you to specify a number of items: amount+ rand(0,amount_range)

Respawn allows you to specify whether an item should cause the item to respawn every time they enter an area (1), never (0), or (-1) every time they enter the area, but only after the first time the item at this location has been picked up. Half of the time they enter a map region (2), a third of the time (3), etc.

Searchable allows you to specify whether an item is laying on the ground and can be picked up. Otherwise, the item assumes it's supposed to be in a chest or in a shop.

Doors are also kind of interesting. Doors have an id variable that lets you specify which quest flag is set when the door is unlocked. This allows you to actually have several doors that all share the same flag and thus are all unlocked at the same time by unlocking just one. The uses for this aren't apparent yet, but it is useful.

Also, you don't have to name a door with a unique id. If you don't bother, the door will assume it is unique and name itself: "[name](x,y,z)" on world initialization, but this might require some savefile editing if you move doors and don't want to wipe player savefiles. Doors with a null id will not save whether they are unlocked or not and will re-lock themselves for that player the minute the player leaves the area.

Teleporter nodes are pretty simple. They contain a variable called link, which contains a string that determines where to send the player. You can use the value of a player variable by typing: "&$NAME;" in the field. Obviously, you need to link staircases in the map editor by linking their tags.

One neat feature is that later in the game there's a room with an infinite stairwell. Since teleporters are one-way linked, it's possible to create an infinite loop with them:



Autotiles also make mapping a breeze. Dragon Warrior only features one tile that's an autotile, but damn does it not simplify the process.



Not only can I autotile single tiles together, but by taking advantage of autotile groups and tile ids properly, I can actually define tiles that contribute inclusively and exclusively to one or many autotile regions.

Setting up an autotile group requires a bit of code know-how, but it could just as easily be done in JSON and loaded at runtime or through a config file:



Shops are constructed dynamically when the player attempts to use them. Items can be individually marked hidden from the player on a per-item basis at runtime. Items also contain a price field that allow you to customize what the shop charges for the item.

Setting up shops takes zero programming knowledge. You plop down a shop counter, you plop your items down on top of it, and the system does the rest of the work for you.

Objects inside of chests and shops don't stick around on the map after runtime. The initialize, stuff themselves into a list, and drop off the map to optimize rendering, view sending, and collision detection automatically.






NPC conversation can be programmed in using the map editor. If you are at all interested in the scripting language, I deposited the current state of it over here in this thread.

http://www.byond.com/forum/?post=2058217




These three NPCs' conversations are entirely scripted using the map editor. In fact, as the scripting language becomes more versatile it also allows more and more of the game logic to be customized and exposes more of the game's engine to the map editor.

The point here is that content can be dynamically loaded into the game at runtime, and if an online editor is built, this could be expanded to multiplayer games to allow developers to create content and test it live.

I don't have to muck with code at all to change what's going on scenario-wise. The new JSON-foo that BYOND is capable of also makes this even easier to do than it ever has been, but I'm only using techniques right now that have been available to me since version 3.5.



This gif shows parts of the UI. It's hardcoded. Before I start work on the tutorial, a bit of work needs to be done to the structure of the UI, but it's far and away more elegant and flexible than anything you guys have seen out of me yet.



This gif shows some other bits of the UI and some more conversations. There's even a bonus bug in play!

And the last thing I'm going to show off is the way that the towns are separated in the map editor.

The player's viewport is 17x15 tiles. That means that on either side of the player there are 8 tiles of viewable area. Towns have a bunch of white space surrounding them in the map. I didn't want to split my towns onto layer 2 of the map. Everywhere that is whitespace at the edge of town will teleport you to the world map. When you enter a town, each town has their own edge "graphic" that you can define by doing a little bit of editing of the area prototype.

Every player has three /image objects that they keep on hand. One is for changing the visual appearance of the blank space, one is for hiding rooves, and one is for hiding outdoor areas when you enter a building.



This is Cantlin. and Rimuldar. They both have several indoor areas. Each town is separated by a buffer of exactly 10 tiles. Normally, I'd have to buffer by 18 tiles because players can walk to the edge of town to escape, and that creates the 9 tiles that players can see past the edge of town. Since each town has its own buffer graphics, this means I either have to group like towns with like towns and space out the ones with unique buffer graphics, or I could just use some visual trickery.

So, override images to the rescue. That whitespace is all part of the same area. By moving the location of an override image to that area, the player that owns the image will see a different graphic than is default. Normally, that area and the turfs inside of it are marked invisibility=101. My override graphics just make it visible and are set to the town's edge appearance which I've configured using the map editor. The appearance is generated at runtime and then the object I generated the appearance is discarded, and thenceforth I can simply set image.appearance with a single instruction.

This is what happens when I disabled teleportation to the world map and wander around between towns:



Whenever I enter a town's area, the edge graphic is updated and the blank area goes away. Whenever I walk across to another town (I shouldn't be able to do this, BTW), I can enter that town and enable a different edge graphic.

The edge graphics are fully dynamic.


Anyway, This... Got a little ridiculous. I'm about a total of six days deep on duplicating this game, and it's actually just about finished. I only have a few bugs left to fix, and a few more systems to flesh out.

Look forward to the tutorial series. Not the game. Because I'm not releasing the game. I'm releasing a tutorial for how to make the game.

Ter have you ever considered writing a novel?

Ter that was a fantastic read, not only out of excitement, but more out of a completely fresh and enlightening approach to handling problems. Lots of 'tricks' I suppose, that make me want to go throw up my own small rpg to test them out and how you'd wrangle them.

Thanks a lot man, I doubt it gets said enough to you, but you're a hero around here.

Frackin' adorbbable. A2J2's art for the turf/objs?

Point taken xD.

Ter13 wrote:

I want to hear about obscure and possibly questionable uses for bitshifting

Like using it to add two numbers large enough that you'd lose precision without it?