Search options (Page 7 of 18)

The development of AquaGate is now officially underway.

I don't know how much we will manage to get done in this session, but I hope to be able to have something by the end of the day.

Just so people can see, I've started up a couple of google docs. I've made them publicly viewable, so people can see what is going on, if you want write access, just send me a message and I'll add you.

Note: These are not complete. Nor are they intended to be viewed as such. They're just some structured places for notes and design to be put. Hopefully they will be bulked out and grow as the project continues

Task List
Design Document
Technical Design Document

And, the GitHub repository

Ok, I'll get it working and submit the fix.
EDIT: was just #include <algorithm>

I guess that's probably an easy way to do it. I guess I can push the object ID (just looking where I can get that from right now) so the lua functions would be:

function fishAI(obj)
end

Hi there! I hope you enjoy your time with Maratis Looking forward to seeing what you do with it

I will have to check, I should have time either tonight or tomorrow to have a fiddle

EDIT: It seems I have mesa, libgl and intel-dri installed, but I can't find anywhere that I've set which dri to use, so I have the sneaky suspicion that it's using the software dri from libgl... I'll try and get that fixed, but I guess it's likely to be the problem

@Anael, I was just doing some quick work and it actually took me a while to realise that Maratis hadn't actually frozen/crashed, but it was just loading for a REALLY long time.

This is due to the fact that it seems to be incredibly slow on Linux for me. I have no idea why this is, I'm getting 2fps on my netbook on an entirely empty scene running one core to the max. My initial thoughts were that as it was using the whole core, it was spinning crazily and locking up, but that wouldn't explain the 2fps... no idea why that is, but even on my PC I'm getting terrible performance. I think I'm going to try and get that profiler stuff working properly (it was outputting valid data before, it was just that I had to paste scope markers at the beginning of every single function that got tedious ) Any idea  what might be causing this performance? Both my machines are running Archlinux and I can get package versions if you think they might be relevant...
EDIT: I tried again on my PC and I'm getting a much more reasonable framerate, I don't think I changed anything... weird :S Still using all of one core though, but I guess that's just the idle spinning

Also, you mentioned at some point that you would put a callback for data loading... would it be possible to squeeze this into the build? As we have MFile wrappers, I think I could probably implement loading callbacks fairly quickish if you want...?

http://webchat.freenode.net/

Not saying you have to join us, but you can

GameMaker, I'll allow you to answer about what Arclord can help with

That's great!

GameMaker (neighborlee on IRC) is busy doing some of the modeling preparation, so I think it would be best if you discussed with him about what would you can take care of.

If you can make it on IRC, there's quite often someone online now

I've shared set up a dropbox folder for preliminary work, so if anyone needs access to see and/or dump stuff in there, give me a shout and I can set you up. For the actual game development, I'm thinking that we can put it on either google code, or github or something. I'm currently working on a couple of framework things (extending what I did in the tutorial series for a little more flexibility) and that's in a personal git repository, so for me, github would be easiest, but if people have a preference, I can put it anywhere.

I have no idea how much more preparation I can do this week, as I think I'm going to be working late... What I already have is a character (penguin "borrowed" from a CC blend on blendswap) which technically moves around, although you can't really tell much as there are no points of reference. I also have a post processor which can be enabled/disabled (and does so automatically if it's not supported) which currently just does fogging to blue. I think that's about it. I've done a little extension to the GameClock, allowing timefactors, and an easier interface for multiple clocks (so you can trigger things off a UI clock which you can keep running constantly, then have a main clock which we can slow down maybe?) and a couple other little tweaks which "might come in handy"

What I still want to do with the stuff for the weekend is make a generic statemachine which we can use for game states (assuming someone fancies making a menu... maybe a 3D menu with penguin going through "gates"?) player state for character etc. I also want to dump a couple of random objects into the world and try and get a very basic swim-control system going.

This weekend, which has been scheduled for the dev jam, what I intend to do is create a shader for the water (ideally above and below, potentially different shaders, not sure yet) and a post processor for the underwater view (maybe a bloom shader which fades for a few seconds after you stick your head above water?) Create more extensive control mechanics. Maybe make an interaction system.

I think with those few things I'll already have my work cut out for me, but it's a decent goal. If we get more people volunteering for code work, we can maybe add some more features

Hey there all. This all looks great!

Would be good to get some little demos for Maratis running up and running.

I shall also be on IRC and providing as much code support as I'm able to

Hmmm, I would say that would cause more problems.

You could potentially get half of the functions implemented and acting as expected, but then the plugin could change it's API and act differently, or some functions might not even link at all. I think, whatever the solution ends up being, adding a plugin version number and allowing version checking from game code.

As I said, I think that distributing one header file is actually quite nice because it gives a beginning to documenting the API of the plugin, plus you can include it into the game project and IDEs like Visual Studio will pick it up and use it for compile time checking, as well as code completion.

Personally, the way I would do this is to have a virtual class, call it MPluginImplementation for the sake of explaining here. Then you can have subclasses like MRecastPluginImplementation which, in StartPlugin, get initialised and added into the plugin system.

Obviously, if you're going to be calling C(++) functions from other code, you'll be linking to the headers of the plugin library anyway, so you can add a wrapper macro into it. This is entirely pseudocode and not even compiled, let alone tested, but something like:

#define MPLUGIN_IMPLEMENTATION_DECLARE(name) \
name* MGet##name() { return (name*)MPlugin::staticGetPluginImplementation(#name); } \
bool M##name##Exists() { return MGet##name() != 0; }

Then you can do things like

if(MRecastExists())
    MGetRecast()->findPath(start, end, &path);

Of course, you would have to add some mapping of names to MPluginImplementation classes, I suggested just having them static within MPlugin, but they can really be kept anywhere.

It really depends, I know a lot of code designers don't like the whole "everything is an object" thing and shoehorning things into OO design when they don't need to be, but I think when it comes to plugins, it's quite nice to have one central plugin object that you can interface with. It also makes any mapping much simpler because you only have to do one lookup for all functions, rather than one lookup per function.