Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jun 2009
Offline Last Active Aug 07 2014 09:36 AM

#5114538 Should I make my game engine cross platform?

Posted by on 05 December 2013 - 04:07 AM

In general, don't make anything you're not using.  There are too many ideas and decisions which you'll only arrive at through practical use, which means that making without using will accumulate wasted work and required rework.


So don't make an engine without also making the game/content which will use it.  And by extension, don't make your engine cross platform unless you're making a cross platform game.


That being said, as has been suggested above, you should make your design as portable as you can even if you don't port it.  I suspect this will be good for design anyway, since isolating platform dependent code is a form of separating concerns.

#5114533 How much it cost to develop a game similar like Clash of Clan, Friendly fire?

Posted by on 05 December 2013 - 03:42 AM

I got zero knowledge about programming, illustration. Like many other gamer, we always have some idea which inspired on abc game and hoping some one will invest their money and whoala, this game get famous.


(Not having looked at the target game, but just speaking of game development in general...)


Most people also have no experience in game, UI, or sound design, music, game production, tech or art direction, IT, QA, HR management, etc.  Good personnel to fill these needs (and several more, for higher-end titles) should be added to the budget just to facilitate development.  


If we hope to do anything more than simply get something made, we'll also need to cover market research, PR, advertizing, distribution, business law, etc. 


A handful of acquaintances making something on the side for fun is one thing.  But when we turn it into a commercial project in which we hope to pay expenses, and maybe even profit, we have to somehow account for at least all of the above.  These are some of the reasons it's tough to arrive at an actual budget. 


It's probably much, much cheaper for an established group whose just succeeded on all fronts with a similar title, to make a given game than it would be for a business speculator to put together the same project from scratch to get the same result.  Figures based on the former are likely to woefully underestimate the latter, in both time and expense. 


This is one of the reasons it's tough to get savvy investors interested. 

#5091597 Game engine as a portfolio project

Posted by on 04 September 2013 - 11:40 AM

I think a good engine is something that allow someone not that skilled in  programming to make a good game/software really easily.

And also that make it easy to a non-programmer (artist) to integrate their content into the software.



A tech demo is fine.  You don't have to create a lot of content or gameplay to showcase engineering skills.


But you should realize that most of the value you'll potentially provide to your creative co-workers is in making it easy for them to create content.  So beyond your ability to create run-time features, you'll want to showcase your ability to facilitate content creation.

#5090229 questions about singletons

Posted by on 29 August 2013 - 03:39 PM

If there were ever two instances of this class then all of my resources would potentially be invalidated because their handles could suddenly be used to load a new resource. My whole motivation in creating the singleton was to enforce one-and-only-one instance.

As pointed out earlier in this thread (and easy enough to forget that I've done so in the past), it's not a singleton unless it provides global access.


If you're forced to use a bit of static data to enforce the "singularity" of an object, that's unfortunate, and may require you to address initialization order and threading issues.  However, that doesn't require you to also make that object globally accessible.  You can still create and use it as a normal object.

#5082257 DLL question

Posted by on 01 August 2013 - 12:55 PM

What i wanted to avoid is having to create an interface for each class that i'd put into the graphics dll, but i haven't made a list of what classes from the dll would actually be exposed outward. I thought i'd have to expose all the low level stuff (like vertex/index buffer, textures and such), but if i compose them into higher level concepts (like sprite, model etc), than i end up with just a few interfaces. Is this a good approach?

Yes.  You should keep the renderer interface used by the rest of the engine as minimal and simple as possible. 


Also, everything created within the dlls factory method should also be sent to the dll to destroy instead of destroying them manually, right?

No.  Your dll will generally be compiled against the same memory manager as the rest of the engine (unless you do something to prevent it), and your engine is linked against the interface you expose from the dll, so generally, the engine can delete objects it gets from the dll.


That being said, code defined in the dll, including destructors and anything they call, can only be called while the dll is loaded.  So it's a bad idea for the renderer to be handing out objects implemented in the dll.


In my implementation, the engine only handled a single dll specific object - the renderer itself.  All other render related objects handled by the engine were defined outside of the dll.  They were written in terms of the renderer's interface.  All data resources with API specific formats were held within the renderer internally, and referenced externally by ID (so the resource could swap out when the renderer did, without breaking external references).


On a side note, this means that if you ever do decide to make your renderer hot-swappable, it'll need to do a little fancy footwork for the post-swap renderer to acquire all the API specific data resources corresponding to those which had been held by the pre-swap renderer.


I'm actually not sure if its even possible to change the DLL on the fly while the exe is running, as the DLL would be in use, right? And even if that's possible, how would the exe know to reload the DLL?

Yes, you can unload a dll.  It's up to you to make sure you don't use it before loading or after unloading it.


I'm not sure I understand the question - but the exe "knows" because you write it to know.  You unload one dll and load another when you see fit.

#5082033 DLL question

Posted by on 31 July 2013 - 03:19 PM

I've done the whole renderer-in-a-runtime-swappable-dll-accessed-via-pure-virtual-interface thing in the past.


I can't be sure why you don't want to use interface inheritance, but I can say that if my engine were making so many calls to the renderer that the virtual function call overhead became a performance concern, I'd think I must be doing something very wrong.


#5075359 OK to 'steal' someones idea if they are doing a crap job of it?

Posted by on 04 July 2013 - 08:03 PM

Ever heard of:

  • Windows (plus Word, Excel, Explorer, etc.)
  • iAnything (pod, phone, pad, mac (esp. the mouse interface), etc.)
  • Amazon
  • Google
  • Facebook
  • Id's shareware model
  • Blizzard MMOs and RTSs
  • Riot's free to play model
  • Etc.

Every single one of those were "stolen" ideas. 


The question isn't whether or not its ok to "steal" an idea if someone else is executing poorly.  The question is whether or not you can execute well enough to make it worth your trouble to develop it.


#5012673 C++ Engine Layout

Posted by on 19 December 2012 - 07:56 PM

Logging is the classic example of the thing you make that everything needs access to, because it's the only example (unless you're re-implementing other environmental features, like the memory manager, etc.)

Personally, I like to treat it specifically as an exception to the rule, because I don't see it so much as part of your application, but instead it's a part of the environment in which you're building your application.

I don't know how Hodgman manages to be right every single time, but once again, Hodgman's right. Logging is the exception because it's diagnostic scaffolding which is unrelated to our code's actual functionality.

But even so, it's possible to come up with a reasonable design for it.

Our design goals might be:
- Support multiple logging channels, locally configurable to be sent to various destinations.
- No logger object needed at point of logging (i.e. no passing loggers to every single function).
- No globally accessible state.

class Logger
  public: // "Object part"
	void SendChannelToFile			  (string const & Channel, string const & FileName);
	void SendChannelToDebugConsole	  (string const & Channel);
	void SendChannelToOnScreenConsole (string const & Channel);

  public: // "Global part"
	static void Log(string const & Channel, string const & Message);

The basic idea is that Logger::Log() has some sort of safe default functionality (like ignoring all log messages), but if a Logger object exists, then the function uses that object's configuration information to route any configured channels.

Note that the globally accessible Logger::Log() function neither sets nor gets state.

The appropriate part of the codebase can create a Logger object, and load a local configuration file to configure logging channels according to the local user's current preference. Setup, access, lifetime, and cleanup of the object and its configuration data are all managed as with any normal object. The Logger class can prevent more than one instance from being instantiated, to avoid mishaps.

The Logger object's internal state does remotely effect the behavior of Logger::Log(), but then Logger::Log() is generally designed to effect the environment outside of the application (like printf() and std::clog() ).

And yes, the connection between the global and object parts would be accomplished through some static pointer, and Logger::Log() may need to be thread-proofed. But again, this system is the exception, and all of the above functions can be conditionally compiled to no-ops in published versions.

#5012562 Alternative to context objects

Posted by on 19 December 2012 - 01:46 PM

I agree that this issue can be addressed with component based design.

I currently favor a design in which components are those parts of entities which are associated with specific engine systems ("services"). They're created (and processed) by the engine systems themselves. And entities are collections of components.

The components generally need to know about a couple of other requisite components types, and often don't even need to know about their own engine system, since the system knows about them.

Note that this still leaves us with entity constructors which know about components, and the engine systems which create them.

This can be resolved by designing an entity factory, with which each engine system registers itself (rather than one which already knows about them), that does data driven entity construction (is given a list of component type IDs and uses the registered systems to generate an entity containing instances of those components).

That should eliminate the need to recompile code for non-dependent entity types when adding new systems. Although I must admit, I'm not sure how much this saves you in terms of re-compiling. On the one hand, there will still be some high level code (AI) which will need to know about a lot of the systems/component types. And on the other hand, adding systems doesn't seem like something which should be happening often enough for this to be an annoyance.

#5009946 An Unfocused Discussion

Posted by on 12 December 2012 - 02:19 PM

Here's a little meta-discussion for you.

Ideas are fun, we all have them. I'm not surprised that GameDev is full of people that are just kicking around ideas; I am surprised ,however, over the constructive criticism and general helpful attitude. Kudos to you, gamedev community! While I'm not going to share my personal ideas...

I don't know if you think your ideas aren't worth discussing, or if you consider them potentially too valuable to share, so this is not necessarily about you... But I think people in general tend to heavily over-value ideas.

This applies to every industry. Apple didn't invent the computer GUI, or the mouse, or the personal-digital music player, or the cell-phone combo-device, or the tablet computer, or the minimalist interface, or mobile web-browsing, or online commerce, or music as a digital commodity, etc. What Apple did was execute better on those ideas than others who had them.

Facebook didn't invent the social network, and Microsoft didn't invent DOS or the windowed OS. Id didn't invent the FPS, Valve didn't invent the story driven FPS, and Blizzard didn't invent the RTS or the MMO.

A high-functioning, efficient game studio can produce a far superior game from a mediocre idea than the average studio can produce from a better idea.

People seem to think that the right idea will produce success, or that sharing good ideas is equivalent to giving away wealth. Don't get me wrong. Ideas are important. But this industry is full of smart people, and as mentioned they all have ideas. Success depends far, far less on the quality of the ideas one produces on their own than on their ability to execute effectively on the ideas available. An idea held by someone not in the position to execute on it has almost zero potential value. And someone who can execute on it derives far more value from that ability than from any one of the world of ideas they might choose to use.

The bottom line is that practically speaking, we loose effectively nothing by sharing ideas, even great ideas.

#5008288 std::chrono::hige_resolution_clock for timer?

Posted by on 07 December 2012 - 06:54 PM

Microsoft didn't use their performance counter in implementing C++11's high resolution clock. As a result it's not really high resolution and is probably an order of magnitude or so low for your frame timer. (See the bug report.)

You can test a clock's resolution by getting a time from it repeatedly until it returns a different time. Then you can decide for yourself if its resolution is sufficient for your purpose.


UPDATE: According to the notes (dated 11/13/2013) on the bug report linked above, this issue is still not fixed as of VC2013.


UPDATE: According to the notes (dated 3/17/2014) on the bug report linked above, this issue is should be fixed in the next major release (after VC2013).

#4988167 Absolute beginner question regarding APIs, frameworks, libraries...

Posted by on 08 October 2012 - 06:49 PM

It's true that there's no need to get bogged down in terminology. But sometimes the best way to avoid that is to get answers to your questions. Posted Image

The term "Library" refers to a specific way functionality can be packaged for use by the application programmer.

Specifically, in a compiled language like C++, a set of functionality is compiled to object code (i.e., "link-able" .obj files), and made available in an "archive" or "library", which on windows is a .lib file (.lib files essentially contain a bunch of .obj files). The application programmer generally "includes" provided header files which declare functions and types implemented in the library, uses them in code, and links the library into the executable.

The term "library" says nothing about what type of functionality is provided, or what it might be used for.

As mentioned, API means "Application Programming Interface". "API" generally refers to a library, but is named for the interface (i.e., the contents of accompanying header files) to which the application code will be written, rather than the implementation in the library.

The phrase, "Application Programming" implies that the functionality provided is specific for creating some certain type of application. The Windows API is used for making Windows applications; The OpenGL ("Open Graphics Library") API is used for making graphical applications; Etc. APIs often deal with how the application interacts with the outside world - how it gets input and/or generates output.

In general, an API is a library but a library is not necessarily an API. The C++ standard library, for example, is mostly functionality for a program's internal processing. It's not designed for giving an application access to, or control over, any specific platform/environment.

A game engine is a unified set of run-time software technology designed to provide a good portion of the core functionality of a game. The thing that makes it an engine, is its frame-based multi-tasking nature. The thing that makes it a game engine is all the basic functionality it delivers that makes it useful for building games. (OpenGL and Direct 3D are not engines, for example. They provide nothing but a way to get graphics on screen.)

While not technically part of the engine itself, most engines would be useless without a set of accompanying tools for generating content specific to that engine, so a tool-set is sometimes thought of as part of the engine.

The term "engine" says nothing about how the functionality is delivered. It could, for example, be delivered as a set of libraries, or as source code for a sample game "stub". If it's a set of libraries, they could be considered an API for developing applications on that engine.

The "Open Graphics Library" is a cross-platform API for putting graphics on-screen.

Providers of all sorts of different platforms, that have graphics rendering ablilty, can implement the library for their platform. All implementations of the library work with the published OpenGL interface. That way, applications programmers can write applications using that interface, and they'll build and work on various different platforms, without alteration.

Direct X
Direct X is a Microsoft API for developing "multi-media" applications on Microsoft platforms. In addition to Direct 3D (their graphics API), it includes other components like Direct Sound and Direct Input.

SDL & SFML are video games APIs.

They provide facilities for such things as audio output, input acquisition, networking, threading, timing, etc. They work with, or along-side, OpenGL.

I don't really know much about Unity, but in general, any robust game engine will include all of the functionality provided by the graphics and video games APIs, and more (e.g., physics, collision, AI, game objects/entities, message passing, asset handling, load/save, GUI/menus, etc.).

#4975892 You wish you had known...?

Posted by on 02 September 2012 - 07:02 PM

No. It's not.

I too have only worked on two cancelled projects in sixteen years. But the majority of projects that are completed in this industry don't end up achieving much commercial or artistic success. The majority of start-up studios fail within a handful of years. And the large publishers routinely suffer large scale lay-offs.

That's life. And it has nothing to do with me.

#4975781 You wish you had known...?

Posted by on 02 September 2012 - 11:54 AM

What did you wish you had known before getting into the industry?

I consider the first project I worked on to be a technical and creative achievement. But a new console was released shortly before we finished. It did alright in Japan, but no one has heard of it in the USA. I consider the second project I worked on to be a technical and creative achievement. But the publisher semi-collapsed near the end of the project and it got no marketing. It was appreciated by the few who played it, but it was few indeed.

That studio closed, and I got hired by the biggest publisher in the industry (at that time). I did great work on projects that made money. But they were only an advertizing success. Management and production were abysmal, the games weren't very good, half the studio got laid off, and development staff brought a massive class-action suit against the company. Lawyers got rich.

The next studio I went to had proven themselves technically competent and reliable by picking up port projects that other studios didn't want. They were working on graduating to actual development. When the economy put the squeeze on the industry, their projects dried up. They are no more.

I went to a new studio being launched by a large publisher, with a producer stolen from a competitor's successful franchise. But the first-time studio management was way out of their depth and ultimately failed to produce anything. The publisher pulled the plug and closed the studio.

I went to another start-up which was picking up contracting gigs, solving other studios' technical problems, with the intention of developing a couple large scale game concepts and landing publishing deals. But the designer turned out to be a fraud, and the publishers wouldn't touch us.

Etc., etc., etc. My experience is not unusual.

What people need to know about this industry is that video game projects are very large and expensive, with thousands of moving parts that need to come together just right. 99.999% of what happens on a project will be outside of your control. It only takes one bad twist of economy, industry, business, etc., or incompetent person in a key position, to ultimately take a project down.

Most projects don't amount to much, and most studios go broke. Odds are, regardless of your talent, failed and mediocre projects will far outnumber successes, you will often be out of work, and likely forced to move to land new jobs. This is not the industry to be in if you value stability.

#4970757 Need Name For Hacking Game

Posted by on 18 August 2012 - 12:14 AM

Disclaimer: I didn't Google to see if these are ok to use.

Fire Wire
Ride the Wire
Electric ICE
ICE Pick
System Subversion
Hired Hack
Part-time Hack
Hack for Cash
Hack Saw
Sam Hack
Subnet Mask
Subnet Take-down
Net Control
Net Shadows
Cypher Fatigue
Super User
Root Access
Inside Job
Cubicle Commando
Protocol Hero
Router Raid(er)