Hey all!
I've been screwing about with OHRRPGCE for bit on a joke game project. It started out as me just messing around, but I've started to take it pretty seriously, and now hope to see it to fruition. The only issue is that for the life of me I cannot figure out how to start assembling a basic level and just inserting a few NPCs. Actually I'm just outright clueless on how to navigate the engine past graphical editing. I looked around on the wiki tutorial, but seeing as my first goal was to place an NPC on the gridmap, that turned out to be less than substantial. Before I even get into my specific questions and troubleshooting throughout this project, I need to be able to build something semi-functional to begin with. Would any of you have a recommendation or two on tutorial resources? I've yet to find something to help.
NOTE: Sorry, I'm sure there's something to answer my question somewhere in the forums already, but I am GOD-AWFUL at navigating forums.
General help?
Moderators: marionline, SDHawk
-
SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
The wiki is an excellent resource:
http://rpg.hamsterrepublic.com/ohrrpgce/Main_Page
You should read up on textboxes if you haven't already.
They're very useful and have a lot of functions, such as managing the party, inventory, setting tags, triggering battles, displaying graphics, and things like that.
http://rpg.hamsterrepublic.com/ohrrpgce/Main_Page
You should read up on textboxes if you haven't already.
They're very useful and have a lot of functions, such as managing the party, inventory, setting tags, triggering battles, displaying graphics, and things like that.
Welcome! Always great to see new users. Like Virtuous Sword said, the Wiki is sort of the be all end all of where to get general information on the OHR. Specifically, the HOWTO pages can help with specifics, walking you through what each menu does, etc. This forum is especially good for specific questions that the wiki doesn't answer explicitly.
If you're struggling, that's ok. There's a lot of menus and hotkeys and stuff. One useful thing to note is that on (almost) every menu in the OHR, if you push F1, it will bring up a help page that will give you more information on what does what.
If you have graphics and know how to make them, that's a good start. Because everything is pretty visual, you're going to need graphics to put together otherwise all the work you're doing will be in the abstract, making it pretty hard to edit a game.
That being said, making an NPC involves
going into the map editor -> choose a map -> go to "Edit NPCs..." -> choose an ID (eg. 0) -> give the NPC a picture, palette (default works) -> give the NPC a display text if you want it to say something when you interact with it
Then, go back one menu (the menu with "Edit NPCs") -> go to "Place NPCs..." -> Choose the NPC you want to place with ',' and '.' (easier to think of them as '<' and '>' like arrows) -> then use Spacebar/Enter to place it on the map wherever you like
You can also edit data about the NPC like how it moves (whether it wanders randomly, follows the player, walks in place, etc.), how it's interacted with (eg. what the player does to trigger the NPC's text box to display), whether the NPC can be used once or continually, etc.
I hope this is helpful. I don't know exactly what's stumping you, but if I failed to address it, just shoot a response and I'll do my best to clarify, or someone else will jump in to do so. From my experience, learning the OHR just takes a lot of fiddling around with it, and sometimes playing other people's games and seeing the things they've done, so you know what's possible.
If you're struggling, that's ok. There's a lot of menus and hotkeys and stuff. One useful thing to note is that on (almost) every menu in the OHR, if you push F1, it will bring up a help page that will give you more information on what does what.
If you have graphics and know how to make them, that's a good start. Because everything is pretty visual, you're going to need graphics to put together otherwise all the work you're doing will be in the abstract, making it pretty hard to edit a game.
That being said, making an NPC involves
going into the map editor -> choose a map -> go to "Edit NPCs..." -> choose an ID (eg. 0) -> give the NPC a picture, palette (default works) -> give the NPC a display text if you want it to say something when you interact with it
Then, go back one menu (the menu with "Edit NPCs") -> go to "Place NPCs..." -> Choose the NPC you want to place with ',' and '.' (easier to think of them as '<' and '>' like arrows) -> then use Spacebar/Enter to place it on the map wherever you like
You can also edit data about the NPC like how it moves (whether it wanders randomly, follows the player, walks in place, etc.), how it's interacted with (eg. what the player does to trigger the NPC's text box to display), whether the NPC can be used once or continually, etc.
I hope this is helpful. I don't know exactly what's stumping you, but if I failed to address it, just shoot a response and I'll do my best to clarify, or someone else will jump in to do so. From my experience, learning the OHR just takes a lot of fiddling around with it, and sometimes playing other people's games and seeing the things they've done, so you know what's possible.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
Hello!
If you haven't already, I recommend reading the early chapters of the 'old' HOWTO ("HOWTO: Main Chapters"), especially How to use NPCs and Tags. A lot of the HOWTO is somewhat out of date, so you'll see lots of screenshots that look different than the current engine, but don't panic! All of the fundamentals, especially about NPCS and textboxes, are still the same, and hopefully the descriptions of the keyboard controls are correct (although not always complete).
Unlike the wiki, the F1 help pages are always up to date and reliable, and have complete lists of keyboard controls.
If you haven't already, I recommend reading the early chapters of the 'old' HOWTO ("HOWTO: Main Chapters"), especially How to use NPCs and Tags. A lot of the HOWTO is somewhat out of date, so you'll see lots of screenshots that look different than the current engine, but don't panic! All of the fundamentals, especially about NPCS and textboxes, are still the same, and hopefully the descriptions of the keyboard controls are correct (although not always complete).
Unlike the wiki, the F1 help pages are always up to date and reliable, and have complete lists of keyboard controls.
Last edited by TMC on Sat Apr 22, 2017 11:07 pm, edited 1 time in total.
-
Skeletoxin
- Slime
- Posts: 6
- Joined: Sat Apr 22, 2017 2:50 pm
Ah, the new HOWTO is almost entirely incomplete.
Virtuous Sword just started a discussion on the wiki about having a Quick Start tutorial. Something that's basically a reorganisation of the old HOWTO we already have, but shorter, not trying to explain everything (that way it'll also be easier to keep it up to date).
Virtuous Sword just started a discussion on the wiki about having a Quick Start tutorial. Something that's basically a reorganisation of the old HOWTO we already have, but shorter, not trying to explain everything (that way it'll also be easier to keep it up to date).
Last edited by TMC on Sun Apr 23, 2017 4:24 am, edited 1 time in total.
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1457
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
This thread reminds me:
I occasionally flirt with the idea of writing up an OHR manual (not a quick tips thing, like the HOW-TO) that can be read as a PDF or an e-book that walks newbies through an introduction, planning stages, menu breakdowns, plotscripting, and advanced tips for things like story and dynamic NPC creation, as an all-purpose station for anyone who wants to make great games on the OHR the first time, using the basics and advanced techniques that people often have to search the forums endlessly for.
Obviously, this wouldn't be a wiki, as a wiki generally tells users HOW to do something without really addressing WHY they should do something. I'd want to create a manual that addresses both (and make it printable). I may still do something like this as a passion project, even though the OHR's constant development would eventually require updated editions. Should be easy to maintain though.
It would basically incorporate game development concepts with development on the OHR, while handling content advice such as story and character development, flavor text, emotional context, etc. Extremely niche, but it could be a first of its kind.
I'd probably want to pair it with a video training series for those who hate reading (even though the videos would be limited to the basic HOW-TOs).
Just some thoughts I'd had this past year, and this thread reminds me that I should still consider it. Again, the quick tips on the wiki would be helpful to those who want to make something. This would be more for those who really want to move from concept (and maybe help them refine concept to something people would want to play) to a great finished product.
I occasionally flirt with the idea of writing up an OHR manual (not a quick tips thing, like the HOW-TO) that can be read as a PDF or an e-book that walks newbies through an introduction, planning stages, menu breakdowns, plotscripting, and advanced tips for things like story and dynamic NPC creation, as an all-purpose station for anyone who wants to make great games on the OHR the first time, using the basics and advanced techniques that people often have to search the forums endlessly for.
Obviously, this wouldn't be a wiki, as a wiki generally tells users HOW to do something without really addressing WHY they should do something. I'd want to create a manual that addresses both (and make it printable). I may still do something like this as a passion project, even though the OHR's constant development would eventually require updated editions. Should be easy to maintain though.
It would basically incorporate game development concepts with development on the OHR, while handling content advice such as story and character development, flavor text, emotional context, etc. Extremely niche, but it could be a first of its kind.
I'd probably want to pair it with a video training series for those who hate reading (even though the videos would be limited to the basic HOW-TOs).
Just some thoughts I'd had this past year, and this thread reminds me that I should still consider it. Again, the quick tips on the wiki would be helpful to those who want to make something. This would be more for those who really want to move from concept (and maybe help them refine concept to something people would want to play) to a great finished product.
Place Obligatory Signature Here
Actually, that sounds a lot like Rinku's "Creating a Game" trilogy, which was about the art of game design in general even though it had lots of specifics on creating OHRRPGCE games.
Really, many articles on OHR development have been written over the years and forgotten, because you have to go to abandoned websites to find them. (I am planning to compile lists of all such articles to bring them back to attention)
BMR has also included various tips about organisation and so forth in his HOWTO articles; it's not just a walkthrough for the engine.
You definitely can put essays and materials on the "Why" on the wiki, although it's not necessarily a good place for that sort of thing. Pro: anyone can update it it; Con: lack of editorial control.
Years ago, James said that the HOWTO should just be a collection of tutorials. As long as the purpose of each tutorial is clear and they're organised instead of overlapping (maybe with certain other tutorials indicated as prerequisites), it could be a good model. (That's the problem with the zillions of mini tutorials that make up the FAQ: lack of organisation and depth)
Really, many articles on OHR development have been written over the years and forgotten, because you have to go to abandoned websites to find them. (I am planning to compile lists of all such articles to bring them back to attention)
BMR has also included various tips about organisation and so forth in his HOWTO articles; it's not just a walkthrough for the engine.
You definitely can put essays and materials on the "Why" on the wiki, although it's not necessarily a good place for that sort of thing. Pro: anyone can update it it; Con: lack of editorial control.
Years ago, James said that the HOWTO should just be a collection of tutorials. As long as the purpose of each tutorial is clear and they're organised instead of overlapping (maybe with certain other tutorials indicated as prerequisites), it could be a good model. (That's the problem with the zillions of mini tutorials that make up the FAQ: lack of organisation and depth)
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1457
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
The organization of the tutorials (or the need for organization) is the primary reason why I'm in favor of a manual. The other advantage is that new developers can have everything they need in one place.
I remembered Rinku's game design epic right after I posted this thought. I remember it being dense (though I really should go back and have a look). I seem to recall that he was basing a lot of his ideas on a famed developer (forget the name at the moment), which is cool. I think his went into everything about game design and theory, whereas I think what we need is a modern adaptation that includes the engine's current abilities, coupled with a scaled back version of game theory, as nobody wants to read 900 pages of information before finding out how to make an NPC walk across the screen. I'd want to develop a layman's version of the OHR's design manual with integrated principals for start-to-finish development, including packaging and marketing tips so that we don't keep showing the OHR off on Steam as a mediocre development kit made to design mediocre games. We all know that the OHR can be used to create great games.
I'd also want to make it accessible to the majority of users who have dedication to making a game, even if they don't have much dedication to reading a manual, or searching the wiki.
Creating a supplemental video will probably be a necessity.
EDIT: I don't think I ever really examined Rinku's article. It's pretty thorough. I think it needs updating, but man is it thorough. It's well-organized, too. My main issue with it in 2017 is that it's pretty dry reading and applies to the engine as it was in 2002, which is far behind its abilities today. I think its principals are sound, and should definitely remain as an important reference to design on the OHR. But, I think we can build on it.
I remembered Rinku's game design epic right after I posted this thought. I remember it being dense (though I really should go back and have a look). I seem to recall that he was basing a lot of his ideas on a famed developer (forget the name at the moment), which is cool. I think his went into everything about game design and theory, whereas I think what we need is a modern adaptation that includes the engine's current abilities, coupled with a scaled back version of game theory, as nobody wants to read 900 pages of information before finding out how to make an NPC walk across the screen. I'd want to develop a layman's version of the OHR's design manual with integrated principals for start-to-finish development, including packaging and marketing tips so that we don't keep showing the OHR off on Steam as a mediocre development kit made to design mediocre games. We all know that the OHR can be used to create great games.
I'd also want to make it accessible to the majority of users who have dedication to making a game, even if they don't have much dedication to reading a manual, or searching the wiki.
Creating a supplemental video will probably be a necessity.
EDIT: I don't think I ever really examined Rinku's article. It's pretty thorough. I think it needs updating, but man is it thorough. It's well-organized, too. My main issue with it in 2017 is that it's pretty dry reading and applies to the engine as it was in 2002, which is far behind its abilities today. I think its principals are sound, and should definitely remain as an important reference to design on the OHR. But, I think we can build on it.
Last edited by Pepsi Ranger on Mon Apr 24, 2017 9:13 pm, edited 1 time in total.
Place Obligatory Signature Here
Must have been Chris Crawford.
Honestly, I haven't read it either (I wasn't even around when it was written in 2001). I found some quotes about it:
I like the idea of a single design manual that covers things like planning, design, marketing and distribution; things that are typically spread out all over the place.
Still, if you want to write tutorials or "menu breakdowns", on how to use the engine, I think the wiki is a better place, since we should have articles like that as part of the HOWTO anyway.
Can't we just organise the HOWTO well, rather than saying we need a whole new document to achieve organisation?
As I said before, there are hundreds of articles on the wiki that show you how to do one thing, but they are too spread out. Reading HOWTO chapters is a vastly faster way to learn the engine, because they don't just explain one thing. I don't like that some of the Extra HOWTO Chapters focus too much on one small thing and have no connection to each other. I think that if you see some feature in the engine which you want to learn about, it should be clear which HOWTO chapter to read. The chapters could be arranged into categories (like "Battles") rather than as an unsorted list.
Honestly, I haven't read it either (I wasn't even around when it was written in 2001). I found some quotes about it:
Looking through it, I don't see that much that's out of date. Even the section explaining OHR attack settings (which I just saw for the first time) is probably still the best reference on damage, aim, and other settings around: afterall, all of those settings are still identical to what they were back then, only new options have been added.Baconlabs wrote:I stumbled upon an article from OHRRPGCE Monthly; Rinku Hero's "Creating a Game" trilogy, and it very probably changed the way I look at game design forever.
...
The fact of the matter is that game design and everything that comes with it are skills that take lots and lots of practice to understand and perfect. What the article taught me was the importance of planning and infrastructure.
I like the idea of a single design manual that covers things like planning, design, marketing and distribution; things that are typically spread out all over the place.
Still, if you want to write tutorials or "menu breakdowns", on how to use the engine, I think the wiki is a better place, since we should have articles like that as part of the HOWTO anyway.
Can't we just organise the HOWTO well, rather than saying we need a whole new document to achieve organisation?
As I said before, there are hundreds of articles on the wiki that show you how to do one thing, but they are too spread out. Reading HOWTO chapters is a vastly faster way to learn the engine, because they don't just explain one thing. I don't like that some of the Extra HOWTO Chapters focus too much on one small thing and have no connection to each other. I think that if you see some feature in the engine which you want to learn about, it should be clear which HOWTO chapter to read. The chapters could be arranged into categories (like "Battles") rather than as an unsorted list.
Last edited by TMC on Tue Apr 25, 2017 1:59 am, edited 2 times in total.
-
Skeletoxin
- Slime
- Posts: 6
- Joined: Sat Apr 22, 2017 2:50 pm
If you guys are gonna start compiling that, I'd be more than happy to give my input on accessibility as a new user with effectively no background in anything needed to make a game. I'll probably finish this project before everything would get written up, but I would get some help out of it, and I feel like I'd at least contribute something to community.
-
Pepsi Ranger
- Liquid Metal Slime
- Posts: 1457
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
Another option would be to link to HOWTO articles within the more structured manual, so that the user can still follow along a suggested path without binding them to a particular order of doing things. That could work well.
I agree that Rinku's article is the best source for doing specific things like battle balance, but one day, as the engine evolves, it will seem less complete. Like, as of now, it doesn't account for map layers, zones, slices, or even sound effects. Those are major HOWTO additions that can change the way people develop their ideas. It's like approaching a Hollywood studio with a pitch for a $2 million movie and finding out that you can now make changes to the script that would warrant a $20 million budget. More options means greater flexibility and time management. With layers, we no longer have to spend hours painstakingly copying backgrounds and drawing over them, when we can just have one background tile and a series of object tiles that we can "paste" over them on the map itself. When Rinku wrote that epic article, layers were still five years away from implementation. Details like that should be accounted for in 2017. I also prefer to announce future plans for the engine so that users can anticipate options should they continue development long enough to see those new features added (like updated font and textbox support, for example).
Also, I don't know of many, if any, who have actually read the whole thing. It's really quite textbook, and while that's perfectly fine, not everyone will want to read all of it, and I think it's structured in a way that people should read it from start to finish. I'm an advocate for reading everything, and even I can't focus on it long enough to really take it all in. I get bored on page one. Though, in fairness, I get bored of information I already know. If I were starting out for the first time, I'd be more likely to sit through much of it. I'd actually be curious to see how newbies today respond to the old Rinku article. We should create a sticky thread for OHR resources where that's prominent, and recommend it as a starter guide for those new to game design, and see how many people get through it all.
I also don't care for how it looks onscreen, which is another problem I have with it. Electronic readers today are laid out better than they were fifteen years ago, so I think it would be easier to get through if Rinku updated it to fit modern readers and read like modern nonfiction.
Anyway, this is something I'll pick at, but I wouldn't expect anything new to explode onto the scene any time soon. I've got so much else to juggle right now that this would be just one more thing (sort of like you and developing features for the OHR--the ideas never end). But I did begin an outline in Scrivener the other day, just to see what we could accomplish with an updated guide for new users.
If you check out early, it would also help to know where you stop reading and where you start skimming.
I agree that Rinku's article is the best source for doing specific things like battle balance, but one day, as the engine evolves, it will seem less complete. Like, as of now, it doesn't account for map layers, zones, slices, or even sound effects. Those are major HOWTO additions that can change the way people develop their ideas. It's like approaching a Hollywood studio with a pitch for a $2 million movie and finding out that you can now make changes to the script that would warrant a $20 million budget. More options means greater flexibility and time management. With layers, we no longer have to spend hours painstakingly copying backgrounds and drawing over them, when we can just have one background tile and a series of object tiles that we can "paste" over them on the map itself. When Rinku wrote that epic article, layers were still five years away from implementation. Details like that should be accounted for in 2017. I also prefer to announce future plans for the engine so that users can anticipate options should they continue development long enough to see those new features added (like updated font and textbox support, for example).
Also, I don't know of many, if any, who have actually read the whole thing. It's really quite textbook, and while that's perfectly fine, not everyone will want to read all of it, and I think it's structured in a way that people should read it from start to finish. I'm an advocate for reading everything, and even I can't focus on it long enough to really take it all in. I get bored on page one. Though, in fairness, I get bored of information I already know. If I were starting out for the first time, I'd be more likely to sit through much of it. I'd actually be curious to see how newbies today respond to the old Rinku article. We should create a sticky thread for OHR resources where that's prominent, and recommend it as a starter guide for those new to game design, and see how many people get through it all.
I also don't care for how it looks onscreen, which is another problem I have with it. Electronic readers today are laid out better than they were fifteen years ago, so I think it would be easier to get through if Rinku updated it to fit modern readers and read like modern nonfiction.
Anyway, this is something I'll pick at, but I wouldn't expect anything new to explode onto the scene any time soon. I've got so much else to juggle right now that this would be just one more thing (sort of like you and developing features for the OHR--the ideas never end). But I did begin an outline in Scrivener the other day, just to see what we could accomplish with an updated guide for new users.
It would actually be really helpful for anyone wanting to update the HOWTOs or developing new manuals if you could give Rinku's old design series a read and offer feedback based on how well you connect with it, how much you learn from it, and how much you think it lacks. Anyone wanting to bridge the connectivity gap would benefit from any input you might have. Again, the link to it is here: http://rinku.castleparadox.com/Septa/oh ... signa.htmlSkeletoxin wrote:If you guys are gonna start compiling that, I'd be more than happy to give my input on accessibility as a new user with effectively no background in anything needed to make a game. I'll probably finish this project before everything would get written up, but I would get some help out of it, and I feel like I'd at least contribute something to community.
If you check out early, it would also help to know where you stop reading and where you start skimming.
Place Obligatory Signature Here
At this point, we've confused terms so much that I'm not really sure what you mean by 'HOWTO' and 'manual'; I know I've switched meanings several times. 'HOWTO' could mean just 'tutorial', but the old HOWTO is really "manual in the form of a walkthrough". It was the documentation.Another option would be to link to HOWTO articles within the more structured manual, so that the user can still follow along a suggested path without binding them to a particular order of doing things.
I think you should have said "anyone wanting to develop a new design manual". For those of us working on the HOWTO, I'd be thankful to hear any feedback about the existing (old) HOWTO, such as where it moved too slowly or quickly, what could have been skipped, you wish was covered, or seemed to be out-of-order.It would actually be really helpful for anyone wanting to update the HOWTOs or developing new manuals if you could give Rinku's old design series a read
Or more generally, if there are parts of the engine that are not self-explanatory, or difficult to understand even with the HOWTO. (For example, I personally find the zone and menu editors confusing.)
-
LieMurderProfit
- Slime
- Posts: 20
- Joined: Mon Feb 13, 2017 10:28 am
- Location: Moscow
-
Skeletoxin
- Slime
- Posts: 6
- Joined: Sat Apr 22, 2017 2:50 pm
So I just tried to get through the introduction, and the way the speaking voice of the piece honestly feels rather demeaning. What it says is of importance, but the way it is said makes me not want to read more of this page, let alone the remaining 300. The second issue I've noticed (mind you I have only gone through half of the introduction, this may change later in the text) is that in what appears to be an attempt at driving a point or a word of caution, I get lost in a repetitive, overly-descriptive, and unnecessarily long wall of text, that makes me want to check out of reading this within 5 minutes. TLDR; The information is valid, and should be conveyed, but it's way too long, and written in a kind of belittling manner, even though I personally don't fit the criteria of who the author is trying to be exclusive against.It would actually be really helpful for anyone wanting to update the HOWTOs or developing new manuals if you could give Rinku's old design series a read and offer feedback based on how well you connect with it, how much you learn from it, and how much you think it lacks. Anyone wanting to bridge the connectivity gap would benefit from any input you might have. Again, the link to it is here: http://rinku.castleparadox.com/Septa/oh ... signa.html
If you check out early, it would also help to know where you stop reading and where you start skimming.
Additionally, the way it is separated into 3 major parts is nice, but to lump it all in one manual seems daunting to a reader first looking at the page. Perhaps separating it into 3 different books, each referencing the others with links, would help with accessibility. Also, having all three parts on the same page makes me feel like I have to read the previous parts to understand what I want to understand - the way to build a game in OHRRPGCE. I already know what it takes to stay dedicated to a project, I have an game concept in mind, I have a rough outline of how the game will progress, all I need to know is how to make that transition from thought to reality. My personal use only needs part 3, but having it all laid out in front of me at once makes me second guess myself on whether or not I need to read what I already know. Basically, if you were to make a new manual, make 3, one on each of the major topics Rinku covers, and make sure that you don't need to read one to read the others. I mean, one might have the capability to make the game with relative ease in engine, and can plan it out no problem, but they may lack dedication, which the first installment helps with. One might have the motivation and the capability to make the game in engine, but is an absolute mess when it comes to planning, which the second installment helps with. One (like me) might have the motivation and planning down, but has no clue in hell how the engine works (part 3).
That's how I view it so far, I'm gonna go skim the rest of the intro, and see if anything in part 2 is important to me, then start reading on part 3.