Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
If you have an email ending in @hotmail.com, @live.com or @outlook.com (or any other Microsoft-related domain), please consider changing it to another email provider; Microsoft decided to instantly block the server's IP, so emails can't be sent to these addresses.
If you use an @yahoo.com email or any related Yahoo services, they have blocked us also due to "user complaints"
-UE
If you use an @yahoo.com email or any related Yahoo services, they have blocked us also due to "user complaints"
-UE
Comments
I mostly just want to make little RPGs and visual novels, so I would stick with 2D. I'm totally willing to learn the coding part. I'm just saying that it would mostly be fruitless, because I can't do the art part.
Programmer art. There's a reason indie devs like pixel games. Just saying.
Also, it's easier to learn art than it is programming. My art was fucking awful when I started my major, but by the time I was done I was at least passable enough to do what I needed to, just by virtue of having spent my more glacial general ed classes doodling and fucking around in Blender.
If you just want to do stuff like that, it'd probably be easier to learn Python or Ruby or Lua or Javascript or... any scripting language like that really, and use one of the avaiable game engines for those. Certainly you won't be making Call of Duty with Pygame, but it'd be fine for 2D RPGs and stuff.
I guess I could try. It's a little daunting tackling two different mediums and trying to become good at them, both programming and pixel art. Especially when neither of those things are related to the bulk of my school work.
I'm just a really bad artist. I'm okay if I'm looking at something to copy. A bit less than okay, actually.
For those, you could get by pretty easily with Game Maker or RPG Maker for the former, and Ren'Py for the latter. They get the job done for simpler projects, but barely count as coding in terms of having to learn stuff.
A word of advice: if your art sucks, stay away from human characters. My storytelling project required five characters -- the human one looked like one of the most derpy, uncanny things ever, and the rest looked fine because you didn't have a baseline built up over your whole life to know how derpy and uncanny they were.
I suppose I could take a cue from something like Cave Story. In terms of art direction, at least.
If you're actually planning on doing something, use shitty interim art while putting stuff together, then get a friend who's good at art to do that and substitute it in as it comes.
Y'know, the sort of thing actual developers do. A lot of our early development is done with mannequins and untextured gray blocks.
Would it be possible to learn to code and successfully make a whole game, then put the art in, if you can find an artist?
Totally. The pictures/models are ultimately just things you hang from code objects that are largely independent of what they look like, and most of the hit detection is done by carefully-chosen bounding boxes to simplify calculations. Pretty much any pixel RPG would be just as functional if all the pictures were replaced with colored rectangles.
You'll have to do additional work once the art comes in to pack a spritesheet, draw from it properly, organize the animation, etc., which can be very complicated and specific to the art. But yeah. Just try to set up your code ahead of time in a way that makes it easier to just plop in art.
For instance, most movement is a simple evenly-spaced cycle of X frames that you can cycle through as soon as you know how many there are, but something like jumping is usually done by choosing the frame based on your vertical velocity. And so on.
side note: if you're making something that relies on collision detection (unlikely since you said you wanted to do RPGs and VNs, but I guess if you're making like a Zelda-style game it could be a thing) make sure the sprite and the hitbox actually match up.
300+ episodes of Indie Impressions have taught me that this is a very common misstep in the development process.
Yes, bad hitboxing is pretty typical of amateur games. Normally you'll want to make the hitbox somewhat smaller than the sprite's actual body to allow for some overlap. Some platforms like Flash have the capacity to check collisions by the sprite itself, but it's very computationally intensive and not recommended (and also have the downside that you appear to get hit one frame before the object actually makes contact, because the collision is checked before the frame draws).
For more complex shapes, you use composite hitboxes. For example, if I were to hitbox the Starship Enterprise, I'd use a circle for the saucer and rectangles for the nacelles and joining bit. For a jumbo jet, you're probably best off using a crossed pair of rectangles for the fuselage and wings.
The nice thing about using circles and convex polygons is that you can check them very quickly if you set up the math properly. With circles you just calculate square distance, and you don't even have to bother with a square root. With a convex polygon, you abuse vector math (cross products) to render any rotation etc. irrelevant and avoid trig. Generally speaking, you want to do anything in your power to avoid any kind of irrational function, because those are actually kinda computationally intensive.
I'd like to support the notion that anyone can do pixel art. It's just time-consuming as hell, because you'll want to ensure that your individual pixels are coloured to give the right impression of shading, texture and whatnot. Just don't do the oversimplification thing with it that so many indie devs seem to love. If you look at actual 8-bit and 16-bit games, their sprites and environments actually have a significant amount of shading and detail (when it comes to good examples, at least).
In retrospect, the change in artistic direction from 2D to 3D was pretty abrupt. I guess this is why the "tone" of so many JRPGs, for instance, changed with the move to 3D. Without the shading and texture detail that was in the 16-bit sprites, the end product often ended up feeling a fair bit more flat, which is an aesthetic trend that I think continues to this day. JRPGs from that era were heavily anime-influenced in art style, certainly, but there was an infusion of the Brothers Grimm in there, too.
A good recent example, I think, is Tales of Graces. Which is disappointing, because the artwork in Tales of Phantasia made it feel really alive. Graces feels very whitewashed and sanitized in comparison, and I think a significant part of this change might be how JRPGs as a whole changed in art direction with the emergence of 3D graphics as granted for AAA games in the mid-late 90s.
That said, I might be entirely wrong. JRPG graphics from the old days was highly abstracted enough that I'm sure there's any number of interpretations placed on top of them.
Okay, I've decided to start writing a game, and learning how to use a system like RPG Maker. I don't really know anything about creating a good RPG Battle system, so I'll want to read all up on that too. After that is all done, if that ever happens, I'll start learning the ends and outs of pixel art. In the meantime, I can pick up on doodling, and see if my drawing improves from that.
I'm pretty determined about this, as it is something I've wanted to do for a long long time, but I never had the free time, or the "creative intelligence".
If anyone has any other pointers, tips or links, they would be appreciated.
Didn't we have a thread for Game Development?
RPG Maker is a decent enough tool, but it has its limitations, too, apart from the immediately obvious. While you can use scripts to break or bend some of them (and there are heaps of these floating around the interblags), some scripts conflict and whatnot, so there are no guarantees when it comes to using a system outside what RPG Maker provides.
In the great JRPG tradition, the damage calculations that come out-of-the-box are already a little on the arcane side. Something like 2.5*Atk - 1.5*Def, which is simple in JRPG terms, but still kind of weird for a default. If you want to use a different set of calculations, you're best off deleting the default attack and ability sets from your first project (but not the RTP, or the core RPG Maker folder, of course, if it's even possible), although that in turn also requires you to build classes from scratch as well. Get ready to do a lot of battle testing in order to get your more meaningful battles to be balanced and tense.
Despite RPG Maker being really convenient, having to create and balance the values for every kind of ability, every class and every piece of equipment is a lot of work, and that's not even counting the labour that goes into map design (in my opinion, probably the most difficult thing). RPG Maker won't teach you to code, but it'll actually teach you the logic of coding languages pretty well -- the event commands "translate" the code into understandable statements for the uninitiated, so what might be several lines of code is merely selected as "Change Sprite" or "Set Timer". You have to ensure that all your commands resolve correctly in a logical fashion, though; if you change a sprite, for instance, the system won't simply know to change it back when the area changes. That sounds pretty obvious, but it's easy to forget when you're starting out.
I think the most important thing to do, before you even begin working on a proper game, is to fuck around with RPG Maker for a while. Don't focus on making a full game, but on, say, 20 minutes of engaging gameplay time using the tools at your disposal. Just take a cool idea for a scenario, a dungeon, whatever, and just make that singular idea happen. Start the party characters off at whatever level is appropriate, and add in whatever enemies, encounters, equipment, abilities and so forth you need. If you can make those 20 minutes (or whatever) a good experience, then you're well on your way to realising your actual desired game. No guitarist begins by trying to shred, and no game designer should begin by trying to make a complete, lengthy RPG.
The silver lining of RPG Maker's limitations is that being able to strongarm such limitations into providing a good experience is a pretty critical skill in game design. That said, you can make platformers and action games in RPG Maker if you're a smarty-pants about the event system... you just have to organise all the required information in the variables tool rather than the actual battle system tool the game provides. Painstaking, but enjoyable in its own way, too.
Is there any version of RPG maker you recommend over others?
VX Ace is the newest and best. The only reason you'd use another is if you already owned an earlier one and didn't want to buy Ace. The only thing is that Ace's (and regular VX's) map editor is a bit worse than XP's. But there are ways around that to some extent and everything else is a big improvement. 2k and 2k3 are shit and don't let anyone convince you to use them.
It's 4*Atk-2*Def, which is just a generic Dragon Quest damage formula.
Why not? RPG Maker is a decent way to teach yourself Ruby, if nothing else. Like... it's totally possible to write your own scripts, and not particularly hard. It's not like you're forced to just copypaste things other people have written...
Or just write it in Ruby like a reasonable person. RPG Maker XP and onward are basically just generic game engines with an RPG-specific editor attached (and a handful of very frustrating limitations, like 640x480 resolution max and no support for non-Windows platforms) and any part of the default game mechanics can be changed.
Decided to go with RPG Maker VX Ace. Got it on Steam, playing around with the system a bit while I make a bunch of notes of ideas for the game.
Thanks for all your help guys. I'll probably come back with more questions for you guys.
Like uh...When it comes to writing a game, particularly an RPG, where should I start? I mean, I've got the basic premise, the conceit, but from there should I just like, write the story or is there a more important step before that?
Beat Chapter 5 in Fire Emblem: Awakening. Whoever came up with that design is a cruel, sadistic bastard.
Are you playing on Hard/Lunatic? Because I don't remember anything being particularly hard on Normal.
On Hard do reinforcements attack the turn they appear? I heard that from somewhere but I don't think it's actually true...
You could do that, or you could learn C# and/or C++ for the very superior tools, platforms and engines that have been developed for them (depending on what you want to do). The game development stuff floating in orbit around those languages is much more versatile than the Ruby equivalents. Such as RPG Maker.
Learning a coding language is not a quick or easy process, which I can say with authority as a monstrously shitty coder. Picking up Ruby as a part of using RPG Maker is one thing, and totally cool, but if one wants to devote time to a coding language for the sake of making games, then the aforementioned variations of C are where they want to be.
Decided I'll make little versions of the game using the assets in RPG Maker. Maybe after I have some little demos and things I can drum up interest.
Keep in mind that RPG Maker is not a particularly well respected platform for professional game design.
It's not impossible; To The Moon is probably the most famous RPG Maker game, and is extremely well-regarded. But most RPG Maker games are dismissed as "another RPG Maker game".
It may be useful as a tool to help you get started as a designer though, to gain some experience.
And if you come up with something decent, you can try releasing it and attempting to get some revenue out of it. A number of people have done this, if you check places like Desura or Aldorlea Games.
That's Game Maker, not RPG Maker, isn't it?
Game Maker has had a few more well-known games like Yume Nikki, Eternal Daughter, and I think Tower of Heaven even.
t.Yume Nikki expert