Hey there,
I am undertaking a final year project as part of my university degree, and for it I need to create a Lua RPG. This sounded great when I was applying for this project, but I am having a problem deciding on the scale of the project. I wanted to make a 2D RPG with basic graphics (similar to old Legend of Zelda/Final Fantasy games). The RPG would be an open world RPG with items to pick up, enemies to fight, and towns/dungeons generated by me rather than randomly generated. I have roughly 6 months to do this, and don't think I'll have enough time to make a complete game. It may be better to simply make a text based RPG where users choose from options (e.g. arrive in a forest, head north/south), but I feel that this could be completed way before the 6 months have passed. Anyone have a rough idea of how much could be accomplished on average in 6 months, assuming something like 15 hours work a week?
Sorry if this is a very vague question, I am just really struggling on deciding what RPG I should set myself on making, instead of making one and finishing it too early, or making another and running out of time.
Creating a Lua RPG rough timing?
Well, since it's a small matter of programming, it sounds like it'll be done Soon, particularly if you're counting in Valve time.
It's really not easy to estimate the scope of a project particularly when little of the groundwork is done and we don't know the resources that you've got. Are you allowed access to third-party libraries? Do you have a partner or a team? Will you have to spend time drawing your own graphics? It also doesn't cover the content of the game itself. If the combat is more dynamic than the exploration, that's going to take more than your adventuring. If there's puzzle elements you're going to have to take the necessary items and widgets into account, more than if the player was just walking around the screen.
It's also different from person to person - I might get lucky and bang out the combat system in a productive week while locked in my room, and be held up at quest tracking for a month while you've blown through both in half the time.
You should probably try to build a simple system then build content onto it as you go. Start with the combat and if it takes you five months, use the last to turn it into an arena style RPG with a text menu shopping screen between bouts. If you manage to get an overworld map done, use it as a point-A-to-B travel system between multiple combat zones. If you manage to get a dungeon system, you might have enough time to throw in procedurally generated instances or a roguelike.
It's also not a problem to finish early - You can continue to polish a completed system and you may find yourself surprised at the innovations that can come out of it. The quality shows when a game has been refined properly, and you'll never know what to put into that until it's finished.
It's really not easy to estimate the scope of a project particularly when little of the groundwork is done and we don't know the resources that you've got. Are you allowed access to third-party libraries? Do you have a partner or a team? Will you have to spend time drawing your own graphics? It also doesn't cover the content of the game itself. If the combat is more dynamic than the exploration, that's going to take more than your adventuring. If there's puzzle elements you're going to have to take the necessary items and widgets into account, more than if the player was just walking around the screen.
It's also different from person to person - I might get lucky and bang out the combat system in a productive week while locked in my room, and be held up at quest tracking for a month while you've blown through both in half the time.
You should probably try to build a simple system then build content onto it as you go. Start with the combat and if it takes you five months, use the last to turn it into an arena style RPG with a text menu shopping screen between bouts. If you manage to get an overworld map done, use it as a point-A-to-B travel system between multiple combat zones. If you manage to get a dungeon system, you might have enough time to throw in procedurally generated instances or a roguelike.
It's also not a problem to finish early - You can continue to polish a completed system and you may find yourself surprised at the innovations that can come out of it. The quality shows when a game has been refined properly, and you'll never know what to put into that until it's finished.
Well, since it's a small matter of programming, it sounds like it'll be done Soon, particularly if you're counting in Valve time.
It's really not easy to estimate the scope of a project particularly when little of the groundwork is done and we don't know the resources that you've got. Are you allowed access to third-party libraries? Do you have a partner or a team? Will you have to spend time drawing your own graphics?
It's also different from person to person - I might get lucky and bang out the combat system in a productive week while locked in my room, and be held up at quest tracking for a month while you've blown through both in half the time.
You should probably try to build a simple system then build content onto it as you go. Start with the combat and if it takes you five months, use the last to turn it into an arena style RPG with a text menu shopping screen between bouts. If you manage to get an overworld map done, use it as a point-A-to-B travel system between multiple combat zones. If you manage to get a dungeon system, you might have enough time to throw in procedurally generated instances or a roguelike.
It's also not a problem to finish early - You can continue to polish a completed system and you may find yourself surprised at the innovations that can come out of it.
The only thing is, we have to write an initial report where we specify the goals of our project. So it will look bad if I implement or do not implement stuff that I have specified/not specified in the project goals.
I am on my own for making this, so it would be the work of just one person.
I was not thinking of implementing a quest system as such, simply something along the lines of go to this location/talk to this person/kill this boss to make the story progress.
I was thinking of making the graphics myself, and using tilemaps with graphics similar to that of Final Fantasy (http://allgamesplayed.com/wp-content/uploads/2010/02/ff1.jpg). But even this could take up a lot of time in the project which could be used for coding.
I'm a decent programmer and I know my way around an image program, but the latter takes me much longer for tinier gains than the former. It's completely different for each person, but if you're doing the art yourself, that will still take up a notable amount of time.
Is the combat action-oriented, or turn-based? You mentioned both Zelda and FF so I wasn't quite sure. With one, you'll have to worry more about proper hit detection and the physics of movement and attacks, which can be a little troublesome. The other can be technically simpler (if you're not making the number system complicated,) but can be further improved with some flair to make it interesting to sit through.
And that's where you can cover yourself on the features - You can call out the concepts in general, but still allow yourself the room to dress it up a bit too.
Plenty of games have been made in 6 months or less, though usually with some level of experience - and drastically differing levels of quality. Comparable to your concept, "Cthulu Saves The World" was released 9 months after their previous title, but carried over a lot of the development work from it too. I don't know how long they spent on its predecessor, but this was in one interview about it:
Is the combat action-oriented, or turn-based? You mentioned both Zelda and FF so I wasn't quite sure. With one, you'll have to worry more about proper hit detection and the physics of movement and attacks, which can be a little troublesome. The other can be technically simpler (if you're not making the number system complicated,) but can be further improved with some flair to make it interesting to sit through.
And that's where you can cover yourself on the features - You can call out the concepts in general, but still allow yourself the room to dress it up a bit too.
Plenty of games have been made in 6 months or less, though usually with some level of experience - and drastically differing levels of quality. Comparable to your concept, "Cthulu Saves The World" was released 9 months after their previous title, but carried over a lot of the development work from it too. I don't know how long they spent on its predecessor, but this was in one interview about it:
Reyes: ... what would you say was the most difficult aspect of making your own role-playing game?
Boyd: Probably programming the battle system and related code. I went in thinking that I’d have the battle system code done in a week or so, and it ended up taking over a month to do.[/quote]
I'm a decent programmer and I know my way around an image program, but the latter takes me much longer for tinier gains than the former. It's completely different for each person, but if you're doing the art yourself, that will still take up a notable amount of time.
Is the combat action-oriented, or turn-based? You mentioned both Zelda and FF so I wasn't quite sure. With one, you'll have to worry more about proper hit detection and the physics of movement and attacks, which can be a little troublesome. The other can be technically simpler (if you're not making the number system complicated,) but can be further improved with some flair to make it interesting to sit through.
And that's where you can cover yourself on the features - You can call out the concepts in general, but still allow yourself the room to dress it up a bit too.
Plenty of games have been made in 6 months or less, though usually with some level of experience - and drastically differing levels of quality. Comparable to your concept, "Cthulu Saves The World" was released 9 months after their previous title, but carried over a lot of the development work from it too. I don't know how long they spent on its predecessor, but this was in one interview about it:
Reyes: ... what would you say was the most difficult aspect of making your own role-playing game?
Boyd: Probably programming the battle system and related code. I went in thinking that I’d have the battle system code done in a week or so, and it ended up taking over a month to do.
[/quote]
I was thinking of making it technically more FF related with the battle system. The numbers system wouldn't be complicated or anything. Looking at Cthulu saves the world, it would be similar in concept to that game too. If that took experienced people 9 months, I don't think me on my own would come close to making a finished game, perhaps a couple of levels...
The content of that game runs 6-10 hours, so you could cut back there, but was programmed between two people and used libraries they'd created for their previous game, so that work was already done. They also spent time working on a number of improvements to satisfy the fanbase they'd created. You can check "Breath of Death VII" to see their less-polished work.
For me working alone on my side scrolling "Egg Hunt" C++ project from Dec 14, 2011 to Jun 15, 2012 it appears that I worked on the project 57 individual days of which I'll estimate 2.5 hours each day which would be 142 hours. This yielded around 3800 lines of new code, various non-coherent rambling notes coming to 25,050 words, and the program you can see on my website. I think it took around 2 months to have a basic prototype going where other people would be able to have a proper feel for the game. There were a lot of fiddly little bits and small additions after that which were never ending. Finally I just decided to declare the project closed as it stood.
I don't think any of those numbers above will be at all relevant to you as they are pretty much all meaningless metrics and because you'll be using a different language, libraries, and working at your own skill level. Also, as you're working on a university degree project, no doubt you will also likely need to produce other formal, presentable writings as part of the project. I can't begin to guess how long that would take.
There are a great deal of things that can probably get done in 6 months coding 15 hours a week. But unless you know your project and your abilities really well, I don't know how you can come up with an estimate.
My suggestion, sit down and give yourself proper time to bang out a rough draft of your initial report. I would bet that a big part of that initial report is to determine if the project is within your ability to accomplish so a rough draft should help you determine that. Write down everything that you plan to include and a development schedule. Determine what things are essential, what things are optional, and come up with contingency plans if you are unable to get something worked out.
As for including things in the initial report that don't get done, features get dropped and changed all the time. It is a natural part of the development process for features to be changed, added, or dropped mid-development. That being said, there are probably good reasons for those changes so you should be prepared to discuss that in any final documents you produce.
I don't think any of those numbers above will be at all relevant to you as they are pretty much all meaningless metrics and because you'll be using a different language, libraries, and working at your own skill level. Also, as you're working on a university degree project, no doubt you will also likely need to produce other formal, presentable writings as part of the project. I can't begin to guess how long that would take.
There are a great deal of things that can probably get done in 6 months coding 15 hours a week. But unless you know your project and your abilities really well, I don't know how you can come up with an estimate.
My suggestion, sit down and give yourself proper time to bang out a rough draft of your initial report. I would bet that a big part of that initial report is to determine if the project is within your ability to accomplish so a rough draft should help you determine that. Write down everything that you plan to include and a development schedule. Determine what things are essential, what things are optional, and come up with contingency plans if you are unable to get something worked out.
As for including things in the initial report that don't get done, features get dropped and changed all the time. It is a natural part of the development process for features to be changed, added, or dropped mid-development. That being said, there are probably good reasons for those changes so you should be prepared to discuss that in any final documents you produce.
Anyone have a rough idea of how much could be accomplished on average in 6 months, assuming something like 15 hours work a week?
Simple 2D games require as much as ~40 hours of programming (without any fancy stuff). So, you could assume, that after ~3 weeks you'll have a playable tech-demo of your zelda-style RPG (simple map of the starting location, moving your character and NPCs, maybe transitions between locations or a simple inventory management). If you'll be programming for several months you could have much more time to polish it's gameplay. My advice: go for it, do not be afraid ;)
Edit for the minusing one:
Haps, I do have examples of the fast (about 40 hours) game prototyping, like ones from http://www.ludumdare.com/ and http://www.pyweek.org/ and what about you? Care to backup your minus? ;)
I was thinking of making the graphics myself, and using tilemaps with graphics similar to that of Final Fantasy (http://allgamesplaye...2010/02/ff1.jpg). But even this could take up a lot of time in the project which could be used for coding.
Btw, do not waste time with drawing the art by yourself (unless you are pretty good at it). Just do the programming. For character sprites you can use some resources from: http://www.famitsu.com/freegame/tool/chibi/index1.html and http://www.famitsu.com/freegame/tool/chibi/index2.html
With 6 months, I wouldn't go all out. You should begin by making the initial town, then continue building dungeons until you feel you're running low on time. Don't set out to have 16 dungeons, only to find out that you have 8 more dungeons to build with 1 week left. Don't get too complex, keep it linear.
I had a similar project early on in CS classes. I spent maybe 4 weeks developing an RPG using a proprietary C++ 2D graphics engine, that essentially just made drawing shapes on a screen easy, while all input was done through a console. In that amount of time I was able to put together,
- A main town with a quest giver, a shop to buy/sell items, and an inn to rest/save
- Two dungeons that connected from the first town, each dungeon was unlocked via the quest giver, and bosses were unlocked via the quest giver.
Really simple game, and it was pretty intensive over those 4 weeks.
I did one later with C++ and DirectX that took about 3 weeks. Had a similar scale with a town/shop/quests, an overworld "dungeon" and a castle that acted as a final dungeon.
Both of these games had an FF-like turn-based battle system which is very easy to develop. All of the areas in these games were scratched down on paper beforehand. I had notes in these drafts that indicated locations of quest givers, shops, etc. If there were mobs on the map, the area would be indicated by mob level and would help me figure out how to distribute enemy levels throughout the maps while keeping up with the player's level based on the likely number of mob encounters (all FF-like random encounters) and level-up opportunities.
There was an old article with a guy putting together a pretty nice RPG (more in the style of Diablo I think) using Python, and doing it all in a week with no budget. http://www.gamedev.n...no-budget-r2259 Maybe you can get some pointers from him to help expedite certain areas of your project.
I had a similar project early on in CS classes. I spent maybe 4 weeks developing an RPG using a proprietary C++ 2D graphics engine, that essentially just made drawing shapes on a screen easy, while all input was done through a console. In that amount of time I was able to put together,
- A main town with a quest giver, a shop to buy/sell items, and an inn to rest/save
- Two dungeons that connected from the first town, each dungeon was unlocked via the quest giver, and bosses were unlocked via the quest giver.
Really simple game, and it was pretty intensive over those 4 weeks.
I did one later with C++ and DirectX that took about 3 weeks. Had a similar scale with a town/shop/quests, an overworld "dungeon" and a castle that acted as a final dungeon.
Both of these games had an FF-like turn-based battle system which is very easy to develop. All of the areas in these games were scratched down on paper beforehand. I had notes in these drafts that indicated locations of quest givers, shops, etc. If there were mobs on the map, the area would be indicated by mob level and would help me figure out how to distribute enemy levels throughout the maps while keeping up with the player's level based on the likely number of mob encounters (all FF-like random encounters) and level-up opportunities.
There was an old article with a guy putting together a pretty nice RPG (more in the style of Diablo I think) using Python, and doing it all in a week with no budget. http://www.gamedev.n...no-budget-r2259 Maybe you can get some pointers from him to help expedite certain areas of your project.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement