Things i have to know if i want to make a game engine in CC

I thought about making an game engine (a VERY simple one) for fun in CC. But i dont know if this will be an success and which tools i can use to do it. Should i use and framework from someone else, watch videos about game engines in non-CC or look at some existing engines like godot?

Engine: 5SSWtBTz
Gamestarter: m84mxdx5
Warning: The pastebins will change, and only the github is up to date anytime!

Github: it is here

CC is not very fast. Using a framework is a bad idea for the performace. If you look at another game engine, choose a engine in lua.

i knew the performance would become a problem…
Do you mean i should take a look at löve, the 2d game engine? I have coded very much with it.

This is hard to answer without knowing why you want to make a game engine?

If you're making something within CC, there are a few engines, although I've never used them so can't comment on their usability. It's entirely up to you whether you make your own.
If you're making something for the real world, don't use CC. If you want to roll your own engine, it won't be simple, so use something else like Love or Godot (or UE4 which is amazing).
If you're doing it for the practise/fun, then of course make an engine. CC is a good start because of its simplicity, although the graphical limitations can be annoying.

Wilma456, on 28 May 2017 - 12:27 PM said:

CC is not very fast. Using a framework is a bad idea for the performace. If you look at another game engine, choose a engine in lua.

Since when are frameworks inherently slow? If you use a good enough framework, it'll hopefully make optimisations that actually *improve* performance, as well as making things easier for the developer.
The issue is CC being slow. If you're wanting to do advanced 3D rendering and physics and AI, it's clearly not a good choice. However, if you're wanting to use CC at all, it's unlikely those will be on the TODO list, and it's still remarkably fast (you can add numbers together a few hundred million times in a second on my laptop)

@OP: Perhaps you could make a text adventure engine, the performance issues that CC will have will be easier to hide then.

Exerro, on 29 May 2017 - 08:32 PM said:

This is hard to answer without knowing why you want to make a game engine?

Making a game engine in CC is a bit more useful than making an OS, though, both are good at teaching various aspects of programming and Lua. Perhaps the OP just wants a project to work to guide their learning.

Lupus590, on 29 May 2017 - 10:07 PM said:

Exerro, on 29 May 2017 - 08:32 PM said:

-snip-

Making a game engine in CC is a bit more useful than making an OS, though, both are good at teaching various aspects of programming and Lua. Perhaps the OP just wants a project to work to guide their learning.

Yeah, I definitely agree that it's a good idea to do at some point. I was just asking to narrow down the purpose of the engine, not questioning his choice. It's important to have a fairly detailed outline of what an engine will do and why before making it, or you'll end up lost in a maze of useless features that don't tie together.

People keep commenting on performance, but should really know that CC can handle a lot before lagging as long as you're writing good code. There are plenty of games on the forums that back this up.

Exerro, on 29 May 2017 - 08:32 PM said:

This is hard to answer without knowing why you want to make a game engine?

If you're making something within CC, there are a few engines, although I've never used them so can't comment on their usability. It's entirely up to you whether you make your own.
If you're making something for the real world, don't use CC. If you want to roll your own engine, it won't be simple, so use something else like Love or Godot (or UE4 which is amazing).
If you're doing it for the practise/fun, then of course make an engine. CC is a good start because of its simplicity, although the graphical limitations can be annoying.

Wilma456, on 28 May 2017 - 12:27 PM said:

CC is not very fast. Using a framework is a bad idea for the performace. If you look at another game engine, choose a engine in lua.

Since when are frameworks inherently slow? If you use a good enough framework, it'll hopefully make optimisations that actually *improve* performance, as well as making things easier for the developer.
The issue is CC being slow. If you're wanting to do advanced 3D rendering and physics and AI, it's clearly not a good choice. However, if you're wanting to use CC at all, it's unlikely those will be on the TODO list, and it's still remarkably fast (you can add numbers together a few hundred million times in a second on my laptop)

I am doing it for fun and for learning CC, lua and game design. And to bring CC to its limits. :D/>

As I already said, I would advise making a text adventure engine. You could even look at how the built in adventure program works.

I'd suggest a top-down RPG. You'll deal with simple collision detection, rendering, inputs, and general gameplay things like inventories and stats, character interactions, objectives/achievements, and world design. Then maybe a side view voxel physics game or something projectile based.

I will try the text adventure engine, and maybe the top-down RPG engine too. Sounds like a good way to start for me. Lets code! Wait… A card game engine sounds cool too…

I thought about the text adventure thing, but i cant realy see were to start. There are many text adventure genres, like DOS, RPG, survival and so on.

Jummit, on 31 May 2017 - 07:38 AM said:

I thought about the text adventure thing, but i cant realy see were to start. There are many text adventure genres, like DOS, RPG, survival and so on.

Are you making a game engine or a game? Game engines are a framework which shouldn't make any assumptions on what the game will be about. Game engines are not something that are playable on their own (I.e. the require a game to be implemented on top of them).

You can make a game without making an engine (sort of, you technically make an engine which is specialised to that game), this may be more interesting and rewarding.

Lupus590, on 31 May 2017 - 11:56 AM said:

Jummit, on 31 May 2017 - 07:38 AM said:

I thought about the text adventure thing, but i cant realy see were to start. There are many text adventure genres, like DOS, RPG, survival and so on.

Are you making a game engine or a game? Game engines are a framework which shouldn't make any assumptions on what the game will be about. Game engines are not something that are playable on their own (I.e. the require a game to be implemented on top of them).

You can make a game without making an engine (sort of, you technically make an engine which is specialised to that game), this may be more interesting and rewarding.

I am making a game engine, but if i make an engine specified on a game the engine is (in my opinion and in CC) useless. I have started the topdown thing:

the dragon and the tileset is animated

PS: how can i make an animated image in this post?

just give an image link that is an animated picture (such as .gif or .gifv)

TheRockettek, on 31 May 2017 - 03:23 PM said:

just give an image link that is an animated picture (such as .gif or .gifv)

how can i make animated gifs in imgur?

I decided to make a main loop, in wich the draw, update and at the beginning load, are called. I decided it because it is hard to make animation while an event listener is waiting. There will be an key_pressed(key), a draw() and a update(dt) function like in löve –> https://love2d.org/wiki/love.run.

Ideally, the engine itself would handle things like animations, but I guess that approach works too.

If you want to make animated gifs, use something like ShareX. You can record a region of your screen and it automatically uploads it so you can just paste a link in here.

Exerro, on 01 June 2017 - 06:24 PM said:

Ideally, the engine itself would handle things like animations, but I guess that approach works too.

If you want to make animated gifs, use something like ShareX. You can record a region of your screen and it automatically uploads it so you can just paste a link in here.

My engine has animation support. You can create one easily with making a sprite with a table with images as image.
PS: Thanks for the 'animated gif help'!
EDIT: Oh, i am on linux, so i cant use ShareX. Wine cannot do it. :(/>

Oh, right, linux. I think there are some tools but I never had much luck with them. If you dual-boot, you could get it on windows and boot into windows to record stuff. It's a pain but might be worth your time for some things.

Exerro, on 01 June 2017 - 06:42 PM said:

Oh, right, linux. I think there are some tools but I never had much luck with them. If you dual-boot, you could get it on windows and boot into windows to record stuff. It's a pain but might be worth your time for some things.

I have a good program for screen capturing and i can convert it to gif.

Hey! I just got an idea: Make a card game engine monitor compatible, so you can make an flat monitor and play poker on it! But then the color would be a large pain. Is there any brown-white color in the palete?

If you want to capture within ComputerCraft, specifically, there's always RecGif.

Jummit, on 01 June 2017 - 02:15 PM said:

I decided to make a main loop, in wich the draw, update and at the beginning load, are called. I decided it because it is hard to make animation while an event listener is waiting.

The idea is to have your event listener listen for timer events, as generated by os.startTimer().

Jummit, on 01 June 2017 - 06:52 PM said:

Is there any brown-white color in the palete?

You can see the default palette here; it's pretty much the same as Minecraft's wool colours. An upcoming version of the mod promises to add a customisable palette.

Bomb Bloke, on 02 June 2017 - 12:26 AM said:

If you want to capture within ComputerCraft, specifically, there's always RecGif.

Jummit, on 01 June 2017 - 02:15 PM said:

I decided to make a main loop, in wich the draw, update and at the beginning load, are called. I decided it because it is hard to make animation while an event listener is waiting.

The idea is to have your event listener listen for timer events, as generated by os.startTimer().

But i thought it only counts the time since the timer is started? How does this work with events?
PS: How do you get words to be links?

I think he meant that you have an event listener that handles all events, then queue a timer every 0.05 seconds. The event handler would then get the timer event and update whichever animation needed updating.

To make things into links, highlight it and press the link button in the editor. It looks like this:

Exerro, on 02 June 2017 - 02:08 PM said:

I think he meant that you have an event listener that handles all events, then queue a timer every 0.05 seconds. The event handler would then get the timer event and update whichever animation needed updating.

To make things into links, highlight it and press the link button in the editor. It looks like this:

Thanks. I will use the parallel or coroutine api, so i can make an event listener whilst everything else can do what it wants to do. I always think of making a move() function for sprites, which moves the sprite if you press the up/down/left/right key. But it doesnt feel right…

Should we leave and expand this post in the 'Games' section? It is on github (here) now…
NO, BECAUSE I ASK QUESTIONS ABOUT PROGRAMMING A GAME ENGINE HERE. (ASK a pro)

Eurgh, coroutines are one way of doing it, but I'd advise against it. Everything I've ever made in a game that would've had some kind of parallelism I handled with event callbacks, and I can't think of any reason you'd need more than just that. For example, imagine a 2D platformer. Every frame, you fire an "update" event, which does physicsy stuff like gravity, collisions, and so on. Then a "draw" event, which draws stuff. When the player presses one of WASD, fire a "move" event with the direction. Animations can be handled with timer events.

Looking at the wikipedia definition of a sprite, I'd say you should be able to reposition them. I guess look at other engines and see how they handle it. I wouldn't tie it directly in with key presses though.

The Programs section (and all sub-sections) are for working code only. Discussions generally go in General. You could probably use GitHub issues to discuss things too.

Exerro, on 02 June 2017 - 03:55 PM said:

Eurgh, coroutines are one way of doing it, but I'd advise against it. Everything I've ever made in a game that would've had some kind of parallelism I handled with event callbacks, and I can't think of any reason you'd need more than just that. For example, imagine a 2D platformer. Every frame, you fire an "update" event, which does physicsy stuff like gravity, collisions, and so on. Then a "draw" event, which draws stuff. When the player presses one of WASD, fire a "move" event with the direction. Animations can be handled with timer events.

Looking at the wikipedia definition of a sprite, I'd say you should be able to reposition them. I guess look at other engines and see how they handle it. I wouldn't tie it directly in with key presses though.

The Programs section (and all sub-sections) are for completed code only. Discussions generally go in General. You could probably use GitHub issues to discuss things too.

But how can the timer help me prevent the sleeping which is created by the timer listener? :(/>

EDIT: OOH! I get it! The start_timer function thing creates an event which is called when the time has ran out. Called with the pullEventRaw function it all makes sense! Cool. I didnt know that.

I added the main loop now. Progress has been made! Love to work on this projekt. Its soo cool! :wub:/>+ :)/> = :D/>

Jummit, on 01 June 2017 - 02:15 PM said:

I decided to make a main loop, in wich the draw, update and at the beginning load, are called. I decided it because it is hard to make animation while an event listener is waiting. There will be an key_pressed(key), a draw() and a update(dt) function like in löve –> https://love2d.org/wiki/love.run.

Wow, i acutally did it! I can now run programms with

 playgame <game> 

. In the game i have to load the engine. I can declare the load, update, draw and many other functions. You can make event callbacks which are called when an event is called in the main loop.

cool
Its on pastebin now, but no one cares about it because it is way to early in the morning ^_^/> .
Engine: 5SSWtBTz
Gamestarter: m84mxdx5

Github: it is here

Just wanted to mention you should start with a screen buffer if you're making an engine for more advanced games in CC. Good luck coding!

Xelostar, on 03 June 2017 - 07:29 AM said:

Just wanted to mention you should start with a screen buffer if you're making an engine for more advanced games in CC. Good luck coding!

Can you short explain what a buffer does, english is not my first language :(/> .

I wonder where to beginn now. I have the basics, but what next?
EDIT: Ah, Inventorys and variable displays. Maybe achievements

Jummit, on 03 June 2017 - 07:46 AM said:

Xelostar, on 03 June 2017 - 07:29 AM said:

Just wanted to mention you should start with a screen buffer if you're making an engine for more advanced games in CC. Good luck coding!

Can you short explain what a buffer does, english is not my first language :(/> .

A buffer is a place where where things are temporarily stored before being moved elswhere or processed. A screen buffer, in CC, is usually a terminal object and it is used to generate the frame before blitting, or 'pushing', the entire buffer to the real screen.

Lupus590, on 03 June 2017 - 06:59 PM said:

Jummit, on 03 June 2017 - 07:46 AM said:

Xelostar, on 03 June 2017 - 07:29 AM said:

Just wanted to mention you should start with a screen buffer if you're making an engine for more advanced games in CC. Good luck coding!

Can you short explain what a buffer does, english is not my first language :(/> .

A buffer is a place where where things are temporarily stored before being moved elswhere or processed. A screen buffer, in CC, is usually a terminal object and it is used to generate the frame before blitting, or 'pushing', the entire buffer to the real screen.

Well explained! :)/>

Just one more thing to add:
Why you want to use a buffer: haveing a way to have a UI without any flickering (UI parts being drawn over each other really fast). You would want everything you would want to be loaded on a screen to be loaded into the buffer and afterwards the buffer should be drawn on the screen. You would need to create your own functions for paintutils.drawFilledBox() etc.

Xelostar, on 03 June 2017 - 11:05 PM said:

Lupus590, on 03 June 2017 - 06:59 PM said:

-snip-

Well explained! :)/>

Just one more thing to add:
Why you want to use a buffer: haveing a way to have a UI without any flickering (UI parts being drawn over each other really fast). You would want everything you would want to be loaded on a screen to be loaded into the buffer and afterwards the buffer should be drawn on the screen. You would need to create your own functions for paintutils.drawFilledBox() etc.

Not necessarily. If you create some way of redirecting to the buffer, all the standard term functions will work. Paintutils uses term, so everything'll work naturally.

Buffers are really important though. I'd recommend using an existing library to help you out (like Surface2, which also adds in images and advanced graphics functionality) if you've never made one before. There's also the window API, although it's notoriously slow so maybe make your own. Seeing the code behind it might help however.

Exerro, on 04 June 2017 - 10:12 AM said:

There's also the window API, although it's notoriously slow so maybe make your own. Seeing the code behind it might help however.

I honestly don't see that it has that much room for improvement. My only gripe is that you can't query window content in any way - not that that's something I even want to do on a regular basis.

Bomb Bloke, on 04 June 2017 - 10:16 AM said:

Exerro, on 04 June 2017 - 10:12 AM said:

There's also the window API, although it's notoriously slow so maybe make your own. Seeing the code behind it might help however.

I honestly don't see that it has that much room for improvement. My only gripe is that you can't query window content in any way - not that that's something I even want to do on a regular basis.

I'm fairly sure it stores 3 strings per line: one for characters, and two for colours. This works quite well if you're drawing longer lines and makes blitting to the screen a bit faster, but if you're drawing lots of individual/smaller groups of characters (something I'd suggest happens a lot in a game), that means a lot of string manipulation, which Lua doesn't like so much. Compared to an array of pixels, where changing a pixel is just a settable instruction per component, the multiple calls to string functions (albeit native functions) is much slower.
I think it's good for general term things, but not tuned for game graphics.

Edit: I think it's also the combination of paintutils and window commonly being used together. Paintutils draws individual pixels for rectangles (seriously Dan?) so that is a major issue for window performance, as mentioned above.

Have you actually tested the speed difference betweeen the two options? String-per-line allows you to blit directly as soon as the buffer is instructed to draw. String-per-character has to either concatenate (width - 1) * 3 times per line or it has to draw by individual characters (extremely slow). I seem to recall speed tests supporting string-per-line, but I can't remember the topic title at this point.

Wow, you had a grand conversation here! I can realy learn many things from this. Thank you! But sadly, maybe i have an other projekt in java now, and i will not code very much here… But i will come back!

Lyqyd, on 04 June 2017 - 05:11 PM said:

I can't remember the topic title at this point.

I wanted to change the topic title to something like things i have to know if i want to make a game engine, but i dont know how to do this…

Jummit, on 04 June 2017 - 05:26 PM said:

I wanted to change the topic title to something like things i have to know if i want to make a game engine, but i dont know how to do this…

go to your original post, click on edit, click on use full editor, you can change the tilte near the top.

Lyqyd, on 04 June 2017 - 05:11 PM said:

Have you actually tested the speed difference betweeen the two options? String-per-line allows you to blit directly as soon as the buffer is instructed to draw. String-per-character has to either concatenate (width - 1) * 3 times per line or it has to draw by individual characters (extremely slow). I seem to recall speed tests supporting string-per-line, but I can't remember the topic title at this point.

Yep. Multiple times. Screen blitting is quicker with string-per-line but internal drawing is quicker without. Games (I would argue) draw internally more than to the screen, making that a better option. I've made quite a few graphics frameworks that got much higher performance with internal drawing and comparable performance drawing to the screen by using a single array with non-unique tables for pixels.

Lyqyd, on 04 June 2017 - 05:11 PM said:

String-per-character has to either concatenate (width - 1) * 3 times per line or it has to draw by individual characters (extremely slow)

Or use a localised table.concat. Which is pretty damn quick. Even quicker if you have a table-per component so the text side of things is just table.concat( text_buffer, lower, upper ) for each line, although that provides various drawbacks for the internal rendering.

Internally, table.concat is still length - 1 concatenation operations. Perhaps some games have enough screen churn that tables of tables of characters make sense, but you'd need to be packing quite a few changes into each frame, which sounds like a game that would be something other than enjoyable to look at. Most normal uses will be better served by tables of lines. Of course, you should use whatever buffer system makes you happiest. As long as it gets the job done, it doesn't matter how it does so. :)/>

Lyqyd, on 06 June 2017 - 05:02 PM said:

Internally, table.concat is still length - 1 concatenation operations.

It's not the same thing as using Lua's regular concatenation operator, though (..) - that's much slower, if you ignore the time lost making a function call in order to use table.concat.

Once you've got more than about a dozen entries to combine, using .. takes more time than the call does, so table.concat() really does win out on all but the smallest of sets… at least, it does in ComputerCraft.

In terms of buffering, whether to put off concatenation until render time is all very situational. Factors include the length of your average write, how many lines are affected per frame, how many writes are performed each frame… with BLittle's buffering system, I actually use both techniques. Each screen position gets its own table index, but I also store by line, so that I don't have to concat unchanged rows at render time (or perform the other load of processing BLittle does to "shrink" pixels, for that matter).