is this feasible in a 2d rpg engine ...
Author
i'm currently learning c++ and was wanting to maybe make a 2d rpg engine as a project. i was wondering if some one who is more skilled than i could tell me if what i want to do is feasible/appropriate or if theres a better way to do it.
1) i wanted compile map data into the executable as opposed to using say xml and making the engine parse a map format on the fly. i would think that there wouldn't be anything wrong with this. you'd create a map class, and give each map an id and a tileset id to use, make an array of tiles (each tile on a map would would be an id of a tile in the tileset), and then you'd have some kind of array of boundaries.
2) is there anything wrong with compiling graphics into the executable similar to how a windows executable has a resource section?
3) also instead of using a scripting language like ruby or something, i was thinking of creating a series of commands (read functions) that could handle the basic things that you might script, say like move a camera from where your character is at to a new set of coordinates, or push a sprite from one coordinate to another. these would be simple commands that could be set to a tile and take 2 or 3 simple arguments that control how it behaves.
are these things good practices ... i know that it would be hard for other people to use my engine unless they know c++ and want to say edit the map data that way. i'm just wondering if some of these practices would make a faster executable.
1. Your executable would most likely be enormous. Why do that when you could use your own custom map format. Then if you need to make a change to one map, you can load it into your editor and make the changes, and you wont have to recompile the whole project.
2. As with number 2, you CAN put resource files etc into the exe, but as with one, why do that when you could have it separate and edit it separately? If you really didnt want people to be able to edit your resources for some reason you could always make your own format and encrypt/decrypt it.
3. Personally I think it would be better to just use lua or a scripting languae. You're going to have to write a function like MoveCamera(int x, int y) anyways and expose this function so your scripts can use them anyways, so why not just use a scripting language.
As far as making a faster executable...Well, load times in every game you've ever played are basically loading map data into memory, sounds, anything that the level will need. Your load times would be almost non-existent for what you're doing, so just do it like everyone else(separate map files, etc)
2. As with number 2, you CAN put resource files etc into the exe, but as with one, why do that when you could have it separate and edit it separately? If you really didnt want people to be able to edit your resources for some reason you could always make your own format and encrypt/decrypt it.
3. Personally I think it would be better to just use lua or a scripting languae. You're going to have to write a function like MoveCamera(int x, int y) anyways and expose this function so your scripts can use them anyways, so why not just use a scripting language.
As far as making a faster executable...Well, load times in every game you've ever played are basically loading map data into memory, sounds, anything that the level will need. Your load times would be almost non-existent for what you're doing, so just do it like everyone else(separate map files, etc)
Well, I think you are missing the major points of having a scripting language or map file completely. The idea is to allow you to make changes without having to compile. You can have different people building maps without having to worry about source control, and compilation. Compilation times with a bunch of embedded resources is going to be a major hassle, and source control is going to be a bitch. You can always EMBED the scripts and map files into your executable anyways, but removing them completely and instead having loads of classes and structural definitions could be pretty bad. Scripting may be a BIT better, but still tough. You could use a factory object I suppose, but you still have the whole problem with compilation for every minor change.
EDIT:
Also! Don't let yourself have the false assumption that putting everything into your executable will make it faster or more memory effective. In reality, any application of any real scope will have quite the opposite effect. First off understand that your application itself will go into RAM (hopefully...), and instead of having "just enough" loaded, you are going to have "too much" loaded.
If you are doing it to make it harder to hack, it really isnt. Resources and data can be grabbed quite easily out of the excecutable anyways. Encryption is key.
EDIT:
Also! Don't let yourself have the false assumption that putting everything into your executable will make it faster or more memory effective. In reality, any application of any real scope will have quite the opposite effect. First off understand that your application itself will go into RAM (hopefully...), and instead of having "just enough" loaded, you are going to have "too much" loaded.
If you are doing it to make it harder to hack, it really isnt. Resources and data can be grabbed quite easily out of the excecutable anyways. Encryption is key.
1 and 2) There's nothing especially wrong with bundling resources into your executable, but it has two distinct drawbacks: first, you won't be able to update the resources without recompiling and redistributing a hefty-sized executable, which turns people off. Second, it makes the executable much larger, increasing the memory footprint. Antivirus software will tend to chew away at it for a while before it even starts, which could delay the load time by an amount proportionate to how big your .exe is.
As a general rule, you want to keep your .exe as small as possible, and you want your data to be as accessible as possible, at least to you. Generally, the only things bundled into an .exe are icons and maybe a few very small resources that are loaded right from the start (like a splash image or startup sound).
A better approach would be to pack all your game-relevant data into a separate archive. If you're worried about people sifting through it, create your own proprietary, encrypted format. It will be cracked, and someone will make a tool for extracting it, if they care enough to bother. Security isn't so much a waste of time as a flight of fancy. Your objective isn't security; it's making your job easier so you can actually accomplish something in a timely manner!
3) You've described a functional scripting language using a precompiled command-driven approach — very popular with Visual Basic 6 and other languages that support implementation — which is a viable option, particularly when (a) you need maximum performance and interpreted code just doesn't cut it, and (b) you don't plan to change or add any commands. Again, for this very purpose, you may want to compile your command library to a separate DLL so you can update it without having to recompile the main executable.
This command-driven approach is less flexible (and thus less preferable) to a pure interpreted scripting language, but it is fast and easy to use once your functions are in place. It also allows direct access to native functions and data without going through an interface . . . which could be dangerous. That part is up to you.
What I'm trying to describe here is modularity; that is, keeping things as logically separate as possible so they're easier to maintain. It's a hallmark of good programming practice.
As a general rule, you want to keep your .exe as small as possible, and you want your data to be as accessible as possible, at least to you. Generally, the only things bundled into an .exe are icons and maybe a few very small resources that are loaded right from the start (like a splash image or startup sound).
A better approach would be to pack all your game-relevant data into a separate archive. If you're worried about people sifting through it, create your own proprietary, encrypted format. It will be cracked, and someone will make a tool for extracting it, if they care enough to bother. Security isn't so much a waste of time as a flight of fancy. Your objective isn't security; it's making your job easier so you can actually accomplish something in a timely manner!
3) You've described a functional scripting language using a precompiled command-driven approach — very popular with Visual Basic 6 and other languages that support implementation — which is a viable option, particularly when (a) you need maximum performance and interpreted code just doesn't cut it, and (b) you don't plan to change or add any commands. Again, for this very purpose, you may want to compile your command library to a separate DLL so you can update it without having to recompile the main executable.
This command-driven approach is less flexible (and thus less preferable) to a pure interpreted scripting language, but it is fast and easy to use once your functions are in place. It also allows direct access to native functions and data without going through an interface . . . which could be dangerous. That part is up to you.
What I'm trying to describe here is modularity; that is, keeping things as logically separate as possible so they're easier to maintain. It's a hallmark of good programming practice.
While all three are feasible, they're all not good practice. They're also not going to make anything faster in any meaningful sense.
Author
exactly what i wanted to know ... thank you.
it really was never about security, because like it said if anyone cares enough they will crack it. it was about a single file download, more like say a self executing rom file. and i wasn't sure if that would be faster and more compact. like chrono triggers rom is 4 megs, now that's with low level graphics, midi sounds, etc and not to mention you need some program to play it.
with the predefined commands, i was thinking in lines of all the things you might want to do in a 2d rpg and make c++ functions as opposed to say requiring them to have the latest ruby library or whatever. i thought it also might make programming events and actions faster; just name a function and some parameters ... done!
it really was never about security, because like it said if anyone cares enough they will crack it. it was about a single file download, more like say a self executing rom file. and i wasn't sure if that would be faster and more compact. like chrono triggers rom is 4 megs, now that's with low level graphics, midi sounds, etc and not to mention you need some program to play it.
with the predefined commands, i was thinking in lines of all the things you might want to do in a 2d rpg and make c++ functions as opposed to say requiring them to have the latest ruby library or whatever. i thought it also might make programming events and actions faster; just name a function and some parameters ... done!
Quote:Original post by b2therizzo
it was about a single file download, more like say a self executing rom file.
Grab something like InnoSetup and use it to put all your files into a single setup file which people can then download. This will also give you the benefit of compression and other custom features such as "Add/Remove Programs" menu entries.
Yea, ROMS are a whole different matter altogether. Those were from the days when you had cartridges, and that is just practically a binary dump of the cartridges.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
