Welcome Guest ( Log In | Register )

[ Big| Medium| Small] -



Post new topic Reply to topic  [ 7 posts ] 
Drago del Fato
  Fri Jul 16, 2010 1:22 am
Dark Slayer
User avatar
Member

L1 Slime

Location: Somewhere with a heater on...
DDF Character Maker - Version: 1.4.2
By: Drago del Fato

Introduction

This script allows you to make your own characters in the game. Characters are made by selecting different parts of the body and changing its image, when you finish it is saved within the save file as an Image and loaded every time you load your game.

Features
  • Making characters and saving them without using any external dll's or Windows API calls.
  • Character image is directly saved into the save file so that you can make different character sprites per game.
  • Character image replaces the main player's (usually character with id 001) image file in cache memory so that every time you load a character image with that filename it will load main player's created image instead. (So only thing you need to do is keep your filename of the character unique and use one character sprite image only for your main character).

Changelog
1.2.5 - Initial version of the script
1.4.2 - Constants are now loaded from a module, changed window for showing the icons next to body parts selection

Screenshots

Images


Demo

Demo version 1.0 - Mediafire.com

Script

Script


Instructions

1. Insert new script above main.
2. Paste the code.
3. Modify the constants for BGM, Parts directory and/or Player image filename.

Compatibility

[i]SDK Compilant?

- Don't know. I don't use it so I don't really know.

Other scripts Compilant?
- Well some Save Game scripts should probably need to be modified to match this.

Terms and Conditions

1. Free for Personal and/or Commecial Use.
2. Mention my name in credits and that's all. :)


Last edited by Drago del Fato on Thu Jul 29, 2010 12:56 am, edited 4 times in total.

Top Top
   Profile  
 

kyonides
  Fri Jul 16, 2010 2:49 am
Member

I'd prefer to see you include some sprites for the body parts menu in your script instead of using a standard menu window. IDK, I just think it'd look better, less boring...


Top Top
   Profile  
 

Drago del Fato
  Fri Jul 16, 2010 10:07 am
Dark Slayer
User avatar
Member

L1 Slime

Location: Somewhere with a heater on...
Well I that's not a big problem to do at all, but I would like a bit more feedback on bugs and glitches than cosmetic appearances, although if somebody really needs that I will do it.

I don't understand how is this boring to you? :S
There a lot of commercial games which use character makers to form your own characters when you start a game, this one is no different. :)


Top Top
   Profile  
 

kyonides
  Sat Jul 17, 2010 12:05 am
Member

Eh, I was talking about the GUI... that's what I found boring.


Top Top
   Profile  
 

Glitchfinder
  Sat Jul 17, 2010 4:38 am
BEWARE: Glitchfinder's sense of humor sucks.
User avatar
Staff

Party Mascot

Location: Approximately 93 million miles from Sol.
Well, I took a look at this, and I noticed some things right away. While I haven't tested the script for bugs, I do have some comments on coding style for you. Please keep in mind that these comments are intended to help you make scripts that are formatted in a way that makes them easier for scripters of all levels to get at least a basic understanding of what you've done, as well as to help you improve your coding style to prevent unnecessary waste. Anyway, on to the comments.

First off, you have constants and globals. I recommend getting rid of them ASAP, because the way you used them is not a part of any standard coding styles from the lest decade. You can find whole books dedicated to the reasons why you should never use a global variable or constant when you don't have to. Suffice to say, it's a waste of data and memory, there are more efficient methods of doing it that are accepted in most programming communities, and it is no longer necessary. In this script's case, I recommend taking all of those constants and variables, and bundling them up and placing them into a module. That way, you can still access them when you need to, but they won't be constantly active code that needs to be checked and reinterpreted every time you iterate through the Ruby loop.

Next, I have a few comments on your commenting, or general lack of it. Commenting is considered a requirement if you plan on sharing your code with others. While the RM* community doesn't stress it nearly as much as most communities, that is simply because we're not a programming-oriented community.

While I'm not saying to comment every line (commenting end statements would be sort of silly, don't you think?), I am recommending that you comment actions. Specifically, when something gets done, place a comment about it. If several lines in a row are all very similar in function, place one comment before them that says what they all do. When things happen fast, you may need to comment most or all lines. And when you set up a lot of variables in a structure like an array or a hash, format them so that you can not only read them easily, but also so you can place comments about what they are for.

If you have a great deal of trouble commenting, to the point where it puts you off scripting, I recommend that you comment as you go. Turn it into part of your logical scripting process. Write a comment saying what you're about to do, and then write the line of code that actually does it. I've found that that method actually helps me crystallize my thoughts, as well as making my in-progress code clean and understandable. It also gives the added benefit of letting myself and others know where I left off, so that I can finish it later.

And if you know you need to fix something, but need to move on or do something else, tag the spot with a "fixme" comment, something that will always be the same, and that you can just search for when you're done, so that you can go back and fix or change what you tagged. (I have a friend who does that with comments to the effect of #zzhack) Plus, this takes some of the load off of you when you're scripting. Instead of being forced to remember what you were doing a hundred lines ago, because you need to fix it, you can forget about it and fix it after you're done.

Finally, on to formatting. This is the subject you need the least work on, and I'm guessing that at least some of the issues I'm seeing are a result of the code tags and not your scripting. First, when something goes to a second line, it's actually cleaner to indent it with a standard inde3nt, instead of indenting the second line to a point dependent on the first line. (I'm guessing you were using the first thing after the equals sign, but the formatting I see prevents me from being sure, because that is not what is actually there) Indenting with the same standard indent (2 spaces in RMXP) will result in code that looks cleaner and better formatted, because you don't have odd indentations all over the place.

Next in formatting is your structures. I went into this earlier, but it's better to format them so that they are easy to read, and so that you can actually place a comment to the right of the structure itself, explaining what each variable does.

Finally, I want to talk about line length. While you don't actually force me to scroll sideways, it does go all the way to the edge of the screen, if you're using default settings. I recommend that, if you're going to be using the screen as a guideline, you should make sure that nothing goes past the gray line they placed on the right. I tend to prefer leaving a full space between the end of any line of code and that border. While this may seem like a nitpick, it isn't. I say this because the way you have it set up, it looks like some lines should scroll to the side, and it makes people go for a scrollbar that isn't there. When you format it like Enterbrain did, it actually looks clean and easy to understand, far more than most scripts currently on this forum.

Anyway, these comments are, as I said, intended to make your script far more legible, accessible, and, most importantly of all, easier to understand. With a script like this, you'll never win The Third Man's Golden Left-Sided Shoe Of Walking-Where-Nobody's-Been-Before.

_________________

Image
Play it now!

ImageImageImageImageImage
Just call me Glitch.


Top Top
   Profile  
 

kyonides
  Sat Jul 17, 2010 6:28 am
Member

Glitch wrote:
Finally, on to formatting. This is the subject you need the least work on, and I'm guessing that at least some of the issues I'm seeing are a result of the code tags and not your scripting. First, when something goes to a second line, it's actually cleaner to indent it with a standard inde3nt, instead of indenting the second line to a point dependent on the first line. (I'm guessing you were using the first thing after the equals sign, but the formatting I see prevents me from being sure, because that is not what is actually there) Indenting with the same standard indent (2 spaces in RMXP) will result in code that looks cleaner and better formatted, because you don't have odd indentations all over the place.

Well, it'd also happen because his text editor automatically indent those line in such a weird way... I always face that small problem while using Kate, but I prefer not to use too long words and just assign the value of that thing to a new local variable... and then I just keep using the local variable until the end of the method or condition.


Top Top
   Profile  
 

Drago del Fato
  Sat Jul 17, 2010 10:08 pm
Dark Slayer
User avatar
Member

L1 Slime

Location: Somewhere with a heater on...
Glitch wrote:
First off, you have constants and globals. I recommend getting rid of them ASAP, because the way you used them is not a part of any standard coding styles from the lest decade. You can find whole books dedicated to the reasons why you should never use a global variable or constant when you don't have to. Suffice to say, it's a waste of data and memory, there are more efficient methods of doing it that are accepted in most programming communities, and it is no longer necessary. In this script's case, I recommend taking all of those constants and variables, and bundling them up and placing them into a module. That way, you can still access them when you need to, but they won't be constantly active code that needs to be checked and reinterpreted every time you iterate through the Ruby loop.


Well thanks for that info. I didn't know it would interpret them every time, as for that global one, it's needed because I need to store player's image class somewhere where it will be accessible from other scripts. Specifically RPG::Cache. It's used per each loading and saving and starting a new game so I can't put it anywhere else. As for my coding style I don't need to change it, I think I'm not doing much wrong except these globals and constants which you told me and that's because I'm not used to interpreter languages, languages which I mostly work are compiler oriented (C/C++ and Delphi). I only work with ruby in RGSS for RMXP/VX.

Glitch wrote:
Next, I have a few comments on your commenting, or general lack of it. Commenting is considered a requirement if you plan on sharing your code with others. While the RM* community doesn't stress it nearly as much as most communities, that is simply because we're not a programming-oriented community.


You got me here, it's something I don't really like to do but on the other side I see no point, since I commented those things which needed attention (like how an image is actually saved and loaded). Other than that it's pretty obvious for anyone who is into scripting to understand what I do, I won't say I'm expert but all other things I did falls unto standard ruby (or in this case RGSS) syntax knowledge.

Glitch wrote:
Finally, on to formatting. This is the subject you need the least work on, and I'm guessing that at least some of the issues I'm seeing are a result of the code tags and not your scripting. First, when something goes to a second line, it's actually cleaner to indent it with a standard inde3nt, instead of indenting the second line to a point dependent on the first line. (I'm guessing you were using the first thing after the equals sign, but the formatting I see prevents me from being sure, because that is not what is actually there) Indenting with the same standard indent (2 spaces in RMXP) will result in code that looks cleaner and better formatted, because you don't have odd indentations all over the place.


Well (if I got you right here) that's more problem of this forum formatting scripts for showing than my coding. When I write it I do indenting for one space after each definition, condition and loop and I go back one space after end.

Glitch wrote:
Finally, I want to talk about line length. While you don't actually force me to scroll sideways, it does go all the way to the edge of the screen, if you're using default settings. I recommend that, if you're going to be using the screen as a guideline, you should make sure that nothing goes past the gray line they placed on the right. I tend to prefer leaving a full space between the end of any line of code and that border. While this may seem like a nitpick, it isn't. I say this because the way you have it set up, it looks like some lines should scroll to the side, and it makes people go for a scrollbar that isn't there. When you format it like Enterbrain did, it actually looks clean and easy to understand, far more than most scripts currently on this forum.


(Hope I understood here what you meant)
Ever saw some of the Tilemap rewrited classes here on forum. Although I haven't seen Seph's yet, some of them which I saw went waaay much in length putting much code in one line. In my case I try too put code in line as long as it doesn't go over the silver RGSS line, it's there for a reason, to let limit your writing. :)
Although there are some times when I really need to pass it.


Top Top
   Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 


Who is online

Users browsing this forum: No users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Hosted By: