• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Gumgo

Memory allocation in practice

4 posts in this topic

So from everything I've read, game engines are one type of software where having fine control over how memory is allocated is often very important. I often read that during gameplay you ideally don't want to actually allocate any memory - it should all be preallocated when the level loads. This seems like a good idea, but in practice there are many cases where it seems very difficult to judge what the allocation limits should be. I've got some specific examples in mind which I'll list below. Could someone give examples on how these decisions might be made in practice?

 

(One thing to keep in mind is that in the particular project I'm working on, the levels are procedurally generated.)

 

- Enemy limits. Normally the player might be fighting maybe 5-6 enemies at once. But what if the player runs around the level and gathers a huge crowd? Would you allocate for worst possible case?

 

- Similarly, with items. Five players fire bow and arrow as rapidly as possible, and there are a ton of arrow items stuck in walls. Should I calculate "max fire rate" and determine the maximum possible amount of arrows that could be fired and stuck in the wall before they despawned? It seems like it might be really hard to determine these limits on certain gameplay elements. And networked objects just complicate things further, since their ordering isn't guaranteed.

 

- Network buffers. Messages that are guaranteed are queued up until the ACK has been received. But if there's a network blip, the queue might briefly have to get big.

 

- Objects that have variable sizes. For example, suppose one enemy has a skeletal mesh with 3 bones, and another has 20 bones. Each requires a "state" buffer. But if I allocate space for at most, say, 100 "enemies", I'd have to assume worst case (they all have 20 bones) if I didn't do some sort of on-demand allocation.

 

- Strings. Perhaps they should be avoided altogether. Right now for example, I have a file which describes the "sword" item, and an enemy might spawn "sword" when killed. Should these all be preprocessed into indices?

 

- Components in an entity component system. If it's possible to dynamically add components (e.g. an enemy is OnFire, Frozen, and Poisoned), should you assume the worst and allocate in case all enemies obtain the largest possible combination of dynamic components?

 

It seems like a lot of these "worst cases" could potentially be pretty hard to spot. Especially if there's any sort of user-provided scripting system. What is usually done to deal with these types of issues?

1

Share this post


Link to post
Share on other sites

I don't generally worry too much about it. The main thing is to make sure you're not doing a LOT of heap allocations at runtime, so reuse buffers/vectors, or use a pre-allocated memory pool and use your own allocator. The more allocations you do, the more memory fragmentation there will be, and thus can run into problems on embedded systems/consoles where virtual memory is not available.

 

You're not going to have many problems if you do a few dynamic allocations, the main issue is if you are doing many hundreds or thousands of allocations every frame.

 

One particular pattern that I've found helpful in reducing dynamic allocations is this:

template < typename T, size_t localCapacity >
class ShortList
{
	public:
		
		ShortList()
			:	storage( (T*)localStorage ),
				size( 0 ),
				capacity( localCapacity )
		{
		}
		
		~ShortList()
		{
			if ( storage != (T*)localStorage )
				free( storage );
		}
		
		void add( const T& newElement )
		{
			if ( size == capacity )
				reallocate( capacity*2 );
			
			new (storage + size) T( newElement );
			size++;
		}
		
		
	private:
		
		void reallocate( size_t newCapacity )
		{
			// replace current storage with dynamically allocated storage.
		}
		
		T* storage;
		size_t size;
		size_t capacity;
		
		UByte localStorage[localCapacity*sizeof(T)];
		
};

 

Basically you have a local storage buffer for a small fixed number of elements which can grow to be any size if necessary. This way, you get the best of both worlds: a statically allocated array, plus the ability to store any number of elements.

0

Share this post


Link to post
Share on other sites
There are two relevant problems here that one could run into:

1. Too many allocations happening per second: In this case you would probably first discover this was a problem through profiling, and you would target the low-hanging fruit, changing only those things to use a memory pool or fixed-size buffer.

2. Memory fragmentation: Harder to detect and harder to deal with, but the solution is more of the same.

And of course, avoid unnecessary allocation. E.g. don't do dynamic memory allocation for things that are small and only exist for the lifetime of a function call. That's what the stack is for.
0

Share this post


Link to post
Share on other sites

Thanks for the replies. My target platforms are PC/Mac and iPad. I'm certainly glad to hear that these allocation issues are less of an issue on platforms with virtual memory. From what I've read, it seems like the iPad virtual memory setup is fairly similar to that of a PC, with the exception of swapping memory to disk (which shouldn't happen in a game anyway). Can anyone comment on this?

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0