Jump to content
  • Advertisement
Sign in to follow this  
ThereIsNoUserName

Unity Not all gamed have graphics...

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

[I have marked this as C#, but any info, no matter what language or technology is of interest]

Some background
I have been reading a lot about game programming, game architecture and game design in general, and it seem like almost everything assume all games are centered around graphics in one way or another. And when you look at most game engines they seem to be centered on a game loop that should produce a "display frame" for each iteration.

What if you want to make a game that, initially, has no visual graphic output what so ever?  Or when you don't know what or how the output will be rendered?

I'm looking for an architecture where the actual game is completely decoupled from the visualization. An architecture where the game itself implements a set of interfaces that whatever visualization component is used need to interact with.

This interface that the main game module implements should allow for quite advanced bidirectional interactions, with at least events, observables, delegates, objects and "normal" API calls.

There should be no relationship what so ever between frames per second rendered (FPS) and the speed at which the main game module runs at.

If the visualization module know of an object at position P with a sped of V, then it should update the the display based on that info til it is told otherwise by the main game module.

Sure, there need to be a way to keep the objects displayed in sync with with the actual positions of those objects so things don't get out of hand.

I'm talking about the visualization here, but the same goes for a physics engine and other non core game components.
For example I can imagine a solution where Unity would both handle visualization and physics.

 

The questions

  1. Is there  an established architecture out there that even remotely resembles my ides described above?
     
  2. Are there any game engines out there that could be used (not abused) for something like this?
     
  3. Are there any libraries around that would make a good base to use in the main game module as base classes and types for generic game objects (coordinates, vectors and so on) that are generic enough to work well with the public interfaces that the external modules should interact with?

Share this post


Link to post
Share on other sites
Advertisement

As Kyoltan said, as long as the Game Logic is decoupled from rendering, and sometimes other sub-systems most modern games rely on, it really shouldn't matter.

 

I mean, I've made games before, that up until near the end, used console output. But the fact still remains, you need some kind of feedback, a debugger provides some, but sometimes you can get a different perspective that only the output of the running app can provide.

Share this post


Link to post
Share on other sites

it seem like almost everything assume all games are centered around graphics in one way or another. And when you look at most game engines they seem to be centered on a game loop that should produce a "display frame" for each iteration.

The simple reason for that is because this is how we generally interact with a video game.  It's a feedback loop:  rendered frame -> Player sees it -> Player responds -> Game reads input -> new rendered frame -> player sees it -> etc.

I'm no expert, but I'd imagine there are lots of discussions around regarding how to keep rendering and game logic separate from each other.  Any physics engine I've ever used was designed to be run independent of any sort of rendering, and you usually had control over when, where, how often, etc. you would step the simulation.  I'm reasonably certain that both Unreal and Unity operate in a way that, as much as possible, keeps the rendering and gameplay away from eachother kind of like how you've described it.

What if you want to make a game that, initially, has no visual graphic output what so ever?

Text adventures almost fit that description.  We generally think of a 'game' as being realtime, but it doesn't have to be.  I've run into some games that were entirely audio-based- nothing was rendered and you had to rely on your ears to navigate a space.

Share this post


Link to post
Share on other sites

1. Is there an established architecture out there that even remotely resembles my ides described above?
 
Yes, as mentioned most major game engines decouple rendering and logic from other systems.  
 
Major online games where the server runs the game also follow the pattern, the game clients do the display but it is completely decoupled from running the game.
 
It also includes most games with persistent elements played through a web page. All that matters is they send the right network calls to follow the protocol of the game.
 

2. Are there any game engines out there that could be used (not abused) for something like this?
 
Yes, any of them that include a networking component which means nearly all of them.
 
Don't draw anything and create a network interface for all the things you want to expose.
 

Are there any libraries around that would make a good base to use in the main game module as base classes and types for generic game objects (coordinates, vectors and so on) that are generic enough to work well with the public interfaces that the external modules should interact with?
 
Again, any of them that include a networking component or that allows you to add your own networking components.
 
So basically any programming library developed or maintained through the last 30 years.

Share this post


Link to post
Share on other sites

I'm surprised you make it sound like every game is coupled to the graphics. While that often does happen in AAA development because of time constraints there isn't really any 'good' reason to couple graphics and game logic. Usually it just happens because people throw things together and it started off separated anyway.

 

Most code that isn't written in a rush like that generally IS decoupled from the rendering because often the game needs to support different variants of rendering anyway, so it ends up using a lot of interface code. Probably the best example I can think of this is dwarf fortress, which more or less runs the simulation by itself and everyone has developed different "visualizers" for the game.

Share this post


Link to post
Share on other sites

As someone that has fond memories and still a love of text adventure games, I really find this thread strange. Of course games do not need graphics. Still, you need to provide the player with some sort of feedback or you're left with what? I really don't know. Games are by nature interactive. That requires feedback, both to and from the player(s). The type feedback is arbitrary, but absolutely necessary.

Edited by MarkS

Share this post


Link to post
Share on other sites

I think the tight couple between render and engine started to fall away after Quake3 days, that had strange behavior where you wanted exactly 62 or 92fps (From memory, long time ago) With the right FPS you could pull off a number of jumps and jump higher than people at different FPS. The tight couple effected the physics calcs.

 

As others have said, it is far less common now, doubt any AAA games do and most games built on a high profile engine will not

Share this post


Link to post
Share on other sites

Any game using a client/server model respond to that criteria, all the game logic and calculation is usually done on the server side and the client is just a "controller" with a screen on it.

Share this post


Link to post
Share on other sites

I think the tight couple between render and engine started to fall away after Quake3 days

 

About 6 years off, but yes it has been a long time. In the early to mid 1990s most games had enough processing power that they started decoupling systems. I remember reading the advice back in old BBS systems as early as 1993, possibly before.  

 

That decoupling is what enabled the original Doom to be successful in the way that it was. Carmack and his crew famously described their task scheduling system which many people talked about, and it was immediately obvious how big the benefits could be.

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!