Forum_account's site

BYOND + Frameworks = Good

Sat, 14 Jul 2012 19:38:47 +0000

BYOND is not a general purpose programming language, it's specifically for making games. This makes it possible for BYOND to make game development easier than C++ and Java could because those languages are general purpose - they don't provide you with maps, networking, movement, and procs like view() or obounds(). When it comes to game development, BYOND *is* general purpose. You can use it to make action games, RPGs, platformers, board games, card games, racing games, and realtime strategy games. This is a good thing but it also limits how easy BYOND can make game development.

It's not because BYOND is lacking. Look through the feature request forum - there are lots of good features being requested that'd improve BYOND's capabilities or provide conveniences to developers, but very few of the features would really make it easy to create a game. Even if all of those features were added you're still going to have to write 2,000 lines of code to make a game. That's just the cost of being flexible enough to produce such a variety of games.

If you want to have a development environment that truly easy to use, BYOND can't take you 100% of the way there. It's a solid foundation but it only takes you 70-80% of the way there. As you might have guessed already, frameworks are the way to bridge that remaining 20-30%. By making a framework for a specific type of game you can provide features that BYOND would never provide itself. For example, to make it easy to create an action RPG with BYOND you'd need to provide people with a health var and on-screen health meters but these aren't things BYOND would provide by default.

Here are some benefits to having and using frameworks:

1. Frameworks are appealing to outside users and current users. Showing non-users an example of a BYOND game lets them see what BYOND is capable of but compared to other tools, that'll never be that impressive. BYOND will attract people by being easy to use and frameworks provide a way to show non-BYOND users how easy it is to make a game. The current BYOND community has also responded positively to frameworks so there's no risk of alienating current users (except Falacy).

2. Frameworks let you accomplish more with less time, effort, and experience. They're not just something that inexperienced users can use because they can't make things from scratch. They'd also let more advanced users create games faster. Also, the more easily you can do things the more a tutorial can cover.

3. Frameworks provide topics for tutorials. ZBT is considered to be a good tutorial but it takes 6,500 words to cover some very basic things and, in the end, you've only got a verb panel and a couple of verbs. If you write a tutorial about how to use a framework it too will cover more in less time. The reader will get a more rewarding result in less time. If BYOND game development is supposed to be easy, tutorials that cover simple topics shouldn't be giant walls of text that only show you how to make a verb panel with two verbs.

4. Frameworks make it easier to develop resources. It's hard for people to write tutorials that cover the basics of how to use DM because it's so open ended. Writing a tutorial to show how to create a board game using a Board Game Framework would be pretty easy. It's also easier to make demos that can be integrated with other projects. If you make a demo in DM now, you typically have to build a game around the demo to make it work. If you write a demo that's made for a framework, it'll be able to integrate with any game that uses the same framework more easily.

5. Similarly, they also make it easier to help users. If someone posts a question in the Developer Help forum you might need a lot of background information about their project. If you know what framework they're using it can greatly simplify things. By being familiar with the framework you know a lot more about their project than you would otherwise. It also elevates the level of questions that people can ask. Currently if someone asked "how can I make a building in my RTS that shoots at enemies?" that's an awfully complicated question that nobody could easily answer now. If the developer was using the RTS framework the answer might just be a few lines of code.

6. Frameworks are something the community can work on. The BYOND staff has a lot on their plate and there's really no way for us to help. Frameworks would be projects that any user can contribute to.

7. Frameworks can drive BYOND feature requests. It's one thing to say "I'd like for BYOND to have this feature because I'd use it" and it's another thing to say "I'd like for BYOND to have this feature because it'd let us add this other feature to a framework that 100 existing projects are already using".

8. The presence of frameworks as part of the BYOND package itself gives BYOND a way to guide game developers. People who have no game development experience would have a way to get started and wouldn't be sucked into this culture where you make a base icon, then a title screen, then post on the Classified Ads forum asking for a turfer, GFXer, mapper, and coder to be part of your team. Also, with a way to literally make a playable game of good quality in under five minutes you can create actual standards for BYOND games.

The only catch is that the frameworks can't just be another resource that people may or may not ever find - they'd have to be treated as part of BYOND. It'd take some work but it'd make a huge difference. Here's all it'd take:

1. A menu that's shown when creating a new environment in Dream Maker that asks the user what type of game they'd like to make. Picking a genre creates a project and automatically includes the appropriate framework. There may also be options to include a sample game that would add a few files to the new project - this would let people compile and run a game to see what the framework provides. There'd be an option to create a blank environment if you don't want to use any framework.

2. Reference pages for vars and procs defined by frameworks. To the developer there shouldn't be any difference between using a proc that's part of a framework and using a proc that's part of DM.

3. Dream Maker might need a way to download content from the hub. Dream Maker could come with some version of the framework when you download and install it, but since BYOND and the frameworks may be updated independently, it would be nice to have Dream Maker able to download the latest version.

4. The staff might have to come up with the list of genres and spend some time reviewing the frameworks before including them in BYOND. If the community is developing these resources, the staff could get a lot of help from the community with this work.

There are many things you could change about BYOND that'd have a positive effect, but simply having a positive effect isn't always enough. Some things would only have a minor effect, some might take a long time to develop, and most wouldn't do much to make it easier to create games with BYOND. The Flash client for example may have a high impact but it also has a long development time and doesn't make it easier to develop games. Other features that would increase BYOND's capabilities (like adding a 3D display mode) are similar - large impact, long development time, no easier to develop games. The changes described here would have a huge impact, small development cost (by the staff), and would simplify game development more than any other feature I can think of.

Thoughts?

Version 10

Sat, 07 Jul 2012 11:45:07 +0000

This version has a lot of changes but there aren't any major additions. I added the info bar, which is shown across the top of the screen and can be used to give info/hints/tips to the player. I also added health and mana regen, the mob.number_prompt() proc, the ability to drop items on the map and pick them up, and made the ability menu capable of showing multiple columns when you have a lot of abilities.

The biggest change was mostly internal. I re-did a lot of HUD stuff to make it easier to create custom HUD screens that look and function like the other ones. By creating an object that extends /HudBox, you get access to some procs that are useful for creating panels and list boxes. There's an example in demo\custom-hud.dm. In about 30 lines of code it creates a window containing a list of your abilities. You can use the arrow keys to move a cursor around and the space bar to make a selection.

Note: This version requires the latest version of the HUD Groups library, which was also posted this morning. I also updated the Pixel Movement library but I don't think anything here relies on that update.

Here is the full list of changes:

Added the info bar which is shown at the top of the screen. Added the Constants.KEY_INFO_BAR var, which is "h" by default, that sets focus to the info bar. While it has focus you can use the Delete key to remove messages and the arrow keys to cycle through them. The Esc and H keys set focus back to the player.
You can use the mob.info_bar.add_message() proc to show a text string in the info bar. You can use the info_bar's remove_message() proc to remove a message. There are examples of this in demo\help.dm.
Added health and mana regeneration. The mob.health_regen() and mob.mana_regen() procs are called periodically when the mob is below their maximum value. By default these procs do nothing but you can override them to call gain_health() and gain() mana. The sample game has an example of this. Note: the regen procs are only called if you're below your max health/mana value.
Added the Constants.REGEN_TICK_LENGTH variable which is the number of frames between calls to health_regen() and mana_regen(). It's default value is 40 so these procs are called once per second.
Increased the mana cost of Fireball in the sample game so you can notice mana regeneration more easily.
Increased the default layer of objects created with the atom.effect() proc to be the atom's layer + 10 because there were still some layering issues with these objects and equipment overlays.
Added the "attached" named parameter to the atom.effect() proc. If you call mob.effect("something", attached = 1), the object will follow the player as they move.
Changed the Quest.complete() proc to be called "is_complete" instead.
Added the Quest.acquired(), removed(), and completed() procs. acquired() is called when you receive a quest, removed() is called when you abandon or complete a quest, and completed() is called when you complete a quest. By default these don't do anything but they let you add custom behavior to getting or losing quests.
Added demo\help.dm which shows some ways to use the info bar to create context-sensitive help messages to a game.
Added the mob.number_prompt() proc which is similar to text_prompt() except you can only type digits.
Changed the way text and number prompts are handled internally, but this doesn't change how they're used.
Added the show_caption var to the HealthMeter and ManaMeter objects. When this is set to 1 it'll cause the stat's value and maximum to be displayed to the right of the meter. It is zero by default but the sample game includes code in demo\mobs.dm to set it to 1 for both meters.
Added the ability to drop items on the map. When you call mob.drop_item(item), the item will be placed on the map. It'll be displayed using its map_icon and map_state vars.
Previously, mob.drop_item(item) would set the item's loc to null and cause the item to be deleted. If you want to simply remove the item from their inventory and delete it, you can call mob.remove_item(item). This will set the item's loc to null.
Added the item.pickup var whose value can be item.WALK_OVER or item.INTERACT. This determines how the item is picked up - by walking over the item or by interacting (pressing the space bar). The default value is INTERACT.
Pressing D in the inventory screen makes you drop an item. Pressing the Delete key removes the item and deletes it entirely.
Made the ability menu able to show multiple columns in case the player has many abilities to choose from. The height of each column is determined by the AbilityMenu/size var which is 8 by default, but is set to 4 in the sample game so you'll see multiple columns there.
Added the AbilityMenu/show_ability() proc which takes an Ability object as a parameter and returns 0 or 1 to determine if the ability should be listed. This way you can limit what abilities are shown when the player is customizing their key bindings (ex: you can hide their crafting abilities from that menu and provide a separate interface to access them).
Added an outline to the item description text in the inventory screen to make it more readable when the caption is over top of a bright item.
Changed some things about on-screen interfaces. The HudBox object which many interface elements extend now contains the box() proc which is used to create the background of each window instead of creating the box using parameters passed to the New() proc.
Added the party.size_limit var which limits the number of players that can be in a party. The default is zero, which means there is no limit.
Added the party.invite_player(mob) proc which is used to invite players. This proc enforces the size limit. You can still call the mob's invite_player() proc since it calls the party.invite_player proc.
Added the HudGroup.focus() and close() procs. By default these do nothing but they're commonly defined procs that might come in handy for defining the behavior that should happen when interfaces are opened and closed.
Added the HudBox.panel() proc which creates an on-screen panel. These panels look like the backgrounds of the mob selection menu, inventory screen, prompt boxes, and other interface elements.
Added the HudBox.box() proc which has the same effect as the panel() proc but panel() creates the box as a child HudObject and box() creates it by adding objects to the current HudGroup.
Added the HudBox.list_box() proc which create an on-screen list box that can be used to display a list of objects. The list_box returns a type of HudGroup object. To use the list box you have to pass keystrokes to it. See demo\custom-hud.dm for an example.
Updated the current HUD interface elements to make use of the new vars and procs.

Version 9

Fri, 29 Jun 2012 20:48:26 +0000

The biggest addition here is banking. There's a "banker" NPC in the sample game. Interacting with them calls your banking() proc, which displays your inventory and bank interface. In this interface you use the arrow keys to move the cursor and the space bar to move items back and forth between your bank and inventory. If you move the cursor off the left side of the bank panel it'll move to your inventory (and vice versa). The Esc key closes the interface.

I also changed how medals work. Now medals exist as an in-game thing. If you want to also award them on the hub you can set the hub_name on the /Medal object and it'll be awarded on the BYOND hub too. Medals are now stored per-character, so even though the BYOND hub medals are per-client it's possible to earn the same medals over again on a new character. The on-screen display of the medal being awarded is shown when the medal is new to the character. This also means that you can award medals when the hub can't be reached. If you call the mob's sync_medals proc it'll award them any medals on the hub that are missing.

I also fixed up the way party members are displayed. It now receives events to add/remove party members and to update their health or mana as they change. It's enabled by default. In the sample game, click on a mob to make it join your party. Click on it again to make it leave.

There were some other minor changes and bug fixes. Here's the full list:

Checked for zero values in the health/mana meters to remove a runtime error that could occur.
Made the health/mana meters show one bubble even if your maximum value is zero. If you've got 0/0 health or mana it'll show as one empty bubble.
Checked for a null quests list in hud-quests.dm to avoid a runtime error that would occur when you pressed Q without having any quests.
Added the player bank which is shared across all characters the player has.
When banking, use the arrow keys to move the cursor and the space bar to move items between your inventory and bank. When you're done, press escape to close the interface.
Added an NPC to the sample game that you interact with to access the banking interface.
Added the mob.item_prompt() proc which can be used to ask the user to select an item from their inventory.
Changed how medals work. Medals are now an in-game thing that can be awarded to each character. If you give them a hub_name they'll also be awarded on the BYOND hub, but you don't need a hub to give in-game medals. Each character keeps track of the medals they've been awarded. This also means that medals can be awarded to a player even if they're playing offline.
Added the mob.sync_medals() proc which checks what medals the player has earned and updates the BYOND hub accordingly. Since medals can be awarded even when the BYOND hub can't be reached, you can call this proc to update the hub's record of what medals the player has.
Fixed a bug with the consume_item and remove_item procs. Now they will properly delete stacks when their quantity is reduced to zero.
I also changed the way that has_item and remove_item compare item types. They used to use istype(), which meant that consume_item(/item/potion) might delete an instance of /item/potion/super_potion. Now it uses the == operator so it has to be an exact match.
Adjusted the health and mana meter bubbles so the images are centered in the icons.
Updated the party display and made it enabled by default. Party members are shown in the top-right corner of the screen. The list is updated as party members come and go and their health/mana displays are updated as they change.
You can press the P key to hide or show the party display.
In the sample game you can click on a mob to add or remove them from your party. This is done just so you can test out the party display.
Added "layer" as a named parameter to the atom.effect() proc, its default value is the atom's layer plus five.
Added a trail behind the fireball ability in the sample game. The trail is purely visual, touching it doesn't inflict damage.
Added the KEY_QUESTS constant which is "q" by default. This is the key you can press to set focus to the quest tracker.

I also made a post in the framework's forum about its development. It explains the different ways that features can be added. You can help the framework's development by suggesting ideas or by tackling some of the features yourself. If nothing else, that sticky post will serve as a way for people to see what's going on with the framework.

Crafted Items

Fri, 29 Jun 2012 19:55:42 +0000

I've played through a bit of the game* and I've only made one crafted item. Most of the recipes I see, I usually don't recall ever seeing the ingredients (sometimes I'll recognize one of them). Even if I recognize the item name I probably don't have one nor do I remember where to get it. The one crafted item I made (bone armor) was useful for a while. Is it supposed to be like that or am I missing something?

There's so much content it could be neat to have more of an emphasis on crafted items. Maybe if the game remembered what recipes you've seen or could tell you where to find certain items. Also, if you could go back into a dungeon you've beaten and zone out once you've got the item you need.

* I gave up this morning when I got locked in a room because I misplaced the wire and couldn't open the door to get back out =)

Development

Fri, 29 Jun 2012 12:48:41 +0000

People seem to be very interested in this framework and I'd like to see it grow to become as useful of a resource as possible. Being able to provide people with these kinds of frameworks for making a game is how BYOND will become a game development program that's truly easy to use. It's hard to know how people will use the framework so it's hard to design it, you just need to have people use it and figure things out as it goes along. The more people that use it, the more things we'll realize it needs, and the better it gets.

My goal is for the framework to be a foundation for building any type of action RPG game. There are very few essential elements. You can use the inventory, quests, medals, enemy AI, and implement some character development stuff to create a game that plays like World of Warcraft. You could use the inventory and add character development stuff to make a game that plays like Diablo. You could also make a game that plays like Secret of Mana. You could lose the character development and make a straight-up action hack-and-slash or PvP game.

With that in mind, there are a lot of features that would be nice to provide but don't make sense to add them to the framework itself. Here are three different ways that features can be provided to people using the framework.

Modules - These are libraries of their own that you can plug into any game that uses the framework. They add additional features that the framework doesn't provide. The reason these things exist as modules instead of being part of the framework is:

1. These are less common features. There's no sense in including a mailbox system in all games when only 5% of them will use it.
2. The modules offer options. There could be three different modules you can pick from to display party members on the screen. One might use a very compact display, which would be good for large parties. In a game where you'll only have 3 people in a party, you can use a different module that offers a larger display.

The modules are libraries that you include in your project. They may require some effort to integrate with your game but it should be minimal. For example, to integrate an auction house system you need to create an NPC that shows the auction house interface when the player interacts with them. Each module will come with a demo that shows what you need to do to integrate the module with your game.

Demos - These are things you can already create using the framework. You don't need any extra support from the framework, you just need to use what it provides. This includes different types of effects, attacks, and AI. People can use these demos to learn how to use the framework and implement similar things in their own projects. Demos can be provided as standalone downloads that reference the framework, but aren't libraries themselves. They can also be provided with the framework in its sample game.

Framework - The features that belong as part of the framework are ones that will be widely used and/or can be provided in a generic way. The most essential features need to be in the framework. It also contains highly customizable features, like abilities and conditions, that can be used to create a wide range of things.

Ideas for Modules:

Variable-size inventory
- Changing inventory size at runtime
Items that span multiple slots
Mouse support
Party member display (different styles)
Trading interface
Auction house
Mailboxes
Player-owned houses (that are saved and loaded)
Time of day or a day/night system

Ideas for Demos:

Friendly AI (ex: summoned monsters)
Stun effects
Instanced content
~~Health and mana regeneration~~ (added in v10)
Random stat bonuses on equipment
Help screen
More interesting enemy AI in the sample game

Ideas for the Framework:

~~Support for multiple columns in ability list~~ (added in v10)
~~Info bar (shows on-screen tips/hints)~~ (added in v10)
~~A proc to create graphical effects that follow the player (like animated overlays)~~ (added in v10)
~~A proc for creating AoE graphical effects~~ Coming in v11
~~Dropping items on the map~~ (added in v10)
~~Picking up items and powerups~~ (added in v10)
Graphical on-screen menu for picking from many options
Ability to make custom menus like the character selection one
~~A proc to prompt the user to type in a number~~ (added in v10)
A more easily customizable inventory display
~~Size limits on parties~~ (added in v10)
~~Size limit on the number quests you can have~~ Coming in v11
~~A mob selection menu (ex: player.mob_prompt(list_of_mobs))~~ Coming in v11
A better party menu with options to leave the party or boot members
~~A way to make mobs assist players (ex: pets, summoned monsters, etc.)~~ Coming in v11

These are the things I've come up with myself and from the feature requests I've received. Nothing is set in stone. It might make more sense to implement the info bar as a module instead of part of the framework.

How You Can Help

If you'd like to help out, you can post ideas in the feature requests forum. Once we figure out how it'd work, I'll add it to the list here. Once it's done, I can cross it off the list and provide a link to it (if it's a module or demo). If you're more ambitious, you can try to tackle some of these modules or demos yourself.

Even the simplest demos help out. Imagine a demo to show how you can create attacks that stun. If this was a regular BYOND demo that wasn't specifically for the framework, it'd be useless. It'd be very limited and it wouldn't work with most games - it'd be highly dependent on how the rest of the game works. If you make it as a demo for the Action RPG Framework, it'll be more complete (it'll automatically show an on-screen indication of the stun as a condition) and it'll work with any game that's made using the framework.

Version 8

Sat, 23 Jun 2012 16:35:24 +0000

I added the ability to award medals and display an on-screen indication of the medal. You have to handle checking the conditions to determine when the medal should be awarded. Here's an example from the sample game:

Medal
    QuestCompleted
        name = "Quest Completed"
        description = "You completed a quest."
        icon_state = "quest-completed"
        hub_name = "Quest Completed"

mob
    completed_quest()
        ..()
        award_medal(/Medal/QuestCompleted)

This uses BYOND's hub so the medals are client-specific, not character-specific. This also means you need to create a hub entry and add medals to it if you want to create your own medals. The demo uses a test hub entry I set up.

I also added the mob.pvp var and the ability to form parties. The library provides these things so its can_attack() proc can properly limit who you can attack, but it's really up to the game to manage how parties are formed or how/when pvp is enabled. For your game, you might want PvP to always be enabled. You might want it to be a server-wide setting that varies from server to server. You might be making a team PvP game where you enable PvP for everyone and automatically put the players into parties.

I started working on an interface to show your party members but that's really something the game would handle (the code's still there, it's just disabled by default).

Here is the full list of changes:

Increased the layer of objects created by the atom.effect() proc to make them less likely to appear underneath overlays.
Added a new graphical effect for being poisoned and taking poison damage.
Changed the way shadows work in the sample game and added shadows to enemies.
Added the /Medal object which contains all of the information you need to describe a medal. You're still responsible for checking the conditions to determine when a player has earned a medal.
Added the mob.award_medal() proc which can take a /Medal object type path or an object instance. This proc automatically handles the on-screen display of medals when the player receives one.
Added the Options.medal_display_time var which determines how long a medal is shown on the screen when it's received. The default value is 30 (3 seconds).
Added two medals to the sample game.
Added the mob.text_prompt() proc which creates an on-screen prompt that displays a message and prompts the user to type in a string. When the user hits enter, the proc returns. The return value is the string that was typed.
Added a message that gets displayed at the bottom of a prompt window that contains text and no buttons. This message is defined in the Options object as Options.prompt_continue_message, so you can easily change it if you'd like. The default value is "Press the Space Bar to continue."
Added a basic character creation process to the mob.new_character() proc in the sample game. When you make a new character, it now asks for your name and character class.
Added the mob.class var to the sample game, moved the mob's description() proc to the sample game, and made it use your class and name.
Updated shadow-47.dmi in the sample game to make the shadows a little bit lighter (important change, I know).
Fixed a bug with quests dialogs. Previously mobs would offer you a quest even if they were only the ending point of the quest.
Added the mob.pvp var. Two mobs on the TEAM_PLAYERS team can attack each other if their mob.pvp vars are both 1. Setting this var is completely up to you. Maybe you want players to be able to turn PVP mode on or off for themselves. Maybe you want the game to enable PVP for players when they enter a certain area.
Added an example of enabling and disabling PVP in the sample game. When you press the P key it adds or removes a condition. See demo\conditions.dm for more details.
Added the /Party object and the ability for players to be in groups with other players. You can invite players to your party by clicking the "Invite" link next to their name in the "Who's Online" list.
Updated the can_attack proc to let you attack players if both of you have pvp enabled. Also updated the proc to prevent you from attacking people who are also in your party.
Added the Options.title_screen var. You can override its default value to specify a custom file to be used as the title screen. If the image is smaller than an icon it'll be tiled, otherwise it'll be centered in the screen. There's an example of how to do this in demo\mobs.dm but it's commented out by default.
Changed the way health and mana meters determine how many bubbles to show. The relationship between the value and the number of bubbles is logarithmic now, so that 50 is five bubbles, 100 is six, and 500 is eight bubbles.

Stop Being Afraid of Lag

Sat, 16 Jun 2012 17:37:22 +0000

The average BYOND user's list of fears looks something like this:

4. Death.
3. Talking to girls.
2. A world without anime.
1. Lag.

BYOND users are irrationally afraid of lag. People are quick to shoot down game ideas before they get off the ground because "it would lag". Nonsense! All communication over the internet will have some latency but that doesn't mean lag will be a problem. You'd be surprised at how well BYOND performs.

Here's a video of Deep Dungeon being played over the internet. There were four or five people in the game, almost constantly moving around and killing enemies. Valekor was hosting, I was connected remotely (I have no idea where he lives in relation to me), and lag was not a problem at all - the game ran about as well as it does when I run it locally!

There was no sign of lag at all. Also, I'm pretty sure this game was made before BYOND had native pixel movement, so the movement in this game was taking up more CPU time than it would if the game were re-made now - this means the server could have easily supported many more players.

If you see someone claim that their game wouldn't work because it'd lag too much, call them on it! What they probably mean to say is that their game idea isn't that good or that it wouldn't be much fun, but there's no reason that lag would be a problem.

Version 7

Fri, 15 Jun 2012 16:26:49 +0000

Quests

This version adds the /Quest datum and the on-screen quest tracker. There are procs to manage the quest-related input with an NPC, you just have to call this:

mob/npc/interact(mob/m)
    m.quest_dialog(/Quest/MySampleQuest)

And the library will automatically check if the player has the quest, check their status on the quest, and take the appropriate action. If the player doesn't have the quest, the NPC will offer it to them. If the player has the quest but it isn't completed, it'll show a specified message (specified by your /Quest datum). If the quest is complete it'll complete the quest and show a specified message. If the player has already completed the quest it'll show a different specified message.

The actions that must be taken to complete a quest are totally up to you. Maybe the player has to kill a really tough enemy. Maybe they have to find a hidden tomb. Maybe they have to collect some items.

Overlay Generation

I added the icon-generation folder which has some code to generate overlays for the player icon that comes with the library. You can easily change what color or pattern is applied to armor and generate extra overlays.

Condition Saving

Any condition applied to the player is saved when they log out. If you're poisoned (taking 4 damage each second) and it has ticked once when you log out, it'll tick three more times when you log in again and begin to play that character. Cooldowns still aren't saved but you can use Conditions to create things that behave like cooldowns.

Music & Game Menu

I added the mob.music() proc and used it to play music in the sample game. I also added the game options menu under the game menu. This menu contains screen size, sound volume, and music volume options.

Here's the full list of changes:

Fixed the alignment of item captions in the loot window when the item name wrapped to a second line. Also increased the width of the loot window by a tile to make it less likely that item names will wrap.
Condition objects are now saved and loaded. Their durations are only being checked and diminished when the character owning them is active. If you give the player a condition that lasts for 10 minutes, it'll only expire after 10 minutes of playing time on that character.
Updated the combat object in the sample game to not check for critical hits when the attacker is null.
Added client options for screen size, sound volume, and music volume. These values are also stored in the client's savefile.
Added the interface to set the client options in the "Game Options" menu.
Made the escape key only open the game menu if it didn't perform any other action (ex: untargeting the mob you're currently targeting).
Set the anchor property of the chat input control so the window resizes properly now.
Added the icon-generation folder which contains code and icons used to generate overlays. This lets you easily generate new armor or helmet overlays with different colors or patterns.
Added the mob.music proc which is used to play music to the player. The songs are automatically updated when the client's volume setting is changed.
Added music to the sample game.
Added the "slowed" condition to the sample game. The blue oozes attacks slow your movement speed by 50% for one second.
Added the base_speed var to the sample game. This is a value that doesn't change so even if you modify the player's move_speed var, you always know what their base movement speed was.
Shifted the condition icons up and over 8 pixels so they're in the center of their icon states now. The ConditionsBar HUD element was shifted down and left 8 pixels so the icons still appear in the same position on the screen.
Fixed a bug with the Condition.stack_size var. Previously it'd allow one more condition than you had told it to allow.
Replaced the mob.saved_loc var with the mob.saved_x/y/z vars. Saving a reference to your turf could cause unwanted things to be saved. Instead we use the saved coordinates to get a reference to your saved loc at runtime.
Added the Quest datum and the mob procs to manage accepting quests, updating the progress on quests, abandoning them, and completing them.
The Quest datum automatically has procs that are called when you kill an enemy, get an item, lose an item, or get killed. This makes it easy to capture these events to update the quest's status accordingly.
Added the mob.quest_dialog() proc which takes a /Quest type and displays the appropriate prompts given the player's current progress on that quest. The second argument is the dialog type, which can be QUEST_START, QUEST_END, or QUEST_START | QUEST_END. This lets you make NPCs act as only the quest's starting point, only the end point, or both.
Added two quests to the sample game. See demo\npcs,dm for more details.
Added the on-screen quest tracker which shows the name of each quest and its status.
Pressing the Q key will set focus to the quest tracker. The player can use the arrow keys to select a quest and press the delete key to abandon a quest (there is a confirmation prompt before it's abandoned).
Made the mob.prompt() proc create a dialog with no buttons if you pass null as a button name. Omitting all button names makes it default to having just an "Ok" button, but calling prompt("text...", null) makes it not show any buttons.
Added support for specifying a width and height for prompt windows. The first parameter to prompt() is still the message. Any parameter after the first that's a number is assumed to be the width or height of the window. For example, prompt("", "Ok", "Cancel", 4, 4) makes a 4x4 prompt. The default size is 6x4.
Added the global Options object. This is like the Constants object except it contains values that aren't needed at compile-time. This makes it easier to change options in your project because you can simply do: Options/space_opens_inventory = 0 to change that option and it overrides the value specified in the library.
Added the "space_opens_inventory" option to the Options object. This is used to determine if the space bar should open the inventory screen when there's nothing else for you to interact with (it's 1 by default).
Changed the mob.wander() proc to check for some conditions that would cause infinite loops.
Added shadows below mobs in the sample game.
Removed the "Chat Menu" button from the interface. It'll be accessed through the game menu (the one that appears when you press escape) though it's still not implemented yet.

Version 6

Wed, 13 Jun 2012 14:09:29 +0000

The biggest change in this version is the addition of saving and loading. Each player can have four characters* that are automatically saved* and loaded. When you run the sample game now you're taken to the title screen. Pressing the Space Bar brings up the character selection interface which shows each saved character (if there are any) and lets you create new characters. You can call the client.save() proc at any time to save the player's characters. By default this is done when you return to the title screen or exit the game.

* You can use the Constants object to configure the number of characters a player can have and to determine if the game uses client-side savefiles or server-side (the default is server-side).

There are some things that don't get saved that probably should. Cooldowns, for example. The problem with cooldowns is that they're based off world.time. If you start up the game and use an ability after the game has been running for one minute, your cooldowns list will remember that you can't use the ability again until world.time = 610. This means if you close the game and start it up again, for the first 61 seconds you can't use that ability.

I could store the value of world.time when a character is saved and set the cooldown times based on that value when you load the character. The problem is that you might want cooldowns to be handled differently. If you have an ability with a 30 minute cooldown, does the cooldown expire if you close the game for 30 minutes? Does it expire if you switch characters for 30 minutes?

What I'm leaning towards is that cooldowns will not be saved at all. Anything like a cooldown that needs to be persisted will be done as a Condition object (which currently don't get persisted, but that'll change too). Most abilities will have short cooldowns (ex: 0-5 seconds), so it's not really buying the player much to log out and back in just to reset their cooldowns. Since Conditions are full objects it'll be easier for you to specify how you want their durations to work.

The next biggest change is the addition of equipment overlays. I added sword, armor, and helmet overlays. You just call mob.overlay(item) and pass if the item the player is equipping and it creates the equipment overlay. There's not much to this technically but it was a hassle to draw all of the overlay icons. In the next version I'll try to include some procs to generate overlays.

In this update I wanted to flesh out the interface a bit more. I did, though not exactly in the way I had planned. I wanted to improve the shopkeeper interface to let the player sell items and possibly add a bank the player can store items in. I didn't add these things, but I did add the ability to delete items (press the delete key while your inventory is open) and I added the title screen, character selection, and game menu interfaces.

I also made some improvements to chat. Now, clicking on a player's name will prompt you to send them a private message. In the next update I'll likely add the interface to make it possible to ignore and unignore players. The procs for these actions exist and the chat is written to honor your ignore list, there's just no interface to access these functions yet.

Here is the full list of changes:

Made it so you can't use, equip, or unequip items when you're dead.
Changed how attack animations are played. Instead of using flick(), it now just changes your icon_state for a specified amount of time.
Added character saving and loading as the client.save() and client.load() procs. The load() proc simply populates the client's mobs list which you can then display to the user to let them select a character.
Added a title screen and character selection menu.
I had to change some things to support saving and loading:
- Instead of using mob/Login to initialize your mob, it now uses the mob's new_character() proc. This ways it's only called when you create a new character and not when you connect to one you loaded.
- Added the client.connect(mob/m) proc which connects the client to a mob. This triggers all of the actions that have to happen (setting client.mob, setting client.statobj, setting client.focus, calling init_hud(), etc.).
- Made a bunch of the mob's vars tmp vars so they don't get saved.
Added the Constants.CLIENT_SIDE_SAVING variable which determines if savefiles are stored on the server or client. The default is to store files on the server. If you change to use client-side savefiles, be aware that you'll have to change when client.save() gets called. By default it's only called from client/Del() which does not allow for the savefile to be exported.
Added the /missile object which is a child type of /projectile. The missile object is purely graphical. It passes through all objects and always hits the specified target, calling the hit() proc when it has reached its target. Its New() proc takes two parameters, the owner and the target.
Updated the ShootArrow ability to use the new /missile object to create a graphical effect and deal damage when the projectile graphic hits the target.
Added the ability to send private messages by starting your messages with a player's name followed by a colon.
Removed the ability to target a player by clicking on their name. Clicking on a player's name now prompts you to send them a private message. Clicking on a player's name in the "Who's Online" output also does this.
Changed how chat messages are colored. Instead of using color constants from the global Constants object, it now uses client/script to control the color. This is needed so the link's color doesn't change to the visited link color after you click on it.
Added a game menu that is accessed by pressing escape while in the game. It contains some placeholder options and a working option to return to the title screen (which lets players change characters).
Added the ability to delete characters at the character selection screen by pressing the delete key and selecting "Delete" at the confirmation prompt.
Added the item.overlay_icon, overlay_state, and overlay_layer vars.
Updated how overlays and equipment overlays are handled. You can now call the mob.overlay() proc and pass it an item. It'll create and return the /Overlay object to represent the item based on its overlay_icon/state/layer vars.
Added the mob.remove(item) proc which removes an equipment overlay.
Added the move_state var which is the movement portion of the player's icon state (ex: standing, moving, attacking, dead, etc.). Overlays created by passing the overlay() proc an item are automatically updated to always match the player's movement state.
Updated the sample game to include equipment based overlays. The shield was changed to body armor which has an overlay. The sword also has an overlay. Also added a helmet which has an overlay.
Updated the melee attack graphical effect to remove the sword part, now it's just the white slashing line (if you have a sword equipped, your overlay will be animated to show the sword slash).
Made the character selection menu display overlays based on what items each character has equipped.
Added the ability to delete items from the inventory screen by pressing the delete key.
Fixed a glitch in the mob.drop_item() proc. Previously it wouldn't unequip an item before dropping it.

Version 5

Sat, 09 Jun 2012 15:48:37 +0000

Most of the changes in this update were to the sample game. I moved the enemy AI code from the sample game to the library. Now all mobs have default AI (note: the AI proc is only executed for mobs without clients). If you want to change the AI you can override the mob's AI proc. By default mobs will wander (the wandering distance is limited by their wander_distance var, a value of zero means they don't wander), look for hostile targets, and approach and attack their target. They use their team var to determine which mobs are hostile, so by putting NPCs on the player's team and enemies on the enemy's team, you can create guards that attack enemies without having to change their ai() proc (there's an example of this in the sample game, see demo\npcs.dm).

The mob's team var is a set of bit flags. This lets you create different factions. Mobs A and B are hostile towards each other if A.team & B.team is zero (they have no common team bits set). If two mobs have just one team in common they won't attack each other. This lets you easily do things like this:

Constants
    var
        const
            TEAM_GOBLINS = 4

mob
    goblins
        team = Constants.TEAM_GOBLINS

This makes goblins hostile to players and enemies. When the player completes a quest to win the favor of the goblins, you can set the player's team var to Constants.TEAM_PLAYERS | Constants.TEAM_GOBLINS and the goblin mobs won't attack them anymore (but will still attack enemies).

I also removed the global Combat var from the library. You have to define your own in your project. I also made the sample game define two types of Combat objects - PhysicalCombat and MagicCombat - which are used for dealing physical damage and magical damage. Physical attacks can be dodged, magical attacks can be resisted. It's similar but they use different stats. I also updated each ability in the sample game to use either of those combat objects.

I also updated the procs for playing sound effects and added sound effects to the sample game.

Here is the full list of changes:

Fixed a movement bug. Previously you would continue moving if you held and arrow key while you died.
Moved the enemy AI into the library to be the default ai() proc. Non-client mobs that don't override their ai() proc will wander, look for targets, and use their abilities to attack them.
Added some vars to manage the default enemy AI. Check enemy-ai.dm for more details.
Made the font of the chat input field match the rest of the interface.
Removed the global Combat var. If you need to use it, define your own.
Defined the PhysicalCombat object in the sample game which contains the rules for physical damage (dodging, critical hits, etc.).
Added the MagicCombat object to the sample game which has slightly different rules than the PhysicalCombat object. It uses the mind stat for critical hits and the resistance stat for damage reduction.
Added the mind and resistance stats which are used by the new MagicCombat object.
Changed how teams work. The team var is now a bit mask. If two mobs have no matching bits set, they can attack each other. By default all mobs are on TEAM_PLAYERS and mobs of type /mob/enemy are only on the TEAM_ENEMIES team.
Removed the TARGET_RANGE constant. If you want to change it, just override the default value of the mob's target_range var.
Added the mob.ignore and unignore procs which can be used to ignore chat messages from certain players. Your ignore list stores each mob's ckey, but you can pass a ckey or mob reference to these procs.
Made the player able to target non-enemies by holding down the shift key while pressing tab.
Also added the ability to target a mob by clicking on their name in the chat log.
Added the name display below targeted mobs.
Made projectiles pass through friendly mobs.
Updated the sound procs. There is now the atom.noise() proc and the mob.sound_effect() proc. The atom.noise() proc is for creating noises that nearby players can hear (ex: casting a spell). The mob.sound_effect() proc is for playing sound effects to a single player (ex: when they make a selection in a menu).
Added sound effects to the sample game.
Added the mob.rumble proc which makes the screen shake.