Action RPG Framework

by Forum_account
Action RPG Framework
A framework for developing action RPGs.
ID:841503
 
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: Ideas for Demos: Ideas for the Framework: 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.
You'll be happy to know that I've completed my Auction House library, Auctioneer++. It's a very, very bare bones library, only handling what is required. It leaves plenty of room for the developer to interpret how and when auctions are created and removed. I do appreciate anyone willing to help me improve the library by any means.

EDIT: A new library called Mailbox++ is also in the works, allowing for a mail system within your games. Will will be a wonderful if not necessary addition to use alongside my Auctioneer++ library.
Thanks! I'll take a look at it later.
Several minor issues (Which inevitably result in one major issue) are currently in the process of being debugged, rewritten, and implemented. I hope you don't take to heart that this is a final draft of the library, they never are on first launch ^^!, as I'm sure you're well aware. If there's anything you feel can be done differently (Other than the demo, I completely understand that it's a sub-par representation of the libraries capabilities and will be redone.) please feel free to let me know. This is how software and plugins are perfected.
To include this in the framework I guess there'd need to be another library that uses Auctioneer++ and provides an on-screen interface.

One reason I'm hesitant to include these kinds of features is because they tend to emphasize the "single server with lots of players in it" design, which is something that games won't necessarily use. I'd prefer if these kinds of features could function across servers.
In response to Forum_account
Perhaps the Auctioneer++ could have a file of text full of the list of items on their auction (and if the items are changed from the original forms or not) and then occasionally the list is shared with all other servers. That way whenever a server is up it's section of the auction would be available.

If there's a better way to handle it, I'd love to hear it. I really like working around the multiple-server structure.
You can use a hub entry's scoreboard to store auctions. It's a bit slow and it's prone to problems if people bid on the same auction at the same time but it's a very easy way to make things work across servers. It'd probably work better for mailboxes since you're not going to have two people reading the same mail messages at the same time.
I started on an auction system that uses the BYOND hub scoreboards but it looks like it'll need to be paired with a mail system too. Everything would work (as well as you could expect it to) except when you outbid someone there's no way to return their money to them.

The only other problem I see is that it relies on world.realtime for determining when auctions have expired. You could probably bid on an auction, set your system clock way ahead, then run the game again and it'd think the auction expired and you were the winner.

I could avoid both of these problems by ditching the auction aspect and just make it a marketplace. You set a price for an item and people can buy it. There's no bidding (so no need to refund money when you're outbid) and no expiration time for auctions. I could also fix the world.realtime problem by grabbing the time from some website since you'd need to be online to access the auctions anyway.
That's a good idea for a later update, access to auctions and mail across multiple servers, (Probably 1.2) but for now, I'm just working on ironing out the kinks and providing more substance and functionality to the library. Thank you so much for the feedback, that was definitely something that I was neglecting in the original design. When I do get around to building it, I'll be sure to include the options of making a auction list personal to the server, able to be used on all servers, or just used on a select few servers.
i have noticed that you have a size limit for parties coming in version 10. the quests also need a size limit or that would result in a screen res change if there is lots of quests displayed. just a reminder :)
I'm not adding the limits because having too many might affect the screen resolution. If there's a limit, people can set the limit too high and have the display go off the edge of the screen. I can't stop people from doing silly things =)

I'll add this limit but for both of these limits the default value will be zero, meaning there is no limit.
Nice people can set these limits themselves but is it not posible to set limit based on view height and view width?
You can figure out what that limit should be but these things are really up to you. You might find that these on-screen displays take up too much space even before they reach the edge of the screen.

I'd also encourage people to develop their own on-screen displays, especially if you want to have lots of quests or lots of players in a party. The library only provides an interface to display quests because it provides the objects and procs to manage quests. The interface is just necessary to show that the objects and procs work. I can make the interfaces more customizable but they weren't meant to be sufficient for all the ways you might use them.
okay