next »

[makerimages]

Cool! I approve! 

[makerimages]

Pioneers has been oiled up! No really!  I just started a game news,-reviews and all things gaming related news blog, called GameOil and Pioneers is the FIRST game to be reviewed there!
Enjoy the reading:
http://wp.me/p4a24Q-n

Ps:GameOil needs writers.

[Eigen]

Apart from typos and a little layout issue at the top it's pretty great, I guess. The overview is very generous. Thanks. Hopefully this won't be a one-off thing and you'll do more write-ups.

The oiling bit makes me a bit uncomfortable though.

[kleiba]

Hopefully this won't be a one-off thing

...or, like, a four-off thing

The oiling bit makes me a bit uncomfortable though.

Come on, Eigen... you know you like it... ;-)

[Eigen]

Come on, Eigen... you know you like it... ;-)

You caught my bluff.

[makerimages]

Apart from typos and a little layout issue at the top it's pretty great, I guess.

What layout issue? All seems fine on my end...

[Eigen]

Apart from typos and a little layout issue at the top it's pretty great, I guess.

What layout issue? All seems fine on my end...

[Eigen]

Streaming some pixelwork right now. Redrawing forest tiles to fit the autumn season. After that I might work on diseases and injuries. Bring your favourites

Join the stream here

[makerimages]

Oh, yeah that..... nothing much I can do about that. Sorry for the late reply

[Sub]

If you choose a screen size which is larger than your monitor, the program disappears and you either need to mess with the data or reinstall to get the screen to start appearing again.

Using std::min should fix the problem.  Something like this:

MainWindow.create(sf::VideoMode(std::min(sf::VideoMode::getDesktopMode().width, DEFAULT_SCREEN_WIDTH), std::min(sf::VideoMode::getDesktopMode().height, DEFAULT_SCREEN_HEIGHT), 32), ProgramTitle, sf::Style::Close);

The formatting gets messed up when I paste it, but you get the idea.

[Eigen]

If you choose a screen size which is larger than your monitor, the program disappears and you either need to mess with the data or reinstall to get the screen to start appearing again.

Fixeth!


I'm streaming some LUA integration right now if anyone cares to join in. Might mockup some native interaction screens or start tinkering with those language symbols which is prety much the next key feature I want to implement.

[eigenbom]

Ooh LUA sweet. :D

[Eigen]

Indeed. I'm porting some of the hard-coded game logic to script and that requires exposing quite a lot of game functionality. I just go line by line and add any new method I need. Bit tedious but it works and will come quite handy, I'm sure.

So (C++)

Code:

sf::IntRect viewportRect = G->getViewport()->getRect();

sf::Vector2f pos = sf::Vector2f(
	SCALE(StoreLocation[currentTownIndex].x) - (viewportRect.width / 2),
	SCALE(StoreLocation[currentTownIndex].y) - (viewportRect.height / 2));

G->getViewport()->animateMoveTo(pos, 16, 0.002f, VIEWPORT_ANIM_GOTO_SUPPLY_STORE);

clearAllWindows();

becomes (Lua)

Code:

local viewportRect = viewport:getRect()
local storeCoordinates = StoreCoordinates[(town:getTownIndex() + 1)]
local viewportCenterCoordinates =
	Vector2:new(utils:scale(storeCoordinates.x), utils:scale(storeCoordinates.y)) -
	Vector2:new(viewportRect.width / 2, viewportRect.height / 2)

viewport:animateMoveTo({
	x = viewportCenterCoordinates.x,
	y = viewportCenterCoordinates.y,
	id = utils:calculateHash("vportAnimStore")
});

clearAllWindows()

I have to see if there's a way to pass my custom data type (Vector2) to methods directly rather than to separate fields (x & y) but since they're all inheritly tables, it should be doable. Then I could write some code to automate the sf::Vector2<T> to Vector2 conversion and same with rectangles.


This is how I define my new data type:

Code:

Vector2 = {} 

setmetatable(Vector2, {
    __index = Vector2;
    __add = function(a,b) return Vector2:new(a.x + b.x, a.y + b.y) end;
    __sub = function(a,b) return Vector2:new(a.x - b.x, a.y - b.y) end;
    __tostring = function(a)
		return "Vector2: {"..a.x..", "..a.y.."}"
	end;
})

function Vector2:new(prmX, prmY)
    return setmetatable(
	{
		x = prmX or 0,
		y = prmY or 0
	},
	getmetatable(self))
end

Still needs multiplication and division.

[eigenbom]

Cool, I love details! Maybe my next game will have some nice Lua, but c++11 can be pretty succinct these days. What's your plan for the Lua-side? The code you gave seems fairly low-level, do you want your scripts to have such fine-grained control?

I can imagine an API that just generates game events, triggers anims, and maybe handle the gui stuff. Something like:

Code:

-- pseudo-Lua
module gui
function button_clicked(button)
  if (button.name=="store") then
    local anim = Animate:sequence([
       Animate:move_to(Game.current_city["store"].position, 2),
       Animate:function(Game.ui:enable),
       Animate:function(Game.ui:show_building_ui, Game.current_city["store"])
    ]);
    Game.ui:disable();
    Game.camera:animate(anim);
  end
end

And a new entity script may look like:

Code:

module peasant

module_type = Entity

function create_at(pos)
  local n = ["Barry", "Harry", "Larry"][random(3)]
  return new Entity{
    position = pos,
    name = n,    
    idle_timer = 0,
  }
end

function update(peasant)
  peasant.idle_timer += 1
  if peasant.idle_timer>5 then
    Events.add(Event:move(peasant, vec2.random(0, 1))
    peasant.idle_timer = 0
  end
  if (random()>0.9) then
    Events.add(Event:say(peasant, "I'm hungry"))
  end
end

Anyway, I'm interested to see where this is heading.

[Eigen]

I think I've mentioned it in the devlog before but I should've incorporated LUA right in the beginning of the project, possibly using an SFML binding (if one exists) or writing it myself. Then the only bits I would've hardcoded were the resource management, UI elements and maybe other solid things.

I like having the game logic scripted as it makes changing things easier and also allows modding at a very deep level. I'm in the process of porting certain bits of the game starting with the town, more precicely the supply store implementation (data + gui). If that works out well I'll port over the rest of the town (that's where the style of the code comes from - I'm simply interfacing classes and methods as they come). And if that works out too other parts of the game will follow.

Scripted UI is something I'm seriously considering since it would make binding "button pressed, list item selected, etc." code so much simpler. Right now the dozens and dozens of button ID checks all in one event handler is really messy.

But that's at least a few months worth of work and little content progess meanwhile ... would I ... should I ...  

Bleh.



But I keep thinking that if it were easy to modify and change things around someone will make something cool out of it, something I couldn't come up with, taking the game to great new places. Or am I dreaming?

[eigenbom]

My honest and maybe too pessimistic opinion is no: people won't make awesome things with it. With that in mind, is scripting something that offers you value, or can u just as easily do those things in c++ if you clean up and refactor a little bit?

I say this because of a few reasons:
- I think games are somewhat commoditised these days, and the best most of us can hope for is our 5 minutes on the front page of steam (rather than an enthusiastic and creative community),
- there are loads of moddable sandboxes out there,
- it's very easy to make your own games these days instead of modding an existing one,
- we need more single player story driven indie games, and
- you're only one guy with limited time.

A compromise could be to make a tool for creating scenarios, which you would then use to build the stories in the main game, but give it some flexibility so users can make their own.

[kleiba]

Hey Eigen & Bom,

I find this a very interesting discussion, mostly because I'm a newbie myself. I never quite understood what would be a good reason for having substantial parts of the game in a scripting language like Lua. A while ago, I read that an early motivation for having a scripting language on top of the game engine was to give (graphic and animation) designers more freedom of expression: scripting languages are typically simpler than C++ and, if interpreted, there is no need for complicated recompiling.

But I still don't quite get why you as developers proficient in C/C++ etc. are excited about Lua as well. Is it mostly the faster turn-around time when testing quick changes (again, by not having to recompile for every little change)? Or are there additional points that I just haven't grasped yet?

Modding is certainly a factor that has become more important in recent years. But similarly to the above, while there's good reason for the developer to include a modding interface for the users, it's nothing that would get a developer excited for their own work on the game...

[eigenbom]

@kleibs happy new year Thomas!

From a solo dev perspective, I think Lua will give you:

* the ability to change logic without recompiling! But with enough structure a small change in a c++ module shouldn't take too long to recompile (10-20 seconds for me.)

* a succinct and flexible language to work with, you can quickly specify tables (dictionaries) and functions etc., in a way that used to be hard in c++, but is becoming much easier. For example, yesterday I was building a toy entity system in c++11 and I had code like:

Code:

e.add(new Inventory{
  {Item::Sword },
  {Item::Axe },
  {Item::Arrow, 30}
});

Which is unbelievably succinct for c++. And the same also holds for lambdas etc.

* But I think the real power of having a Lua VM running in your engine is that, if done properly, you can change Lua code while your game is running. I'd love to be able to click a monster in my game, open up an editor, change some lines of code, and then instantly see the results. This requires quite a bit of setup to get working properly, but engines like Bitsquid seem to have it working well.

* And then there's the whole modding thing which you understand already. Games on this forum (e.g., Crea) have made modding a strong feature. The attraction, I think, is that someone is going to come along and make something awesome with your game. Counter Striker, Gary's Mod, Elder Scrolls, Neverwinter Nights, Minecraft, etc., all demonstrate what is possible. Minecraft didn't have a modding system, whereas Neverwinter Nights had a very flexible and extensive one. I'm sure many games are out there which have strong modding support, but unfortunately aren't fun enough to attract the modders in the first place.

Sorry for hijacking, Eigen. :|

[kleiba]

Happy New Year to you, too, Ben!

Thanks for the long explanation. Yeah, I guess that pretty much reinforces my understanding so far, plus raises a good point with hot swapping code. I know that some compiled languages like Java support that as well, but that runs in a VM, and of course, everyone hates Java (not me though :-)).

A lot of programming languages have been making more or less successful attempts at becoming more succinct in recent years. I guess they feel the pressure coming from Python, Ruby, and the likes. Having hash maps as primitives and syntax for easy list construction is definitely welcomed. The popularity of functional paradigms in recent years certainly added to that trend.

Now back to Pioneers! :-)

[Eigen]

It took a couple of evening of tinkering and trying different approaches but ..

THE LUA CALLBACKS ARE WORKING! F*CK YES!

Code:

buttonOne:onClick(function()
    print("Don't touch me!")
end)

buttonTwo:onClick(function()
    print("Touch me!")
end)

I also added a simple retain/release logic for Lua states since I need to clean up after I close a window or remove all widgets using this state. I can already see this simple binding helping me out tons. The metatables are still quite confusing. I couldn't just do ..

Code:

// Naive JS-like approach ...
myButton.onClick = someFunction

.. because my widgets are simple C pointers wrapped and even if the metatable were accessible it would bind the same function to all buttons. For uniqueness the metatable would have to be created for every instance and they contain quite a few methods which doesn't seem very resource-friendly. And right now it wouldn't work in my system because widgets aren't created on Lua level, they are internal instances and the script only receives the pointer. That's what's known as lightuserdata. Other option is to use userdata which are allocations on Lua stack. In that case each object would have a separate metatable to which you could add unique callbacks but you have to manages these objects from Lua but Pioneers' GUI system is very much in C++, so no.

Amyway, I'm passing the callback function and reference it storing the index for later invocation. Upon deleting the widget the index is unreferenced.



Registering the callback in button wrapper class:

Code:

int onClick(lua_State * L)
{
    int functionRefIndex = luaL_ref(L, LUA_REGISTRYINDEX);
	
    obj->setLuaOnClickCallbackReferenceIndex( functionRefIndex );
}

Later when triggering the click event in the actual button class:

Code:

if (L && lua_onClickCallbackReferenceIndex != -1)
{
   lua_rawgeti(L, LUA_REGISTRYINDEX, lua_onClickCallbackReferenceIndex);
   lua_call(L, 0, 0);
}

Yeah, that simple ...


Although I now realize I should've used a better binding library. Something like Luabind or LuaBridge which could make the function referencing a bit simpler I think.