Jump to content
  • Advertisement
Sign in to follow this  
brightknight

Would using a front end/back end methodology to make games be a good idea?

This topic is 711 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

What I mean by this is, c++ for behind the scenes stuff, ie stuff the users can't directly see like applying hit damage when the bullet hits something(aka back end). Then using Blueprints for the stuff that the user can see like animations(aka front end).

I'm talking about in the unreal engine 4
also feel free to tell me any disadvantages of this.

Share this post


Link to post
Share on other sites
Advertisement

This idea, and topic to be frank is a very abstract one to say the least. It extends past the topic of game design, and embarks on a topic of semantics, and overall development, and who's perspective it emanates from. Say I make an object that renders 3D objects to the screen. It's a very self-contained object, and reusable in other projects. Now let's say Dave a programmer who writes bank software for whatever reason needs to use my object for whatever reason since he does not know how to perform 3D rendering.

 

Well in this scenario above I as the author of the 3D rendering Object can refer to my code as the back-end to Daves Bank software 3D functionality. But now Dave authors a few functions that calculate all sorts of monetary taxes, and interest. And Sally comes along. Sally is no accountant, but she is in charge for the GUI of this Bank Software. Sally uses Daves functions/Object for performing all the necessary calculations for an amount in a savings account. Dave could than say that he authored the back-end for the savings account, and Sally is interfacing the front-end of the application with it.

 

Now say a end-user uses this bank software. Well Sally could say that the end-user is interfacing with the front-end of the application, and that she authored the back-end of the GUI. And due to the intricacies, and dependencies normal everyday software can have, this can be extended a lot further.

 

Programs are like onions. They have several layers, and each layer can be said to have a front-end, and a back-end. So it's not an argument of is it a good design, but more so an observation that it is a design, and methodology that is present in most, if not all software development, and shoot, even engineering in general.

 

Marcus Hansen 

Share this post


Link to post
Share on other sites

Then using Blueprints for the stuff that the user can see like animations(aka front end).

 

Any tool that improves your productivity is a good tool.

 

Think of blueprints as reusable code snippets you can cut and paste into those places where they will do what you need.  Then you can do the rest with handwritten code.

Share this post


Link to post
Share on other sites

Then using Blueprints for the stuff that the user can see like animations(aka front end).

It doesn't matter much the cost of using Blueprints is so low now you can make the whole game with it and won't even notice, and in the end you will need to use Blueprints to connect the C++ code to the game.

 

Also the Blueprints save a huge amount of performance with things like opening doors, often game developers don't want to rotate the door using the in game rotations and export it as a skinned mesh that is a lot slower, blueprints allow you to program it once and then reuse it as much as you want.

 

So yea, you can do it as you mentioned, however you will be using the Blueprints more than you think.

Share this post


Link to post
Share on other sites

also feel free to tell me any disadvantages of this.

 

Online games do the pattern quite often.  The game client only renders a view of the data, and is only given enough information to view the game they can see to prevent cheating.  For example that means when people are around corners their information isn't sent to the game client, otherwise a transparent wall cheat could see them. 

 

The biggest disadvantage is something you will need to resolve based on the specifics of your game:  There is a delay in communications.

 

The time between when the player triggers an event, the data is encoded and sent across the wire, the server process it, the response is sent back, the client processes it, the client prepares it for display, and the client finally rendering it, that can be a LONG time. It may be as short as four or five graphics frames, or it may be twenty or thirty graphics frames or even longer. 

 

How you deal with that depends on the game you are building.  A turn based game like chess this isn't an issue. A real time strategy game or a first person shooter that delay will be a primary issue for all development.

Share this post


Link to post
Share on other sites

There is a delay in communications.

 

But this is a problem endemic to all networked games, not something specific to unity blueprints.  As I understand it, blueprints are just visual programming code snippets - right?

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!