Kris, you may want to see this:
http://www.gog.com/news/say_hello_to_gogcomindie

[Zeus] wrote:

Kris, you may want to see this:
http://www.gog.com/news/say_hello_to_gogcomindie

Thanks for the link. I probably would've found it myself before too long but it's good to know it's there. ;)

Vectorzone's nowhere near done. I have a lot of code to rewrite over the next couple weeks and I'm presently having some issues with the new UI layout. (Nothing I can't handle, just mostly trying to balance user friendliness with quantity of information given.) The public alpha on my website that hasn't been updated in months represents about 1/10,000th of the entire game. Plus, I'm done making dubious predictions about how long it will take to complete since ADG remains my primary project and predictions when it comes to programming time are often very wrong. :P

is it going to be windows only?

Yes, but only because I have no experience coding for other platforms. I was considering maybe making an OUYA port, but from what I understand you need to know Java to integrate your stuff into the OUYA libraries and I'm very inexperienced with Java. I'm not sure if it would be worth the hassle and time to learn an entirely different language just to do that. :/

If the game turns out to be super-popular (not likely but not impossible) I might hire someone else to port it to other systems like Linux and/or MacOS.

Have you considered just using Unity? I think it's come quite a ways from what it used to be and is even being used for higher tier projects like wastelands, it's also multiplat form. just an idea, i figured i'd fire it out there.

Allegro supposedly supports Windows, Linux, Mac, etc.

SDL supports even more platforms, both officially and unofficially, and is used by DOSBox and ScummVM.

Unity does seem to be the flavor of the month, probably because it uses Mono and Microsoft dumped support for XNA.

cdoublejj wrote:

Have you considered just using Unity? I think it's come quite a ways from what it used to be and is even being used for higher tier projects like wastelands, it's also multiplat form. just an idea, i figured i'd fire it out there.

I've already created my own game engine that's specialized for the kind of rendering I'm doing, so using something like Unity would just overcomplicate everything. Plus, developing for multiple platforms isn't a limitation of the tools I'm using, just the hardware/software I have access to and my own experience working with other operating systems.

HunterZ wrote:

Allegro supposedly supports Windows, Linux, Mac, etc.

Yup. Even Android which is why I was musing about an OUYA port. :)

Porting an Allegro project is easy if you know the specifics of the system you're porting to. I know next to nothing about Linux and while I have some experience with MacOS coding, it was enough to know I never wanted to code for it ever again. That's why it makes more sense to hire someone else to do the port who knows the intricate differences between the operating systems and can account for them. For instance, I've written my own timer routines in place of Allegro's to be able to do certain things that would be difficult to achieve using Allegro's routines, but these routines rely on Windows-specific functions. Since I have no experience with Linux coding I wouldn't know how to transition these routines over in the most efficient and performance-savy way possible. :P

Gemini000 wrote:

Porting an Allegro project is easy if you know the specifics of the system you're porting to. I know next to nothing about Linux and while I have some experience with MacOS coding, it was enough to know I never wanted to code for it ever again. That's why it makes more sense to hire someone else to do the port who knows the intricate differences between the operating systems and can account for them. For instance, I've written my own timer routines in place of Allegro's to be able to do certain things that would be difficult to achieve using Allegro's routines, but these routines rely on Windows-specific functions. Since I have no experience with Linux coding I wouldn't know how to transition these routines over in the most efficient and performance-savy way possible. 😜

That sounds terrible. You should really look into SDL, as you generally only have to tweak the video initialization code and maybe write some different input code (if going from, say, a keyboard+mouse driven platform to a controller-driven one) in order to port between vastly different platforms.

I was able to port the current open-source version of Abuse (which is SDL-based for graphics, sound and input, and uses common C++ libraries for most everything else) to the Nintendo Wii in only a few weekends, despite not even being familiar with the codebase (or even SDL really, since I still haven't coded anything from scratch with it beyond following tutorials) when I started.

My only SDL turn-off is that they are currently trying to transition from 1.2 to 2.0, and a lot of third-party ports of the SDL libraries are not going to move forward. This means that you really have to weigh the potential benefits of 2.0 against the reduced porting options. It's honestly not really a hard choice right now, though, because 2.0 is poorly documented.

I'm sure I'd run into similar things if I tried to use SDL instead. Every OS has its own semantics and idiosyncracies about how things work and all, and certain optimization tricks to get around minor bugs or to play nice with multitasking or other such things don't necessarily work so great when porting. For instance, if I ported my game to Linux and suddenly found the framerate terrible, yet the framerate was perfectly fine on the Windows side of things with almost identical hardware, I'd be very stumped as to what was wrong because I wouldn't understand what Linux might be doing under the hood that might screw with the framerate, whereas with Windows, I know just about every little nuance that could affect that kind of thing and can thus far more easily debug problems that crop up that shouldn't be happening.

It's all a matter of time and I simply don't have the time to learn new operating systems and languages anymore. Especially not while trying to keep a webshow going. :/

Besides which, I do believe Vectorzone runs in Wine on Linux without any issues, though it's been awhile since anyone's last checked.

EDIT: I feel I should clarify too that I'm VERY slow at learning new computer languages. You don't even want to know how long it took me to figure out how to properly use pointers in C... >_>;

Going from VC6 to GCC is hell, even for the Windows platform. It's kinda the reason why I don't want to port Engoo to anything else.

Going from VC6 to VC2010 wasn't so bad at least. The massive change in accessing reference materials though had sort of left me going to other websites online when I needed to look up basic syntax for C/C++ stuff I don't often use. :P

Oh yeah, and I'm pretty sure the majority of programmers hate my coding style too, since it's a hybrid of C and C++ semantics, because I use a fairly sizable number of global objects, and because every once in awhile, I use LABELS and GOTO. :O

...all of you on here who can code stuff may now rage at me. XD

Just from the description of your coding style, I want to refactor your code 😜

Gemini000 wrote:

I use LABELS and GOTO. 😳

Whelp.

You shouldn't feel too bad, any application that uses VBA for macros still requires an esoteric use of GOTO for error handing, i.e. "On Error Goto [label]", owing to essentially being a subset of VB6. And yes, that's on new applications shipping today (like Office 2013 or AutoCAD 2014). Heck, the VBA IDE even still looks like VS98.

Actually, I typically only use goto commands and labels in C++ when it's the simplest solution to a problem that's not time-critical, such as if I need to run an entire routine again from the start because of something that happens halfway through it.

oh okay, i see your doing the old school but, it if i'm understanding correctly you do have multiplatform support but, it has to be programmed/altered for each platform like traditional Open source libraries.

So long as you stay away from OS-specific stuff, you only have to change your code in as so much as subtle syntax differences between C/C++ on different platforms. When I originally went from DOS to Windows, the first major change I had to deal with was that I wasn't able to make the contents of an object equal the contents of another object with a simple = operator anymore, at least, not without first coding an operator function in for the object class, which I had no knowledge how to do at the time, so instead I had to use memcpy().

Even going from Visual C++ 6.0 to Visual C++ 2010 had some changes, such as the depreciation of any functions which could be considered "unsafe" due to their ability to overflow past the end of their buffers, such as sprintf(), which is a function I use a LOT. In its place, sprintf_s(), which needs to be given a buffer size limit.

But anything exclusive to Allegro itself transfers over fine. :)

It's really difficult trying to express why I don't want to do a port on my own accord without help. Part of the reason I was musing about an OUYA port was because at least that's a console, so if someone has a technical problem, chances are very high I could recreate the problem or figure out what it could be. With other operating systems beyond Windows, I simply don't know enough about them to know what kinds of quirky things could go wrong related to various combinations of hardware, software, drivers, and random chance, so I wouldn't be able to provide decent tech support to anyone on those operating systems. x_x;

Yeah I know, I shouldn't be working on a project of this size by myself. I've had terrible luck in the past with trying to recruit help on multiple occasions (more than I can count on a single hand) so I'm at a point where the only people I trust to bring in on a project are people who I'm personally friends with, or people who I see as being equal or greater in talent to me, not necessarily with coding but with anything. The trouble there is I only have two personal friends who have exceptional coding skills, but one's busy doing astronomy work every day and hasn't done game coding in quite awhile now, while the other has had a programming job for numerous years and has never once done game coding. All my other personal friends are either graphics artists, a website designer in the case of my mother, or computer inept. :P

To that end, at least I've got a friend helping me with some of the graphics stuff this time around. I'll still be laying out the final graphics that will go into the game itself since the formatting needs to be precise, but he'll be doing all the prototyping. :)

Gemini000 wrote:

Even going from Visual C++ 6.0 to Visual C++ 2010 had some changes, such as the depreciation of any functions which could be considered "unsafe" due to their ability to overflow past the end of their buffers, such as sprintf(), which is a function I use a LOT. In its place, sprintf_s(), which needs to be given a buffer size limit.

I'm sorry for this. Know that it's nothing personal!

It's deprecate.

Depreciation is the decline of value of an asset over time, for tax and accounting purposes.

I don't know why, but this particular language faux pas irritates me.

😢

it's not as bad as abuse of the word loose. Like this gem in Jamagic (the flopped overhyped 3d attempt at Click & Create i'm sure Gemini once followed at one point)

leileilol wrote:

it's not as bad as abuse of the word loose. Like this gem in Jamagic (the flopped overhyped 3d attempt at Click & Create i'm su […]
Show full quote

it's not as bad as abuse of the word loose. Like this gem in Jamagic (the flopped overhyped 3d attempt at Click & Create i'm sure Gemini once followed at one point)

Wow. That's a pretty terrible oversight in a commercial product...

SquallStrife wrote:

It's deprecate.

Depreciation is the decline of value of an asset over time, for tax and accounting purposes.

:O

Considering the fact this is one of those extremely few words I've never had to actually SAY aloud, combined with a very slight case of dyslexia, I'm not surprised I've gone this long without realizing this. (Though I'm also surprised no one's corrected me until now.)

Still, thanks for pointing that out; I can understand the frustration. One of the ones that irritates me is when they call a futuristic device "Inertia Dampeners". It's SUPPOSED to be "Inertia Dampers". >_>;

Even Wikipedia agrees with me: http://en.wikipedia.org/wiki/Inertia_damper :B