When I was working on Ponies Among Us, I decided to use the SVG graphics from my web comic as the graphic engine. I didn't mind the lack of per-pixel graphics since it was good enough for the game.

There were some really nice things about what I did, mostly a bones-based animation system and I could change colors and shapes on the fly (I was doing a Fable-like display of your powers).

Right now, the methods for getting SVG to OpenGL in a cross-platform manner are... slim. I managed to cobble together something using Rsvg+Gdk+Tao (C# of course) and I was pretty happy with it. Another nice bit is that I created a layer for the intersections (physics) and just parsed that as part of the loading process. That way, I could use the same program (Inkscape) to edit the character graphics and the shape for the physics engine in the same thing. I also encoded some of the avatar settings into the XML of SVG, which I then parsed as part of the loading process. One editor to handle just about everything was nice.

Ditto with the area loading. I created a foreground, background, and active layer (well, stealth too), then had a "action" layer which had the trigger points for the plot, and also a physics layer to handle the intersections. Once everything was there, it was pretty easy to scale it and still retain the looks.

It would be nice if OpenVG (a vector graphic standard on top of OpenGL as far as I can tell) would get a bit more stable and a more streamline SVG -> OpenVG implementation existed, ideally open-sourced and/or free. But, you have to start somewhere.

Right I have absolutely no idea what most of that meant. Not inspiring me with a lot of confidence!

`apt-get update`
`apt-cache search libtaoframework | grep libtaoframework`

That should give you the list of Tao Linux packages. If there is no such thing, then they need to be ported. And if you want me to make a Debian package, I can do that as soon as I get back to my apartment.

Yeah, actually I'm one of the people who did the original packages for Tao. Then others took over because I'm unreliable. Its on Sid (of course), under the libtaoframework-*-X.Y-cil where * is one of the major packages, like "libtaoframework-opengl-2.1-cil". Ditto for SDL and pretty much everything but "libtaoframework-cg" I think.

They should be ported over to Ubuntu, if not, they are fairly well self-contained and you might be able to build them on Ubuntu from the source.

It is easier to go from Debian to Ubuntu, at least in my opinion. However, it isn't that hard to port since most of the debian-mono and ubuntu mono guys are the same people and chat in the same channel.

I'll see about getting an Ubuntu distribution installed at some point.

If you get an Ubuntu, I'll port it over to Debian if you want.

One of the frequently asked features for my csharp mode for Emacs is code folding. Which is a pain in the ass to figure out in Lisp. *sigh* One of these days...

But, I don't like #region for "public instance methods" ...

If you look at my C# code, you'll see I'll do regions like "Logging", "Sprite Management", "Collection Overrides", etc.

Mono doesn't check /usr/local/lib/mono/gac by default. Well, depends on install. If I recall from the various things before, it really only checks one place, so you can't really have it look at /usr/lib/mono/gac AND /usr/local/lib/mono/gac. At least, from what I remember. You can set MONO_PATH to check in multiple places however.

http://www.mono-project.com/Assemblies_and_the_GAC

Another approach is to copy the appropriate DLL's and .config files (since Tao needs it) into your working directory (i.e. /home/arne/OpenGL_intro/OpenGL_intro/bin/Debug) and that would also work (I use that for my Mono games).

There is always a trade off of speed of development verses using formal methods. I mean, most of us probably don't use flowcharts or document our code in UML (I *said* most ), but for larger projects, that is pretty much one of those universal things. A small project won't use use cases, but a larger one might actually do it.

One of the key points is numbers. When you have 1 developer, its pretty easy just to move forward and write things as you go. When you don't really have a deadline, you don't really need a schedule to move forward. So, you can work fast and just get it done. When you have 2-3 developers, you need to start planning out more and if you have 10+, a design methodology is pretty much a requirement. Doesn't matter if it is TDD, Agile, X, or waterfall. You just need something to work with, otherwise the anarchy slows everything down.

I use TDD in most of my development because it fits with my methods of development. I like to test my stuff heavily, simply because I made rather complicated systems and I like single-function models with graphics in front of them. That comes from the Unix philosophy: many small tools, each does one thing well. I also make stupid mistakes. I'll repeat that a lot, I make a LOT of stupid little mistakes.

I don't bother with TDD for views but I'll consider it for controllers. I feel that having automated test suite is very useful also when you are bouncing between projects, as I frequently do, and also when you want to get a feel for how the code is actually going to be used. I also use the tests for example snippets, they have enough multiple uses to justify doing TDD.

TDD by itself won't make a great product, just as MVC or AOP coding won't. Instead, it is just a framework for developing and to give structure. I think the structure works out well for larger projects but I also sketch out UML in my notebook when I'm coming up with programs.

Most of the buzzwords are more applicable with larger projects and larger teams. Or, more accurately, the extra effort for the cruft to maintain and develop them becomes less significant as the scope, complexity, and resources increases. At least, that is how I see it. I just happen to use it to keep my skills up for my professional life and also because it helps reduce the context switching I go through.

Regardless of how you write it, you still need a good goal of where you are heading. A specific game or end result. Making it flexible and updating frequently (agile development) is just another way of handling changes and "we can't plan for everything" that always happens. You can do the same with monolithic development, it just requires a different culture and skill set.

EDIT: Lots of little bugs in what I said.

There are a few things with agile (rapid cycles) development where you don't plan out everything, but you still have an end result or goal. You just work in smaller chunks to get something done now, then add on to it. It still requires a fairly good designer/architect to think at least a few iterations ahead and it requires you to break down your tasks fairly well, but that is partially what the work breakdown structure and other methodologies are all about.

I've worked very well in agile environments and I think it works out very well, for a given culture, group, and arrangement. I've also seen it not work in almost as many projects, but I think it has more to do with the skills and knowledge of everyone around more than a shotgun "it doesn't work."

Test-driven is nice because the architect can set up what it should be doing, then you do an iteration setting up the test cases, then the following iterations make them work out.

Speaking from the non-gaming side, TDD is very nice when you have a model (as opposed to monolithic) to work with. On the Linux side, I put my (n|j)unit tests as part of the build process. It only takes a few seconds to run a couple hundred tests and it tells me if I break something. And I frequently write tests for the model before I do the code, since it lets me get a feel for how I'm actually going to use it as opposed to what I think I'll needed.

Another advantage of test-driven is that it encourages you to build functions that do one thing well, because it is easier to test one thing well than tons of everything.

Of course, I use a model/view approach to things, which really helps. And I'm used to working with rather complicated systems. In the game development, at least as far as I got, I found it useful since I try to keep my game model separate from the view. And making sure I didn't accidentally break scoring while fixing a death spiral helped. Or a damn bug where I accidentally did log(0) as part of the score.

For C++, I would probably start with google-fu on "c++ unit test visual studio" and go from there.

I guess the essence of a roguelike is to represent ideas through symbols and text rather than images.

Eh, for me roguelikes have more to do with random game play, a very wide variety of things, and discovering what something does. Cheat books are useless with most RL's and that is what I like. It doesn't matter if it is graphical or not for me, just that you have to explore and learn the game every time.

Heh, I have two books of poetry, none of which rhyme. Of course, I also have a few novels, but it was an interesting analogy. Nothing wrong with deviating from either the Japanese or English variants of a haiku (different rules, actually, Japanese is stricter). Everything is based on something else.

I do think that a lot of it comes down to seeing the very top. People hear or read about Sid Mier, Miyamoto, and Will Wright. They see the fame but not the work it took to get there. Then, they just aim for that, since its easy, right? I've seen the same with interior design (Trading Spaces shows you to the top 1% of 1%, except for Hilde), remodeling, cars, and everything else. Its hard to see the teaming masses who aren't just Awesome everywhere. For me, it is the authors I meet and admire, seeing how easily they create a book that makes me want to do that. It wasn't until I actually started writing that I realized exactly how hard it is. And then I thought it would be fairly easy just to self-publish one of my older novels that was out of print. Heh, talk about "it looks easy at first" verses the hours I spent getting covers, editing, getting into the proper lists, and even making it look really damn good. About as hard as taking an simple idea (danc's CuteGod for a good example) and making a game out of it (MfGames' CuteGod).

Sadly, it is really hard to tell someone with lots of dreams that. You tell them that it takes a lot of work to take an idea, they'll just plan on getting 2 super-coders in the world. Maybe offer them lots of profits because they'll make BILLIONS on the game. My old boss had that problem. She insisted that her ideas would make MILLIONS, damn it, MILLIONS, because it was a great idea. Years later and hundreds of thousands dropped into her great, and it still wasn't making her precious MILLIONS. And she still isn't realizing that it takes more than a grand idea.

Ideas are easy. Putting them into reality is a royal bitch. Doesn't matter the field either. I'm finally getting out of the dream stage of idea into the "can this be done" reality. Or, having my dreams and ideas be only slightly ahead of my actual skills. Yeah, Running Bomb sucked and the ideas in my head were grandiose compared to reality, but the gap was much smaller than "Ponies Among Us" and "Turf Wars" before that (my last two entries into 4E*). My next goal is to learn how to work with a team to do the things I really can't do well (graphics and music).

As for self-taught verses school-taught. I think most people dedicated enough to teach themselves anything are going to be more motivated. Simply because they have to start so much lower and they have plenty of times to change their mind as they realize it. When you go to school, you have a plan but you also have another goal, graduating. It is easier to realize you hate game programming (or you are taught that all you need is a good idea) but just to suffer through it to get your piece of paper at the end. For self-taught people, you have less goals which means it is easier to realize something specific might be not for you.

It reminds me of a making of feature for a horror movie (something about Illusions, but I can't find it via google-fu). At one point, the director wanted the wall to fall down and for the main character to look out into the abyss. The guy in charges of building the stage asked one simple question: "how much plywood do I need for the abyss?"

Game design is like that, I think.

Overclocked Final Fantasy and Thieves of Fate. Also the G.A.M.E. archive someone listened to. Well, that and Smile.dk, Johnny Cash, Kingston Trio, and random rap and country songs on the mp3 player.

Make a semi-serious game about game development and have people like programmers and idea people. Even if you go with a snarky attitude like the McDonalds game, it probably would get the point across.

http://www.mcvideogame.com

There is also a FedEx/Kinko's version out there, but I can't remember the name.

The hard part is writing something that gets the point across. One great idea never works by itself just as a home improvement project never looks as big as when you are "almost done" and you still have 90% left.

[impossible]

I think working within limitations is a great aid for creativity.

The main thing is though: if we don't make them that specific, it will all just be a bit arbitrary, and we might as well just say "games should be more innovative and different".

The thing with the original Dogma95, was to present such a strict set of rules that it would be impossible to make a standard movie  while adhering to the rule. In the same way, a dogma set for games should make it impossible to make a standard game; that way, we are forced to work on improving the bits we can improve under the rules: the gameplay mechanics.

That is how I saw Dogma 2001. Nearly impossible and requiring you to look at things entirely different. And trying to wrap my mind around it is somewhat hard, hence it works.

2- You shall not use over-complex control schemes or unusual control hardware that doesn't add anything to your game besides gimmicks.

Does this mean I wouldn't be allowed to have "Inspect" mode in MMORPG Tycoon, which lets you watch the activities of a single simulated user?  It doesn't actually contribute anything to gameplay and I only added it as a novelty in the last hours before the competition ended, but a lot of people seem to feel that it's their favourite part of the game.

I read it as closer to not requiring the drum in Taiko Drumming (which is nearly impossible to play without), a plastic guitar for Rock Band, or a fishing rod controller. Just sticking with basic, standard inputs like keyboard, mouse, controller. And then not having "control-x, control-y, shift-s" being the command for upper-punch.

No chance in hell, but Dyson would be a cool entry. Specially if you really polish it up and have people play the hell out of it.

World of Goo was fun, I love what I've played in the beta.

Still be a fairly interesting challenge, to see if you could make Dogma 2001 actually an interesting game. And a 4 week contest is about as much effort as some people will put into it, but I think you can make some fun games based on that. It would just be hard to make it a good game and as danc says "find the fun."

Probably why I'm interested in it.

How about a game where your enemy is Windows Vista, and as you progress you're actually fixing flaws in the system. The end result is a usable OS!

Yeah, and if you beat the game, you will have Windows XP Professional with DirectX10.1 support all working flawlessly. 

Better than 95.

http://www.sluggy.com/daily.php?date=970826

That looks like a really fun game, but I'm still obsessing about CuteGod.

Heh, I was actually working on notes for a Kingdom of Loathing RL last week. At least, how to do it properly.

EDIT: Which is to say, not properly according to a RL developer and "properly" as how I would write it.