Jump to content

  • Log In with Google      Sign In   
  • Create Account


Beginning to write my own engine where do I start?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 JimBridges   Members   -  Reputation: 103

Like
0Likes
Like

Posted 08 February 2012 - 04:26 PM

Beginning to write my own engine where do I start? I started to write a basic stack-based state machine design.
Where do I start?
I have most of the artwork drawn. No copyrights yet.
It is a fighter but I want this engine to be re-used on multiple other games.


Definitions?

Copy protection?

frame counter?

Hit detection?

Artwork?

Sponsor:

#2 jbadams   Senior Staff   -  Reputation: 14755

Like
1Likes
Like

Posted 08 February 2012 - 06:35 PM

Write Games, Not Engines; that is to say, you should focus on the features you need for this specific game, and then worry about what might be re-usable later. Over time as you extract bits of code that can be re-used, clean them up and perhaps generalise certain things you will end up with a solid reusable engine which meets real-world requirements and has several games demonstrating it's usage and functionality. Obviously if you encounter a specific system where you know a certain choice would prevent re-usability you should avoid that choice unless it is overly difficult to do so, but in non-obvious cases or if you aren't sure just write whatever works for the current game.

Where to start? I'd suggest creating a window, then getting a single image on the screen, then making it respond to basic input, then adding a second graphic and detecting if the first one collides with it, and so on and so forth... just keep adding things till you've built your way up to an actual game.


If you've never written a nice simple game like Tic-Tac-Toe or Pong before this would be the time to consider doing so, to learn some valuable lessons about how to structure your code before you start on your fighter project.

I have most of the artwork drawn. No copyrights yet.

Copyright applies as soon as you've created your works. Registering it will likely to required (or at the least a BIG help) should you have to go to court, but copyright is free and automatic.

Copy protection?

If you decide to worry about this at all it should be when the game is otherwise finished or almost complete, and you should not spend too much time on it; no matter how good your copy protection is someone will crack it, so you really only want to spend a minimal (if you spend any at all!) effort to deter casual copying rather than some complex scheme that might possibly annoy a genuine customer.


I'd put the artwork aside for now until you have a working (not necessarily complete, but working) game to put it in -- you can write code without artwork, but all the artwork in the world won't make a game until you get around to writing that code (or using an editor, but it sounds like you've decided on coding your game).


If you haven't done so yet, you might also want to take the time to write out a basic design document outlining the features you want in your game so that you can write appropriate code to support those features.


Hope that helps! Posted Image

#3 Ravyne   Crossbones+   -  Reputation: 5686

Like
1Likes
Like

Posted 08 February 2012 - 06:43 PM

<sarcasm>Copy protection, duh. How else will you make your millions and prevent people from stealing your sweet code?</sarcasm>

Back to reality now -- You're getting way ahead of yourself. The standard advice around here is Write Games, Not Engines.

The very fact that you don't know where to start, is evidence incarnate that you're exactly the developer that this article was written for. Engines are all about solving problems and meeting requirements. Someone who is as (I'm assuming) green as yourself just doesn't know yet how your idea translates to requirements, that in turn translate to problems, that in turn translates to solutions, that in turn translates to a single game. This is a really hard problem, and involves the kind of foresight that one is not simply born with -- it must be learned and experienced. Only after you've been through the trenches of a few complete games might you have enough flashes of insight to not do a terrible job; and please, for your own sake, don't make the mistake of assuming you are the exception to the rule.

For now, go make a game instead of an engine -- or perhaps better, go *use* an engine as a first step (Unity, or what-have-you). Its relatively rare that anyone does anything at all (least of all, does it well) without first knowing how others have succeeded or failed before. When you're done with that game, do a few more and then re-visit the thought of your own engine.

#4 Hodgman   Moderators   -  Reputation: 24033

Like
0Likes
Like

Posted 08 February 2012 - 06:57 PM

As above - get a list of requirements for your game, and produce a list of features that the engine needs for fulfil those requirements.

Personally, I'd start with the content pipeline (the tools that convert your artwork into game data files) and the renderer (that displays the game data).

#5 Telastyn   Crossbones+   -  Reputation: 3692

Like
1Likes
Like

Posted 08 February 2012 - 07:16 PM

Personally I like to start with logging. You're going to screw things up; sooner rather than not. Don't waste time debugging when a passable logging framework takes about 10 minutes to throw together.

#6 jbadams   Senior Staff   -  Reputation: 14755

Like
0Likes
Like

Posted 09 February 2012 - 12:29 AM

Personally I like to start with logging. You're going to screw things up; sooner rather than not. Don't waste time debugging when a passable logging framework takes about 10 minutes to throw together.

While this is a pretty solid suggestion in general, I'm not sure if it's the best starting point for a beginner... as with the engine and game, until there are actually errors that need to be tracked down and handled it's likely the OP won't be sure of exactly what features would and would not be useful in a logger or even how one might be helpful.

Unless the OP has some prior experience that isn't mentioned here a logger might be better left until there is something to log.

#7 Washu   Senior Moderators   -  Reputation: 3953

Like
1Likes
Like

Posted 09 February 2012 - 01:10 AM

Personally: I start with a game.

If you have never written a game before, you are in no position to write an engine. After your first game you start to have a glimmer of an idea of a thought that might be behind a concept that's possibly an engine. At that point you go write another game, and re-use/cleanup some of your earlier game code. Then write another game, cleaning up and expanding on the re-used functionality from your previous two games.

As jpetrie states, and has been linked several times before in this thread: Write Games, not Engines. This cannot be emphasized enough.

Now, where do you start with a game...

Well, start with getting a basic application that does nothing working on your chosen platform. Then expand from there, get the background clearing to a color, get your basic game loop in place. Now you'll want some artwork to display, so start working on your content pipeline, get a nice process going that converts from your raw art to game supported formats (for instance, going from PSD to DXT, or FBX to your own model format).

Now that you've got art assets to play with, get basic rendering working. Get just a plain old image to draw in the center of the screen, get other images to draw. Draw tiles (if you're doing 2d), and get that perfected. While you're working on that you might find that you want to store your tiles in a file for quick testing... now you've got a MAP format...

You see how this grows out to become a game? Once you've got the game it becomes much easier for that to grow out into an "engine"

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX


#8 Krohm   Crossbones+   -  Reputation: 2748

Like
0Likes
Like

Posted 09 February 2012 - 01:42 AM

Beginning to write my own engine where do I start? I started to write a basic stack-based state machine design.
Where do I start?

I strongly suggest to sit down and write the game itself to a reasonable amount of detail. Then, following the "make games" suggestions: implement everything this games requires and no more. This is the 1st engine iteration. For complex games, this is already very complicated!
I was surprised how much a well specified artistic direction can give me a boost. No more "I might need this" code paths. What is required, what is not, this is important.

It is a fighter but I want this engine to be re-used on multiple other games.

An long as they're all beat-em-up there will be some reuse. I am in the unfortunate position to be able to share something about "very flexible designs". The break even point is too far.

Collision detection: use a physics API!

Edited by Krohm, 09 February 2012 - 01:44 AM.


#9 Telastyn   Crossbones+   -  Reputation: 3692

Like
0Likes
Like

Posted 09 February 2012 - 08:30 AM


Personally I like to start with logging. You're going to screw things up; sooner rather than not. Don't waste time debugging when a passable logging framework takes about 10 minutes to throw together.

While this is a pretty solid suggestion in general, I'm not sure if it's the best starting point for a beginner... as with the engine and game, until there are actually errors that need to be tracked down and handled it's likely the OP won't be sure of exactly what features would and would not be useful in a logger or even how one might be helpful.


Enh. If the beginner is taking the wrong route by making the engine, then screwing up a logger is probably the least impactful mistake available. And really; almost any logger will do to start with. Take strings, write somewhere.

#10 Josh Vega   Crossbones+   -  Reputation: 1098

Like
0Likes
Like

Posted 09 February 2012 - 11:46 AM

Unless you plan on licensing you engine to other developers, you should probably Write Games, Not Engines. Lets say your writing the 3D model loading code. Don't ask yourself "What file formats should I include.", you should be asking "What file formats am I using." When first starting, don't write your game for flexibility, write it for usability. Rather don't write it so the 3d artist can do use file formats x, y, or z, write it so the artist has to use x (leave y and z unsupported).

As to where to start, if you are the only developer, start where you want there to be the most impact. Lets say you want a game with really great graphics, you should then probably start by learning and setting up your rendering system (DirectX, OpenGL, etc.). Or if you want a realistic physics system, the slap together a simple rendering system and create a couple test dummies and start working on the setting up the physics (NVidia Physx, ODE, Bullet, custom, etc.) In short whatever part you want to be the "selling point" for you game, start with that (and whatever else is like a prerequisite for it), finish it and them do everything else. Also word of advice from someone who has written 3 different games (an f-22 flight simulator, a CoD-like FPS game, and an open-world RPG), never multitask. If you start with the graphics, you should finish the graphics and then move on the the next part.
Some favourite quotes:
Spoiler

#11 Kristoffer   Crossbones+   -  Reputation: 743

Like
0Likes
Like

Posted 09 February 2012 - 11:50 AM

If you need to ask this question then you should probably scale down everything until you know what parts you will need to make "what you want".

I know this sounds very confusing but I would recommend that you start with something like pacman, and when its a playable game try to see what parts the project can be divided into. Then see what different games could possibly be made with those parts.

Now you could try to make a new game (a bit more advanced maybe) and reuse the old structures but also make improvements and adjustments where you earlier code was performing badly.

Now you should be starting to see more and more common elements and can be creating structures that will work good for both kind of games, well now you are a good way to making your own library/engine/framework/collection of structures but most importantly you can vision broadly what elements a certain game could need,

To apply this to a fighter game make a really simple 2d platform game instead.
Blekinge Institute of Technology
Twitter @devmoon
Homepage http://devmoon.se
Stream http://twitch.tv/devmoon

#12 Josh Vega   Crossbones+   -  Reputation: 1098

Like
0Likes
Like

Posted 09 February 2012 - 12:01 PM

To apply this to a fighter game make a really simple 2d platform game instead.


I'm gonna agree somewhat with Kristoffer. Rather than making the actually game you should make a much simpler game. This is where I think our concepts diverge.

Say you want to write a game like the latest Mortal Kombat. Rather than creating the actual game now, maybe you should start with something more along the lines of the original Mortal Kombat and work your way up. You could start with something with only 4 player states (idle, punching, kicking, and dead). Then eventually you can add more moves, like some type of spinning kick and maybe a uppercut punch. Then maybe some sound effects, a main menu, a pause menu, different arenas/backgrounds, more characters, etc. Eventually you'll get to where your original concept was.

NOTE: I have never played any of the Mortal Kombat games but have seen videos and screenshots of it. This was just as an example.
Some favourite quotes:
Spoiler




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS