• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Bar?? Ekinci

Writing Game Engine!

13 posts in this topic

Friends I want to write C + + using the game engine. Already writing games using c + +. I believe that an adequate level. I command the C + + language. How long it takes to write the game engine? How to write C + + suitable?

0

Share this post


Link to post
Share on other sites

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

0

Share this post


Link to post
Share on other sites

 

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

 

Yet I'm convinced if zigzak had written games before, he would know where to start, or have an idea as to where to start.

It looks like he's got nothing.

 

@zigzag, you may want to think in subsystems. Whan have you written so far? (as in lifetime experience)

Do you know how to get rendering to work using C++, and what graphics api do you prefer?

Also, by being adequate in C++ you are by no means commanding the language.

I've been programming for 18 years, C++ for 5 years, and I often feel like I'm still just exploring it.

Edited by SuperVGA
0

Share this post


Link to post
Share on other sites

 

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

 

 

If the motivation is to just make an engine and you need to ask how to go about it then that advice still applies, engine design without experience is a recipe for a bloated unusable mess that won't actually be usable for making real games.

 

The only difference i would say is, if the goal is to get an engine rather than a game, keep that goal in mind as you make the games.

0

Share this post


Link to post
Share on other sites

 

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

 

 

My goal was to make an engine. I should have just made games and derived an engine.

0

Share this post


Link to post
Share on other sites

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.

Edited by Nyssa
0

Share this post


Link to post
Share on other sites

 

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.

 

 

If you've worked 5 years on an engine without making any games with it you might have a big problem though, you got 5 years worth of work that hasn't been properly tested. Making complete games using an engine is the only sane way to test its design, performance, stability and workflow(a big problem with many hobbyist engines is that they are virtually unusable for large projects, despite shiny tech demos) issues tend to pop up quite quickly when you try to use pretty much any engine(even good engines have issues, allthough they tend to be less severe) for a real game and you want to catch the major issues as early as possible.

Edited by SimonForsman
2

Share this post


Link to post
Share on other sites

 

 

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.

 

 

If you've worked 5 years on an engine without making any games with it you might have a big problem though, you got 5 years worth of work that hasn't been properly tested. Making complete games using an engine is the only sane way to test its design, performance, stability and workflow(a big problem with many hobbyist engines is that they are virtually unusable for large projects, despite shiny tech demos) issues tend to pop up quite quickly when you try to use pretty much any engine(even good engines have issues, allthough they tend to be less severe) for a real game and you want to catch the major issues as early as possible.

 

 

Partly because I'm interested in your perspective, partly because I think OP could benefit from hearing more, would you, SimonForsman compile an article (or point to one)

about how to evade the pitfalls you mentioned? I've rewritten my engine several times over, but something makes it so I can never really take pleasure in working on an actual game.

I like my project, and from making smaller games earlier on, I do believe I know what I'm doing.

 

But what you just wrote sparks that fear, that although I do my best to create a diverse, powerful engine, it will come short once I want to apply some more abstract game to it.

I guess iterating is always good, stopping up going "Aha. GUI and Messaging system is now complete. Let's create a form-based game." Next, random landscape generator using the forms from before etc.

 

But I don't know for sure. I've never finished one engine. Games. But not engines. And although I'm convinced I know how the things I write now should be used,

perhaps it's not actually a good way to go about it.

Edited by SuperVGA
0

Share this post


Link to post
Share on other sites

 

 

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.

 

 

If you've worked 5 years on an engine without making any games with it you might have a big problem though, you got 5 years worth of work that hasn't been properly tested. Making complete games using an engine is the only sane way to test its design, performance, stability and workflow(a big problem with many hobbyist engines is that they are virtually unusable for large projects, despite shiny tech demos) issues tend to pop up quite quickly when you try to use pretty much any engine(even good engines have issues, allthough they tend to be less severe) for a real game and you want to catch the major issues as early as possible.

 

 

This is true, and it's true about any product that is created, not just software. However if you have a background in what it is you are creating, set out with some clear design goals, and use an iterative design through regular testing then problems will more likely be caught early too.

 

But yes, the best way to test any product is to use it in a real life situation.

0

Share this post


Link to post
Share on other sites

 


That's because you never finish an engine - they are always changing and evolving as you learn and find weaknesses while using it.

Which is kind of the problem with trying to develop one on it's own; unless you are constantly using it you'll never know how much works and how much is flawed.

Even at work, where we have a small team developing an engine, it is being driven by customer game requirements and ideas.

 

So would you encourage me to first create small games with the different subsystems like I described, and then create new, different projects on it over and over when all subsystems are finished, to mature it?

(Sort of a rhetorical question, I guess, but maybe you have a better idea...)

Edited by SuperVGA
0

Share this post


Link to post
Share on other sites


I think you just disproved your own point. You're making an engine that has no specific finish line, no goal, no hard list of requirements to fulfil, and no way of evaluating/testing it's merit... so you've not finished 
Having an explicit purpose for the engine (it must support the needs of this game) gives it a solid focus, and a framework for evaluation.

 

Maybe I was far to broad in my statement. When I started, I had specific design goals from previous experiences, an end goal, and time frames. Of course I didn't always meet deadlines but I did my best to meet them. I set sprints on work and goals to achieve and that kept my motivation high. I did achieve what I originally set out to achieve and I am happy with with my efforts. By not finished I meant things like bug fixes, optimisations, and "nice to have" features. I had purpose when creating it, and it was being designed side by side a game, a number of games over time actually. 

 

What I found difficult being the only coder was the artists needed to see the game coming together to keep motivated (which is totally reasonable and I understand that). If I didn't stay on top of the game then it would hinder their workflow of iterating over the artwork and animation to improve on it. The issue there with me was the game was dependent on me getting some feature in the engine working, not necessarily finished, just working. So it became a situation of constant context shifts for me as to not slow the artists down too much.

 

In my current position we have an engine team, and product teams. The product teams can focus on making the products that are customer driven, without worrying too much on how the underlying tech works. While the engine team can of course just focus on the core tech. If the customers want some new tech then that obviously falls on the engine guys. In this separation it is rare for a team to slow another down. 

 

So the point I was originally making was it can be hard as a lone coder to create a game and reusable engine side by side.

 

I agree with everything that has been said about game engines failing because they have not passed the "dog food test". I've used gamebryo and it was a horrible mess.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0