TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: When to cut your losses and rewrite with a framework?

2 点作者 andygeers将近 16 年前
I've invested four and a half years in coding my own game engine specifically tailored to the niche genre I'm writing (3D point &#38; click adventure games). It's still pretty buggy and doesn't have many bells and whistles, and it's Windows only with very limited prospects for porting to other platforms. On the other hand, it's certainly usable and I am able to make progress on actually scripting out my game content with it, and it is obviously very focussed on my precise needs.<p>How do you make the call on whether to persevere with your own reinvented wheel and invest the effort required to debug it, or whether to jump ship and use someone else's fully-featured wheel that's tried and tested by hundreds of thousands of users?<p>I don't think there's any doubt in my mind that if I were to start from scratch today I'd go with a 3rd party game engine (maybe something like Unity or Torque 3D - good but affordable).<p>(P.S. You can consider this related to today's Coding Horror blog post if you like, but I've been thinking of this independently)

3 条评论

lrm242将近 16 年前
I think the fundamental question is: "will having your own game engine give you a decided advantage by making your game unique in some way?"<p>Will your game be more memorable, enjoyable, etc because of your engine? I'd doubt it, since that will most likely come from your game itself (the rules, balance, game play, etc).<p>As humans we are inherently programmed to not be able to cut our losses very effectively. We don't want to walk away from an investment even though we know deep down inside that it's the right thing to do. In the financial trading world, this is often quoted as one of the #1 things that makes a trader "good" vs "bad". Can they identify a bad situation quickly and cut their losses so they can focus on the next winner.<p>In my opinion, the very same could be said for an entrepreneur. Some of the hardest decisions we have to make when running a company have to do with what NOT to do. When to stop a failed effort, regroup, and carry on. If you follow the path far enough you'll see very clear parallels between "cutting your losses" and other "startup" advice like: adapt, don't be afraid to fail fast, more downs than ups, etc etc etc.<p>So, back to your situation. You have, IMO, answered your question already. You note that your engine is not as good as commercial engines and that there are commercial engines out there within your reach. You also note that it will take away time and energy from your ultimate goal which is to release a game. Finally, you note that if you were to make this decision today (without the fundamental human urge to not walk away from the invested time and energy) that you'd pick the commercial engine.<p>Without more detail, I'd suggest you go with a third party engine so you can focus on the game and not the framework. Good luck!
TallGuyShort将近 16 年前
Here's some thoughts. I can't say yes or no for you, but I hope these questions help you focus the issue more.<p>1) Does your engine offer something over these other frameworks that other people might find useful if you finish it? If so, I think you should finish it. But more importantly...<p>2) Are you more interested in producing your game, or creating your own gaming framework? And what do you stand to gain from each? (Even if it's just satisfaction and learning).<p>3) How much work do you have left to accomplish both? How does that compare to the work of starting over with a 3rd party framework?
gruseom将近 16 年前
There is research suggesting that when there is 80% or more overlap in requirements it makes sense to use a library and when there is 20% or more divergence it makes sense to write your own code. Obviously there's no precise way to measure such divergence, but I'd say that rule of thumb sounds about right intuitively.<p>(I read about this in Robert Glass' <i>Facts and Fallacies of Software Engineering</i>.)