• Advertisement
Sign in to follow this  

Game Engines + Easy-To-Make-GUI

This topic is 3030 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello GameDev.net, This is my first posting on the forums. I'm not sure if this question belongs here, but I'll post it here anyway. Please redirect me if I'm mistaken. /* * Question begins here. */ Rather than starting my game programming by making a stand-alone game, I want to take an indirect approach. I want to make a program that makes it easy to build games. To put it vaguely, it'll be an interface that will allow users to put their own "stuff" in and make their own game. If you've heard of the RPG Maker series, you know what I'm talking about. By (counterintuitively) putting alot of sweat and blood into this, I hope to make my own game projects much easier. Of course, a game needs engines (like a graphics engine and a physics engine). I also might plug-and-play some of these (perhaps by substituting one physics engine for another). However, I don't know the first thing about engines. What are some of the essential engines a game needs, and what are some of the basic operations they should support? /* * Question ends here. */ Thanks for reading! - KrazyKaiju P.S. I know I said "a program that makes it easy to build games", but that sounds really ambitious. Is it even possible to have such a program that could help you construct an FPS AND a turn-based RPG? I might just concentrate on one genre, like fighting or platforming. P.P.S. Sounds ambitious for a first try, but I've been through about 2.5 years of Comp Sci at college. This'll be challenging, but not overwhelming.

Share this post

Link to post
Share on other sites
What do you mean my "program making it easy to create games"?

You can create either:
1. An interpreter or a compiler that uses your own, invented, programming language. However, your language and compiler will necessarily be worse than those already existing (like Visual Studio). So, nobody will use it.

2. Make a tool like FPS Creator, where user inputs maps, units, some variables, choses some options relating to the gameplay and pushes "Make a game". If you try this way, then the more space you want to give to the user, the more possibilites you want to give him, the more confused he will be and the more will the interface be difficult. So, if you make a tool that allows creation of FPS and TurnBasedRPG or even RTS, lots and lots of effort would be needed on the part of the player.
Perhaps you can create a prototype game, a platformer, for example and then make a Platformer-Creator on top of it. The user will input sprites for hero, monsters, platforms, will create the maps, the levels, will set what happens when hero touches monsters, when hero touches bonuses, will input the storyline texts and so on...
That kind of Game-Creator could be used by those who just want to make a game because it makes the game creating process really simple. (At the cost of limiting severely the possibilities)

I don't want to start a flamewar with this post but C#/XNA with Visual Studio are the most simple solutions. C# is the language and XNA is the framework and the engine you can make yourself. (For platformer, the engine is really very simple, and XNA handles the graphics)

Good luck with your project.

Share this post

Link to post
Share on other sites
This is a popular link from this site and I largely agree with it.

Most importantly though is this question: What are you trying to do?

Are you doing this to practice programming? Because you think the project sounds fun? Because you want to write games? Because you really really want such a tool? Because you want to sell the made tool as a business? You want some experience on a real project?

Answer that first, or you won't be getting very far, IMO.

Also, look at the software Game Maker.

Share this post

Link to post
Share on other sites
An engine/game is composed of a lot of different parts potentially. This can vary depending on how many things you want/need to support.

* Denotes Optional
- Denotes an example subpoint

Level Editor/Plugin
Model exporter and/or importer
Various editors/xml editor.

Game Layer:
Game scripts/code modules
AI behavior framework
Path Finding

Engine functionality:
-Graphics Card
-Vert Streams
-Command Buffers*
-Dynamic stream writers(For dynamic things like particle sytems)
-Post processing (if shader support is present)
Scripting System*
Animation system
-animation trees
-attachment points
Model format/framework
-Vertex formats
-Random things artists want supported
Shader support*
Resource system*

As you already realize there are different libraries already out there to fill some/all of these roles. I am also certain I missed some or included some that you may not need. There are so many moving parts it can be a lot to keep track of.

Share this post

Link to post
Share on other sites
The idea of making a library or engine and then building the game may seem good on the face of it. However, if you attempt to do so, you'll find out that its hard to build such a library or engine until you understand what it takes to make games, what parts are good candidates for abstraction, and what kinds of libraries can make the creation process easier. Those points aren't something you can look up. You have to learn all of this by actually making games.

That's why the vets in the forums say: "Make games, not engines." After you make a game, you can refactor the re-usable parts into a library, and continue to add on to it as you make more games.

Chances are, if you try to sit down and plan out some sort of toolchain and architecture, and then build the game, its going to end up not being useful to the games you actually make.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement