itch.io

If you don't mind me asking, I'm curious about my next questions because it's nice to get some experience in knowing the way that other people work on their projects. When you spent 1-2 weeks developing your games, How many days do you think you worked on it in a week, and for about how many hours per day?  One of the reasons I am curious is because I generally only have time during the weekend to work on my games and I feel that may be slowing down my progress.

I work full-time but don't have many demands on my time outside of that.  Most of these were made for game jams, so I worked more intensely on them then I otherwise would have, probably a couple hours a night on weeknights and more on the weekends.  They would probably have taken 3-4 weekends to complete if I were only working on them then.  I also can't keep up a jam pace of development indefinitely, so this time frame doesn't necessarily scale up for larger games.  Note that these aren't extensively-polished games with full option menus and such; they were made quickly to a minimal standard, and I moved on after finishing them.

Something else that interests me is that you said you made an RPG game in two months. I don't generally play RPG games so forgive me if I'm way off... But when I think of RPG games I imagine them including Inventories, characters, missions, maps, maybe some animals, a storyline, interactions, music, rewards, save points, etc... And while all of these things can be cut down — for example maybe the game only has 1 map instead of 5 — It is not much different from what I'm trying to achieve. Perhaps I'm just slower lol, but what do you think helped you to efficiently develop those aspects of the game? and Also what did your "bare-bones" game include or not include that made the initial development phase quicker? 

The game is a traditional dungeon crawl, so I asked myself, what does a dungeon crawl really need and what can I do without?  Thinking about what worked in the classic games was helpful here.  Graphics are low-resolution, largely iconographic, and all flat images / sprites that I could draw fairly quickly.  You control five characters, but they are predefined, not custom.  Combat is turn-based against up to ten enemies at once.  Stats and skills are very simple and balance is hand-tailored to this scenario; it is not a full-fledged and fully-scalable system.  There is basic equipment and inventory, but only static NPC interaction, no shop feature, and no "side quests" as such.  The game world is small - five dungeon levels, each a 12x12 grid, and your objective is to explore them all and overcome the challenges presented in each, ending with a final boss.  The game being built on a grid made it easy to rapidly snap dungeon geometry and events into place.  There are save/load and automap features.  I wrote a post-mortem where I talk about some of these decisions and fitting the work into the allotted time frame.

Turn-based combat in particular appears straightforward, and it some ways it is, but it also demands a lot of menu programming and a strictly-controlled cadence of play and visual feedback.  This can be considerably more time-consuming to implement than, say, moving a fireball across the screen each frame and checking for collisions (unless maybe you're working from scratch and haven't implemented a collision API at all yet).

If your objective is just to tinker and play with code, then it doesn't really matter how you spend your time, but if your objective is to ship the game, the key is really to nail down your scope early and try not to get sidetracked adding stuff that might be cool, but isn't really important.  You can always add that stuff in the sequel.  As hobbyists, it is crucial to not let ourselves get carried away, because we can only do one thing at a time.

Also, know when good enough is good enough.  That goes for both game design and code architecture.  Don't spend time significantly refactoring code unless doing so will really save you time later.  Otherwise, save it for the next game.  It is much easier to declare a feature complete if you know when to stop.  I learn better practices and techniques with each game I complete, and since my next game is also an RPG, it is built directly on the framework I created for the last one.  I can now make something bigger and better, with new features, improved workflow, and enhanced playability, while also having shipped a complete game in the mean time.  Shipping is good for motivation.

I find it helpful to design things on paper first.  Whether it is a complex algorithm, a dungeon map, a statistical formula, a monster's behavior script, a gameplay feature or whatever else, I get my clipboard and sit in my bedroom for a while to work it out.  This eliminates the distraction of the IDE and level editor and lets me focus entirely on creating or problem-solving.  Then when I come back to the computer, it is much easier to implement the design I have settled on.