• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

[Discussion] Software Development (Games)

Status
Not open for further replies.
The purpose of this thread is to discuss a few things about game development.

A lot of you are probably inspired to make games and have the sufficient skills to do so.

Do not make a game without making a game engine.

An ideal software developer writes code to solve problems and reuses that code.
This is why writing a game engine before writing a game is important.
If you create an excellent dynamically linked library and continue to develop it, you can easily make /many/ games.

Your game engine will develop over time allowing you to make better games as time passes in less time than it would take you if you were to write all games from scratch with their own engines.

You would also have more control over the game because you know how the game engine works from the inside out.

I'm not going to develop games before I finish writing a decent engine.

Another option is to use an already finished engine like CryEngine or Unity, or maybe even the UDK. Torque3D is another example of a good engine.

What I don't like about this is the fact that I wouldn't have as much control over the game as I would if I were to develop my own engine to suit my needs.

I was once told by Nestharus that someone who wants to make games should use finished game engines rather than writing his own, because people who writes game engines are going to end up writing game engines and not games.
I sort of agreed with him, contradicting what I said above, but I'm not the kind of person who would use other people's code, I like to write my own, and a lot of people are like that too. (Well, only in C/C++ anyway ;D)

Discuss. ^_^
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,255
The biggest problem with making anything is to define what you want it to do.

Before sitting down to write code for a game engine is is very important you think about what game you want the engine for. Will it use 2D or 3D graphics? Will it be a platformer or a RTS? Multiplayer or singleplayer? Small decisions early on have huge effects on the code you produce. Consider taking notes on decisions and sticking to them so that your opinion does not drift while you program.

Making incorrect decisions early on can waste days of coding or more. If you add a feature that is not required all the coding done for it is equivalently wasted. If you require a new feature be added late in development it can result in code having to be rewritten (previous code wasted). Deciding to change game type like from RTS to platformer late in development is an example of very bad decission making as a lot of code will need changing, adding and removing.

In addition to the functional requirements of the game engine there are a large number of non-functional requirements to consider. What platform is the engine going to run on? How portable must it be? What hardware range should it target? What language should be used? What compiler of a language should be used? How will it be deployed? Engines made targeting Windows and Xbox platforms should use DirectX for graphics. Engines made targeting other platforms should use OpenGL for graphics. An engine for both Windows and Linux might have support for both with a OpenGL linked library for both platforms and a DirectX linked library for Windows.

When the coding does start effort should be taken to keep cohesion high and coupling low. Well designed interfaces can be used to handle coupling in a component like way abstracting the implementation away from calling code. Failure to keep coupling under control can make changing system dependencies nearly impossible without rewriting all calling code. Breaking down problems into individual tasks and writing a standalone system to solve that task keeps cohesion high. If cohesion is not kept high it might become impossible to maintain a program as there is no quick way to find the required code for a task and modification exposes unrelated code to changes (requiring all parts be retested for faults).
 
Level 18
Joined
Mar 7, 2005
Messages
824
You guys must have time like hell an be a bit crazy.. I wouldn't suggest any1 to create their own game-engine.

It's always easier to make games with existing engines. The UDK for example was developed by MANY MANY people over many years (Unreal-Engine 4 started in 2003, and it's still under development. and there's surely more than just 1 guy that works on it :p ), till they could release the first versions of it, and it's also developing further at the moment, so this progress in creating a game engine is endless, and if you do this alone or with just a few people this will take too long as it has any profits for you and your game you want to create. Also you'll need professional knowledge about programming and informatik to do such a task..

Simply use one of the many many cool game-enginges out there. It's easier and you can make big steps and watch you game grow and work within some days (depends on skill an engine)..
 
Level 35
Joined
Oct 9, 2006
Messages
6,394
I think that game development is 20% programming and 80% art.

That really depends on the game. And programming can be very very time consuming easily equaling the art time. I would however argue that in some cases the art is harder to do, due to the inspiration required to do it.

But in regard to the topic of game engines; In our company we opted to use unity's game engine for 2 simple reasons: We're an indie firm and not really gifted with large amounts of money and secondly we wanted to save the time so the game could be released faster. That said, using unity is also causing some annoying problems, mostly in regards to 3D models since unity has some odd bugs with models from time to time.

Hence we reached the discussion to make it in unity and then if successful consider if we needed to make our own engine (but that require us to make quite a bit of money on our game, since otherwise we won't be able to effort the time to work on something that isn't going to grand us money when done (assuming we don't license it out/ sell it :grin:)).

Also a good idea with this forum.
 
Level 9
Joined
Dec 21, 2011
Messages
332
That really depends on the game. And programming can be very very time consuming easily equaling the art time. I would however argue that in some cases the art is harder to do, due to the inspiration required to do it.

True that. But sometimes a single letter ( or phrase ) can turn into a massive custom game engine breakdown. Which, is equal to finding inspiration (or Waldo).
 
Level 18
Joined
Mar 7, 2005
Messages
824
At least you can fasten and improve this by using unity, as you save the percent and licence pricings. You can use tricks to illusionate some leaking features, like shadows.. and some games even don't need such things..

So easiest way would be. Use unity indie version (no costs at all) and create a simple (takes not much time) game that has some rating stuff. Any score or something like that might work, so people can compare themselves. You will always have people playing this game like shit just to get 1 point more than others. With that you just implement some kind of item shop that can give u some bonuses in reaching that score faster or something like that (nothing unfair, like pay2win) and you'll get fast some money.. spent that on whatever you want.. a real engine (like UDK or CryEngine) on which you can create HD Games with superb graphics. or create your own engine with a team of fellowers. You'll have the time and money due to the facebook game :D

Those people are just crazy you'll always find enough people that pay some money for senseless InGame Items ^^
 
Level 35
Joined
Oct 9, 2006
Messages
6,394
This is very simple:
1. Buy a licence for an engine or give a percent of your profit to the one who made it
2. Create the game
3. Sell it
4. Release updates and bugfixes
5. Release an "enchanced version" with more content
6. ???
7. Profit
8. Pay a good team to work on a quality engine
9. Finish the game.
10. ???
11. Profit!

Yep pretty much the idea we have :smile: And with unity its even easier.
 
If you make your own game engine, you don't have to pay the owner of a popular game engine when you deploy your game(s) ;D

Many game engines are free for commercial use up to a certain sales level. So you pay, say 20% of profits to the owner of the game engine, but only if your game sells for more than 10 000$. Up to that it is free.

Like someone said, it depends a lot on the game - if you want to make a 2d tile based game like terraria or survivors of ragnarök, then sure, it is a realistic task for one or two amateur developers (with lots of patience and spare time) to overcome. If you want to make a 3d game however, making a game engine is a much greater task than you could imagine. Even if you should use public libraries for all the math operations, such as vector, matrix and quaternion functions, you still need to write your own animation library (perferably with IK support, and using the Spherical Linear Interpolation method you just wrote for your quaternion class) and your own shader, not to mention physics and collision (most sane people don't do rigid body physics themselves, but instead go for something like Havok or Bullet, which are both free). Even XNA framework doesn't include initial support for texture blending or texture transparency, and by default it doesn't handle models with more than one geoset very well, this is all stuff you have to fix yourself. Using an existing game engine lets you focus on just programming the game mechanics, which is usually quite a handful on its own!
 
Level 12
Joined
Feb 23, 2008
Messages
587
Game Engine.

I think it highly depends on time and the magnitude of your project.
I personally disagree with this statement

Do not make a game without making a game engine.
I don't even think you need a game engine in mind.

My first major project, and on going project i first built using a game engine in c#.
I felt later on that I really want to connection from my back end and front end.

So I made my back end more generic that it could be used by "Any" Front end.
Its worked out great for me. I have been able to get my project running in Console, WPF, XNA(Windows, and slierlight xna for phone), Standard Sliverlight, Metro (Moho XNA) and have it ready to port to Unity when I ready to the make the move.

The back end is the same, and the front ends are simmalier but work differently with saving and loading files, and ui, and some of the models are higher polys.

For the most part your going to get plenty of power from game engines, and flexablity. If you really know what your doing, and have enough time making a game engine may be more then worth it. For me that's not the case. I am willing to lose flexablity and speed (assuming i can make a rocking game engine better then those available or works better for my project) to spend more time polishing my project.

Last note: I am using C#, not c++, Easyer to code in general, but you lose some flexalbity , I am using xna, designed to be made for small groups devs, or single person.
I am not using pro tools. Partly due my computer science skills, and that i dont want to focus on those things, i want to focus on a game that works good enough. :)
 
Status
Not open for further replies.
Top