RPG Framework

by Albro1
A small framework for a simple RPG. Newbies can learn from it.
In response to Corax Software
Corax Software wrote:
Okay so I downloaded 4.94 and cranked this up. Looked almost promising to begin with, and then I tried to do things, intuitive things...

You're on the right track as far as selecting the different pieces of an RPG that need to be there but the execution quite frankly is dismal.

Even behind the scenes was kind of like looking at a pile of corpses in a slasher movie. I understand everyone has their own style but the code is very hard to read. I really can't understand why you're hoping to hand this out as a Framework if it's such a night mare.

Can you explain what parts are hard to read? I tried to keep it as readable as possible, but I haven't released very many things for others to read. I can read it and navigate it extremely easily even after having not looked at it for a week, but if others cannot get the hang of it it needs to be fixed.

As for the framework, I never intended it to be a framework. This was my 7DRL entry for ET's competition. I didn't finish in time, so I released it.

Like I said, there are positives to this but I really just think you've taken one of the most difficult tracks. Try looking at other basic environments, rethink then, cut cut cut, reorganise, rebuild.

My advice but I've tried to give advice to people on this forums many times before and man oh man do they not like it. Sorry if I offended you because I know you put so much work into it but please picture me like Simon Cal.

I appreciate the feedback, so long as it is soundly founded. I am not one to refuse constructive criticism. I released this to the public to help, so if the public can't understand it, I'm not doing it right.
In response to Albro1
Well there are two primary problems in your written code. Remember that people can write whatever they like for themselves, we speak our own language but these are issues related to other people using your code.

-------------------------------------------------------
First Issue
-------------------------------------------------------

The first problem is that your framework's success pivots entirely on your ability to comment it and to be frank, at the moment you can't. On top of this your documentation is totally internal. This leads to many issues, one of the main issues that no one reading can gain a clear and consistent image of your work. Example:

How am I supposed to see that A is linked to B with this in my way?

Blah blah A blah blah

// blah blah blah blah
// blah blah blah blah
// blah blah blah blah
// blah blah blah blah

blah blah blah blah blah blah

// blah blah blah blah
// blah blah blah blah
// blah blah blah blah

Blah B blah blah blah

This is just a simple example of finding letters but you want your users to be able to do it with very complex mechanics. It's just not working... You need external documentation on process and they all need to be independently isolated.

-------------------------------------------------------
Second Issue
-------------------------------------------------------

The second issue you have with your commenting is that it often suffers for a common issue of:

- Apple // This is an apple.

Or this problem:

// this checks to see if src is dead
// the code is very self-explanatory, though undocumented

-------------------------------------------------------
The Game
-------------------------------------------------------

Now this is where my final problem lies. I've played a lot of PC games in general and fair amount of Byond games. This doesn't entitle me to demi-god properties in understanding game environments but it has allowed me to be accustomed to how I'm supposed to play games when they're presented to me.

The issue is that I hit Ctrl-R and saw recognizable objects but nothing I clicked did anything. On top of this nothing I pressed on my keyboard changed my situation either. So I was left totally stumped on how to do anything which would hint to me that either 494 isn't seeing I have a way to interface with the game or there are seriously ambiguous controls.

-------------------------------------------------------
My Solution
-------------------------------------------------------

Isolate and segregate functionality. Remove unnecessary commenting and shift documentation to an external reference source such as a forum post or even a wiki would be great. My final tip, most things I found were over complicated and ambiguous.

Well... That's my thoughts.

In response to Corax Software
Oh and forgot to add a couple of things. Defining functions in different areas is a very strange thing to do in Byond. I'm just learning C++ at the moment and becoming accustomed to how spread out functionality can be but there's really no need for that in Byond. The whole _filename thing needs to go in a major way.

And the last one is a question. Are you writing this as a tutorial or as a pure framework? Just cause a framework works on the idea that all the detail is cut out of the project and people have to understand very little. A tutorial teaches how everything works. At the moment it's like you're half trying to teach and half trying to create a framework.

In response to Corax Software
Corax Software wrote:

Or this problem:

// this checks to see if src is dead
// the code is very self-explanatory, though undocumented

Not quite sure how that death procedure was that complicated. It does very simple things. It calls simply-named procedures. You say I am commenting too much, but then say that I am not commenting enough. Which is it?

The issue is that I hit Ctrl-R and saw recognizable objects but nothing I clicked did anything. On top of this nothing I pressed on my keyboard changed my situation either. So I was left totally stumped on how to do anything which would hint to me that either 494 isn't seeing I have a way to interface with the game or there are seriously ambiguous controls.

If nothing you clicked did anything, it is a client-side error. It uses the default movement controls (Arrow keys) and uses Space and G as other macros. You learn about the macros when you walk near something that can be interacted with.

My final tip, most things I found were over complicated and ambiguous.

Elaborate?


Oh and forgot to add a couple of things. Defining functions in different areas is a very strange thing to do in Byond. I'm just learning C++ at the moment and becoming accustomed to how spread out functionality can be but there's really no need for that in Byond.
It's a matter of preference. I find it easier to remember procedure names when they are defined separately and have nothing in them than having to scroll through a file to find the procedure name.

The whole _filename thing needs to go in a major way.
No it doesn't. It's like a form of inheritance. Using _filename ensures that that file will be compiled before those below it. If you feel that strongly about it, then please show me how I am in the wrong for doing it. I will take it out if you do, but I see nothing wrong with doing it right now.

And the last one is a question. Are you writing this as a tutorial or as a pure framework? Just cause a framework works on the idea that all the detail is cut out of the project and people have to understand very little. A tutorial teaches how everything works. At the moment it's like you're half trying to teach and half trying to create a framework.

This is a framework meant for developers of any skill level. I'm not teaching anything, I just tried to explain what I did in detail (for the most part). You are confusing a framework with a library. A framework, depending on how narrow the genre it is, is going to require some studying and understanding. I provided examples for the major systems. BYOND Newbies wouldn't need to touch the internals until they learned more about them. They could see how things are made and make something with them. That was my goal.

----------------------------------
I know my responses sound a bit defensive, but I assure you I mean what I said with the best of intentions. I'm not going to blindly modify my framework whenever someone says something about it. I just want more detail and for you to prove to me that it needs fixing. If I just change whatever everyone tells me to change, it'll be a mess.
I expected this would be more like a library. The framework provides a set of objects, vars, and procs to manage the player, their stats, items, and enemies. Then, the "demo" part of it is what uses the framework to create a game. That way there's a clear separation between the framework itself and that code that uses the framework. People with less experience can easily find the code that just uses the framework and modify it to learn how they can use the framework.

There isn't much of a difference between a library and a framework. The difference is that a framework is larger and provides features that are specific to a certain type of game.

@Corax Software: The nice thing about projects like this is that you have the source code. If you find that the comments could use some work, you can fix it and send the updated version to Albro1.
In response to Albro1
Albro:

-------------------------------------------------------
Commenting Reply
-------------------------------------------------------

I said the quality of the comments that are there need to be improved or if you're not making it a tutorial then most of them can go and all you need is a how-to-use section on each process. Like when you press F1 in the dream maker. I don't actually know how get_step() works but I know how to use it so the DM Framework is great.

About the death_check thing, I wasn't trying to directly parallel the complexity. It was just a analogy sorry. I meant the complexity of the comments don't match the complexity of the code. Didn't mean to say it was death_check in particular.

-------------------------------------------------------
Macros
-------------------------------------------------------

Interesting point, I went into the DMF file and found only the standard macros for the directionals. Interesting.

At the very least I should have been able to right click on the objects.

-------------------------------------------------------
Preference
-------------------------------------------------------

Then please elaborate on why the proc's need to be defined twice, their prototype form in a separate file. Fact is those shouldn't need to be compiled first, I've seen it in a Byond project before. Seems unnecessary and just over complicating things.

-------------------------------------------------------
Skill Levels
-------------------------------------------------------

Seems that the project having no target audience means it's kind of in limbo then. Without knowing who you're writing for I'm worried you're not actually getting in touch with the audience wanting a framework, more that you're just showing older users (who know how to make one themselves) that you can do it.
In response to Corax Software
Corax Software wrote:
Albro:
-------------------------------------------------------
Macros
-------------------------------------------------------

Interesting point, I went into the DMF file and found only the standard macros for the directionals. Interesting.

At the very least I should have been able to right click on the objects.

They aren't DMF macros. They use Forum_account's Keyboard library. They take the key_down() procedure.


-------------------------------------------------------
Preference
-------------------------------------------------------

Then please elaborate on why the proc's need to be defined twice, their prototype form in a separate file. Fact is those shouldn't need to be compiled first, I've seen it in a Byond project before. Seems unnecessary and just over complicating things.

Maybe to you. Not to me. There isn't really a need for it. However, they aren't defined twice. They are defined once, when they are placed under proc. They are told what to do in procs.dm.

-------------------------------------------------------
Skill Levels
-------------------------------------------------------

Seems that the project having no target audience means it's kind of in limbo then. Without knowing who you're writing for I'm worried you're not actually getting in touch with the audience wanting a framework, more that you're just showing older users (who know how to make one themselves) that you can do it.

I cannot choose who is going to use this. I know that there will be newbies who will download it and try to make a game out of it just as they do with rips. I'd like to give them the best shot at getting better as a programmer as I can. If I set my standards low, then everyone higher will understand me even clearer (in most cases).
In response to Albro1
Albro1 Wrote:

I cannot choose who is going to use this.

That's total rubbish. It's called a target audience and you design your program for them. Simple.

I know that there will be newbies who will download it and try to make a game out of it just as they do with rips.

I can tell you now that no noobs will use this. They can't even understand what's out there now, don't know how you want them to use this.

I'd like to give them the best shot at getting better as a programmer as I can.

Then why did you mash your bad documentation in your unorganized code? Hardly what I would call giving them the best opportunity to get better.

If I set my standards low, then everyone higher will understand me even clearer (in most cases).

No, everyone higher will just laugh and dismiss you. After that everyone who needs what you're offering won't get what they need and you barely make a ripple.


This project isn't the best you can do and it's disappointing. If you want to make project for other people then you need to be a perfectionist and understand how they'll use it. Not saying you should give up, I'm saying that you can do a lot better.
In response to Forum_account
@ ForumAccount

If I was going to do work on this, my first order of business would be re-writing the entire thing. I may as well make my own but I've got things to do in my own life as well. Maybe some day.
Corax Software wrote:
This project isn't the best you can do and it's disappointing. If you want to make project for other people then you need to be a perfectionist and understand how they'll use it. Not saying you should give up, I'm saying that you can do a lot better.

As I said before: if you don't like it, you've got the source code and can fix it up.

Albro1 wrote:
I know that there will be newbies who will download it and try to make a game out of it just as they do with rips.

I can tell you now that no noobs will use this. They can't even understand what's out there now, don't know how you want them to use this.

People often make rips because they're not just looking for an easier way to make a game, they're looking for an easier way to make a DBZ/Naruto game. Unless you're going to make this an "anime RPG framework" I don't think it'll appeal to rippers. Luckily, there's nothing to gain by making this appeal to rippers.

To make a framework, what I'd do is pick an existing RPG and create a framework that'd let you easily create that particular game. Once you have that done (it's easier than it sounds because you don't need to create a tremendous amount of content) you can figure out what people things would likely want to customize, then reorganize that code to make the framework give the developer more flexibility for those things they'd want to be flexible.

For instance, the Sidescroller library is close to a framework. It handles a lot of game specific things. I tried to find the best way to split the behavior into different procs so if you want to make some typical changes, you only have to change a var or override a proc in a very simple way. For example, I could have put lots of things directly in the key_down() proc but then it'd be difficult to change how things work.
It is giving me a "var doesn't exist because it isn't set in the type's namespace." error.

In your maptext.dm file inside text_obj it should look like this...
text_obj
parent_type = /obj
icon = null
var
maptext = null
maptext_width = null
maptext_height = null

Sorry bout the way the code looks for some reason there are no [dm] tags.
In response to Squizzle
You mean <> DM tags, not [] DM tags.

for(x in y)
In response to Squizzle
Squizzle wrote:
It is giving me a "var doesn't exist because it isn't set in the type's namespace." error.

In your maptext.dm file inside text_obj it should look like this...
text_obj
parent_type = /obj
icon = null
var
maptext = null
maptext_width = null
maptext_height = null

Sorry bout the way the code looks for some reason there are no [dm] tags.

Don't know what you did, but you're the only one who's gotten this error.
In response to Corax Software
Corax Software wrote:

Then why did you mash your bad documentation in your unorganized code? Hardly what I would call giving them the best opportunity to get better.

Please, tell me how it is unorganized. Things are separated into clearly named files and the contents of each file is expressed at the top of each file.

No, everyone higher will just laugh and dismiss you.

I can already tell you that isn't true.

This project isn't the best you can do and it's disappointing.

If it's disappointing to you, then I'm sorry. I'm going to be expanding on it more, but this is what it is for now. My first framework doesn't meet the perfectionist's standards. My sincerest apologies.

lol good read
I'd make it two separate projects - one for the framework, one for the sample game that uses the framework. That way people can download the sample game and see how easy it is to use the framework without there being any chance at all that they'll be confused by the framework's own implementation. People can see that it's easy to make a new item (I'm making this up, I don't know if this is exactly how the framework works):

item
sword
icon_state = "sword"

And they can place it on the map, run the game, and be able to pick up the item. The framework defines the /item type and all of the verbs for picking items up, displaying them in your inventory, and dropping them. You can have examples in the sample game that show different properties that items have, all it'd take is for people to see something like this:

item
shield
icon_state = "shield"
slot = OFF_HAND

bread
icon_state = "bread"
stack_size = 20

Once people see that code, they'll know you can specify what slots items are equipped in and that you can make stackable items.
While that's a good idea, the game and the implementation are separated fairly well. When I was originally programming this for myself and not for the community, I was making all of the core parts first and separating the implementation, so everything is easier to find and see.

Anyways, I am busy right now making an external documentation file. I have some updates planned for the framework as well, such as a system for managing quests.
I'm not sure it'll be clear to newbies how things are separated. You know how it's separated because you made it. I try to make things in my libraries behave like a built-in feature would. You don't need to know how an atom's pixel_x var works, you just need to know that it exists. A framework provides vars, objects, and procs that people just have to know exist. People should be able to learn to use the framework effectively enough to add their own content and make a game by just looking at a sample game. If they want to make bigger changes to how the game works they may need to look at the framework's implementation, but using the framework in the simplest manner should be obvious without much documentation at all.

Also, making the framework a separate project means that people can update the framework and not overwrite any changes they've made - their changes are in the project that includes the framework.
v.maptext_CreateText(src, "[v:message]", FLY_LAYER, v:mt_width, v:mt_height, v:px, v:py) while the function only takes one parameter.
Your post confuses me. What is the problem?
Page: 1 2 3