ID:114073
 
Tiny Heroes

I've been working on Tiny Heroes again. I really need to plan out what character classes will exist and what abilities they'll have. Before this is done I can't make too many maps because the maps depend on what abilities your character can have. I don't want to create a dungeon that relies on you having a wall-climbing ability if some classes won't have one.

Still, there's plenty of work to be done. I've been working on enemy AI because it's one of the areas my pixel movement library is light on. I want to be sure that the library gives you everything you need to create AI and so far it does.

I'm still undecided on how heavy I want the RPG elements to be. I like old-style games where you don't know how much damage you do or how much health enemies have, but you learn through experience how many hits it takes to kill an enemy (think Crystalis). Unfortunately I think I'm in the minority there and most people would prefer to see the numbers.

Here are some new screenshots. I'm reusing the tiles from Exordium & Terminus a lot but I also have a lot of new tilesets ready.



Hopefully I can pin down definitions for character classes this weekend and start making more content.


Pixel Movement / Sidescroller

Initially, both of the libraries had support for fractional moves. You could set the mob's vel_x to 3.5 and it would move three and a half pixels each tick. Because it can't display half a pixel, your client would round these (so you'd appear to alternate between moving 3 pixels and 4 pixels), but internally you'd be moving 3.5 pixels per tick.

Unfortunately this created some problems so I had disabled it. A couple of updates ago I added it back. I noticed it caused some issues with the camera. Because of how the rounding is done, there's some jitter - the camera will shift by a pixel when it shouldn't. I'm working on fixing this. When I get a solution I like, I'll update both libraries.

There were also some issues with the pixel movement library's handling of sloped tiles. I'm working on fixing these issues and should have an update ready this weekend.


Static Lighting

I'm not sure why people make such a fuss about static lighting. Maybe I'm just pessimistic, but the "static" part draws more attention than the "lighting" part. I don't see the nice shadows, I see a bunch of objects that mysteriously don't cast shadows (makes sense in a vampire game, I suppose). I don't see objects that are light sources, I see objects that should be light sources but aren't (ex: a lamp acts as a light source but an explosion doesn't because it would have to be dynamic).

That being said, I think that something similar could be used to make simple environments look more natural. For example:

Before:


After:


I've always said that the graphical quality of a game isn't just dependent on the quality of each individual icon, it's how you use the icons that matters. Both screenshots use the same icons but the second image looks much nicer. With some simple techniques you can get the most out of graphics you make yourself. Before forking over $3 per icon to a self-proclaimed pixel artist, think about what you can do to get the most out of your own icons.

Here's the code for the program used to generate these images. It's written in Java: shadow.zip

It needs some fixing up before you could use it for a game. I'm mostly posting it for DarkCampainger, but other people might be interested.

Here's an example of this being applied to Tiny Heroes:




Flash Client

There's been some chatter about the Flash client lately. Maybe this is another example of me being a pessimist, but thinking about the Flash client always makes me think about the problems it'll create, not the ones it'll solve:

1. I'm not sure why it's needed.

It's a very old mentality that says people won't download and install something to play a game. There are tons of awesome indie games you have to download, and some of those are really old (ex: Within a Deep Forest is 5 years old). Having to download/install BYOND in addition to downloading a game isn't a new concept either. Gamers have been installing DirectX with games for a long time now. Sure, the Flash client makes BYOND games more accessible, but is that a good thing...

2. In some ways, it makes BYOND look worse.

By being just a client, Flash client users must connect to remote servers. This means that any game played in the Flash client will have lag, and it won't be clear to the player where the lag is coming from. Many multiplayer games manage things on the client, so even in times of high network latency the game client is still responsive to user input. This isn't the case with BYOND, everything is handled on the server, but people who don't understand BYOND won't understand that.

It also begs for direct comparisons to be made between BYOND and Flash, and in terms of graphics, Flash wins without a doubt. BYOND offers very little that Flash doesn't.

3. BYOND's strength is that it's not Flash.

By making a Flash client for BYOND games you're saying "anything you can do with BYOND you could do with Flash" - BYOND becomes a strict subset of Flash. BYOND is a standalone piece of software and this should be used to its advantage - make the program fast, make it portable, and make it to things that Flash can't.

4. It creates development problems.

For the BYOND staff to add a new feature they either have to add it to both Dream Seeker and the Flash client (which takes more time than just adding it to DS) or they have to say "it's not feasible to add that to the Flash client" and only add it to DS, in which case the feature is less useful because you can't rely on players having access to that feature. Or, to ensure that both clients have similar features, potential DS features could be scrapped because they can't be supported in Flash, and in this case we clearly lose out.


A Miner Adventure

A very small part of my brain, way in the back, is constantly thinking about the next update for A Miner Adventure. I'd like it to be a new mode similar to the current adventure mode. I'd like there to be more exploration and some re-use of content. In the current adventure mode you progress through a map that's essentially linear. Sure, there's scenery to look at as you play through it, but you can generally forget about things once they're off the screen. You never really need to go back through a place you've already been. I'd like for the next adventure mode to address these problems.
I flippin' love Crystalis. It brightens my day to see someone reference it :3
The lack of installation is a benefit of the Flash client, but that isn't the main one. The big gain is the ability to give games more exposure. We need to get away from the mentality of only advertising games on BYOND, because we're a tiny community with niche interests. There are some pretty good games here that never get played because they aren't catered to our audience (mostly children into Anime). If we can get those games out into the mainstream they might have some success. Flash gives an avenue for that because it can be used with social networks (Facebook) as well as gaming-specific sites like Kongregate and ArmorGames.

That said, I am having some reservations about the UI of BYOND games in a Flash environment, since there are certain expectations about how modern games (even modern hobbyist games) should look. We may end up doing a map-only system (with limited input & output options) and focus on improving the drawing control. This may also be a spinoff of the BYOND system entirely so that we don't have to worry about keeping the web and main clients in sync. A lot of it is still in flux because I have to determine what is really do-able in our time frame. I think this has the potential to be a pretty powerful product given the numbers of users already playing pseudo-multiplayer games on social networks, and possibly one that could garner us some outside investment.

As of now, we have most of the map system working in the Flash as well as some hard-coded input/output. Verb handling, stats, etc all work but I think it's an outdated model that I'm leaning towards not propagating here.
It seems like there are some other features that could give you more bang for your buck. There are even some non-features that could help out (ex: my previous blog post) - you don't need to change BYOND itself to improve it. I understand how the Flash client can improve exposure (though I'm skeptical of how it'll go), but it seems like there are other (better?) ways to improve exposure.

I guess it's because I've always hated Flash that making a Flash client for BYOND sounds like the most horrible work ever. I wouldn't take on such a task unless I was absolutely certain it would payoff (ex: world peace, cure cancer, etc.), but it sounds like you enjoy working on it.
Thanks for uploading it. I'll try to learn from it to improve my generator's output, if you don't mind of course :)

As to the Flash client, I think BYOND games would have an edge in their multiplayer support; that's not very common in Flash games, and not often implemented too well.
DarkCampainger wrote:
Thanks for uploading it. I'll try to learn from it to improve my generator's output, if you don't mind of course :)

I don't mind at all. The code is sparsely commented, but if you'd like a better description of what's going on then just post on my forum and I'd be glad to give a better explanation.

There are a few issues with it that I noticed since I uploaded it. It assumes that all dense pixels have height. Also, when you output to file, it assumes the output is 512x384. Also, when you output to file, the resulting .png image doesn't use the alpha channel (which you'd need to use if you were going to import the PNG into a .dmi).

As to the Flash client, I think BYOND games would have an edge in their multiplayer support; that's not very common in Flash games, and not often implemented too well.

The problem is that built-in multiplayer support is a benefit to the game's developer, not the game's player. The game players are going to notice that, for a Flash game, the graphics are below average. The players aren't likely to ever notice that the game's developer saved a lot of time by using BYOND to handle the multiplayer aspect.
My last blog post was about creating a document that would explain appealing aspects of BYOND to experienced game developers. If anyone's interested in working on this, I took a crack at it. Here's the current draft: http://files.byondhome.com/Forumaccount/dev-guide.html

Its purpose is to explain BYOND to people who have experience with game development, just not with BYOND. BYOND has a lot of selling points, much more than being multiplayer. A lot of these points get overlooked because BYOND/DM attracts many first-time game developers and they don't know how good they have it. If you don't have any serious experience in other forms of programming or game development, this probably won't make much sense to you.
I think that is great and I'm glad you are being proactive with this. Assuming you don't mind, I'd like to repost that to the dev intro page.
As far as the Flash goes, I agree that BYOND may get a bad rap if the games have a consistent low-quality feel about them (part of the impetus of BYOND 4.0 was to get away from the immediate recognition of games being "BYOND games" via their identical interface, but the windowing environment is still problematic). That's why I've been thinking about just spinning this off to a separate project so that, at least graphically, games might fall more in line with what people expect. Maintaining that and compatibility with all existing features would be too much to handle. The hope would be that someone could easily port their existing BYOND game to Flash though.

Certainly using BYOND is going to have some negative consequences due to the inability to process most things client-side. However, given the dearth of multiplayer Flash games I don't think this is a big deal. The audience for these games is different than, say, the audience for X-box games (where a premium is put on the glitz and response time). I really do believe that a game with a great concept can be a big hit even if it is not executed optimally. In fact, I think quite a few of our existing games would appeal to the mainstream if they were aware of them.
Tom wrote:
Assuming you don't mind, I'd like to repost that to the dev intro page.

It still needs a little work. There are some sections I haven't filled in and I'd like to include some pictures.

The hope would be that someone could easily port their existing BYOND game to Flash though.

I agree that this would be neat. It'd be cool to have a playable demo of your BYOND game embedded into the game's site. Even if it had to be a stripped down version because of interface differences, it'd still be a lot more interesting than a gameplay video. I'm not sure it's worth it, but as long as you enjoy working on it.

Certainly using BYOND is going to have some negative consequences due to the inability to process most things client-side. However, given the dearth of multiplayer Flash games I don't think this is a big deal. The audience for these games is different than, say, the audience for X-box games (where a premium is put on the glitz and response time). I really do believe that a game with a great concept can be a big hit even if it is not executed optimally. In fact, I think quite a few of our existing games would appeal to the mainstream if they were aware of them.

If the BYOND server has the default world.tick_lag, you'll have to wait 50 ms (on average) for your input to be processed. Your ping time gets added onto that, so a response time of 100-150 ms would be considered quick. On a crowded server it might be closer to 200 or 250 ms. This isn't necessarily going to ruin the game (though, when you consider how overloaded a server can get when the game is discovered, it certainly could), but it'll be annoying enough that (even in a lightly congested server) players will think "the controls are unresponsive, boo!" before they think "I'm playing with other live people, neat!"

I guess I'll just hope that the Flash client brings more attention to BYOND and all the new users download the software so we don't have to worry about Flash anymore :-)

Edit: When you consider how poorly games with dedicated servers can handle a large influx of players, I believe that distributing games that people can run or host locally is the way to go. I'm not sure how easy it is to distribute a BYOND game to people who don't already have BYOND installed. I know there's a "Make EXE..." command but I don't know how effective it is (from the number of forum posts I've seen about it, it doesn't sound super-easy). It'd be nice to know that this distribution method is getting the same TLC that the Flash client is getting.
Well, don't forget that another bonus of the Flash client is multi-platform support. Games won't just be limited to Windows anymore.

As to the server scaling issue, I was thinking about the same thing. When posted on a large Flash portal, the "multiplayer" buzzword is likely to draw enough players to bring just about any BYOND server to its knees. I was thinking someone should write up a server manager/lobby system, where players initially log into a *simple* lobby server, and are then forwarded to another server. As the server fills up, the lobby program would start up another and forward players to that one instead. If the maximum number of servers are running that the host(s) can handle, display a message suggesting they go to the game's website and host their own server.

Also, Tiberath wrote an article on how to distribute your game so your users don't need to install BYOND to host/play

Metamorphman also wrote an NSIS script to compile the zip file into a single nice and neat EXE. (I'm not sure if that link is his most recent version of it, though. Should probably check his blog)
I was thinking someone should write up a server manager/lobby system, where players initially log into a *simple* lobby server, and are then forwarded to another server.

Without some kind of shell hosting service, I expect the problem would be that once you get a load of users, starting more servers running on the same machine won't do any good. BYOND makes it nice and simple to build and distribute a game, adding the steps: "sign up for a $5/month shell hosting service" and "set up this lobby/loadbalancer thing" kind of ruins that.

Letting people download and host the game is the easiest way to avoid this problem. Unfortunately, the BYOND software isn't the easiest thing to figure out when it comes to hosting. I expect that people will be a little paranoid about opening their computer up to remote connections, especially without a clear way to manage it (there should be an easily accessible control panel that shows if the game is being hosted, what port it's being hosted on, who is connected, and have options to close individual connects and to stop hosting).

With things like world.OpenPort() you can create in-game ways to manage hosted instances, but there are problems with creating, finding, and joining hosted instances of a game: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=2333