New SDK Game-Genre Frameworks...

#1 I kind of like the mission concept actually :) but just doing an apples for oranges name change seems a bit redundant.

Does simulation actually describe a set of objects loaded into a FPS scene any more than mission does?

I'd like to see a restructuring of some elements to get rid of game specifics for sure. But i dont think the naming scheme is the worst offender here either :)

I think part of the problem for me, is that a lot of the actual setup is done in scripts. This kind of confuses me, as its not easy to identify what components are in place and what arent. I like the script setup for game.cs and those things, but stuff like setting the client/server stuff up and loading the packages are all script side! whilst its funky, its not too readable (for me at least).

Phil.

#2 That sounds like a great Idea Melv, the SKD still has many FPSish or even Tribish things around, and Mission is one of the things I always disliked, I never thought of the word Simulation though, I guess it's fair enough. The common dir needs a nice cleanup too since there's many things there that should be in the game related directory.

-Xavier.

#3 I guess at some point down the road, when I'm futher along with the game, I'll just have to bite the bullet and start hacking things how I like em.

Its just scary to think that i might move away from the main codebase so much that I miss an important bug-fix.

Or more importantly, become incompatible with any major additions.

I guess the issue then is one of being able to combine codebases once they diverge in order to maintain nice and managable core function (to my taste) whilst being compatible with updated code.

Bah! I dont need to worry for a while yet :)

Phil.

#4 I think that the scripts need to take on a much more object oriented approach. I used the object oriented game scripts template resource for my current project, and it is much easier to see what is going on.

Yeah, I also like the idea of taking out the game related stuff from common... cant think of an example off the top of my head though.

But, what would be cool is to have a sorta, "Genre" class that implements all the stuff that pretty much every game will need, then you subclass that into Action and Strategy or whatnot, doing the Object Oriented thing. Then, it should be easy enough to create a new game.. just subclass one of these genres or sub genres (such as FPS for example), then work in your own code.

That would take a lot of work to pull off, but the way I see it, once you have the initial framework, the subclassing can be done to any degree, creating more and more specialised games.

Hope you understand what im trying to say, its 2am and im tired :D It would probably not work how I think it would, but such are the workings of the mind in the early morning ;)

Dylan

#5 Guys,

@Phil: Yeah, the thing about naming conventions is that they can be very personal. One persons "Mission" is another persons "Level" or "Simulation". I tend to go for the technically accurate, others for the aesthetically more pleasing terms.

I agree with your points regarding initialisation steps. Packages can potentially be very powerful and provide a nice hierarchical structure to your configurations but can be confusing at first. Paramount on my mind would be having a different organisation for the scripts. At the moment I still find them confusing and constantly second guess where stuff is.

The name of the script file strongly matching its content would make things much simpler. Sometimes things just don't fit and I would prefer to have them all bundled in a single server/client location under 'misc' or something similar.

@Xavier: Glad it's not just me!

Anyone else got any ideas?

- Melv.

#6 I used to like the idea of packages. Until they started acting up on me and werent turning off when I told them to and stuff. I like the idea of a clearly laid out object.

Eg. I started using packages for my gametypes, but I found that if I changed gametypes, some methods from the old gametype were being called over methods from the current one. So i did a search, and found that a few other people had this problem, and someone suggested useing objects for the gametypes, and wrote a resource for it. It worked much better, because you can delete the object (ScriptObject) and you know its gone. But as a game generally wont be changing genres too often, i suppose packages would work.

#7 We have begun this already: i.e., scene rather than mission...glad to see others taking the global view :)

#8 @Desmond: Hmmm, Scene is much nicer than simulation and easier to type. :)

I suppose technically you can have stuff in the Scene a.k.a. mission that isn't renderable but hey, who cares?

It would be interesting to see how far you've got Desmond, if that was possible.

Any other ideas anyone?

- Melv.

#9 @Dylan: I must admit that I don't particular like using packages as they do tend to make things a little too implicit and fragmented. I do believe that they are used cautiously in the existing SDK and not everywhere which is a good thing.

- Melv.

#10 I think that the optimal solution would be to do this change as part of a scripting language rewrite. Go to a "full" OOP architecture in a scripting language that supports it, and make a more agnostic design.

I personally think mission is as good a name as any for that on which the simulation operates, and I think renaming mission to Simulation makes things confusing (ie, SimulationGroup vs SimGroup), but those are my opinions, and not very well thought out ones at this point, either. :)

Packages are an incredibly useful tool for modding, but they should definitely be used in moderation.

#11 Hmm.. Simulation... I hate that word!
Scene I vote for! :D

The main reason why I hate "Simulation" is simply because it was abused in many past games making the game feel so freakin fake that it was not acceptable. Scene just makes it seem more realistic, sure it isn't really "real", but when people game or develop they prefer naming that makes it feel more real.

OK I lost my train of thought. Also won't renaming stuff break a lot of scripts and code? :\

#12 Guys,

I serious don't expect everyone to choose words now and certainly nothing like my choice! Simulation was appropriate for what I was doing and was part of a 'bettering' experiment and this thread is a continuation of that.

I'm just trying to inspire a little thought into ideas that may improve the framework ... got to be a good thing.

I think different frameworks would serve to inspire new and hopefully unique ideas from the indie community. The talent is there, now there's an engine and all we need now is some wonderful inspiration. A push towards non-FPS ideas would be super sweet. There's got to be a few people out there who don't want to spend time on a full game so perhaps they could think about doing a game-genre mod instead?

What I'm trying to develop in this thread is a discussion on whether you all think that an natural extension of the existing framework is called for or a radical shift in the layout in terms of getting different game-genres up and running.

Maybe the answer is *not* to put different genres in there but to have a really simplified core framework that people can take and run with. People with plenty of coding experience can use the existing scripts and get up and running quickly but I'm thinking of the people with good ideas that perhaps cannot bring them to life.

Some juicy ideas to inspire...

Action
Fighting
FPS
2D Scroller

Adventure
2D-Cartoon
First/Third Person
Hunt

Puzzle
Various Board
Geometry
Mechanical
Education

Recreation and Sports
Billiard&Pool
Cards
Hunting
Pinball
Sky-Diving
Baseball
Basketball
Bowling
Boxing
Cricket
Football
Golf
Ice Hockey
Professional Wrestling
Racing&Driving
Rodeo
Water/Snow Skiing
Speedboating
SoccerSurfing
Track&Field

Role Playing
RMOPRG (Realistic Multiplayer Online RPG)!
2D Pen-Paper Die Throwing Jotter System (for real RPGamers)

Simulation
Flight
Life
Racing&Driving
Space
Submarine
Tank

Strategy
Cards
Board
Military

Virtual Reality Presentation
Architectural Visualization
Scientific Visualization
(to attract universities and architects)

Wacky (I just made these up)
3D Characters (e.g. models sitting around a table or moving about) IRC
Day in the life of a Sewer Rat
Car Salesman
Nano Olympics (arena is everyday room)
Build and run a space station


Some good opinions coming out here ... come on guys ... more ... :)

- Melv.

#13 Come, Melv, we all know that the name is the most important part of any project... :P

I'd love to weigh in, but I don't think I can say much meaningful about the scripting layer. I haven't yet tried to totally change the gameplay to something non-FPS... :-/

#14

Quote:come on guys ... more ... :)

lol something about that reminded me of Agent Smith in the Burly Brawl fight in Matrix Reloaded :D

I was going to start on a top down 3d space shooter (2d movement). I could do p a prototype/starter kit to get the core gameplay, before I actually start adding game specific stuff.

But, yeah. Now that I think of it, making the start kits should be just that. You download the kit you want, then start modding.

#15 I'm listing sub-projects to work on for next year and have got Strategem and another project sorted. I'd like to think that I can also make time to put together a couple of these mod-frameworks myself for the community, starting with a turn-based one.

Anything that could potentially make the TGE more accessible is good in my books.

Maybe next year this thread will get picked up where we left off. :)

- Melv.

#16 I think this is a great idea Melv!

Add
Virtual Reality Presentation
Architectural Visualization
Scientific Visualization

...to attract universities and architects to GG too.

-Bendik

#17 Well, there are a few conceptual issues inside the engine I'd like cleaned up. The scripting language itself is fine imho, but the structure of where things are right now could do with cleaning up.

What concerns me most, is the obfuscation of how to create simple objects.

Ive always disliked the datablock idea, I'd rather see distributed class static data, but thats just me :)

Other area's I dont particularly llike the look of right now?

Zone management. seems very "black box" and not uber-well-commented.

There are a lot of things in the environment that are hard-coded that shouldnt be. Things like sky, terrain, etc etc. Those things should just be classes of objects in the scenegraph, much like anything else.

In fact, I'd like to see a more generic scenegraph api, which can be used for generic object containment. Objects could then be kept in different scenegraphs for different things.

As far as specific genre's go, I think I'd start with getting a "back to basics" script codebase up and running. Get that sorted out, so you can get a blank slate.

Now thats a damn large amount of work really :)

I think basically, moving torque towards being more "generic" is a good thing. Being as its more a sort of middle ground between totally starter engine (click and play style) and the sort of mad-as-hell engines (quake style), I'd say we should move towards the generic in most things.

I'm not a big advocate of deep inheritance in engines, but at least making things non-object-specific (for instance, try taking out the landscape stuff), such that it is all modular and can be peiced together in ANY way, is a good thing in my view.

BTW: I'm doing a SDK pack, so keep yer mitts off!

Phil.

#18 @Phil: Good stuff; my mitts are official off. At least until May'04 so you've still got some time. ;)

@Bendik: Added to my list! Good to see you back on the forums; hope the family is well bud.

- Melv.

#19 I read somewhere (I think it was the enginuity tutorials on gamedev.net) that when you start building an engine, it has lots of possibilities for what you can do with it. But as you build it and add things, you start to focus the engine to a specific game or gametype. The only way to use the engine for another gametype is to remove the feactures bit by bit, then add new ones.

I dont know how true this is, but if it is, maybe we need to have multiple versions of things like the 'game' folder in the engine directory for different genres. That way, you compile the engine version that suits your game.

Or is this just about making different genres in the scripts? Because I dont see how you can do that without touching the C++ code.

Dylan

#20 Dylan,

The way the TGE is organised at the moment is that a majority of the engine is abstract but anything off the game directory is game-specific. Of course, this hasn't been completely adhered to but is pretty close.

My main focus was the scripts with potentially new custom genre-specific C++ objects hanging off the game directory or a new sub-directory specifically created for different genres.

- Melv.