Action RPG Framework

by Forum_account
Action RPG Framework
A framework for developing action RPGs.

Version 5

Page: 1 2
Jun 11 2012, 4:04 am
In response to Kaiochao
Kaiochao wrote:
I don't think I like how I can't change any of the constants without going into the library and changing it. If I want something completely customizable, I guess I'd have to copy/paste the library into my project where I can change things without changing everything else using the framework.

That's the only reason I don't like it but I'm not sure how to fix that. The constants are needed at compile-time and the library will likely be compiled first. I'm not sure there's a way around this without modifying the library. You could do something like this:

// the library's _constants.dm:

#ifndef PROJECT_1
Constants
    var
        const
            // the library's default definitions
#endif

#ifdef PROJECT_1
Constants
    var
        const
            // the constants for Project 1
#endif

Then in your project's .dme file you can #define PROJECT_1 before the #include statement that includes the library.

I'm not sure if it'd work if you simply unincluded _constants.dm from the project and defined the Constants object in your project. I don't know if the library would compile with the object being defined outside of it. This would be a nicer solution because the project's constants would reside in the project, not in the library, though you would have to open the library and include/uninclude _constants.dm if you wanted to switch between its default values and your game's values.
Jun 11 2012, 4:06 am
Yeah, I've done that #define thing before. It gets overwritten when you update the library, though.
Jun 11 2012, 4:12 am
In response to Kaiochao
Kaiochao wrote:
Yeah, I've done that #define thing before. It gets overwritten when you update the library, though.

Yeah, that's why the second approach would be better. Updating the library would re-include its constants file and give you a duplicate definition error, but it wouldn't erase the constants you defined.

Though, if you were using a library like this in a serious project I'd make a separate copy of it so that updates don't impact your project. You can switch your project and run it using the new version but you still have the old one around in case the new one doesn't work or if you've made changes to the library itself.
Jun 11 2012, 4:31 am
I ended up coming up with this solution:
object
    var/global/const
        value = 5

#define access(O, V) access__(O, #V)

proc
    access__(objectType, varName)
        var/global/list/accessObjs = new
        var/A = locate(objectType)
        if (isnull(A))
            A = new objectType
            accessObjs += A
        return A:vars[varName]

client
    verb
        Test()
            src << access(/object, value)

The only problem is there isn't a compile-time check to see if the var is actually a part of that object, or that the type is a valid object type.

EDIT: Also, sorry for being off-topic in your thread.
Jun 11 2012, 4:56 am
It does compile fine if you remove the /Constants object from the library and define it in the project that references the library. For the next update I'll shift some code around so it's easier to remove the /Constants object from the library or maybe add a compiler flag that'll make it skip that code.

Complex Robot wrote:
EDIT: Also, sorry for being off-topic in your thread.

I don't mind. It's a good discussion and it's sort of on-topic.

I'm still not sure what that all buys you. A single extra global instance of each object type isn't going to take up much extra memory (if any) that it's worth giving up the object.variable_name syntax and the compile-time checking that variables exist.
Jun 11 2012, 4:24 pm
In response to Forum_account
Well, if you had a lot of these objects, you would have line after line of the same 'var/X/X = new' hundreds of times. I think we've already established that memory is not the issue here.
Jun 11 2012, 11:34 pm
That's static code of course, though, and well worth the compile-time type-safety it provides. Doubly so if you have lots of them (as that implies a much larger project, that is more time-consuming to test).

Given the choice between having the compiler confirm basic stuff like typos, and me having to confirm that myself through run-time testing, I'd gladly let the compiler do it.
Jun 12 2012, 2:47 am
In response to Stephen001
Stephen001 wrote:
That's static code of course, though, and well worth the compile-time type-safety it provides. Doubly so if you have lots of them (as that implies a much larger project, that is more time-consuming to test).

Given the choice between having the compiler confirm basic stuff like typos, and me having to confirm that myself through run-time testing, I'd gladly let the compiler do it.

I agree completely. The issue I have with it is that the code would become a bit bloated with the same thing over and over with only minor changes. It's not that big of a deal, especially because you can just use metaprogramming in your favor. It's just something to consider.
(Especially for people who don't know how to metaprogram.)
Page: 1 2