226

(16 replies, posted in Showcase)

Haha, you've almost described my project.
My project definitely doesn't have the same story, setting or probably genre, but it's heavily story based. I'm also currently in the prototype phase and hoping to make a short demo to put on kickstarter wink I guess whatever they said about great minds must be true wink

I really should put some stuff for my game up, but it's currently little more than placeholder graphics so I am a bit nervous about putting anything up before I'm happy with them (a bit of a strange viewpoint from a programmer who had little to do with the creation of them, I know)

Something that might interest you. I've done some video playing in a previous project, I've not done any videos-to-texture in Maratis, but I can see if I can dig out some code maybe (no promises, a lot of my old code goes walkabouts, never to be seen again).
Also, I'm currently looking into both particle systems and shaders within Maratis and will have some documentation up shortly on both I guess.

I have to say, I'm in two minds about exposing more to lua. One issue I've had with people using something similar to what Maratis provides, in lua, is that it's very very easy to get lost in it. I think it would probably be beneficial for Maratis to more split up it's lua API into several modules, so in general, you don't have to care about the majoirity of the functionality within the low(er) level stuff when you're just looking. API documentation for hundreds of functions, however comprehensive, is daunting.

Of course, I don't have any say in this, it's entirely up to Anael, but after having an in depth look at how Love2D works, I would strongly suggest a similar method of partitioning the functionality.

Anyway, back on topic. The music sounds quite fitting. Again, I've got to say, I'm looking forward to seeing how this turns out smile

227

(16 replies, posted in Showcase)

I have absolutely no idea how your nun might fit in with your existing plot, but she certainly seems to fit the atmosphere you've demonstrated.

I love the idea of a episodic game, too few games do it. I've considered trying to make an episodic game myself but I honestly wouldn't know where to begin. Will you keep a project blog or just document your progress on here?

228

(16 replies, posted in Showcase)

Hey, this game looks really great. It's certainly coming along a lot. I'm looking forward to seeing more soon smile

229

(47 replies, posted in Tutorials/Examples)

Gah, it's taken me so long to get this one finished, and it was a very simple tutorial actually. Sorry again, it's finally online for people to see. I wouldn't expect anything very impressive or revolutionary, it's still just framework code, but we're getting to the end of that finally. I have 2 more tutorials to tie everything up, then we're onto making a game!

As always, look forward to any feedback. The sourcecode is all on Github as usual.

230

(2 replies, posted in Gossip)

Ok, the plugin system isn't "live" as such. I can provide the source code for anyone interested to get it to work so far, until we wait for the ok to get it on svn and then into the next release.

Still, I've been working on a couple of things with regards to plugins, mainly as investigations as to what I can (easily) do for my game. Nothing is in any way complete, or even usable (the particle system doesn't even run yet) but I've started documenting things on my website. It would be great to get some feedback as I go along, if anyone would have time to do so.

I do have to stress that, as well as a full time programming job, I now have several things "on the go". There is my game, the 3 plugins I have and a GUI system. I'm also being two people to make small 2D games for them. No rest for the wicked. Oh, and there's the tutorial series. As such, I wouldn't expect any of these projects to be speeding ahead at a phenomenal pace, however, as they are all related to the progress of my game, they will get developed slowly. I will put what I do on github and document things in code and on my site so people can see what's happening.

Anyway, time to drop a couple of links
MLove - integration of Löve2D with Maratis - No Github
Gooey - data driven GUI system for Love/MLove - Github
MParticle - integration of Particle System - Github
MProfiler - Maratis CPU/memory profiler plugin - Github

231

(6 replies, posted in Engine)

Thanks for the quick replies. I will have a look what work is involved with the possible solutions. I will maybe try and persuade the artist sitting next to me to throw together a couple of test models for me tongue To be honest though, I probably won't touch this for months tongue I'm still working on a small demo for my game. There are some features I will need for that, but I don't think facial animation is one of the most important things.

232

(6 replies, posted in Engine)

Not something I intend to do any time in the very near future, I've just been attempting to plan a roadmap for my project.

For my game, I will need to animate characters. That much is simple. I've played with the animation stuff a little. What I was wondering was whether there was any way to split these animations up. For example, what I'm used to at work is having a "main" animation which applies to the whole skeleton, and then potentially multiple sub animations which will overwrite the animation from one bone down it's children. To be honest, I've not had an in depth look at the animation system yet, so I'm not entirely sure if it's possible.

Also, if it's not possible, and not easy for someone (could be me) to add at a later date, how difficult would it be to expose the animation stuff itself, so (and here I go again) I could get a 3rd party library and add it in a plugin.

I realise that 3D models and animations are likely to be heavily integrated so it's probably not very easy to extract and extend. As I said, I'm trying to plan a roadmap, seeing what's possible and how much time I would need to invest for each feature. I would _really_ like to be able to have independant facial animations and am prepared to spend a considerable amount of time getting it to work smile

EDIT: I realise that I keep coming up with new features, and I'm definitely not planning on taking this one on until I've got considerably further.

233

(47 replies, posted in Tutorials/Examples)

I've not yet finished writing up the next tutorial, but I've made a start. And I've done all the code (minus the comments) If anyone's interested, the code is up on Github and I've started writing the introduction.

Just some tidying up to do, then we're practically done with stage 1.

Apologies to all for this going so slowly.

234

(12 replies, posted in General)

Unfortunately, I've been incredibly busy with both work and personal life, so the tutorials have sort of taken back seat. I will continue them shortly. I promise. Good to know you like them though smile

Only the executables are GPL. Under the GPL only the bits compiled together have to be GPL, so if you make changes to the player or editor executables, you should re-release it. The game itself doesn't need to be at all. It's compiled separately (if you need code) into a library which links to the zlib components of the engine. If you're releasing the game under Windows, Linux, OS X, and you use the player rather than write a game executable yourself, then you will have to add a GPL license text file along with the game distribution. That's about it. There was some discussion about how I did the packaging work, I get the editor to modify the player executable data, but again, it's not really changing the game at all, if you got into any GPL related issues on that count, all you had to do was change one cpp file and have it freely available for people to download if they wanted.

tl;dr - Nope, no issues as long as you don't change the Maratis executable files smile

235

(12 replies, posted in General)

The iOS project, I believe, is zlib. Anael's very kindly sorted the licenses so that there will be no issues at all with making commercial games. Just the usual "it would be nice to get credit" kind of thing. But other than that, you're free to use it as you want. Just the desktop OS player and editor are covered by GPL.

236

(8 replies, posted in Engine)

Haha. I had an issue with it last night, that it didn't draw, so I gave up and went to bed. Now I took a look at it again and it was because I was trying to test it in my game scene, which had the custom MGame class to handle the post processing shader. Guess what I forgot to do...

I called MGame::draw and... well, it crashes now. That's more like what I was expecting tongue I made a guess at how to translate OpenGL array calls to MRenderingContext calls. I guess I got them wrong

EDIT: removed some of the smileys, they were annoying me

237

(12 replies, posted in General)

I can answer some of these questions for you smile I already asked about the full screen post processing shader, Anael provided an example over here. It requires some C++, but using any one of the code examples and tutorials can set that up for you. I should have a post processing shader tutorial, with external shader file, coming up shortly.

At this moment, there's no real 2D image system. The agreed method is to render a separate 3D scene without perspective. One of my subprojects is integrating the love2D engine to create a nice GUI solution, but again, I've not completed this yet. It also requires a couple of things which aren't (yet) in the binary release of Maratis.

With regards to the CPU usage, it's not _actually_ using 100%, it's just spinning idly. The standard way for a windows program is to put a sleep() call in at the end of the logic loop. Again, something Anael has added, but isn't in the binary release.

I can't answer any questions definitively about what happens if the computer forces a lower framerate, but I believe that most of the examples would probably run 2x slower, in the tutorial series I've been writing, I've got a clock system that, as long as you use that, you should be able to sync to any framerate.

I believe Anael won't have any problems with you speaking French on here, I haven't exercised my French knowledge in about 6 years now, so I'll feel hurt and left out wink

238

(8 replies, posted in Engine)

That's awesome! thanks smile I Hope I'll have time to play with it now tongue

239

(8 replies, posted in Engine)

That would be great. I don't know if I'm going to have much time to work on stuff myself any time soon, so it's no rush though smile No need at lunch time if you don't have time smile

240

(8 replies, posted in Engine)

Hmmm, thanks, I'm not entirely sure what I can do with that, as I'm working on plugins which can't really have a game. I might try and add extra function pointers to MPlugin which can call update and draw if they're present.

I'm not sure I quite understand what's unsafe, considering that it's already abstracted to MRenderingContext... but I will admit a serious lack of knowledge here, so I do believe you tongue I will try and have a closer look later and see if I can think of anything smile

241

(8 replies, posted in Engine)

What is the best way to be able to add renderable behaviours? I assume during update() the GL state is unlikely to be set up correctly. There is a runEvent call with parameters, but I can't find where that would be called from, so I have no idea if there would be a "draw" event. Ideally, a late-/post-render event would be amazing too, as I could do debug drawing in that, but I guess that's asking too much tongue

242

(37 replies, posted in Engine)

That's quite alright, I've had a busy weekend too. I was just wondering what I should do as, for example, the particle system I'm plugging in, the ideal thing would be to create a button next to the create entity/light/... buttons in order to create a new particle emitter. Of course the "simple" thing to do would be to just make anything like that a behaviour, but then the user would have to create an entity, make the mesh invisible and assign the behaviour, which is ok, was just wondering if we could allow for a slightly more simple way to extend the editor UI.

Anyway, I'll try and get this thing working for now with the entity+behaviour stuff, I can worry about those things later smile

243

(37 replies, posted in Engine)

Hmmm, what would be the nicest way to create plugins that need to add to the editor UI in some way? I can get MGui::getInstance to add to the necessary UI elements to to editor, but there doesn't seem to be a logical place to put it. Should I add a Windows menu next to File and Edit and have plugins add themselves to that menu, requiring each plugin to contain their functionality within a separate window?

244

(47 replies, posted in Tutorials/Examples)

No worries. I'm actually planning on using the majority of the tutorial stuff for my own game project, even though it's not an FPS, so I'm trying to write most of it nice and generally wink

What I've been trying to do until now is give a solid idea as to the concepts I use when coding. For that I've been going pretty slowly. In order to cover the topics I have planned for the next stage, I'm going to have to change to either writing considerably more per tutorial, or go over the stuff at a greater speed, relying on the reader to understand techniques from earlier on. I'm not sure which I will choose yet, but yes, it should be a bit juicier tongue

I've been playing with the idea of the save system, but I've decided to drop it for now. The reason being that the game we're making will be incredibly minimal from a functionality point of view, there won't be much at all to save. There are arguments for both implementing a save system early and leaving it until later, I think I'd prefer, especially with the tutorial series, to leave it until there's something worthwhile saving.

Pausing can be (hopefully) done pretty quickly and easily. I can try and work it into the existing tutorial layout, maybe enlarge stage 2 to maybe 25 tutorials tongue Replays are another matter however as it requires keeping track of everything which happened  up until the point you want to play to. That means a whole load of extra information to store, the exact animations every entity was playing for a set period of time. It's definitely not something for this tutorial series at this stage.

Thanks for the feedback. I'll try to keep working on them this weekend, I've been trying to get a particle system plugin sorted though to let us all make nice effects smile Also wondering whether I should invest time in integrating it with bullet, or maybe putting it on GPU. Oh the possibilities. So much to do, so little time tongue

245

(37 replies, posted in Engine)

So, I've built with VC2005 and VC2010 and got the same issues. For now, I've only sorted the getNew() and destroy() in Maratis, not MaratisPlayer, so the player will almost certainly have more issues. I've also only sorted the release settings for the VC2010 solution for now as I was putting MGui etc into the Maratis binary directory tree. One strange thing that this showed up is that Maratis.exe, when run, requested MCoreDebug.dll, even though I built a release build and (as far as I know) only linked to release libraries... If I gave it MCoreDebug.dll, it would start loading, then crashed, if I renamed MCore.dll to MCoreDebug.dll, it asked for MCore.dll, so I copied MCore.dll and renamed the copy to MCoreDebug.dll and it worked perfectly. Well, apart from the crash on closing. None of this effects running from VC debugger, but still weird.

Ermmm, what else, I think that's about it. I think I've cut down the required libraries after the split, but I'm not 100% sure that it's not got extraneous links.

Download

EDIT: Oh, I haven't got the plugin stuff working right now tongue It was hardcoded for Linux in there at the moment with my home dir, so no plugins will work tongue

246

(37 replies, posted in Engine)

Sure, I've been working on VC2010, so let me just update the VC2005 solution then I'll package it all up. I'll try and have a go at getting scons to build it too, but I can't guarantee that today unfortunately.

247

(37 replies, posted in Engine)

I've finally got time to put all the getNew() and destroy() functions in for all of the MGui stuff... apart from MWindow, as this is a singleton instance. However, it is causing a crash on exit, so I think I will try and rewrite the singleton stuff so we can also destroy it when we need to. Not quite sure. Any idea why wglDeleteContext(m_hRC) in ~MWindow might be causing a crash somewhere in system dlls?

Anyway, I only replaced the new/delete in MaratisUI for now, there didn't seem any point in doing internal ones in MGui, as they would all be using the same memory, right? I'm not entirely sure where I go from here... but I think I'll start wrestling with Love2D tongue

248

(5 replies, posted in Gossip)

Hey, I wasn't complaining! I think libnpk is clear enough to use as it is smile I managed to use it and I'm definitely no genius tongue you just asked for suggestions and it was the only one I could think of smile I'm sorry if I sounded too negative. I'm always very cautious about using external libraries as they very often enforce a particular code design which the author(s) envision as being the best way. It almost always ends up causing design conflicts. I didn't have any problems like this with libnpk, so it is now on my (very short) list of nice libraries smile

249

(47 replies, posted in Tutorials/Examples)

I've, unfortunately, been pretty busy recently so I haven't had time to work on the tutorial series so much. I have, however, I think, come up with a full plan of the next stage of the series. Let me know what you think.

Still to do in Stage 1:
- Tutorial 8 - Game framework 4 - Interaction
    Some basic inter-behaviour framework stuff
- Tutorial 9 - Game framework 5 - Tidying up
    Branching the project and setting up for our game
- Tutorial 10 - Overview and planning
    Some scribbles about what we're planning on doing

Up and coming in Stage 2:
- Tutorial 11 - Revisiting our controller
    Making a simple player object which will listen to commands
- Tutorial 12 - Give me a place to stand
    Adding a world for us to explore and some physics-y stuff
- Tutorial 13 - Guns, guns, guns
    How we handle guns and shooting them
- Tutorial 14 - Pew pew. Bullets
    Making things fly around the world, possibly even visibly, depending how enthusiastic we get
- Tutorial 15 - Decals
    Bullet holes in the scenery. Nice.
- Tutorial 16 - Animations
    Setting up for reloading etc
- Tutorial 17 - Enemies are stupid
    A very basic AI. Don't expect much here apart from randomly walking around (maybe do an AI series later?)
- Tutorial 18 - Particles everywhere
    Fire. Smoke. Water. That kind of thing. They look pretty
- Tutorial 19 - Fun in the shade(r)
    I've been playing with post processing, so I may as well put some shader stuff up.
- Tutorial 20 - How gooey is a game?
    some GUI work, maybe a simple HUD, we'll see

There's really not a lot left in Stage 1, Stage 2, however, will get a lot more involved. I'm hoping to go into as much detail as possible when writing them, but at the same time, I don't have several weeks to write a particle system and tutorialise it. I think the plan for this is to use an existing system. With any luck, the plugin system will be up and running and I will write up a bit about integrating a particle system (possibly this one even though it's a bit old now) into a plugin, separate from the tutorial series, then use the tutorial to explain how to set up pretty looking particle systems. The same is true for the GUI stuff as I'm intending to integrate a GUI system into a plugin. Of course, if the plugin system isn't ready to go at this stage, I'll probably do the work in the game project, at the very least as a placeholder.

Anyway, what do people think? I should be able to scrape together some more time this week to hopefully finish off the last 3 tutorials in Stage 1 and start thinking about Stage 2. Are people finding this helpful?

250

(15 replies, posted in General)

Which would be a perfect target for a plugin, incidentally wink