Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Nov 2006
Offline Last Active Mar 16 2014 01:05 AM

#4977052 What exactly is a Game Engine?

Posted by nfries88 on 05 September 2012 - 08:55 PM

A game engine is, in general terms, the reusable portion of a game. For example, this would be the code for rendering a model, playing sound, for physics interactions, etc. Some of them are loose-knit functions that people have just put together over the years, others are designed from the beginning.

If you want fast results, then a game engine is for you. If you want to learn and learn every single piece of programming a game, then they are probably not.

#4975559 RPG Inventory HUD

Posted by nfries88 on 01 September 2012 - 03:55 PM

rather than use a flat array of inventory tiles, use a linked-list of items. Since the inventory will presumably be small like in Diablo (fitting maybe 50 small items, max); iteration will not be a bottleneck. This not only probably saves on memory usage, but will prevent from having to update each inventory tile occupied by an item when adding or removing it.

From there, items in the inventory will need a position and size, measured in inventory tiles. This will allow you to detect whether or not you can add the item to the inventory.

class InventoryItem

   Sprite* m_visual;
   int m_x;
   int m_y;
   int m_w;
   int m_h;
std::vector<InventoryItem*> inventory;
bool AddItemToInventory(Item* item, int x, int y)
	InventoryItem* iitem = new InventoryItem(item, x, y);
	for(std::vector<InventoryItem*>::iterator it = inventory.begin(); it != inventory.end(); ++it)
	   if(Rects_Intersect(make_rect((*it), make_rect(item))
		  return false;
	return true;

#4973753 Blender and Python: Objective Opinions Sought

Posted by nfries88 on 27 August 2012 - 05:53 AM

1) a. Is Python a good or great language for game performance, specifically frames per second and smoothness in 3D scenes? The reason I ask this is because Python appears to be a very adaptable language but I wonder if it could be "too good to be true" in the sense of maybe game performance might be the price to pay for all that language adaptability, especially the syntax expressiveness. I don't know but there seems to be some doubt out there about performance.
b. How does Python compare to C++ for game performance, all other things being about equal?

Depends. The worst answer in the world to give a newbie, but it's also almost always the right answer. Python gets very reasonable performance for a scripting language, but it is a scripting language. For a typical 2D game (such as a pac-man clone), it would perform very well. If you're hoping to make Crysis 3, you will most likely find Python insufficient. The issues with using scripting languages over C/C++ or even C#/VB.NET for game development is that you not only gain interpretor overhead, but also lose the ability to play directly with OS interfaces.

As Goran mentioned, on newer hardware, and written by a good programmer, the CPU (interpretor overhead) is not likely to become the bottleneck of any game, it will be GPU, but I feel the need to mention interpretor overhead anyway. I'm old-fashioned.

2) Is Python better for people of lesser experience to learn it compared to C++?

Yes, Python is simple to learn relative to C++ and even C#. Not only is it easier to learn, but you will get faster results when creating from (essentially) scratch, which is great for encouraging newbies (and why very few newbies stick with C++ after realizing such alternatives exist). I highly recommend using Python or a similar scripting language to familiarize yourself with programming, even if it winds up being insufficient for the purposes of making your game.

3) With all the flexibility of Python, what are it's strengths and weaknesses for games?

Easy to use
Easy to learn
Fast results
Many bindings available for open-source game development APIs
Reasonable performance
Boost.python provides excellent C++ bindings to python, making it easy to use for scripting events, should Python prove to not be performant enough to do all game functionality in.

Interpretor overhead
No direct access to OS and hardware features
Most game programming tutorials are still in C++, few serious game developers use Python

4) How do I deal with the issue of an IDE for Python? Is Blender going to be a dead end in one sense of needing an IDE eventually?

There is no IDE for Python -- well, okay, I'm sure somebody's made one by now. But there is no need for an IDE for Python. Python is a scripting language that does not need to be compiled or linked to be run (it is run by an interpretor), so the only use for an IDE in the case of Python would be syntax highlighting, in which case you should find Notepad++ quite suitable.

The unasked question: Is the Blender API good for making games?

Blender is a great tool for making 3D models, and it is awesome that they provide a method to easily see those models in action.
I do not think any serious game studio would use it for its entire game. But I'm sure there's someone who has disproved me.

Also, on your last post:
As a matter of conscience, I must get enough information in order avoid months or years of learning things which will never be needed again, so I am choosing my path carefully. I know what I want in a very general sense and I am looking for a system which will be a good match to my goals both short term and long term.

Whoa, bro. The only re-learning in game development is between various APIs (X11 vs Win32, OpenGL vs DirectX, etc); and even then, it's more like learning an alternative than it is re-learning; you don't want to dump the old knowledge, only gain the new.
All programming experience is a positive thing. Even if your software is a steaming pile of crap that doesn't run, crashes sporadically and frequently, and every now and then even leaves you with a BSoD, at least you have the experience of making that crap.
All programming experience improves you, as a programmer, as long as you actually learn from it. I look back at code I wrote in '06/'07 and laugh at my inexperience.
Learning Python is never a waste of time, and every bit of experience in Python will carry over to C++ (or whatever language you use next), even despite their vast differences. Painting may not be sculpting, but programming is programming, period.
Unless I'm missing something and there's some urgent reason why you must finish your game in the next couple years, like it's your dream and the doctor told you that you only have three years to live or something, take it slow and experiment. Nobody can tell you the best route to take, we're all still learning too.

Personal Recommendation:
Start with Python, use it to make a nice simple game like a pac-man clone. This will likely take you a few months. That should give you perspective enough to decide your next step. Ultimately, I would recommend C# and XNA -- XNA is a great API, C# is a great language, and the .NET framework is probably the greatest I've played around with. Unfortunately, XNA is not portable, and will only work on Windows and XBox360, and I found some requirements of using XNA (not the API itself) to be aggravating after knowing the unbounded freedom of developing games in C++. These requirements will certainly not bother someone who has never had that experience.

#4972976 Manage multiple resolutions

Posted by nfries88 on 24 August 2012 - 07:49 AM

Also, don't stretch your GUI -- it makes things ugly.
Draw GUI after you stretch the game (and obviously, no need to convert coordinates if it's in the GUI).

#4972963 Manage multiple resolutions

Posted by nfries88 on 24 August 2012 - 06:31 AM

You are using SDL's software rendering to draw (SDL_BlitSurface)?
In that case, just create a surface at the resolution the game is meant to be drawn at; blit to that, and stretch it to fit later. The alternative is to maintain a variable that is the ratio the player's resolution vs the expected (IE, if the player's resolution is 800x600, but the game is meant for 640x480, this variable will be 800/640 or 1.25), then multiply all rectangle's values by that variable (either pass it to each rendering function [ideal], store it in a global variable, or use a singleton), but this will likely require modifying a ton of code. Keep in mind that no matter what you do, in order to create useable mouse-input, you will need to convert real screen coordinates to expected screen coordinates (divide by the ratio mentioned above).

#4832150 Setup OpenGL like Direct2D

Posted by nfries88 on 07 July 2011 - 01:54 AM

glOrtho is what you're looking for.

It's really simple. glOrtho(0, screen_width, 0, screen_height, -1, 1); for the most basic setup.

You should really read the NEHE tutorials if you're learning to use OpenGL. They walk you through all this stuff. Link: http://nehe.gamedev.net/

#4829777 delete this thread please

Posted by nfries88 on 30 June 2011 - 03:46 PM

If nothing of the above works for me then I would have to build it, with something like Boost as you suggested, nfries88. How long would that take me, providing I can work lets say the average 40 hours a week in the project. 1 year? 5 years? 10 years? (I can't spend more time than that :)).

Depends on your own ability as a programmer, how quickly you can learn new APIs and solve problems, and the dependability of other developers you gather.

1 year is a fair estimate for a basic Minecraft-like MMO. Certainly less than 5 years.

#4829365 A Newbie, A Vision, No budget.

Posted by nfries88 on 29 June 2011 - 08:00 PM

Patience, my friend, patience. I spent several years learning, and I still haven't completed my dream project. Patience.

Learn programming. Learn to do your own art. Be active in online communities; especially ones that center around game development, programming, art, or game modding. Make contacts, gain respect, learn things related to game development. Look around for the numerous resources that occasionally get brought up -- sloperama.org is a big one here. You might need to buy a book or two later on; but not now. Eventually you'll need to get a little bit together so you can make your own company, or maybe you'll join another startup; but that won't be for quite some time yet.

Regardless, you're not where you need to be to make your vision into a game just yet, and nothing anyone on this forum would be willing to do for you will make your game without patience and hard work on your end.

Good luck to ya!

#4829360 Newbie looking for Help to get started

Posted by nfries88 on 29 June 2011 - 07:52 PM

I frequently use cplusplus.com's reference to supplement my own knowledge (using tons of different APIs, sometimes you forget the standard stuff; right?), but I find that the programming tutorials at cprogramming.com to be much more well-rounded and complete. But different minds learn different ways, and maybe cprogramming.com's tutorial structure will only serve to confuse you.

Overall, your approach is the proper one. I would keep going as you have been. If you ever get stuck somewhere, feel free to PM me here. I check the site a couple of times a day.(NOTE: That's an exclusive offer for the OP. Please don't harass me via PM, strangers! =[)

#4829354 delete this thread please

Posted by nfries88 on 29 June 2011 - 07:22 PM

Is there an engine in the market that would allow to do this? And that could render that amount of objects without suffering? And of course that doesn't cost houndreds of thousands of dollars (although it would be interesting to know also).

With no work at all? None exist.
You will need to do a large amount of programming/scripting regardless of how flexible or inflexible your world is. The only "game engine" that can simply be downloaded and function entirely on its own to be a complete game, is a complete game. Sorry.

Or maybe the most viable option would be to create the engine myself? I wouldn't need fancy state-of-the-art graphics, just a basic lighting and shadows. What i'm more worried about is performance.

Also, the idea i have in mind is an MMO not too centered in combat, rather a sandbox MMO where combat would be one option out of many. I would like to recreate a living world with a basic ecology and some other features not found in traditional comercial MMOs. For instance player freezing under extreme cold.

Here I can help you.

If you're a C++ programmer, Boost has a few excellent libraries that will help you on the server-side of things (in MMOs, you interact with other people via connecting to a server, in case you weren't aware). Boost.Thread (concurrency) and Boost.Asio (highly scalable network) are the most important of these, but there's also Boost.Filesystem (crawling your hard disk), Boost.Pool (for managing your own memory), and Boost.MSM (useful for any interact-able game objects; such as NPCs, players, and the blocks to an extent).

On the client side of things, there's a few different libraries you could use. Irrlicht, Ogre, SDL+OpenGL, ClanLib+OpenGL, some cheap proprietary engine; it's up to you.

I've done a ton of work with MMO servers, so I'm pretty familiar with those concepts. Boost will save you a crazy amount of dev time there, with little performance hit (in fact, Boost.asio will probably implement the network better than you would yourself -- it's a godsend for anyone wanting to write a scalable server).

#4829348 Need advice on where to go next

Posted by nfries88 on 29 June 2011 - 07:06 PM

You don't need a book to learn C++, especially if you've been using Python for three years. I do recommend that you pick up some books for specific subjects later on, but for familiarizing yourself with the language there is no need.

cprogramming.com has tutorials that provide an excellent introduction to C and C++ programming (note: C++ is a superset of C; most C code will compile with a C++ compiler and run, with only minor modifications (dealing with C++'s strict typesafety, for the most part)). I learned using these tutorials myself, although I now own a reasonable number of books about specific areas of programming.

If you've been fiddling with Python for a few years now, I'm sure you've realized that the most important part of learning to program is not in reading, but in practice. C and C++ are (comparatively) low-level languages with many useful tricks that you'll only learn how to properly use through practice and experience.

You can get a C++ compiler and IDE (integrated development environment, convenience tools for programmers pretty much) for free. Microsoft offers the newest version of Visual Studio Express, and in the open-source world I highly recommend Code::Blocks with MinGW (what I personally use).

As for what API to use, I recommend steering clear of system-level APIs for now. Not only are these significantly more complicated than higher-level APIs like Irrlicht or Ogre, but there's very little benefit to be gained from using them over the stated alternatives. Generally speaking, games only need the common feature subsets provided by the mentioned APIs (as well as many similar APIs). The open-source world contains several useful libraries that you can make use of to minimize your development time, especially if you are using C++.

C++ programming will be harder to get into than Python, but ultimately more rewarding.

PS: If you're interested in making games for XBLA as an indie developer, your best bet is actually C# and XNA Game Studio. The same is true with Windows Phone 7 games. For Android, Java is your best bet. For iPhone, you'll need Objective-C.

PSS: Unity is a very expensive investment if you want the full feature set, $1500 for Pro (PC) and another $1500 each for iOS Pro and Android Pro.

#4805650 C++, XNA, OpenGL, DirectX...

Posted by nfries88 on 02 May 2011 - 02:59 PM

You seem to be confused.

C++ and C# are programming languages. C++ is a low-level language with many high-level features, while C# is a very high-level language with a handful of fairly low-level features. C++ and C# have very similar syntax (they look alike), but migrating from Java to C# would probably be just as easy / easier than C++ or C#.

XNA, DirectX, and OpenGL are 3D graphics programming APIs (although DirectX actually contains sound and input APIs, and all of them can be used for 2D graphics as well).
OpenGL is available to almost every system ever known. DirectX is available only on Microsoft's platforms (Windows, Windows Mobile, Xbox, Xbox 360). OpenGL and DirectX are typically used in C and C++ code. XNA is an API created by Microsoft that wraps DirectX, and is usually used in C# code.

As for where to begin... It depends on what you want to do. Generally I'd start with 2D games. XNA actually makes it very easy to make 2D graphics. OpenGL doesn't make it very difficult either. Not sure about DirectX, but I do know that Windows 7 brought with it "Direct2D" as a new sub-API of DirectX. Don't stick around in 2D games too long or you get stuck! :P

#4805187 Having a program send input to another program

Posted by nfries88 on 01 May 2011 - 04:33 PM

You can have application A replace stdin with a pipe which application B uses for stdout. In this way, the output of application B acts as the input for application A.
You can also use a normal file for stdin, but this is more limiting.
EDIT: You can use a file for stdin, stdout, and stderr. stdin = fopen("myinput.txt", "rt"); is how that'd work.

I'm not sure if it would work the same on Windows, but it's worth investigation.

#4805060 Passing Integers through a server C# [help]

Posted by nfries88 on 01 May 2011 - 08:52 AM

It sounds like the problem is that your "Player 1" is still receiving that he has 100hp, or that your "Player 2" is still receiving that your "Player 1" has 100hp.

The solution is that you need to send your players a packet that says "Player 1 now has 80hp" or "Player 1 lost 20hp".

#4805047 GameState as a game's conciousness

Posted by nfries88 on 01 May 2011 - 08:12 AM

There is no need to provide additional encapsulation over a game state, and in fact doing so short-sightedly will likely cause need for changes down the road.

Beyond that, I agree with the ideas you have in a vague sense; but I think you're over-complicating your interface.

Here is what I usually do for my "GameMode" class (generally the same concept):

	@class GameMode
   		Encapsulates all game-implementation specific things, and allows for vast changes in
   		how the game might be played or how game logic might be performed between various
   		states, without requiring a bunch of conditionals etc.
class GameMode
   		@fn Update
           	  	Handles player input, game logic and physics, and prepares for the next frame.
   		@param elapsedtime
           	  	Time in milliseconds between this frame and the last frame.
   		@param next
         	    	Next gamemode to be run. "this" to continue with this mode, "NULL" to quit.
   		@return true if the caller is responsible for freeing the gamemode.
 	virtual bool Update(uint64_t elapsedtime, GameMode*& next) = 0;
   		@fn Draw
   				Does nothing but draw the game.
   		@param elapsedtime
   				Time in milliseconds between this frame and the last frame.
   		@param context
   				The rendering context for this game -- Direct3DDevice9, GL context, SDL_Renderer, w.e you're using here.
 	virtual void Draw(uint64_t elapsedtime, RenderContext& context) = 0;

class GM_TitleScreen: public GameMode
 	/* implement the gamemode here */

int main(int argc, char** argv)
	// get a rendering context
	RenderContext context = SetupRendering();
	// get the time of starting the game
	uint64_t lasttime = GetTimeMS();
	// create the title/loading screen
	GameMode* game = new GM_TitleScreen(...);
	// loop as long as we have a game state
   		// calculate elapsed time
   		uint64_t now = GetTimeMS();
   		uint64_t elapsedtime = now - lasttime;
   		GameMode* next = game;

   		// draw the game
   		game->Draw(elapsedtime, context);

   		// update the game
   		bool freegame = game->Update(elapsedtime, next);
   		// change gamemode as requested by Update
                	delete game;
   		game = next;

	return 0;

It's a method I learned a few years ago and it's so simple and flexible that I still use it today. You'll see it occasionally in open-source games in one form or another, too.