#162123 - Matthias - Tue Aug 26, 2008 4:00 am
Okay. I'm absolutely new to GBA game developing, not to mention C++. My knowledge of C++ is very little... almost nothing compared to the things I need to know for game programming actually. The reason I found this forum today is because for the past couple of weeks I've had all sorts of ideas for game developing with structures similar to a typical GBA game. Finally I just randomly thought, "Is it possible to develop for the Game Boy Advance platform?" I did a Google search and it came to this website as the first result.
So I've read through the "Frequently Asked Questions *READ FIRST!*" topic, mainly the first two posts. It says this:
| tepples wrote: |
| Learn the C programming language. A member has found this tutorial helpful. Make some simple text-based programs for the PC. If you are looking for a PC-targeted compiler, and you're on Windows, try MinGW. |
Does that mean I have to know C programming or does that also mean C++ as well? I know C++ is derived from C and they're both very, very similar, however which one should I focus on? Also can C++ and C programmed files work together or must they be separate? I'm sorry I know these are ridiculously newbie questions, but I just want to get a basic idea of where exactly I should start at.
#162124 - Dwedit - Tue Aug 26, 2008 6:57 am
You can use either language. Language doesn't matter as much as the libraries you use.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#162125 - Matthias - Tue Aug 26, 2008 7:02 am
Alright I appreciate the response. I'll just keep on with C++ then. :)
#162129 - gauauu - Tue Aug 26, 2008 3:24 pm
Good questions Matthias. I'll try to elaborate a little more, but some of things I'll say aren't necessarily the absolute answers, but a reasonable answer injected with a healthy dose of my opinion. :)
| Matthias wrote: |
| Does that mean I have to know C programming or does that also mean C++ as well? |
C++ is fine.
| Quote: |
| I know C++ is derived from C and they're both very, very similar, however which one should I focus on? |
Whichever you want. C is a bit simpler, so will likely be easier to learn. C++ has a lot more fancy stuff you can do. If it was me learning from zero, I'd learn C first, but if you are confident in learning C++, that's fine as well. If you come from a very Object-oriented programming background, then C++ won't be as big a leap.
| Quote: |
| Also can C++ and C programmed files work together or must they be separate? |
In a nutshell, yes, they can work together. Read up on extern "C" and check out the C++ faq lite section on mixing code for more detail.
| Quote: |
| I'm sorry I know these are ridiculously newbie questions, but I just want to get a basic idea of where exactly I should start at. |
They may be newbie questions, but they are intelligent questions, which is better than a lot of people. The exact question of where to start always depends on your experience. It sounds from your questions like you have some programming experience. In that case, I'd pick C or C++ (C if it was me, but that's up to you), read up and do a few small practice programs, then dive in. And bookmark TONC.
Have fun and welcome to the community.
#162131 - Miked0801 - Tue Aug 26, 2008 5:58 pm
I hate to say it, but C is a dying language in the main stream. You'd be much better off learning C++ form the start instead of picking up C to C++ bad habits like I have :)
#162136 - Kyoufu Kawa - Tue Aug 26, 2008 7:17 pm
| gauauu wrote: |
| C is a bit simpler, so will likely be easier to learn. C++ has a lot more fancy stuff you can do. |
Actually, I find that most "fancy stuff" from C++ can be at the very least approximated in C.
As an example, Wolfenstein 3D is written in C, but the game actors are done in object oriented ways using linked lists and a version of C++'s this pointer. I was amazed.
#162138 - tepples - Tue Aug 26, 2008 7:33 pm
| Matthias wrote: |
| Does that mean I have to know C programming or does that also mean C++ as well? I know C++ is derived from C and they're both very, very similar, however which one should I focus on? |
C++ the language is fine. But parts of the C++ standard library, especially <iostream> and exception handling, aren't implemented very space-efficiently in the GNU toolchain on which devkitARM is based. A statically linked hello world program using <iostream> has been known to eat up over 250 KiB, an order of magnitude bigger than the equivalent program using <cstdio>.
Space is at much more of a premium on a GBA than on a typical PC or even a DS. The GBA has 32 MiB of space for code and read-only data and only 288 KiB for read-write data and the heap. For players 2, 3, and 4 in a multiplayer game, and for all players using a GBA Movie Player, the 288 KiB has to cover code and read-only data as well.
Kyoufu Kawa is right: C is enough for some forms of object-based programming. The Allegro library, written in C, even uses what are obviously supposed to be vtables for method dispatch.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#162142 - Quirky - Tue Aug 26, 2008 8:22 pm
| tepples wrote: |
| C++ the language is fine. But parts of the C++ standard library, especially <iostream> and exception handling, aren't implemented very space-efficiently in the GNU toolchain on which devkitARM is based. |
Have you seen the Google coding standards for C++? They recommend not using exceptions and favouring printf style functions over streams. And that's for cross platform code (Linux, Mac, Windows), not just embedded code. Although they do admit that if they "started from scratch" that they may have allowed exceptions.
Streams have problems other than their size. Formatting with streams is painful (record flags, set flags, check flags, ugh) and printf-style string-with-format-information is far more useful for translation work, for example. Exceptions are a very difficult to get right and not leak memory. For more C++ headaches, the Defective C++ article and related "FQA" (frequently questioned answers) are an interesting read.
Of course I think C++ used right is the best tool for the job on the DS. The "managed environments" available on the DS (e.g. Java, Lua, Python) are all hobbled in some way. C has less magic, but I'd hate to lose the OO features of C++ - I think you'd end up recreating some of them (buggily) in C. Be careful, and C++ is not too bad.
#162148 - Dwedit - Tue Aug 26, 2008 10:14 pm
You can do exceptions in C, it's called Setjmp and longjmp. But C++ exceptions are more powerful because they can call destructors.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#162153 - keldon - Tue Aug 26, 2008 11:47 pm
Why C? Well C is just plain procedural programming, so you can cover the basics of algorithms easily without having too much possible language features to think about.
Why C++? Well C++ allows (native) support for OOP (Object Orientated Programming). If you learn C first, you will have to unlearn and relearn your design process when getting into OOP.
You also have to remember that learning how to use the language to implement a solution to a particualr problem is not the same as learning how to solve a particular problem. So whilst learning a language (for the first time) you must also learn how to solve problems - which is a bit of a catch 22, considering they both require a bit of each other to do so.
I learned BASIC first, so I already had procedral programming out of the way before I got into C++, but didn't learn it through C; so my experience gives me a bias towards learning something else before C++ - but thinking about it a little more, start with a good C++ book.
Once you are comfortable with C++; read Effective C++, More Effective C++ and then Design Patterns (that gang of four book). I think there's another one called (something like) coding standards, it's a crimson coloured book (I think). It is through reading these books that you are likely to reach the full potential of C++, and really know how and when to use each feature systematically and like a professional. You will have much greater satisfaction in your work too, and your hobby will become a greater joy ^_^
#162155 - Matthias - Wed Aug 27, 2008 12:15 am
| keldon wrote: |
Why C? Well C is just plain procedural programming, so you can cover the basics of algorithms easily without having too much possible language features to think about.
Why C++? Well C++ allows (native) support for OOP (Object Orientated Programming). If you learn C first, you will have to unlearn and relearn your design process when getting into OOP.
You also have to remember that learning how to use the language to implement a solution to a particualr problem is not the same as learning how to solve a particular problem. So whilst learning a language (for the first time) you must also learn how to solve problems - which is a bit of a catch 22, considering they both require a bit of each other to do so.
I learned BASIC first, so I already had procedral programming out of the way before I got into C++, but didn't learn it through C; so my experience gives me a bias towards learning something else before C++ - but thinking about it a little more, start with a good C++ book.
Once you are comfortable with C++; read Effective C++, More Effective C++ and then Design Patterns (that gang of four book). I think there's another one called (something like) coding standards, it's a crimson coloured book (I think). It is through reading these books that you are likely to reach the full potential of C++, and really know how and when to use each feature systematically and like a professional. You will have much greater satisfaction in your work too, and your hobby will become a greater joy ^_^ |
Haha I'm already getting excited just about starting! *geek geek geek* :P
But is there really a book called "MORE Effective C++" or were you just kidding? I already know there's a book called Effective C++ I think. I'm wondering because I'm thinking about looking into some books to start out with or for future reading when I get more experience. (In this case it's Effective C++, MORE Effective C++ if it exists?, Design Patterns, and possibly a good beginner's book.) So far it's I have a "crash course C++ book" but for some reason I'm not getting very good vibes from it.
Also are there any beginners books that are recommended? I'm not sure about C++ for Dummies, but I do have a copy although I never read it. Also are there any good C++ resource/tutorial websites you guys recommend for beginners?
#162156 - putzpie - Wed Aug 27, 2008 12:35 am
#162160 - tepples - Wed Aug 27, 2008 2:17 am
| Matthias wrote: |
| But is there really a book called "MORE Effective C++" or were you just kidding? |
Scott Meyers wrote Effective C++. Then he wrote a sequel titled More Effective C++. Then they both got repackaged into a single CD-ROM. I own a copy of that CD, and I recommend it.
| Quote: |
| So far it's I have a "crash course C++ book" but for some reason I'm not getting very good vibes from it. |
That's not by Herb Schildt, is it? I hope not.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#162166 - Matthias - Wed Aug 27, 2008 3:31 am
| tepples wrote: |
| Matthias wrote: | | But is there really a book called "MORE Effective C++" or were you just kidding? |
Scott Meyers wrote Effective C++. Then he wrote a sequel titled More Effective C++. Then they both got repackaged into a single CD-ROM. I own a copy of that CD, and I recommend it.
| Quote: | | So far it's I have a "crash course C++ book" but for some reason I'm not getting very good vibes from it. |
That's not by Herb Schildt, is it? I hope not. |
It's called C++ Weekend Crash Course 2nd Edition by Stephen R. Davis. Also the "author of C++ For Dummies" (that I never realized). It's supposed to guide you through C++ on a 15 hour "crash course."
Also what a coincidence! I was looking through my father's library and I found the book of Effective C++ by Scott Meyers. He probably used it back when he worked at IBM. The only thing that worries me is that the book was published in 1992... I'm wondering if Scott Meyers updated the book later on? And I also found another book in the same "series" of Effective C++ (Addison-Wesley Professional Computing Series) and it's called C++ Programming Style by Tom Cargill. Has anyone read it and do they recommend that?
#162293 - MotK - Sat Aug 30, 2008 4:36 am
Building on the OP's question, perhaps your answer may depend on the exact TYPE of game I am looking to build.
My goal is to develop a Final Fantasy-style RPG based on the Stargate SG-1 TV series.
I understand that sometimes the genre of game lends itself better to the language. For example, with an RPG, I can see how OOP and the use of classes would lend itself to constructing monsters to battle and so forth. Therefore, I can see how C++ would be the way to go.
On the other hand, there have been many successful RPG games developed for the GBA that were programmed using C, which from what I understand needs to be modified somewhat to utilize OOP. (As a sidepoint, I stumbled upon Jonathan Harbour's e-book on Game development for the GBA, but the knowledge of C is required. Yet, since I would like to also develop my game for the DS, perhaps C++ would be the way to go.)
Perhaps I am just asking everyone to repeat themselves but I believe a more nuanced question will help me in my struggle. Time is not a valuable commodity (I have a 5-month old son) and I don't want to spend time learning a language that will not let me do what I want to do!
Thanks in advance for your answers!
#162294 - sgeos - Sat Aug 30, 2008 8:15 am
| MotK wrote: |
Building on the OP's question, perhaps your answer may depend on the exact TYPE of game I am looking to build.
My goal is to develop a Final Fantasy-style RPG based on the Stargate SG-1 TV series. |
Your engine can be programmed in C or C++. Whether you use structs and functions that modify them, or objects is largely irrelevant. Either way you looking at big arrays of data. RPGs are easy to program, but because of the content level people expect, a team of one can not make an RPG in a reasonable amount of time.
Now, the language you are probably looking for is Lua. Binding it to C or C++ is relatively painless from what I understand, and you will need some sort of scripting langauge if you intend to make your RPG the smart way. Before you dismiss Lua, keep in mind that WoW and at least one of the FF use it.
Also, the other concern is your tools. You probably want to use high level languages like perl, python or ruby to mangle your data into shape on the PC side. Remember, regular expressions are your friends.
So, to sum it up, this is your require list of languages:
C or C++ for the engine AND
Lua for the in game scripts (or a custom solution if you have one ready to go) AND
Perl, Python or Ruby for data manipulation
Good luck!
-Brendan
#162302 - Miked0801 - Sat Aug 30, 2008 7:05 pm
Creating a RPG from scratch with a limited time budget huh? In a language you've never used? On a difficult system to develop on? May I suggest scaling Mt Everest without an oxygen tank instead? You'll have a higher chance of success.
Oh and you don't have to be OOP with C to make an RPG. You can spaghetti away if you are the only person working on it and you have a 'large internal stack' for keeping track of everything; and you document like crazy. The RPGs I helped develop were done in z80 (GBC) the first two and C on the third (GBA) - all without a canned scripting language. We created our own Basic like script language to handle event programming. It was a bit touchy to use, but it worked.
To give you an idea of why I find it funny for you by yourself to do an RPG, the GBA one in C took almost a year with over a half dozen experienced and profession developers and artists working on it 8-10 hours a day. The Z80 ones actually went faster (9 mos), more to do with client relations that anything else.
Please, just go make pong.
#162307 - silent_code - Sat Aug 30, 2008 10:18 pm
... or a shooter. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#162314 - sgeos - Sun Aug 31, 2008 9:08 am
| Miked0801 wrote: |
| all without a canned scripting language. We created our own Basic like script language to handle event programming. It was a bit touchy to use, but it worked. |
Whether you use a canned scripting or language, or you roll your own, you want to use something. Writing all the scripts in C would just be silly.
| Miked0801 wrote: |
| To give you an idea of why I find it funny for you by yourself to do an RPG, the GBA one in C took almost a year with over a half dozen experienced and profession developers and artists working on it 8-10 hours a day. |
By my calculations this would take 8 - 9 full time years (2080 hours) if one person did it all on their own. Admittedly, the quality would probably be lower and I supect it would actually be finished in 4 to 6 years (about 10,000 hours), if for no other reason than that you would get sick of it. =)
-Brendan
#162323 - MotK - Sun Aug 31, 2008 2:14 pm
Wow! I don't know if this is one of those moments where everyone is doubting me and I should just plow ahead and make history, or listen to the voice of reason and give up now!
#162326 - Miked0801 - Sun Aug 31, 2008 5:32 pm
If you make a pong / puzzle game first (and second), 90% of the code you write will eventually be applicable to a future RPG. Sprite Management, Palette management, actor control, menu genesis, etc. We're not telling you to start small for no reason! Once you have the basics in place, then RPGs go from impossible to just impractacle - something that can be overcome.
#162331 - silent_code - Sun Aug 31, 2008 8:23 pm
Nobody is actually telling you to stop. We're trying to help you with starting in a better way, thus increasing your chances for success with your goal in the long run. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#162334 - keldon - Sun Aug 31, 2008 8:59 pm
Good point about the menu system; at least try some of the smaller components you will be needing in your RPG.
#162345 - MotK - Mon Sep 01, 2008 3:19 am
I understand the suggestions regarding trying out smaller games. That seems to be the consensus wherever I go and whatever book I read. Interestingly, I am so bereft of original ideas that I have no idea what kind of puzzle game to make. I've tried to inspire myself so many times to take up programming as a hobby, with the sole intent on making the kind of games no one else is making. (By this I mean an RPG that is NOT based on some sort of Tolkien universe - or Pokemon which I just can't get emotionally involved enough for.)
Since the RPG is the end result I'm looking for, would perhaps studying an open-source or homebrew RPG already in existence be a good starting point as well? Especially since all the game design books I have read seem to be so abstract, I'm lost how to apply it toward the genre I'm interested in, or more to the point, I don't know how to put it all together!
To be totally honest, I understand that undertaking an epic 40-hour RPG like FFVII is prohibitively restrictive given my time constraints and level of knowledge. I suppose if I can just accomplish enough of a tech demo that shows off my idea well enough to peak the interest of a publisher (specifically Cheyenne Mountain Entertainment, the company with the property rights to the Stargate franchise). I'm only interested in designing a few levels well that will give everyone a glimpse of the final project - whether that ever happens or not.
I'm sure you can now see better the fork in the road I am up against!
#162349 - nyarla - Mon Sep 01, 2008 4:18 am
MotK: I think studying an open source rpg would likely end up being really confusing. I agree with what others said about starting by making something small - because in the process, the more complicated concepts you'll need for an RPG will become apparent. It will really help you fix all that abstract stuff from the game design books into place in your mind. That's what I'm finding anyway. (no reason NOT to study some open source rpg code though).
Not very good example of how simple stuff is the building blocks of more complex stuff: if you made say, a breakout clone.. you'll probably use multiple moving sprites and a tilemap, and simple collision detection.. Once that's all working nicely it's easy enough to change the paddle and ball sprites into, say, cute people with spiky hair, and the bricks into a landscape for them to walk on, with the collision routines being used to stop them from walking through walls.
I'm just repeating what other people said, cos it's what I'm up to in my coding adventures at the moment too. :)
#162353 - sgeos - Mon Sep 01, 2008 7:20 am
The engine code for an RPG is not any more work than the engine code for another game. The problem is all the assets. You have the basics, like graphics, sound, and music. Then you have field scripts, battle scripts, and a whole bunch of data. The scale is what kills you.
The two "simple" solutions are:
A) Spend forever making it by yourself, or
B) Work with a team.
You could also create all the assets for a PC version of the game and then port them to the GBA/DS, although you need to be careful how you do this.
Because the engine does all the basic things any other game engine does, 90% of your pong code (as mentioned above) will be usable in a larger scale project. Naturally, an RPG game engine will have RPG specific code, and also some other things that are specific to your game.
None of this is hard, but it takes time and you need to do things one step at a time. If you don't you will probably get overwhelmed or bored and give up. Taking on a smaller scale project first is highly advised. A few of them is even better.
-Brendan
#162354 - silent_code - Mon Sep 01, 2008 7:29 am
Motk, you just made another point (in fact, a few of them) to start simple. Really.
I haven't made a homebrew game that got finished (yet), but got into the industry through little tech demos and (rather) well written source code. Small and fun or (still small and) impressive things are better than making potentially hughe things. Sort of. ;^)
Well, RPGs (even "just" a framework and some demo content) aren't among them.
Again, if you can't think of a puzzle to make, make a simple shooter and add some fun and simple element to it. :^)
Have fun! :^D
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#162360 - keldon - Mon Sep 01, 2008 8:21 am
Looking through the source code for an RPG project will teach you as much about programming as looking at schematics will teach you about electronics; nothing! Look at the syllabus for a software engineering University course; each of those topics are relevant to game programming.
Whether the end product of the books is an RPG or a bus journey simulator; they all teach you what you need to learn first before thinking about tackling any project. There are pre-requisities to programming a game, each of those books will teach them to you.
To name a few areas you need to learn before thinking of creating an RPG:
- algorithms and data structures
- logic and reasoning
- OOP (which is more than just knowing what a class is)
- design patterns
- software engineering
- code design and implementation practices, and effective use of the language
Once you learn these aspects of programming, then you will be able to look at RPG source code and make sense of it. That is not to say that learning to program is a big hurdle; but you have to learn it step by step.
You will learn the basics of algorithms and data structures, as well as (really really basic) logical reasoning and general OOP through a basic beginners book. Software engineering, best practices and design patterns will be learned through reading certain books and the experience gained from making your pong games.
#162413 - sgeos - Tue Sep 02, 2008 3:22 pm
| keldon wrote: |
| To name a few areas you need to learn before thinking of creating an RPG: |
To add a few more:
Managing lots and lots of files
Managing lots and lots of data
Managing time
-Brendan
#162415 - MotK - Tue Sep 02, 2008 3:49 pm
Good lord, now I'm scared!
Okay....maybe MY job should just be providing the idea vision and gather other interested parties to do much of the design and coding work then, huh?
#162419 - bean_xp - Tue Sep 02, 2008 6:57 pm
I don't want to be the one to burst your bubble here, but there are already thousands of these projects, in which somebody has an idea and needs a team but can't offer anything to the project. For your project to stand out and appeal to people who may be in a position to help you, you need to have something to contribute.
I'm not trying to discourage you from your ideas (nobody here is), for you to be successful in the long run you need to start with a much smaller project. Even if it is something completely unrelated, you will undoubtedly gain more knowledge which will help to in your long term goal of creating an RPG, and will increase your chances of success. If you are stuck for ideas, perhaps making a clone of a simple arcade game may be a nice way to learn, even if your game isn't released you will still learn plenty.
#162427 - sgeos - Tue Sep 02, 2008 8:30 pm
| MotK wrote: |
| Okay....maybe MY job should just be providing the idea vision and gather other interested parties to do much of the design and coding work then, huh? |
Working as part of a team is probably a good idea. If you take the 10K+ hours needed to put an RPG together, and you split them between a programmer, scripter (event/battle), writer (story), data planner (monsters/items/etc) and a couple of artists (sprites/field/battle/UI) and level designers, you could probably get something done in a year if everyone can stay focused and work on the project full time. An army of one doesn't have a fighting chance.
There is plenty to do on an RPG, but there is not a spot for "ideas guy". The closest things are story/scenario writers, stage designers and field event scripters. If you are willing to tackle at least one of those things while providing overall guadance and you can find people to help with all the other work, you have a chance of pulling off an RPG. (There is a reason these things don't just get done on a whim.)
But, I suggest simpler projects first or an RPG for a simpler platform to develop for- like the PC. You probably want to do both before attempting a full scale RPG on something like the GBA.
As for an RPG tech demo... people have made them, but I doubt the demos are easily scalable.
-Brendan
#162429 - MotK - Tue Sep 02, 2008 9:08 pm
I see what you mean...I suppose by "ideas" guy I meant story writer foremost because I am already a writer by hobby. I have some art experience as well, but where I am really lacking is in the very technical end of things.
Btw, getting back to the original question of C or C++, might I add a 3rd option? What about a high level language like Python or Lua (specifically DSLua) to help me get started? What would be the downsides there? Or would speed be the main drawback?
#162434 - Miked0801 - Tue Sep 02, 2008 10:36 pm
Non-compiled lanugauges will not do what you need them to do at the speed needed.
C or C++ are pretty much the defacto choices for good reason: they both allow low level access to the hardware needed for GBA/DS work while giving you high level concepts to speed up development.
#162437 - keldon - Tue Sep 02, 2008 11:30 pm
Don't be scared off by the information given here. There is a whole plethora of expertise and understanding involved in a game of such complexity; but by taking people's advice here you will undoubtly reach a formidable position in due time.
At first you see a myriad of puzzles and obstacles that seem to make this task appear impossible. And, not only does the journey seem to be a challenging feat of great magnitudes, but every person seems to be leading you on a different paths to get there (C, C++, Scripting, GBA, PC, algorithms, organisation).
Each of these disciplines accumulate to a point where you think in terms of C, C++, Scripting, GBA, PC algorithms and organisation at the same time as you gain 'sport' in each of the practices. You will notice that pong was suggested; that is because it has much less requirements to pull off, and allows you to gain 'sport' in a few areas, after which you can use that knowledge to tackle the next obstacle (armed with your knowledge of pong). See How do I make games? A Path to Game Development" by Geoff Howland for more info on a decent order of games to tackle so that you can learn some of the basics.
#162444 - MotK - Wed Sep 03, 2008 1:07 am
Okay one last grasp at getting the answer I want (lol):
Does the fact that the game I am proposing is not going to rival FFX2 or
WOW make a difference at all? I'm imagining a 2D FF clone in the mold of Breath of Fire and Chrono Trigger. Any hope now?
#162447 - gauauu - Wed Sep 03, 2008 3:42 am
| MotK wrote: |
Okay one last grasp at getting the answer I want (lol):
Does the fact that the game I am proposing is not going to rival FFX2 or
WOW make a difference at all? I'm imagining a 2D FF clone in the mold of Breath of Fire and Chrono Trigger. Any hope now? |
Nope, sorry. The original Dragon Warrior, just maybe. Final Fantasy, Breath of Fire, Chrono Trigger...forget it.
#162459 - sgeos - Wed Sep 03, 2008 2:08 pm
| Miked0801 wrote: |
| Non-compiled lanugauges will not do what you need them to do at the speed needed. |
On the GBA, that is. You could use python to make an RPG targeted at the PC.
| keldon wrote: |
| C, C++, Scripting, GBA, PC, algorithms, organisation |
The thing is, you basically need all of them in some form or another.
| MotK wrote: |
| I'm imagining a 2D FF clone in the mold of Breath of Fire and Chrono Trigger. Any hope now? |
The above information is for a 2D FF clone. Say 10 qualified people for 18 months if you want a full scale clone.
| MotK wrote: |
Does the fact that the game I am proposing is not going to rival FFX2 or
WOW make a difference at all? |
Something on the level of FFX2 or WOW will take a silly amount of people. Say, a hundred people if not many more than that, although frankly I don't know what the technology curve has done to team sizes for large scale projects.
-Brendan
#162467 - Miked0801 - Wed Sep 03, 2008 5:53 pm
Let's think for a moment about CronoTrigger. Wonderful game.
What are the main systems in this game and what do you need to know to get them to happen?
1. Boot up the GBA and get the hardware to display a splash screen. This will take you quite a bit of time in and of itself due to the steep learning curve that is GBA.
2. Front-end menus. We need load/save functionality from here to get in and out of a game. Not the most complex code, but challenging to get it to fit in memory contraints. Pong doesn't need this.
3. In-Game. A dynamicly scrolling 2D background with beautifully drawn (not rendered) maps. How many maps? The large surface map, a dozen towns, a few castles, a handful of dungeons, a dozen or so outside areas, shops and houses... perhaps around 100 maps or so. Oh, they must fit with 4-bit chars in order to display them well. Oh, and pass-behind adds another bitmap or 2 per map. Then you get to tag all those maps with collision information. Then, you get to go through and tag all those maps with 'event information' so that you know when and how a special event happens.
We need a scripting system in place to interperate where all the NPCs can wander and what they say and how they interact and how they walk in formation and when to spawn canned combat and... Needless to say, this is over 1/2 the work in an RPG.
Then you get to figure out in-game sprite rendering. There are 10 or so characters that need full walk/run cycles for 4 directions along with all their 'emote' animations. Then you need another 2-3 dozen NPC with walk and stand animation. Then all you special effects for fireballs and fireworks and the like. By the way, all animations need to be accessable via the scripting system so no shortcuts here. Guess what? Fitting all those animations into VRAM is impossible without a sophisticated dynamic char and palette loading system in place. That isn't easy code to write either.
Then we need in-game menus. Gotta be able to equip all the goodies we find and trade them between characters and adjust stats or else there is no game. That means 200 or so items to be drawn and stats to be tracked along with an experience advancement system that makes sense. More tables of boredom here. Plus, all in-game character states have to be saved and paused while playing in menus - not an easy task with the limited amount of memory you havae to work with.
Then, a combat system. Alas, ChronoTrigger has a very complex combat system. No statically loading canned monster animations and having all of system memory available for use. Nope, the game engine is left resident and the menus are overlayed on top of everything along with all the spells and everything else. This is extremely difficult to code which is why the RPGs I've worked on never attempted it. Oh and more assets needed. We need all the spell effects, all the monster animations, all the cursors and text, etc. Perhaps another 100-200 individual animations need to be created - each with at least 30-40 frames of animations.
Then we need a music/sfx system to sit on top of all of that and not hog away too much system resources while delivering mood. Good luck with that.
Then, you get to try to fit all that code and all those assets into a cartridge that will work on the GBA and spend months debugging everything so that all the various crashes go away.
And I've probably only mentioned half of the code systems and art that need to be created.
RPGs are out of scope for casual development.
But don't feel bad. RPGs are out of scope for most professional developement.
How about a nice game of Pong?
1. Systems:
1. Game bootup code.
2. BG BMP splash screen or leave black.
3. 2 Rectangle, sprite paddles with no animations.
4. 1 ball sprite (or bg)
5. Text rendering code for score.
6. Reading input from d-pad to move one (or both) paddles up and down.
7. Simple reflection physics and movement for the ball.
8. Capture mechanic (optional) for the ball
9. A simple, match Y position of ball AI for far paddle (optional)
10. A you win/lose screen and retry menu.
11. A 'PONG' SFX upon paddle or top/bottom wall reflection.
Not very exciting, but the code above gets you BG rendering, static Sprite Rendering, splash screen rendering, game bootup, collision detection, text rendering, sound systems, and AI systems all coded. You'll notice that everyone of those systems matches up to the RPG side (or any other game for that matter.) Plus, you'll be able to play your creation in 2-8 weeks - which is true satisfacation.
#162470 - tepples - Wed Sep 03, 2008 7:31 pm
| Miked0801 wrote: |
| Non-compiled lanugauges will not do what you need them to do at the speed needed. |
MECC's The Oregon Trail for Apple II Plus was written in interpreted Basic with some assembly language subroutines for graphics and the like. The closest GBA/DS equivalent would probably be interpreted Lua with some C subroutines for graphics and the like.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#162471 - silent_code - Wed Sep 03, 2008 7:40 pm
If that project means a lot to you, you will have to learn a lot first, doing some other projects, because you don't want to spoil that project for yourself. Believe me, I am carrying a project around with me for over ten years.
I have won some prices with one of my projects, I have done quite some programming (games related and unrelated) and software design during a big part of my life, I have studied computer science, I am working in the industry (finally) and still, I don't feel I am ready to start that project. It simply doesn't feel right, yet.
But nevertheless, everything I do is preparing me for this one thing, so I'll be able to do my best and not fail due to missing experience.
Does this apply to your project? Maybe just a little bit?
PS: You should probably talk to the Aguna programmer. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#162473 - Kyoufu Kawa - Wed Sep 03, 2008 7:57 pm
| Miked0801 wrote: |
| RPGs are out of scope for casual development. |
Great post, but what am I doing, then?
#162475 - gauauu - Wed Sep 03, 2008 8:10 pm
| silent_code wrote: |
| PS: You should probably talk to the Aguna programmer. :^) |
He has been ;-) ...... and my experience with Anguna is where I got my previous estimates that Dragon Warrior just might be possible for a single programmer with a few years of hobby time to spare. (Where SNES-style RPG's aren't going to happen)
So yeah, Anguna for an example:
1. Previous Experience: I'd been writing software, and misc small cheesy games for 15 years before starting. I hadn't done a ton of C before GBA development, but a little. So I already knew how basic game programming logic should work.
2. I spent a couple weeks/months (can't remember) working on a cheesy dots game to learn GBA programming. (like we're recommending you should do!)
3. Spent 3 or 4 months of hobby time making an extremely simple basic game engine for Anguna. No special items, no menus, etc. Hand drew a few sprites, used a few random graphics from the internet.
4. Posted a cheesy demo, attracted an artist.
5. Spent another 6 months reworking my engine to use the fancier assets the artist created, writing and modifying build scripts to deal with my graphic, sound, and level resources, adding support for special items, etc.
6. Spent another 2 years designing maps, the extra fancy stuff that the maps need (switches, dark areas, triggers that occur when you do things, etc), writing enemy "AI" routines (AI in quotes because my enemies are simplistic and stupid), creating menus, etc
7. Another month of testing and debugging.
Total time: 3 years. And that was with plenty of previous programming experience, and a cheesy GBA game under my belt.
#162483 - Miked0801 - Wed Sep 03, 2008 10:11 pm
| Kyoufu Kawa wrote: |
| Miked0801 wrote: | | RPGs are out of scope for casual development. |
Great post, but what am I doing, then? |
Wasting time? (ducks) ;)
#162484 - Kyoufu Kawa - Wed Sep 03, 2008 10:12 pm
| Miked0801 wrote: |
| Wasting time? (ducks) ;) |
What, you don't like Pok?mon? That's coo'.
#162487 - Miked0801 - Wed Sep 03, 2008 10:38 pm
I have a Pikachu stuffed animal in my office on a noose hanging from the top of the blinds.
:)
#162488 - Kyoufu Kawa - Wed Sep 03, 2008 10:42 pm
That's.... not so coo'. Mine just sits there on my DS game stack.
#162506 - Matthias - Thu Sep 04, 2008 2:43 am
| MotK wrote: |
I understand the suggestions regarding trying out smaller games. That seems to be the consensus wherever I go and whatever book I read. Interestingly, I am so bereft of original ideas that I have no idea what kind of puzzle game to make. I've tried to inspire myself so many times to take up programming as a hobby, with the sole intent on making the kind of games no one else is making. (By this I mean an RPG that is NOT based on some sort of Tolkien universe - or Pokemon which I just can't get emotionally involved enough for.)
Since the RPG is the end result I'm looking for, would perhaps studying an open-source or homebrew RPG already in existence be a good starting point as well? Especially since all the game design books I have read seem to be so abstract, I'm lost how to apply it toward the genre I'm interested in, or more to the point, I don't know how to put it all together!
To be totally honest, I understand that undertaking an epic 40-hour RPG like FFVII is prohibitively restrictive given my time constraints and level of knowledge. I suppose if I can just accomplish enough of a tech demo that shows off my idea well enough to peak the interest of a publisher (specifically Cheyenne Mountain Entertainment, the company with the property rights to the Stargate franchise). I'm only interested in designing a few levels well that will give everyone a glimpse of the final project - whether that ever happens or not.
I'm sure you can now see better the fork in the road I am up against! |
Believe me. I'm in a very similar situation as you are. Any inspired gamer always has a great concept for the perfect game they want to create. Heck I'm dying to create a killer RPG for the GBA/NDS platforms. Unfortunately you and I can't just jump into it, especially if you're lacking in programming knowledge in the first place. I haven't started game development from scratch yet AND I'm lacking knowledge in general programming just like you, so we're the new people in town. This gives more reason that you should be aware of so many things. Even if you did know general programming, putting it into game design would be an entirely different journey. You need to think of how to program artificial intelligence, how to setup puzzles, how to generate physics, how to save and load data, create graphics, create music, create sound effects, control the camera in a way that doesn't obstruct with game play, understand the limitations of the platform you're in, and so many more aspects I can't even think of at the moment because I'm a newbie, just like you! The fact all of the game design books are so "vague" is because programming and game development is somewhat like an artist with an open canvas. Maybe the idea and vision is vivid in the mind, but once it comes down to the brush and paper there's just problems generating your vision into a reality. The thought and method is just so abstract! There are so many ways to do something whether some be better and some be worse. Sometimes artists, especially the new ones, can stare blankly at this white canvas, wondering where to start or how to do things correctly and efficiently. That's where your basics and fundamentals come in and this is why you start things off small. Once you build a concrete knowledge by starting small and once you start your first, new, "real" project, you utilize these concepts to form your own for the game. Eventually your own formed concepts and fundamental concepts that you learned form your vision. You can also think of it as math. If you don't know any math, you don't jump into Calculus on learning day 1. You start with the basics, addition and subtraction. Soon you work your way to multiplication and division. As you ascend to higher levels of math, you still constantly use the basic concepts (addition, subtraction, multiplication, division) together while learning and possibly creating new methods to solving problems. When it all comes to the bottom of it in almost anything, not just programming and game development, it's all about the understanding of the basic foundation of what you're working with.
Truthfully I'm just a kid. I'm not going to deny I'm only 16 years old. But I want to start somewhere. All of us at one point want to just dive right in, but we all have to roll our eyes as the stupid life guard blubbers out the (what we believe is) garbage and "irrelevant" guidelines. Yes you could not take my word seriously just because of my age, but if it's one thing you should take from this, it's to start small. Even once you see the reality of your vision and you see it's an obstacle that seems too great for you, just take a few steps back to look at the huge wall and slowly climb your way up, rock by rock. Understand that games that seem simple like Breath of Fire, old Final Fantasy games, or even something like Pacman are MUCH more complicated than they appear. But never give up, anyone can do it with hard work and patience.
#162511 - gauauu - Thu Sep 04, 2008 3:30 am
Well said Matthias. You've got wisdom beyond the average 16 year old ;-)
#162526 - keldon - Thu Sep 04, 2008 11:26 am
| gauauu wrote: |
| Well said Matthias. You've got wisdom beyond the average 16 year old ;-) |
Yeah; he explained it extremely well!
#162542 - silent_code - Thu Sep 04, 2008 7:41 pm
@Matthias: Beautiful post! :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#162564 - Miked0801 - Fri Sep 05, 2008 2:22 am
Love the math metaphor. I'll steal that for future use :)
#162822 - MotK - Sat Sep 13, 2008 4:58 pm
So I'm sure I'm not the only one here who has ever felt stupid for even dreaming of something so big!
One more thing: Given the apparent limitations of the GBA, might it be a good idea to focus my efforts on applying all of your advice to DS development instead? And getting back to the OP, should I then focus my efforts on C or C++?
#162824 - silent_code - Sat Sep 13, 2008 5:54 pm
Whatever you feel more comfortable with.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#162840 - sgeos - Sat Sep 13, 2008 11:31 pm
| MotK wrote: |
| So I'm sure I'm not the only one here who has ever felt stupid for even dreaming of something so big! |
There is nothing wrong with dreaming big.
| MotK wrote: |
| One more thing: Given the apparent limitations of the GBA, might it be a good idea to focus my efforts on applying all of your advice to DS development instead? And getting back to the OP, should I then focus my efforts on C or C++? |
It depends on what you want to do.
A) If you want to make a game for the GBA, make a simple game for the GBA. It does not matter what you make it in, you could use one of the BASIC distributions if you feel like it.
B) If you want to make a game for the DS, make a simple game for the DS. More or less the same as the above.
C) If you want to be a professional handheld programmer, learn C++ and make a simple game for the DS. When you are done, keep making things for the DS in C++.
D) If you want to make an RPG, get a copy of RPG Maker (XP or VX) and make an RPG. Start small. There are RPG Maker forums out there.
E) If you want to write a scenario, write a scenario.
F) If you really want to do something else altogether, figure out what it is and work on it instead.
#162937 - MotK - Tue Sep 16, 2008 6:47 pm
| sgeos wrote: |
E) If you want to write a scenario, write a scenario.
F) If you really want to do something else altogether, figure out what it is and work on it instead. |
What do you mean by scenario?
#162938 - Kyoufu Kawa - Tue Sep 16, 2008 7:36 pm
The script, I guess.
#162949 - MotK - Tue Sep 16, 2008 11:22 pm
I see. Yeah I was so excited about my idea. I was sorting out in my head all the characters and villains and storylines from the show I wanted to inject into the game. I was even thinking about maps for all the Stargate worlds I wanted to visit.
Needless to say that that's as far as I've gone. This isn't to put blame on anyone here of course but the reason I've grown despondent is because of all the naysayers here. I know they are the voice of experience and everyone means well; I'm glad to know there's a community of people out there that will give it to me straight.
Nevertheless, I feel like I've been shot down in a big way and I'm mad and discouraged.
Just another quick point, I've already followed a tutorial on building a simple game of Pong. It looks okay right now, but I have an idea that I'm hoping no one has done before. What about a Pong clone where the player controls both paddles? And the longer he plays, the faster the ball gets or the more balls get added to the mix. Or maybe the longer he plays, the smaller the paddles get? In other words, the game never ends. It's just a mad dash to the highest score! (I'm thinking of porting this over to the DS using PALib btw...) Would that be out of my reach?
#162953 - elhobbs - Wed Sep 17, 2008 2:17 am
| MotK wrote: |
I see. Yeah I was so excited about my idea. I was sorting out in my head all the characters and villains and storylines from the show I wanted to inject into the game. I was even thinking about maps for all the Stargate worlds I wanted to visit.
Needless to say that that's as far as I've gone. This isn't to put blame on anyone here of course but the reason I've grown despondent is because of all the naysayers here. I know they are the voice of experience and everyone means well; I'm glad to know there's a community of people out there that will give it to me straight.
Nevertheless, I feel like I've been shot down in a big way and I'm mad and discouraged.
Just another quick point, I've already followed a tutorial on building a simple game of Pong. It looks okay right now, but I have an idea that I'm hoping no one has done before. What about a Pong clone where the player controls both paddles? And the longer he plays, the faster the ball gets or the more balls get added to the mix. Or maybe the longer he plays, the smaller the paddles get? In other words, the game never ends. It's just a mad dash to the highest score! (I'm thinking of porting this over to the DS using PALib btw...) Would that be out of my reach? |
stop asking if something is possible. someone will always tell you it is too hard because you are asking the question. just give it a try then come back when you have a specific problem.
#162954 - sgeos - Wed Sep 17, 2008 2:55 am
| MotK wrote: |
| What do you mean by scenario? |
Designing the world, setting, plot, key events, characters (PC and NPC), character dialogue (PC and NPC), and anything else the game (or book or whatever) needs. Getting all of this straightened out and in a format that other people can understand is a big deal and it takes a fair amount of time. Often, the people who are good at the technical side of games are bad at (or uninterested in) the content creation. If you really want to be designing a game instead of putting one together, do that instead.
| MotK wrote: |
| I see. Yeah I was so excited about my idea. I was sorting out in my head all the characters and villains and storylines from the show I wanted to inject into the game. I was even thinking about maps for all the Stargate worlds I wanted to visit. |
And that is a good start. Again, if that is what you really want to be working on, work on it and worry about the rest later. There is more to making games than programming them.
| MotK wrote: |
| Needless to say that that's as far as I've gone. |
Most projects stop at the initial concept phase for one reason or another.
| MotK wrote: |
| This isn't to put blame on anyone here of course but the reason I've grown despondent is because of all the naysayers here. I know they are the voice of experience and everyone means well; I'm glad to know there's a community of people out there that will give it to me straight. |
Your project can be completed, but it would be very hard to go at it alone. If you do not intend to be a driving force behind your project it will fail. The biggest part of being a driving force is keeping at it when other people are not helping, do not care and are not paying attention. The point is that big projects do not magically materialize, they are a lot of work, and someone needs to do that work. How much of 10,000 hours are you willing to put toward a game that will not be as fancy as Chrono Trigger? (Something as fancy or fancier will require more time.)
Having said that, completing small projects before working on large ones is a good idea.
| MotK wrote: |
| Just another quick point, I've already followed a tutorial on building a simple game of Pong. It looks okay right now, |
Everyone needs to start small.
| MotK wrote: |
| but I have an idea that I'm hoping no one has done before. What about a Pong clone where the player controls both paddles? And the longer he plays, the faster the ball gets or the more balls get added to the mix. Or maybe the longer he plays, the smaller the paddles get? In other words, the game never ends. It's just a mad dash to the highest score! (I'm thinking of porting this over to the DS using PALib btw...) Would that be out of my reach? |
Barring premature death, no, of course not. Given enough time and effort you will be able to complete anything. How much time do you want to spend on it? You could, in theory, keep building upon pong for the rest of your life. My recommendation is, keep working on it until you get bored with it and then move onto something else, finished or not. Chances are, it will feel unfinished due to the laws of feature creep, but that is OK.
#162968 - bean_xp - Wed Sep 17, 2008 3:29 pm
| MotK wrote: |
Nevertheless, I feel like I've been shot down in a big way and I'm mad and discouraged.
Just another quick point, I've already followed a tutorial on building a simple game of Pong. It looks okay right now, but I have an idea that I'm hoping no one has done before. What about a Pong clone where the player controls both paddles? And the longer he plays, the faster the ball gets or the more balls get added to the mix. Or maybe the longer he plays, the smaller the paddles get? In other words, the game never ends. It's just a mad dash to the highest score! (I'm thinking of porting this over to the DS using PALib btw...) Would that be out of my reach? |
Nobody is trying to discourage you, we are trying to show you an easier path to your goal, it's better you try things out on smaller projects before diving into something bigger.
I think taking your pong game to that level would be a great learning experience for you, just stick at it, keep experimenting with what you already know and see what you come up with, don't be afraid of trying something or having to look something up or ask about something. As long as you understand the code you are following in the tutorial this should not be a problem, although even if you don't it will help you fammiliarise yourself with it. As for porting to DS it is definately something you can learn, but again it takes time, you may want to experiment with the DS a little before diving into porting the pong game over.
#163061 - sajiimori - Sat Sep 20, 2008 11:12 pm
MotK,
It is nobody else's responsibility to motivate you. Try doing some work instead of fishing for reassurance.