next »

[sweetfish]

Dear TIG,

a couple of years ago there was a project called Fuel (no, not that Fuel (and definitely not this Fuel)), which sadly never got the attention it deserved. In short; Fuel was a scriptable, multi-platform, 2D game engine with awesome multiplayer support. The project was however put on ice, and soon forgotten. (Fun fact: The developers were the ones that did Teeworlds.)

I did some small games myself for Fuel, before the project was put on ice, and I remember how easy and fast the development was. All the game code went into a script which was written in a language called Squirrel. The application/engine supplied easy to use drawing calls, and ready made sprite handling etc... The nice thing about the multiplayer however, was that when you needed a variable to be synced, you simply declared it using a special type, and optionally how to interpolate it.


Inspired by my memory of this, I have been thinking about resurrecting this project myself, or create something in the same vain. First of all I would like to hear if there would be any interest at all for this sort of engine?

I'm also interested in what features you, as a multiplayer 2D game developer, would require/like to see in such engine?

I realize my description of the old Fuel-project might not be the best, so if anything is unclear, let me know and I'll try to explain better.

[Danmark]

There's interest here. Sounds like a cool and totally worthwile project, hope you find time to get it done.

I'd want to see support for both C/S and P2P models. That's all I can think of now.

[michael]

[sweetfish]

There's interest here. Sounds like a cool and totally worthwile project, hope you find time to get it done.

I'd want to see support for both C/S and P2P models. That's all I can think of now.

Ah, I guess both topologies are possible, however, initially I will focus on C/S. Regarding the network, I currently have my eyes on RakNet, and from what I can tell by the IndieLicense it should be alright.

From reading the overview, this is a perfect example of a game that could be done in this engine.

Also, forgot to mention; As for the language of the games, will probably be written in Lua, instead of Squirrel (which Fuel used).

[michael]

From reading the overview, this is a perfect example of a game that could be done in this engine.

[Saint]

Speaking of Teeworlds, why not just use their source? it's free and available for download on their site.

[sweetfish]

Speaking of Teeworlds, why not just use their source? it's free and available for download on their site.

Sure, the Teeworlds source could have some great parts/snippets that could be used, but not the engine as whole. It's kind of the challenge of building the engine itself that drives me.

[michael]

i dont know where you are in the process, but at some point i would like to start a discussion about how it could be used for battle in the heart. there's still a lot that needs to be figured out gameplay wise but i was wanting to know where it would be made before i started that.

[sweetfish]

I'm in the process of figuring out how the game scripts should be built, what they should contain and how to make the object synchronization work smoothly and transparently. I do have some ideas that I'm testing at the moment, but it's very important to get a solid foundation to avoid major changes to the script functionality later on. As soon as I have draft of how a game script could look, I'll post it. I wanna know what you guise think, and what features you would want etc..

Fortunately I have the old Fuel source, and a couple of old game scripts for it, so I'll be studying them to see if I can borrow some ideas.

Also, I'll be going away on vacation this saturday, so I wont be able to code for a while. But as soon as I get back I'll try to prototype it.

[nihilocrat]

Have you got any links to a website for the engine? A cursory Google search is full of links for the games you mentioned.

Sounds really powerful, being able to simply tag stuff as syncable and then having a multiplayer game is something a lot of engines lack.

[sweetfish]

Have you got any links to a website for the engine? A cursory Google search is full of links for the games you mentioned.

Sounds really powerful, being able to simply tag stuff as syncable and then having a multiplayer game is something a lot of engines lack.

For my engine, or for the orginal Fuel engine? I know teetow dug up an old site for Fuel, but there isn't much information on it, yet alone any builds available.
As my project is just in the planning stages, I don't have any more info available... I have however though of a workname for the project; ReFuel, or perhaps ReFueled

[sweetfish]

Alright, here is the first draft of what a game script could look like.

(Also here: http://codepad.org/NtZaIV9f with better syntax highlighting.)

Code:

require "refuel"

TestGame = inherit(Game)
CClient  = inherit(Client)

-- Game info
game = {}
game.name      = "TestGame"
game.author    = "Sven Andersson ([email protected])"
game.version   = 1
game.enginever = 1
game.web       = "http://md5.se/refuel"

---------------------------------------------------------------------
--- Client specification
---------------------------------------------------------------------

--- Init method for each client
--- also specifies synced data.
function CClient:init()
	-- sync_data = {}
	SyncData.Add("x", "decimal", { interpolate = "linear", default = 0.0 })
	SyncData.Add("y", "decimal", { interpolate = "linear", default = 0.0 })
	SyncData.Add("is_cool", "bool", { default = true })
end

---------------------------------------------------------------------
--- Shared
---------------------------------------------------------------------

--- Some local data
my_bool        = true
my_number      = 123.45
my_table       = {}
my_spriteindex = 0

--- Init game
function TestGame:init(is_server)
	-- Initiate gamedata
	my_table[0] = "Hello!"

	if (is_server) then
		-- If this is the server,
		-- do server specific inits here...
		my_table[1] = "Only server has this table field, he he! :3"
	end
	
	-- Call same method for base class in case
	-- there is any underlaying magic...
	self:super():init(is_server)
end

-- Load game resources
function TestGame:loadContent(is_server)
	-- Lead textures, sound etc..
	gfx.resAddTexture("path_to_file.png", "texture_id_here")
	gfx.createSpriteMap("texture_id_here", "spritemap_id_here", 16, 16, 32, 32)

	if (is_server) then
		-- If this is the server,
		-- do server specific resource loads here...
	end
	
	self:super():loadContent(is_server)
end

--- Draw game
function TestGame:draw(remoteclients, localclient)
	-- Draw each frame! :)
	gfx.quad(localclient.x, localclient.y, 50, 50)
	gfx.sprite("texture_id_here", 40, 40)
	gfx.spriteMap("spritemap_id_here", my_spriteindex, 40, 70)
	
	-- NOTE: Draw method in base class could possible handle
	--       buffer swaping and additional basic graphics
	--       related actions.
	self:super():draw(remoteclients, localclient)
end

---------------------------------------------------------------------
--- Server functions
---------------------------------------------------------------------
function TestGame:updateServer(clients)
	-- Integrate game
	-- (update all synced game objects)
	
	-- Iterate clients
	for i,client in ipairs(clients) do
		-- Check actions that was performed ( = sent from clients)
		if (client.hasAction("up")) then
			client.y = client.y + 1.0
		end
	end
	
	-- The server could output debug info to the engine console,
	-- if the engine is built with game debug lib.
	debug.console.write("updateServer got ", #clients ," number of clients!")
	
	self:super():updateServer(clients)
end

---------------------------------------------------------------------
--- Client functions
---------------------------------------------------------------------
function TestGame:updateClient(player, remoteclients)
	-- Integrate game
	-- (update all local non synced game objects,
	--  and send client actions)
	my_spriteindex = my_spriteindex + 1
	if (my_spriteindex >= 256) then
		my_spriteindex = 0
	end
	
	-- Check keys (or mouse), and send if we got a valid action
	if (keys.isPressed("up")) then
		sendAction("up")
	end
end

Easy to follow? What do you think about the CClient-part, and how the synced vars are created/added? Suggestions, or if something is unclear, please let me know!

[Danmark]

Looks nice to me. How would you specify server-side variables that must be synched?

[sweetfish]

Looks nice to me. How would you specify server-side variables that must be synched?

Hm, I'll have to think about that, but there will be options to send data by yourself so something like this could work:

Code:

...

--- Init game
function TestGame:init(is_server)
	var_on_both = "hello server and client"

	if (is_server) then
		var_on_server = "only on server"
	else
		var_on_client = "only on client (not synced)"
	end

	self:super():init(is_server)
end

...

Then when we want to send he server var to the clients:

Code:

...
	net.send("some_label", var_on_server, "string", nil) -- nil for all clients
...

Another approach would be to also have something like the CClient, as in the first draft for the server, and specify synced server vars. I didn't realize it earlier, but synced and predictable server vars could be used for example moving platforms etc. that don't really belong to any specific client.