oop - Is it a good idea to build an API over a game engine's API for the sake of portability? -
let me give background first context:
i interested in building game intention of being modular. started project in unity3d. coding game closely unity3d's api, wondered, should have built own api game in case wanted/had move off unity3d in future? (to game engine, or better yet, use opengl/directx directly)
i interested in moving game on unreal engine 4, tried best abstract game, of explicitly uses unity3d's api own api. example of class still depends on unity3d player
class (github)
//vector , gameobject both unity3d classes private player(playerid id, vector position) { gameobject playerprefab = resources.load<gameobject>("player"); playerobject = gameobject.instantiate(playerprefab, position, quaternion.identity) gameobject; playerobject.addcomponent<unityobjectscript>().bind = this; playerobject.name = "player " + id.tostring(); coreobject = playerobject.transform.findchild("core").gameobject; bodyobject = playerobject.transform.findchild("body").gameobject; players[(int)id] = this; unitylink(playerobject); }
long story short, gave abstracting made , decided rewrite it. anyways, point of is:
is worth build own api on api exists (the game engine)?
while feel if there isn't other alternatives achieve 'modular' vision of game, main concerns of making api is:
is overhead penalty worth (if any)? or rather,
is 'overkill' have api built on api in case?
should have built own api game in case wanted/had move off unity3d in future?
you should, if want move off existing game engine in future ;) should not if don't ;)
but adding abstraction layer slow things down. degree of slowness depends on api design.
is 'overkill' have api built on api in case?
if don't want move game engine in future - yes.
Comments
Post a Comment