Elysian Shadows

ok so i would like to know what game engine is truly for and how would i use it with my actual game. or is the engine completly different from the game itself.

A game engine is what makes the game exist essentially. It provides all the components to run/handle the game(i.e. input, output, rendering, etc...). There are two ways, in my view, to create a game. Write code with a specific game in mind and combine that source with your logic for your game and you've technically got an engine, but you won't be able to use it for much else. You could also write an engine by itself which is capable of expanding and changing per whatever project you may be working on while minimizing the amount of code you need to use to write the actual game as you'll be able to use references or calls to the engine in your now separate game code.

Either way, you'll be writing some redundant code, but by going in the mindset of just writing the engine, you can work on working out redundancies and you should be able to add the engine or change things easier to fit what you need.

I'm burning through a book that is walking me through creating an advanced 2D engine that once it's all said and done, I'll have a .dll file that I will include with the source to my games, I will then make calls to that engine to create the game's core components. This will allow me to concentrate more on the actual game than sprite handlers(well DirectX), inputs, etc... instead its a fraction of the code to implement everything and since I already wrote out the long winded and redudant code, I can now go an create the game logic and make it look pretty. Otherwise, I'd have to write out all the DirectX stuff each project, all the windows functions, etc....

Future projects, I can go back into that engine and add functions or improve existing ones based on my needs. Writing the engine hasn't been exciting(aside from the thrill of learning, etc...), but when I get to concentrate on my projects' contents only, then it will be well worth the effort.

Sounds like an interesting read, what book is it exactly???

alright then i have a question, for example almost everygame has a chest right? if u havent played a game with a chest the play zelda, but anyway , so say your character lands on a chest(or activates a chest) and when u land on it the game calls a funcition chest(), does the engine handle\determine what chest u landed on, what is in the chest, and puts whatever is in the chest where it needs to go, so if i land on a chest that contains a sword, the engine is what determines that u landed on a sword chest, and then it puts the sword into you inventory, is that the basic idea????????

eatcomics wrote:Sounds like an interesting read, what book is it exactly???

Advanced 2D Game Development - Jonathan Harbour

http://www.amazon.com/Advanced-Game-Dev ... 337&sr=8-1

Trask wrote:

eatcomics wrote:Sounds like an interesting read, what book is it exactly???

Advanced 2D Game Development - Jonathan Harbour

http://www.amazon.com/Advanced-Game-Dev ... 337&sr=8-1

Thanks for the link

spum wrote:alright then i have a question, for example almost everygame has a chest right? if u havent played a game with a chest the play zelda, but anyway , so say your character lands on a chest(or activates a chest) and when u land on it the game calls a funcition chest(), does the engine handle\determine what chest u landed on, what is in the chest, and puts whatever is in the chest where it needs to go, so if i land on a chest that contains a sword, the engine is what determines that u landed on a sword chest, and then it puts the sword into you inventory, is that the basic idea????????

I would say that the game engine handles the fact that you've clicked on an object (pressed a key, or however you open chest in your game) and where the object is located. The actual game code would take that information from the engine and say "Oh, the player clicked on an object which I recognize as a chest. This chest is supposed to have a sword in it. I will give the player the sword". You can reuse the engine function that checks if an object has been clicked in essentially any game, but the fact that it's a chest with a sword in it is specific to that one game.

dandymcgee wrote:

spum wrote:alright then i have a question, for example almost everygame has a chest right? if u havent played a game with a chest the play zelda, but anyway , so say your character lands on a chest(or activates a chest) and when u land on it the game calls a funcition chest(), does the engine handle\determine what chest u landed on, what is in the chest, and puts whatever is in the chest where it needs to go, so if i land on a chest that contains a sword, the engine is what determines that u landed on a sword chest, and then it puts the sword into you inventory, is that the basic idea????????

I would say that the game engine handles the fact that you've clicked on an object (pressed a key, or however you open chest in your game) and where the object is located. The actual game code would take that information from the engine and say "Oh, the player clicked on an object which I recognize as a chest. This chest is supposed to have a sword in it. I will give the player the sword". You can reuse the engine function that checks if an object has been clicked in essentially any game, but the fact that it's a chest with a sword in it is specific to that one game.

u are the bomb, this is the best response i have gotten, now i know and have an idea of where the engine stops and the game begins, thankyou so much u rock!!!!!

Glad I could help, I hope my response was accurate. I'm sure someone will come along and correct me if I made any mistakes in explaining.

I'll simplify the design of a game (or at least an RPG) for you... with some examples from Elysian Shadows

Usually there's at least 3 parts:

• 1. The game engine. This is the actual executable usually, and it is pretty much the center of the project; none of the other parts would have a point without it. It handles rendering, logic (usually), and contains what you need for the scripting language to work.
  
  2. The scripting language (Lua, in ES). This is what makes the actual content of the game. NPCs, items, AI, etc. Sometimes it could also handle the logic.
  
  3. The utilities (level editor, in ES). These are programs outside of the engine needed to make the game. This could be level editors, NPC designer (if you're too lazy to write out the script ), etc.

Sometimes there could be others, but not usually.

This is the setup ES uses if you didn't figure that out already.

thx for the reply... so ES uses lua to run all the functions that the engine has. is that right?

Just about. Other than the stuff like rendering and logic, yes. However, if you watch the more recent AiGD vids, you can see that they disable the engine's logic and use just Lua... but that's only for "minigames".

so ES uses lua to run all the functions that the engine has. is that right?

Noooot really.

I'll simplify it. Imagine the item system. The engine has items. The player can drop an item from their inventory onto the level, pick it up, throw it around, and put it back without ever touching Lua. The original item might have also been in a chest that was placed with the level editor, so there's no Lua involved.

Using Lua, we can do things with items. For example, if you do a certain quest, I can call AddInventory("item") to add the item to your inventory. The item then becomes a part of the array that the engine handles. It now has physics and all of that stuff, so Lua didn't do anything other than put it in your inventory.

On the other hand, what about when we use the item? Lets say the item is a potion. Each item has a use script associated with it. Say it's a potion. potion.lua may just be something along the lines of Player.hp = Player.hp + 30 to restore the player's HP by 30.

NPCs would be another good example. They can be placed and can exist without any sort of fancy Lua. You can put them on the map with the level editor, and they can say something when you speak to them. Or they can have a custom Lua script where speaking to them can trigger some sort of event or make something else happen. Special NPCs can also have custom AI scripts for special logic, but most NPCs can just use the engine's preset logic.

The engine draws the NPCs, updates the NPCs, and handles/manages them.

Our design theory is not to power everything by Lua. On the contrary, it's actually far less. The C/++ engine handles everything. Lua is used to extend the engine by adding additional flexibility, but it's not the driving force. There are many reasons for this decision. First of all, we are targeting low spec systems, so the more the engine handles, the less heavily we will have to rely on scripting. Secondly, it's easier overall. If every single NPC had to have its own custom lua script with no presets in the engine, it would be pain in the ass. By having the engine able to handle as much as possible, we're speeding up production (making the majority of the game with editor and engine) as well as run time speed (Lua is slower than things happening in the engine).

Despite all of this, as you can see in the recent dev videos, I have put a tremendous amount of effort into giving Lua lots of power. It's true that you can basically do anything in Lua. You can disable the main logic in the engine, and write your own (Mario or Chu Chu Rocket) completely in Lua (engine still stores, draws, and contains players/enemies/items and gets input while Lua is performing actual operations on them).

I had a very complex goal with Lua and the extensibility of our engine. The goal was to be able to do as much as possible with just Level Editor and Engine. So Lua in that regard is minimal. But I also wanted to give Lua a huge amount of power and control over the engine where it's required. For the most part, Lua is doing very little. It's handling special events, updating AI for unique NPCs and enemies, and storyline progression, everything else is engine. But under certain circumstances (minigames, cutscenes, extras, crazy items, anything that we want), Lua can assume complete and total control over the engine.

I know this was an insanely long and drawn out post, but implementing a scripting system is a pretty detailed process. It's up to the designer to determine how much power should be delegated to the script, what should be handled in the engine, what should be laid/handled in the level editor, etc. Our system grew from several months of me working and has been rewritten several times before I found something that I am finally proud of.

And yes, it's very hard to explain. The entire process is abstract. The way that I learned was by doing. Start implementing a scripting language, and you'll start understanding what I mean.

OK. Now that is why you're making ES and not me... Thanks for clarifying things for me. I suppose I had been trying to explain something I didn't fully understand myself.

Ok i get it.. and i understand everything.. thx for the reply, i couldn't have asked for anyone better than the engine programmer of ES himself. But i do have one more question and this is for anyone who is familiar with blitzplus. What would be the best way to handle inventory and equipped items. i've been stuck on it for a while and i just simply can't figure out how to make an item system. thx for any1 who can help me with this.