Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsMUNINN'S PROFILE
Muninn
2233
Close
Programmer. Amateur Author (non-published, so nothing really to be impressed over). Game Designer.
Has many stories to tell you, and games to give out. If only there were enough time to finish them all...
Has many stories to tell you, and games to give out. If only there were enough time to finish them all...
Search
Filter
All
Game Pages
User Statuses
How do you decide to make a story into a game?
author=Ronove
I don't think people should make a story and then fit it into the game. If you want to make a game--be it visual novel, RPG, whatever--you need to make the story alongside the gameplay. When that happens, the story evolves with what you want to do in a game and thus feels more interconnected.
I'd disagree with this only in respect to the "visual novel" part; A visual novel has no "gameplay" other than the decision points, and it doesn't even have to have those. As such, it is a "storytelling-centric" medium rather than a "gameplay-centric" one.
Regarding RPGs, there's no problem with thinking up a story first and then deciding to tell it as a game as long as the author is thinking about how to adapt the story into the new medium.
Your Top Features in Games
author=Sauceauthor=prexusRedundant and non-sensical? You've never been caught by an on-touch encounter that you wanted to avoid? How about if there's 3 or 4 of them chasing you in an area? The point is to let you skip it if you want by choice.
No, Messi. That doesn't work.
The point of on-touch encounters is that you can avoid them by running around them. If you are then given a second opportunity when they touch you, that is redundant and non-sensical. Unless it was a special ability of a character or item you have equipped, then maybe.
The point was that if you're given a chance to evade the encounter by dodging the on-map sprite, and then given another opportunity when caught to not fight the encounter, then the whole "show the sprite on the map so that the player can try to avoid it" bit is unnecessary, and it may as well be a random encounter with an option to skip the battle.
From Lucidstillness' list, the only ones I could really consider "good game design" rather than "one possible option of game design" are Unique Abilities (or at least unique combinations of nonunique abilities), Clear Story Progression (to any extent, anyway. A story shouldn't be overly padded with mandatory filler content, but optional content that gives the possibility of padding a story is a different case, due to being optional), and Avoiding Grinding (once again, to an extent. I'm in favor of the idea of grinding as difficulty modification, so ideally players should arrive at a difficult section of the game slightly underleveled, so that the section is doable but difficult, and will become less difficult if the player grinds. I'd also support the idea that instead of grinding by pacing around in patches of grass for hours on end, a better idea would be for a variety of sidequests to become available for the player.)
Seven Day Roguelike 2012
I'll participate unless I get swamped with work on that particular week (right before finals, blegh). I've been planning on doing a roguelike anyways, so this can be sort of a practice run.
Java Binary Tree & Node Data Structure
Sorry, I can't really help with the graphical portion of that because I've not really had any experience in java graphics.
Java Binary Tree & Node Data Structure
You're not wrong, it can be done either way and I just happened to go into more detail about one of them. If you put leftNode and rightNode in the Tree class, they should be "Tree leftNode, rightNode;", and you'll need to add a separate element along the lines of "Node content;". The beginning of it might look something like this:
public class Tree
{
Node content; //this holds the Node data structure.
// If you're not doing anything else with
// the nodes, you could probably just roll
// them into the Tree and replace this with
// "String content" (or whatever else you're storing)
Tree parent, leftChild, rightChild; //points to the adjacent nodes in both
// directions. parent will be null value
// if this particular tree object is root.
/* various methods would go here */
}
Java Binary Tree & Node Data Structure
The two methods that you moved would need to go in there, but I also meant to add something like this (only the Node code is shown, the change is a few lines in with a comment by it):
You'll also remove the "Node leftNode, rightNode;" from your Tree class. This will result in a "Tree" object which contains the pointer to the root node of the tree, methods for searching the tree (ie, if you're using a tree to order terms for searchability, or if you're looking to insert a term into a specific spot), while the "Node" object contains links to the other nodes in the tree, and methods for adding or subtracting elements.
public class Node {
String element;
Node nextNode;
Node rightNode, leftNode; //This is the added element
// Creates a node with the given element and next node
public Node(String s, Node n){
element = s;
nextNode = n;
}
// Returns the right node
public Node getRight(){
return rightNode;
}
// Returns the left node
public Node getLeft(){
return leftNode;
}
// Returns the element of the node
public String getElement(){
return element;
}
// Returns the next node of this node
public Node getNext(){
return nextNode;
}
// Sets the element of this node
public void setElement(String newElement){
element = newElement;
}
// Checks for a left node, if there isn't makes Node b the new left node with element
// as the value of the Node b. If there is a left node return an error
public Node insertLeft(Node b, String element){
// If there is no left node, make Node b the left node
if(b == null){
leftNode = new Node(element, b);
// If there is already a left node, return an error
} else {
JOptionPane.showMessageDialog(null, this, "Error, left node is already present", 0);
}
return leftNode;
}
// Checks for a right node, if there isn't makes Node c the new right node with element
// as the value of the Node c. If there is a right node return an error
public Node insertRight(Node c, String element){
// If there is no right node, make Node c the right node
if(c == null){
rightNode = new Node(element, c);
// If there is already a right node, return an error
} else {
JOptionPane.showMessageDialog(null, this, "Error, right node is already present", 0);
}
return rightNode;
}
}
}
You'll also remove the "Node leftNode, rightNode;" from your Tree class. This will result in a "Tree" object which contains the pointer to the root node of the tree, methods for searching the tree (ie, if you're using a tree to order terms for searchability, or if you're looking to insert a term into a specific spot), while the "Node" object contains links to the other nodes in the tree, and methods for adding or subtracting elements.
Java Binary Tree & Node Data Structure
Are you using Node for anything else in your program? The elements you're defining for it seem to be more in line with a Linked List than a binary tree.
As it is right now, you have no way to extend your tree (you've basically got an object which contains three linked lists instead of a tree). You'll want to make it such that either your Node item has fields for Right and Left child nodes, or make it so that the leftNode and rightNode elements of your Tree class point to subtrees instead of nodes (this would necessitate something along the lines of "Node content;" to contain the node itself).
how you implement the attach() method would depend on which solution you choose.
As it is right now, you have no way to extend your tree (you've basically got an object which contains three linked lists instead of a tree). You'll want to make it such that either your Node item has fields for Right and Left child nodes, or make it so that the leftNode and rightNode elements of your Tree class point to subtrees instead of nodes (this would necessitate something along the lines of "Node content;" to contain the node itself).
how you implement the attach() method would depend on which solution you choose.
The RPG Music Challenge - Phase 2 results
Vote: Entry 21
Some of the percussion in the background seemed a little bit out of place, but other than that I can't really find any fault in this piece. I especially loved the piano introduction.
I might add some comments on more individual pieces at some later time.
Some of the percussion in the background seemed a little bit out of place, but other than that I can't really find any fault in this piece. I especially loved the piano introduction.
I might add some comments on more individual pieces at some later time.
Making Random Encounters More Bearable
author=Avee
...or in spending more than three turns doing the same actions toward enemies that just won't die already.
In such a case, wouldn't it be better to design encounters that don't involve performing the same actions three turns in a row, rather than deciding that those same actions will suddenly become more interesting if you're only doing them for one round of battle instead of three? It might make the annoyance less noticeable by virtue of being shorter, but it still won't add any significant gameplay compared to just removing the battles altogether.
Making Random Encounters More Bearable
Those are some pretty good tips (I'd extend the first one to all encounters in general), although I'd say that the third one should be taken in moderation. Half-hour random encounters might alienate the player, but nobody wants to be dragged away from the map for an encounter that's going to be finished in less than 2 rounds of battle (aside from early-game training battles, I suppose). In general, there should be an inverse relationship between encounter frequency and encounter length, but going too far toward either extreme becomes unworkable. (ie. hit-attack-once-and-everythings-dead encounters every 3 steps, or a 20-minute encounter once every 5 rooms).
The "Warning Posts" idea might also be less-than-effective at first, as well. I seem to recall once being told that in Zelda games (but being information that could be extended into rpgs), there are two major types of NPC dialog: "You should check out location X" (which means go to location X), and "location X is a dangerous place, you shouldn't go there" (which also means go to location X). Players might eventually get the idea, but at first they'll probably hear "It's a dangerous place that can only survived by a 'Strong Hero'", where "Strong" is defined as "whatever level the PCs are when they arrive at that location".
The "Warning Posts" idea might also be less-than-effective at first, as well. I seem to recall once being told that in Zelda games (but being information that could be extended into rpgs), there are two major types of NPC dialog: "You should check out location X" (which means go to location X), and "location X is a dangerous place, you shouldn't go there" (which also means go to location X). Players might eventually get the idea, but at first they'll probably hear "It's a dangerous place that can only survived by a 'Strong Hero'", where "Strong" is defined as "whatever level the PCs are when they arrive at that location".
Games - Tester
Games - Other
