Jump to content

  • Log In with Google      Sign In   
  • Create Account






So I've been reading about game development...

Posted by studentTeacher, 09 August 2013 · 508 views

....and it's only confused me more and more. This is the sad truth of over-analyzing something that you are working on. I try and try again to figure out the best way to perform a process when I now realize that, heck, this is programming, and there isn't just one way to do things (usually). I need to just go at it, and start coding; the controversial parts that I reach, when I reach them, can be easily solved with a little bit of logic.

For example, I've been thinking about how to factor in user code when they use my game engine. Do I want to write code that allows them to run the engine without knowing any underlying details? Do I want them to have to follow specific patterns and write specific code in every project using this engine, to get things up and running? Which way do I code this? Things are actually much simpler after you write it all out.

It is simple to see that there must be some specific engine-based code that must be called -- otherwise you aren't really able to use that engine! So that cleared that up. As a user of this engine, and other engines as well, I know what it can be like to have to write the same 40 or 50 lines of code to get a specific project started. That can be troublesome, so I decided to keep the specific required code to a minimum. Lastly, I thought about what it is that could make it easiest to make sure one can get the engine running without so much as one or two lines of code, easily found by the JavaDoc for the engine class. The answer was Interfaces!

Using the simple ideas above, the specific, required code for the programmer to write to get the engine running is this:
public static void main(String [] args) {

   //using the game interface (which one would 
   //implement in their application of the Game class 
   //for game logic), one can have the engine run the 
   //game!
   Engine.addGame(new Game());

   //simple as this, to run your game!
   Engine.run();
}
One only needs to include the engine in the libraries folder, and must create a Game class that implements (but does not necessarily write implementation code for) the Game interface, and run this main method. The window context is created and displayed, and you can exit without an error by clicking on the 'x' in the corner of the screen. Presto! Don't get me wrong; this may have you screaming "where's the customization? Are we stuck to your implementation?" Well the answer is no. This is just the necessary code to get the engine up and running. If you want to fine tune or change the way the engine runs, there are module switches that can be called and changed to set up the engine's configuration to what is necessary for your project.

The implementation code in the Engine class is a little more involved, using timers, calculating and capping frames per second, and handing system messages. But with that little bit of effort added to the Engine class, the implementation of getting the engine included and up and running is simple, easy, and effective. Hopefully, if and when people might use this engine, it will be easy to begin using right from the beginning.

That'll be all for now, but I'll be back as I continue designing the engine. I know I had a hard time coming up with a way to effectively work on this engine without analyzing things too much, but now I hope I can help others start such projects, or at least gain some insight to this project of mine. Voxel engine out.

Thanks,
St




I have a question for you. Or more like a hypothetical scenario. Say you want to design a gasoline-fueled internal combustion engine. You want other people to be able to use your engine in their own cars, so you want to design the engine to be as flexible as customizable as possible. But here's the problem: you've been reading about car design and it just confuses you more and more.

 

The issue is that you just don't have a deep enough understanding of auto design in general to allow you to design a truly flexible and powerful engine that can be used in many types of cars.

 

For somebody who isn't very experienced, it is a mistake to start with the general-purpose, all-powerful engine to run a hundred types of cars. Henry Ford, when learning how to build cars, didn't sit down and say "I need this engine to be able to be used by lots of other people to build their own cars, so I have to be sure to design it from the start to be flexible and customizable." He sat down instead and designed to the problem at hand: building a single type of car quickly and efficiently.

 

This is where the mantra "build games, not engines" comes in. It is far, far easier for a less-experienced dev to code to a single game's requirements, than it is for that same dev to code to the requirements of all the hundreds of potential games he thinks his engine might someday be used in. He just doesn't know enough about game engineering in general to solve that kind of sticky problem, not yet.

I have a question for you. Or more like a hypothetical scenario. Say you want to design a gasoline-fueled internal combustion engine. You want other people to be able to use your engine in their own cars, so you want to design the engine to be as flexible as customizable as possible. But here's the problem: you've been reading about car design and it just confuses you more and more.

 

The issue is that you just don't have a deep enough understanding of auto design in general to allow you to design a truly flexible and powerful engine that can be used in many types of cars.

 

For somebody who isn't very experienced, it is a mistake to start with the general-purpose, all-powerful engine to run a hundred types of cars. Henry Ford, when learning how to build cars, didn't sit down and say "I need this engine to be able to be used by lots of other people to build their own cars, so I have to be sure to design it from the start to be flexible and customizable." He sat down instead and designed to the problem at hand: building a single type of car quickly and efficiently.

 

This is where the mantra "build games, not engines" comes in. It is far, far easier for a less-experienced dev to code to a single game's requirements, than it is for that same dev to code to the requirements of all the hundreds of potential games he thinks his engine might someday be used in. He just doesn't know enough about game engineering in general to solve that kind of sticky problem, not yet.

 

 

I understand that I may not have enough experience to just create the engine on its own, and that is not what I am doing. I am creating games alongside the engine, and factoring reusable code into the engine, just like the mantra "build games, not engines". I've made a 2D top-down shooter, a pong games, pac-man, a 3D exploration game surrounding the idea of perspective (that was a tricky one), among others, and a few tools like a voxel editor and some abstract game-logic creators. What I am doing is building the engine's components as they become reused in different applications I make; however, the one thing that annoys me the most is getting things started.

 

That's why I I worked on the entrance of my engine; I have created the beginning of many games, and each one is obviously different. This was just me trying to make a unique and easy handle to the engine, that works for many different games. I've been able to factor this engine's startup into each and every one of these games without any problems, and the flexibility I've seen from it has been greatly appreciated by me. Before this, I could see the reusable code, but even then there's a billion different ways of incorporating a user's code into the engine, and all of them have their pro's and con's. I decided that, instead of using someone else's implementation, I decided that screw it, I'll just come up with something on my own, as I was just analyzing the situation too much.

 

Just to recap, I'm not coding just an engine, but games alongside it. This will not be a generic engine to use, but one that's been at least applicable to the game's Ive made, and hopefully it can continue to grow as I make more games. I'm just trying to show the beginnings of creating a semi-polished game engine that some less experienced game developers might be interested in doing, between the steps of using no game engine to using a full-fledged custom pool of game-reusable code.

 

Sorry for the little tangent; I don't think I'm very good at expressing what I know and what I am trying to learn; I'll be working on my communication as these posts continue. This is an educational experience for me, and I hope I can learn a lot not just from myself, but others on here as well :) The games will continue at a reasonable rate; this engine is just a side project for pooling together reusable code!

 

Thanks,

St

Whilst I think writing an engine is a brilliant learning experience, I personally have fallen into many traps whilst doing so. I have a collection of 15 or so engines, all designed to be flexible and user friendly, with large numbers of features. But none of the games I wrote to test the engines ever got finished, let alone the engine.

 

I recently read a fantastic article, and I would suggest you do to. I'm not saying don't write an engine. But write a game, and see what worked, and what didn't. Then rinse and repeat, learning from the previous game. This way you will be building on a foundation, and making the back end engine better. If you do this with enough different genres, you will be able to see the common features within the games, and then extract them, and focus on them. That way you truly create a flexible game engine.

 

As for the entry point of the engine, what, in a perfect world would you want to do?

 

In case you are interested, the article is here:

http://scientificninja.com/blog/write-games-not-engines

 

Hope this helps,

 

Matt

July 2014 »

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930 31   

Recent Entries

Recent Comments

PARTNERS