In response to Kozuma3
any chance of an update to kHuds
In response to Kozuma3
Kozuma3 wrote:
I've quit progress on Elora to learn JS and get familiar with it as I'm jumping ship to work with a more powerful "language" and switch to Aaiko's project.

An engine is only as 'powerful' as the programmer.
In response to Lavenblade
Lavenblade wrote:
An engine is only as 'powerful' as the programmer.

A internal combustion engine is only as powerful as the mechanic.
Well, it's a start. Getting it to work the way I want is going to require rewriting pretty much the entire generation routine.
In response to Flick
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.

In response to Rushnut
lol
In response to Rushnut
You might want to back up a bit...
In response to Flick
I might need to revisit this once it's updated to see if I can do this kind of stuff for the AI characters in Lux. Currently they're generated on the fly, but I imagine it wouldn't hurt to save a good deal of their appearance as an icon.
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:

var
list/autotile_groups = list(
"water"=list("water" = 1, "bridge" = 1)
)


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.
Oh, and I forgot to mention. All that UI business is done almost entirely with maptext. The only screen objects are the cursors and the background boxes. Each box uses eleven to thirteen objects only, and they use matrix transformations to scale and position themselves rather than tile repeating using screen_loc.

I created a pixel perfect font that was an exact imitation of the Dragon Warrior NES font, and wrote some code that lets me do a lot of neat things with it that otherwise wouldn't be easy to pull off.

Definitely excited to finally compile all the useful shit I've learned how to do in BYOND into a single-track comprehensive: "HOW I BYOND" tutorial series.
In response to Ter13
Ter have you ever considered writing a novel?
Ter have you ever considered writing a novel?

Give me one ritalin, one adderall, exactly three marijuanas, a case of soda, and some superglue to cover the raw spot in my left thumb from all the typing I just did and yeah, we can talk about that 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.


boop
Frackin' adorbbable. A2J2's art for the turf/objs?
It's actually a tile set that I found online. I honestly haven't even looked at the creator (or usage rights).


Edit: Created by a 'Buch' on OpenGameArt
In response to Ter13
Point taken xD.
Rushnut wrote:
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.

And here I was worried that I'd sort of rambled myself hoarse. I love above anything else the prospect of figuring out how things work.

If you decide to make a JRPG, I'd really recommend keeping it simple. Something you can write the core engine for in a month or less, and stick to filler grinding rather than story.

It's damned rewarding. And hell yeah, I'd be game to see what solutions you come up with. Creative solutions and listening to the logic behind programming decisions is damn awesome when you are talking to someone that can keep pace.

Listening to ideas about "Like, my game will have player housing and guilds and stuff"... Blech. I want to hear about obscure and possibly questionable uses for bitshifting, lookup table structure, jagged array parsing techniques, and other things that make designers/artists pass out from boredom.
In response to Ter13
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?

In response to Ter13
Maybe I should serenade you about our game's almost entirely database-driven game logic ;)
Page: 1 2 3 ... 161 162 163 164 165 ... 342 343 344

Login to reply.