I'm trying to figure out what the best way of going would be:
1. Programming my whole game first with graphics placeholders
2. Working on all my graphics first, then the programming
3. Working on both, scene over scene
I don't have enough experience with RPG maker yet to figure out the best way to go about it. I'm leaning towards making sure all the graphics are done first as most of the pictures get selected when creating the events.. but I don't know.
If anyone has any advice on work flow I'd love to hear it. I'm using rpgmmv
How do you manage work flow?
● ARCHIVED · READ-ONLY
-
-
i tried 2 and 3 before, no success at all, now im trying 1 and im actually getting things done. Also 1 is the best way to test if your game is actually fun or not, if a mechanic isnt engaging with placeholder graphics, chances are it wont be any better with fancy ones.
-
What works best for you. I first pay full attention to the system, while only drafting the visuals. When I don't feel like coding, I make the visual stuff.
-
Use placeholders. Get the entire game done. If you don't even have a story yet, write it out separately before you even start. Then put enough of the database to test maybe say the first hour or two of that story out with graphical placeholders for everything (even the maps if need be, just put enough to test the basic ideas. You can always go back and fix them later).
Once you got a few hours of the game made AND also released a demo for testing and gotten some feedback, them maybe start tweaking the graphics. Sure, you may take a little flax for your use of RTP placeholders (one of my characters was using the maid sprite in my demo. A couple people commented on it, but most of them understood), but at least this way you know the game is worth finishing before spending the extensive time making it look pretty. -
Today, I focused on making the shape of the game first. So, it goes to the coding first. I use placeholder and all. To test if my concept actually works and fun to play. Once the shape of my game is done, I know what to make, I know what the resources I'm lacking. Then I may began to collect or make resources.
I finished my game using all placeholders first for about 3 months of developing. It was horrible because it looked like cheap RTP games. After getting some feedback, I revisited my game, change some of things and graphics, to make it stylized. Editing RTP so it's wont be like your another RM games. And eventually replacing my actor placeholder graphics. It worked great for me -
Thanks so much everyone. Seems you all have pretty much the same consensus. :D
-
For most people this is the way to go, because you won't move anywhere otherwise :D
-
I like being pretty basic with my workflow
#1 have a story in mind and general idea how it will go
#2 develop my world map; this helps me figure out the story even more
#3 database entries, hate this part; I keep the base spell graphics, but pretty much reenter everything else
#4 one town/story piece at a time. I develop the story as I build it
I try to avoid burnout at all costs; if I feel tired, i finish the small part i'm working on and take a good break -
I would say that there really isn't a right or wrong answer, beyond perhaps whichever method produces the best result for you, & keeps you motivated to keep working on your project.
Personally I try to plot out my development in intervals, & if I am tired of working on a particular element, I switch over to something else to provide some variety.
For example last month was a great deal of database work involving skill trees, class progression trees, balancing the classes parameters, etcetera. This month I am mostly working on terrain features for the field maps. Next month I might work on the enemy & troop files, or I might put more work on the field maps, or I might spend more time writing world lore.
On a long enough timeline you have to do everything no matter what order you place it in, so the most important thing is to maintain forward momentum. -
I would say:
0. Plan your game's story first.
At least an outline of it. Without it you may spend hours of work on some event(s) which in the end will seem not coming togheter with the rest of the story or be just unecessary. -
I would say:
0. Plan your game's story first.
At least an outline of it. Without it you may spend hours of work on some event(s) which in the end will seem not coming togheter with the rest of the story or be just unecessary.
Sorry, the original post was assuming the story is already down. I didn't think anyone would start without any sort story first :LZYyuck: -
Sorry, the original post was assuming the story is already down. I didn't think anyone would start without any sort story first :LZYyuck:
I and a friend actually did that one summer when we were bored. It ended with the line "And then aliens invaded". Let's just say it was so bad that even we could see it, so we decided to essentially just nuke the story in the most ridiculous way possible. -
I would recommend:
- Design first (written designs of overarching narrative, town designs, game mechanics, battle system, etc., with at least small amounts of actual content written down)
- Implement second (programming everything needed to make the "core" of your game work, eventing out all of the scenes, and using placeholders to design maps)
- Add depth third (add the full list of skills, states, stats, items, etc. - there are times you'll want to interchange this with 'Implement')
- Polish last (replace all of your placeholder graphics, sounds, menus, and other assets with the final, perfect product)
Also, a lesson I've learned in the project I'm working on now is that the team members who are responsible for creating the final resources should be involved in the design revolving around those resources early on. For example, I designed custom menus on my own, sent the requirements for them to a scripter to program it, received a good script, and then turned it over to my GUI artist to design cool graphics that would fit that menu. My artist came up with ideas for presenting information that could not be implemented by the script that I designed, but that I had to admit were better ideas than my own. So then I had to send it back to my scripter for a second round of major enhancements to the script, which cost me additional time and money. If I had discussed the design with my artist at an earlier stage and had him make a quick mockup, the process would have been far more efficient. I'm gonna do it right on my next project! -
There is a good video from Yanfly about game making process which I think is good. Here it is.
-
I personally work in cycles of mapping, databasing, and story. I also set weekly or monthly goals.
Avoiding video games is a huge plus. I play less than half the games I used to.