A little confused...

[Zencro]

Alright , I'm new , never made a game/mod and am trying to make a rts.

I'm a little confused as to what spring is. Can spring be turned into a standalone game? Is it always going to be linked? Can you remove the whole "mod" thing and just make your mod the actual game?

If anybody could explain I'd really be grateful. Thanks in advance.

[==Troy==]

Spring is an open source engine. Literally you can do whatever you want with it. Make it standalone. Make your mod into an actual game. Whichever modifications you want. You are not limited by lua-only if you are going standalone. Just remember to keep the CODE in GPL.

[Zencro]

are there any tutorials as to how to do that?

ps: I'm really new , but everyone has got to start somewhere , right?

I'm just trying to figure out how to make a simplistic game.

I can model/texture and all that fancy stuff.

[smoth]

CODE in GPL.

or pd or whatever.

[smoth]

are there any tutorials as to how to do that?

All mods and games in the spring engine have readable code. Your game or mod is stored in a package file either sdz(zip) sd7(7zip)

ps: I'm really new , but everyone has got to start somewhere , right?

Flozi released a basic starting packagage somewhere here on the forum.. look for his post by setting username to flozi in the search function of the forum.

I'm just trying to figure out how to make a simplistic game.

find that base project and you will be pretty well along the way.

I can model/texture and all that fancy stuff.

good. Can you do basic coding? if so you can handle this stuff.

[wilbefast]

All mods and games in the spring engine have readable code. Your game or mod is stored in a package file either sdz(zip) sd7(7zip)

In noob that's "to open the archives, change the extension from .sdz to .zip or .sd7 to .7z and extract"

Speaking as a noob though I'd say that it's very daunting looking at the mod files, there's so much stuff in them and at first it's hard to figure out what does what.

I'd recommend you break up the impossible task of building a game for Spring into several merely difficult ones, then break them up into a multitude of easy ones. The best advice I was given was to try and get one really simple, ugly unit working in Spring - if you can get one ugly unit working, you can get a second not-so ugly unit working, then more and more, better and better (I hope) - you'll also have a base to work from and a sense of achievement.

You can start here:
Unit development Wiki

But I'd specifically recommend these tutorials:
UV Mapping in Wings3D
Model Preparation: Upspring and DXTBmp

Once you've got your model in a format that Spring recognizes you can simply copy the file and texture into an existing mod directory. You'll need to create a "unit definition" but I'd just copy one of the ones that's already there and change the name and the model it uses (these lines should be easy to find). After that you should be able to set your unit as the starting unit in the "gamerules" and see it in game

Also, talk to FLOZi about the "ABC" he's working on

[Saktoth]

The best way to learn is to dive in with an established mod. Open one up, take a look at its guts, poke them and see what all the stuff does.

Most any mod will do, one you are familiar with from playing is best- you're going to have to play games on the engine to learn how to develop them. Naturally id suggest CA, its open source and open development, anyone can contribute, so whatever you want to do, you can see how it will look in an established game. Though CA is pretty huge by this stage and can be daunting, we'll be glad to teach you whatever you need to know.

[Neddie]

Any established mod or game project that will accept contribution will do. A few weeks there, and then you could have all the skills necessary to work on your own.

[SinbadEV]

yeah... find a mod that needs a unit (the fantasy ones and complete annihilation IP free (1faction) would be good choices... start by modelling and texturing a unit... then get a basic script and get it in game... totally the best way to get into the whole deal... and it will trick all of us into helping you a whole lot more then the average Newb... Spring is an awesome platform on which to build pretty much any clever RTS idea you have...

In the background I would suggest you also build a design document for you game... if this is less then 3000 words you need more details.

[Saktoth]

A game that doesnt accept contributions is fine to mess with, i started out just poking BA's guts until i learnt the ropes, though its much nicer to work on something that will actually see the light of day, when you're starting out everything you do will be crap in some way or another (even if you're impressed with it).

Jumping in with a whole unit, learning bos scripting upspring exporting, etc is probably a bit much at first, a lot of the best modellers around here still dont know how to animate their units. Its fine to take baby steps and have other people help you out with any of that stuff, its more motivating and a better use of your time if you are already a modeller to be able to see your stuff in game without having to learn to script first.

Anyway i think he has disappeared again...

[wilbefast]

In the background I would suggest you also build a design document for you game... if this is less then 3000 words you need more details.

Whoa there

3000 words before you understand the technology you're working with!? Some general idea is certainly a must, but the specifics should probably wait till you have a better idea of what you're up against.

[zwzsg]

In the background I would suggest you also build a design document for you game... if this is less then 3000 words you need more details.

I never understood that, I'd even go as far as saying it is bad advice. Putting on paper your daydream does not constitute modding.

And writing a design document before you even know what's doable, how Spring works, etc... is ludicrous.

I'm sure you already know what you want, no need to waste time writing it down. But as you start doing the actual work, models, code, getting the first unit ingame, then your plan will change. Some things that sound good in paper won't work out as expected. You'll realize that some things you didn't dare writing because they seemed so obviously impossible are in fact super easy. Spending time on your project will get you spend time thinking about it and get new ideas.

Then there is also the motivational aspect: How fun is it to spend all your free time of your next 3 years labouring like a drone, suppressing all creative thoughts, all novel ideas, on what was thought up in a day? (by a younger, unexperienced person, none the less.)

The only time when I may understand a use for design doc is when you already have much experience in creating Spring mods, have a team to coordinate, and want to complete a large project.

Fact: 99% of mods that start up as an exhaustive written design document never reach completion. Forums are littered by those.

[Neddie]

A design document is a tool unsuited to a beginner's project, zwzsg is correct. I've written too many unrealized ones myself. As a tool, a design document offers structure and communicability; the former is not helpful for basic learning, the latter is not helpful for somebody working alone.

[Nemo]

I think the best approach to 'design doc' is more to have a general 'design ethos' or general guiding principles, and then keep design decisions to one person - a balance/design czar of sorts. That way you keep the flexibility and creative response, but also get a fairly consistent and coherent design (since it all came from one mind, more or less). Not that other people shouldn't contribute (they very much ought to: design and balance are uber-complex problems, so more competing views/hypotheses for the design lead to consider-->better), but the actual implementations should be made through the 'lens' of that design lead.

More on topic: modding an existing game (preferably not BA, since its internals are really old and icky. CA has very up-to-date internals, but also quite complex. EvoRTS is probably a good balance between the two, or perhaps S44 - as long as you don't play with infantry scripts) is a great way to create something cool very quickly, and helps you learn the ropes while getting a sense of what things are easy to do and what things are hard to do.

I think trying to jump onto a team that's still getting going before you have much in the way of applicable skills won't help that much.

[smoth]

lol people suggesting waterfall..

[Argh]

You can write a game design document like this:

"Players win via scoring points. Points are scored whenever the Mighty Iron Steam Droid dunks a Red Hot Lava Ball in the Hoop of Agony".

There, it's a game design. The rest is frickin' details. You know what these different things are. You can visualize them. You know it will be fun. Don't worry about it yet, get back to figuring out how to Do Stuff.

Is it good to write those details out? Sometimes, definitely. If you work within a group, absolutely yes.

You're just learning how to Do Stuff atm, though, so... relax! You have plenty of learning-curve to climb before you have to even bother with anything that isn't straight-up mechanical.

[wilbefast]

I think we scared him off...

[Forboding Angel]

In the background I would suggest you also build a design document for you game... if this is less then 3000 words you need more details.

I never understood that, I'd even go as far as saying it is bad advice. Putting on paper your daydream does not constitute modding.

And writing a design document before you even know what's doable, how Spring works, etc... is ludicrous.

I'm sure you already know what you want, no need to waste time writing it down. But as you start doing the actual work, models, code, getting the first unit ingame, then your plan will change. Some things that sound good in paper won't work out as expected. You'll realize that some things you didn't dare writing because they seemed so obviously impossible are in fact super easy. Spending time on your project will get you spend time thinking about it and get new ideas.

Then there is also the motivational aspect: How fun is it to spend all your free time of your next 3 years labouring like a drone, suppressing all creative thoughts, all novel ideas, on what was thought up in a day? (by a younger, unexperienced person, none the less.)

The only time when I may understand a use for design doc is when you already have much experience in creating Spring mods, have a team to coordinate, and want to complete a large project.

Fact: 99% of mods that start up as an exhaustive written design document never reach completion. Forums are littered by those.

I agree with this. I wrote one for Evo way back in the day and roughly only 20% of it came to the fruition that I had imagined. It was before I knew what I now know about the spring engine.

The better course is to outline a roadmap for yourself, and leave it open to interpretation so that you are not strictly bound by it, because if you do become bound with it, then your project has much less chance of succeeding.

[JohannesH]

Joined: 16 Nov 2009, 02:43
Last visited: 16 Nov 2009, 03:37

[Gota]

Joined: 16 Nov 2009, 02:43
Last visited: 16 Nov 2009, 03:37

Nice punchline.