DefSP - A starter project with batteries included!

The Defoldmine
#1

The purpose of DefSP is to have a new “blank” project with many features already in place so that gamdevs can focus on the gameplay part of the project when they begin new projects and not spend so much time on other aspects which are needed but not the core gameplay.

This is not yet ready to use, but am posting about it now to get feedback. What would you like to see in a project like this without knowing what’s already in it? All suggestions welcome and useful.

5 Likes
#2

Render scripts and helper modules to handle a camera, screen-to-world transforms, etc., are the number one thing that I spend a lot of time fussing with when I would like to be working on gameplay. I’ve done several different versions and I still don’t have a setup that I’m really confident about, so it’s a fight every time I start a new project.

Defold really needs a good, extensive, UI library to be easy and quick to make games with, but I think that’s way beyond the scope of a template project. Maybe you could include a simple button setup though.

Setting up the broader game organization and UI stuff (menus, a game mode collection proxy, etc. ) is another thing that I always procrastinate about when starting a new project. Working out gameplay is always fun, but it seems like a big hurdle to get from just gameplay to a more complete game that you can start up, press “Play”, pause, resume, die, restart, quit to the menu, quit the game, etc.

It’s hard to say what’s the most universal thing without assuming tons of things about other people’s projects, this is just two cents from my perspective.

Oh, I also have a little module that I use in every project. It’s just some simple math, array, and other random functions, see it here. (round() and sign() really should be in the default math library, but what can ya do :rolling_eyes:)

3 Likes
#3

Most of that is in DefSP so that is good (though needs more polish and iteration before it’s ready for general use).

I sent you an invite to https://github.com/subsoap/defmath would you be willing to contribute those functions to the module there? I’ll be adding a bunch too as this has been on my todo for a while and I agree that the builtins need more but at least we can fill the gap.

5 Likes
#4

Don’t think of my suggestion as of the advertising my own library, but you may want to include UI Router library :slight_smile: If you have more than one screen in a game, you definitely want to have something that will help you to switch between them.

2 Likes
#5

I may switch to that. This is what I’m using for screen switching for now, but it has obvious issues


local screen_collectionproxy_loader = "main:/collectionproxy_loaders#collectionproxy_"


function load_screen(self, screen)
	assert(not self.loading, "Cannot load a screen while another is already loading!")
	msg.post(screen_collectionproxy_loader .. screen, "async_load")
end

function unload_screen(screen)
		msg.post(screen .. ":/script", "release_input_focus")
        msg.post(screen_collectionproxy_loader .. screen, "disable")
        msg.post(screen_collectionproxy_loader .. screen, "final")
        msg.post(screen_collectionproxy_loader .. screen, "unload")
end

function init(self)
	self.loading = false
end

function on_message(self, message_id, message, sender)
	if message_id == hash("switch_screen") then
		load_screen(self,message.screen)
		pprint(message)
		if self.current_screen ~= nil then
			unload_screen(self.current_screen)
		end
		self.current_screen = message.screen
		self.loading = true
		self.start_loading_time = os.clock()
	elseif message_id == hash("load_modal") then
	elseif message_id == hash("unload_modal") then
    elseif message_id == hash("proxy_loaded") then
        msg.post(screen_collectionproxy_loader .. self.current_screen, "enable")
        msg.post(self.current_screen .. ":/script", "acquire_input_focus") -- have to talk to socket not collectionproxy
        pprint(screen_collectionproxy_loader .. self.current_screen)
        self.loading = false
        print(self.current_screen .. " is loaded and it took " .. os.clock() - self.start_loading_time)
    end	
end
#6

Yes, try my library. It solves a couple of important problems:

  • Passing data between screens
  • Decoupling navigation logic from screens (screen doesn’t need to know where to go next, navigation is controlled with a state machine built with pure functions).

I plan to get back to improve the library soon. I have a roadmap with some functions that were suggested by the community:

  • Sync/async loading of screens
  • Saving screen states to the file
  • Animated screen transitions
3 Likes