Structure of Spine application

battlebottle

Hi Nate! This is a question for you..

I'm a long time hobbyist programmer and there's been a few times where I've felt compelled to create a fairly elaborate custom level editor to use to help create some cool game ideas I've had. I've attempted projects like this before, but I find my code gets horribly complex before I get as far into it as I would like. I've also had a difficult time finding good advise on how to go about creating an application like this.

Basically stuff I'd want a level editor to be able to do would be:

Have a map of 2D objects that's pannable and zoomable, where the map can have arbitrary dimensions
Be able to select any object and change it's properties in properties window
Be able to select multiple object and change their properties together
Have a reliable undo system
Be high performance enough to be comfortably usable
Have a highly maintainable, readable and extendable codebase

I usually get the first two things in before my code becomes messy and hard to read and make significant changes to. At the same time I think all these features don't sound like anything special and are nothing less than what most users would expect from a good level editor and many applications, like Spine, seem to manage all these things with grace. I don't expect getting all these features in a single application to be easy, but I expect there must be much better approaches to organising code for applications like this than I know.

I'm a huge fan of Spine btw, and I think it's a fantastic example of a program that has much of the feature set that I hope to have in some applications I write in the future, though I don't plan on writing any animation software =p. The whole application feels very solid, well thought out and seemless. So I'm wondering if you could offer me tips for writing software like this? Some people have mentioned using models like MVC and MVVM, I'm fairly familiar with these already and use them a lot, but could certainly learn a lot more, is this a good direction to look in? Would you have any advise on articles to read or programming patterns to learn about? Anything useful you've learned while creating Spine? Good frameworks to use?

Any advise would be helpful 🙂

Cheers

battlebottle

Nate

There is some info here:
http://esotericsoftware.com/spine/building-spine/#tech

Using a good scene graph helps with UIs, both with being productive and organizing your code. Selection in Spine is pretty complex, as it tries to be smart about it: there is no select tool, you just click and it does what you'd expect.

Undo can be tricky. At first I just snapshotted the whole project. This worked fine until projects got to be about 8MB in memory, then it was too slow. I now snapshot only the objects that change. Eg...

Undo.next();
Undo.add(object.stuff);
object.stuff[0] =123;

Undo.add does a shallow copy using Kryo. This code is enough to know what the object was before and after the change, so it can move forward and backward through the history.

I'm very anal about having nice code, especially for my OSS. For a personal project, having nice code can waste a lot of time. I start by building the app in a single file. As it becomes complex, I refactor break portions out into static classes, still in the same file. By the time it gets even more complex, I have a good idea of how to organize it properly and I break things into their own files.

It's a balancing act, if you refactor too soon your program will change a lot and you'll have wasted time making things nice that you then throw away. If you refactor too much and have fancy interfaces, tons of separate files, etc then your over engineering makes it harder to work on and harder to refactor later. In a complex app that only you work on, you want reasonable organization without wasting too much time.

Be aware of decoupling but don't be afraid to use public fields, don't worry about optimizations (especially for a desktop app), and don't worry about making the code too nice. Refactor periodically to clean up your mess, but don't go crazy with it. 🙂 The goal is to get things working, not a code beauty contest. You need nice code so you can be productive and implement everything you want, but making it any nicer than that is a waste of time. If you get stuck because your code gets messy, hard to read, hard to change before you can implement everything, maybe you should refactor sooner. Identify why that happens and maybe I can give better feedback.

Choosing good technologies is also important. Having experience with a bunch of technologies can really help. You'll work faster, choose good libraries right off the bat, etc.

That said, using a tool someone else has built can save you a massive amount of time. Do you want to make games or do you want to make tools?

If you can find a tool that costs "C" that does (or almost does) what you want...do the math:
1) T = Guess of time savings.
2) Account for opportunity cost: 2T
3) How much is my time worth: E
4) If 2TE >= C: buy and move on to important stuff.

https://www.iforce2d.net/rube/
http://gleed2d.codeplex.com/
http://www.mapeditor.org/

Here is someone building a level editor with some of the same technologies Spine uses:
http://www.badlogicgames.com/forum/view ... =16&t=8951

Pharan

Nate ha scritto
It's a balancing act, if you refactor too soon your program will change a lot and you'll have wasted time making things nice that you then throw away. If you refactor too much and have fancy interfaces, tons of separate files, etc then your over engineering makes it harder to work on and harder to refactor later. In a complex app that only you work on, you want reasonable organization without wasting too much time.

Oh, man. Have I seen overengineered stuff. It's the perfect antithesis to the code made by the programmer who only cares about things that work immediately. Both can be equally horrendously unreadable and unmovable. Except the former is more bureaucratic and sneakily hides behind well-named objects and lots and lots of dots.

This is really good, practical advice, Nate. As is the rest of your advice. Thank you. :love:

And it's what they teach at Stanford and Harvard anyway— judging from those free online lectures they release. Best advice you could give to someone who just learned OOP, or has simply fallen madly in love with its principles. It's definitely a balancing act.

Personally, I've found overengineering easy to avoid as it's a logical conclusion to make that it's too hard to predict how ever-changing things will ultimately work. It's also part of an artist's training to start loose and assume things can be thrown away, and then just solidify it once you're decided about how it's going to work.
The thing I've been consciously doing is avoiding adding features and structure until it becomes needed or obvious (or if was planned for from the start).
Having an API that covers its bases is helpful if you're making a library, but for personal code and internals, it's much more helpful to keep things lean and obvious.