Development dilemma

[siread]

Hi guys. I'm starting development of New Star Soccer 4 and i'm having real trouble deciding what path to take. I should point out that NSS4 will have an extensive career mode which invloves lots of stat screens, fixture lists and so on (think Football Manager) but will also have a 2D action side to it when match day rolls around. NSS3 was coded partly in Visual C and partly in BlitzPlus (the match action). I've decided that I want re-write the game completely as I am unhappy with two aspects. 1) A lot of my early code is a shocking mess. 2) I don't like the game being split into two halves (VC and Blitz+).

Now, forgive me if I waffle a bit as I go through my apparent options, but i'm trying to get my thoughts in order here. :)

Visual C++/DirectX: I love programming in C++ and VC makes creating a functional gui very easy. However, I would prefer the game to have a full-screen colourful GUI, which links seamlessly to the match action. This would rule out VC would it not? I mean, I can skin VC apps but getting nice curved buttons and having background images is not really what MFC is designed for. This also doesn't solve my "game of two halves" problem. It's still a windows app which switches to DirectX for the match action. On top of which, i've never programmed DirectX, so there's an immediate learning curve there (although the VC side would be a doddle.)

BlitzMax: I love what i've seen of BlitzMax so far. It has a lot of similarities with C++ and has my favourite benefit of all - getting things whizzing around the screen in next to no time. Another huge plus point is that the game can be developed simultaneously for Mac and PC. The downside? NSS4 will be stat heavy, so the gui is all important. Ok, i can use MaxGui which allows me to create lists, combo boxes and so on, but if i want them to look nice I have to use some kind of wrapper like iGlass or HighGUI3 which to be honest, don't seem to be quite up to scratch.

Torque: I'm thinking TGB here rather than TGE seeing as though NSS4 will be strictly 2D. I've had a dabble with TGB and really should give it some more time, but my initial feeling is that it might be a bit lightweight. I've yet to see a TGB game dealing with something as complex as a footie match with 21 AI players running around the screen, not to mention the massive football database and career mode. (Point me in the right direction if i've missed it.) On the other hand, Torque's potential compatibility with Xbox360 get's more than a few neurons firing with excitement. Then there's the built-in netcode which could prove useful and like BlitzMax, it's cross platform.

There may well be other options, so please do suggest them but that's my thinking so far. In making my choice I guess I have 3 priorities in mind...

1) I want the game to look and feel like a professional product (one of NSS3 biggest drawbacks).
2) Speed of development is essential if I want to remain a full-time indie.
3) I seriously want the NSS series to be able to compete with commercial football games one day. This may take years to achieve so it's absolutely critical that I make the right choice now so that I don't have to rewrite the game every couple of years.

I welcome your comments. :)

[luggage]

You could stick to VC and use something like PTK? You might have to write some GUI code yourself but it really shouldn't take more than a day or two to get something usable.

Oh. And steer clear of MFC if you use VC.

[Jamie W]

Yup, another vote for VC and PTK here. :)

[Jack Norton]

Use PTK. I did to, and made my own crap GUI, but works :) took me just 2 days (and I'm not a good programmer).

[Applewood]

Whatever you chose, DO NOT EVER EVER EVER use windows dialogs. I won't even look at a game that does that as it says so many other bad things, apart from the classic "I can't even be arsed to make a nice gui".

[Applewood]

This may take years to achieve so it's absolutely critical that I make the right choice now so that I don't have to rewrite the game every couple of years.If you're asking questions like "which SDK should I use?", I wouldn't get carried away with plans like that. Take it as it comes

[siread]

If you're asking questions like "which SDK should I use?", I wouldn't get carried away with plans like that. Take it as it comes

Wow, thanks for the advice. :rolleyes:

[raigan]

if you do decide to write your own GUI stuff, you should check out the "IMGUI" stuff on the mollyrocket forums: http://mollyrocket.com/forums/viewforum.php?f=10&sid=3055f3df1e266c42595ff5092a077c0e

[Pallav Nawani]

You could also try PopCap Framework. It has ready made GUI classes for buttons, lists, dialog boxes, text entry widgets, check boxes etc. Although they're not very flexible, it is easy to derive from them and create ones to suit your needs.

It also has things like titlescreen widget, resource manager which loads resources specified from an xml file, software rendering etc. If you are interested in working only on Windows, PopCap framework is hard to beat.

Unfortunately, it works only on windows!

Another available library is HGE (Haaf's Game Engine). Like PopCap framework, HGE is open source (and free). It also has something that PopCap Framework dosen't have - A particle editor. But I guess its not that important, is it?
And like PopCap framework, it works only on Windows.

Edit: This question seems to come up quite a bit. Maybe we could have a sticky thread with a list of 2D game engines/frameworks?
Edit: PopCap/PTK/HGE can all be used with Vc.

[impossible]

You might want to look at CEGUI (http://www.cegui.org.uk/) or Guichan (http://guichan.sourceforge.net/). Either that or write your own GUI stuff. It might not be too bad depending on what kind of controls you need.

[Polycount Productions]

You have experience using VC so my recommendation would be to stick with it. Getting PTK (and whatever that is - I don't know) as others recommended to expand the capabilities of VC seems to me the "fastest" solution. Learning new tools and managing the odd stuff that every new dev kit has always takes time.

I'd vote VC (for the reason that you already know that well) and then either
- look for solution to get better gui system
- get rid of that "I'd like to get fullscreen stuff" feature if that's not crucial

In case you are (or somebody else is) looking for development kits, I'd like to remind that www.devmaster.net is filled with engines.

[HairyTroll]

if you do decide to write your own GUI stuff, you should check out the "IMGUI" stuff on the mollyrocket forums: http://mollyrocket.com/forums/viewforum.php?f=10&sid=3055f3df1e266c42595ff5092a077c0e

And check out the other side of the UMGUI coin:

UMGUI on SWENG (http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-September/003908.html)

[princec]

I'd use Java ;) Then I could develop an incredibly complex GUI based game in no time at all. When it was all working I'd just play around with look & feels until it all looked nice and professional and presto, done.

Cas :)

[siread]

Some good stuff there guys, thanks. Are there any good resources for PTK? The docs aren't very beginner friendly and the old forum has been shut down. Doesn't exactly fill me with confidence.

[Jack Norton]

Well if you really need a good easy GUI, then I would go with java as other have recommended. You're sure it will run even on other system as Linux, which could be a bonus!
I would have used java too, if I was able to understand it :o

[Deux]

How active is the ptk community ? I cant find a link to their forums on the ptk website.

Also, I dont hear much talk about SDL and or SDL.net, I take it ptk is a better solution ?

* EDIT, I take it this is the forum, which is well, kinda dead.
http://www.phelios.com/forum/

Oh, and BlitzMax is an awesome language, and a great choice too. For the price you cant go wrong either.

[raigan]

And check out the other side of the UMGUI coin:

UMGUI on SWENG (http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-September/003908.html)

meh.. having a lot of experience with RMGUIs via Flash, there's something refreshing about being able to add a slider by simply calling a function once, in one place -- instead of having to go define the slider during init, then write all the event-handling functions, etc.

possibly it doesn't scale well for super-complex GUIs, but personally i find it to be much more clear and easy/fast to use.

also, i think that post is misleading -- IMGUI vs RMGUI isn't about non-OOP vs OOP, it's about polling vs event-driven.

[simonh]

Use BlitzMax and write your own GUI code :)

[Jack Norton]

Oh, and BlitzMax is an awesome language, and a great choice too. For the price you cant go wrong either.

Blitzmax isn't good for big project like that...

[Deux]

Blitzmax isn't good for big project like that...

Says who ? and why not ? Whatever facts you have to back that up I would like to hear. I see no reason why one couldnt embark on a large project with BlitzMax.

[luggage]

Oh, and BlitzMax is an awesome language, and a great choice too. For the price you cant go wrong either.You can get a copy of Visual Studio and the DirectX SDK for free. You can't beat that price.

[HairyTroll]

also, i think that post is misleading -- IMGUI vs RMGUI isn't about non-OOP vs OOP, it's about polling vs event-driven.

I think it is more immediate mode versus retained mode. Having to compose an object each frame and then draw it as opposed to just drawing the object each frame.

But there is no reason why an RMGUI GUI can't be implemented to work like an IMGUI. The first call to drawButton(...) will initialize the button, set up the listeners and draw the button. Subsequent calls to drawButton will only draw the button as the initialization has already been performed.

[Deux]

You can get a copy of Visual Studio and the DirectX SDK for free. You can't beat that price.

True, but you can beat the speed of development.

[jwc]

Realmcrafter is a MMORPG made with Blitz3d (so even worse than Blitzmax). Surely you can create BIG project with it! and since there's even mac support now...

[zoombapup]

I'd go with TGB, but then I've used the torque engine for many years.. Just be aware, it can EASILY deal with what you mention.

[simonh]

BlitzMax is fine for big projects - you can split them up so that it only compiles the source code files that have changed.

I'd agree though that Blitz3D/Plus are not suited to big projects. Recompiling *everything* eventually becomes a pain.

[siread]

Well PTK is getting a massive thumbs down from me, so far. The example demo doesn't work, the documentation is sparse (at least for getting things started) and the (3rd party) set-up instructions are out of date. Oh, and the forum has been dead for the last 3 days. If the developers can't be arsed to provide proper support then I don't see it as a viable option.

[PaulModz]

I think it is more immediate mode versus retained mode. Having to compose an object each frame and then draw it as opposed to just drawing the object each frame.

But there is no reason why an RMGUI GUI can't be implemented to work like an IMGUI. The first call to drawButton(...) will initialize the button, set up the listeners and draw the button. Subsequent calls to drawButton will only draw the button as the initialization has already been performed.

I'm all for novel approaches to old problems, and I'm sure there are times when using an IMGUI makes sense (like the 1980s). With all the IMGUI hype, I took a good look at it before deciding it throws 20 years of technology out the window by pushing ALL the GUI state data out of the library and into you app.

Case in point, one of the hot discussion topics in the IMGUI world is finding a way to give each UI widget a unique ID, since the widget itself is stateless. This (http://sol.gfxile.net/imgui/ch04.html) is probably the best IMGUI tutorial that actually shows working code, and (I'm not making this up) it uses a preprocessor macro to set the widget's ID to its LINE NUMBER in the source file, with a few "tips" to help make sure widgets called on the same line number in different files don't collide!

Sorry if I'm stepping on any toes here, but the emperor is bare ass naked and not enough people are pointing it out to the noobs. One of the few game programmers I know by reputation alone, Brain Hook (he created the Glide API at 3Dfx before becoming one of the 3 coders who wrote Quake 2 and 3 at id), couldn't get an IMGUI implementation to work to his satisfaction and gave up on it, read it here (https://mollyrocket.com/forums/viewtopic.php?t=150&sid=36e024b29c78fb34d3d601b5be27a171).

[Emmanuel]

Creating/deleting GUI widgets isn't incompatible with polling. Atlantis 1/Fairies/Mystic Inn/Atlantis 2 use the same code (the garden golf GUI ported to ptk), where each game stage creates its own sheet of widgets (buttons, sliders etc) as needed, the widgets process events sent by ptk to update their state (outside of any game code and untouched since A1), and then the game logic update polls for state (isClicked(), hasNewValue(), etc.) as needed. Widgets are hierarchical -- just simple linked lists in the parent. Cleaning up takes a single C++ "delete" of the parent. It's a really minimal part of the code, and I don't see how IMGUIs would simplify this further while creating less new issues than they solve.. In any case if your intent is to create a game you should use something straightforward, worry less about engines and GUI and more about gameplay :)

PTK's examples are probably out of date, although the main point was to show you can make a fully working breakout game in 150 lines of code. Seeing as there is virtually no learning curve to use it, I'm sure you can get the examples to work in much less time that it would take you to make a dual D3D/GL renderer for pc and mac that has been tested and debugged on millions of downloads of our games, Jack Norton's games, or for instance, Fish Tycoon and Virtual Villagers on Mac.

Best regards,
Emmanuel

[siread]

PTK's examples are probably out of date, although the main point was to show you can make a fully working breakout game in 150 lines of code. Seeing as there is virtually no learning curve to use it, I'm sure you can get the examples to work in much less time that it would take you to make a dual D3D/GL renderer for pc and mac that has been tested and debugged on millions of downloads of our games, Jack Norton's games, or for instance, Fish Tycoon and Virtual Villagers on Mac.

I'd like to give it a proper shot but from Patrice's comments on the new forum, and the fact that it has been down for 4 days suggest that he's lost interest in the project.

All i'm trying to do is display an image with this code:

KWindow *myWindow = NULL ;
myWindow = KPTK::createKWindow( K_OPENGL ) ;
myWindow->createGameWindow( 640,480,16,true,"my game" ) ;

KGraphic *myPicture ;
myPicture = KPTK::createKGraphic( ) ;
myPicture->loadPicture( KMiscTools::makeFilePath("Title.png" ), 1, 1 ) ;
myPicture->blitRect( 0,0,100,100,0,0 ) ;

do
{
myWindow->setDefaultWorldView( ) ; //resets the transformation matrix
myPicture->blitRect( 0,0,360,181,0,0 ) ;
myWindow->flipBackBuffer() ; //display the drawing
}while(myWindow->isQuit() == false);

All i get is a black window with a white rectangle where the image should be. Now i'm sure it's something simple, but without any working examples or a forum where I can ask a question i'm stumped.

[Emmanuel]

My first guess is that loadPicture() fails (you aren't testing the return code). A white rectangle (texture) would be a symptom that nothing got loaded in your KGraphic.

I've eventually abstracted loading so that I could trust all the resources (and have a loading screen) :)

Best regards,
Emmanuel

[HairyTroll]

With all the IMGUI hype, I took a good look at it before deciding it throws 20 years of technology out the window by pushing ALL the GUI state data out of the library and into you app.

It's funny that you bring up the subject of technology. I'm not advocating the use of IMGUI. I guess I'm saying that implementing IMGUI is way more difficult than it needs to be depending on the choice of language.

[Bernard François]

All i get is a black window with a white rectangle where the image should be. Now i'm sure it's something simple, but without any working examples or a forum where I can ask a question i'm stumped.


I noticed exactly the same thing when I wanted to compile a ptk project which worked under windows on os x. Probably there was a problem with some header files or library files, since I tried to do everything manually (passing all include/library directories as parameters to gcc) and I think there's a big chance something went wrong on the way.

I think you should verify that you have added all needed header files and libraries to your VC project, and that you have proper versions of it.

But you could still try to post your questions first on the ptk forums. The more people do this, the more those forums will grow to a database of usefull troubleshooting information (I still don't understand why the old forums had been removed without migrating the posts...).