Game Development Community

dev|Pro Game Development Curriculum

7DFPS 2014: let's make a better FPS template!

by Daniel Buckmaster · 10/20/2014 (2:24 am) · 53 comments

I've been umming and ahhing about what I'd like to make for 7DFPS this year. I've finally realised the answer was staring me in the face: a new FPS template for T3D!

But we've already got an FPS template!

We do - the Full template is set up as a kind of poor-man's-arena-shooter, just waiting for you to come along and add your own content. But I have many problems with it, the most important of which are:

  • The gameplay is outdated - I want to demonstrate features like iron-sights, dual-wielding, grenade-throwing, melee attacks, and other stuff that has happened in shooters since 1999. Having examples of scripted events would be super helpful, too - the current template gives you no help if you want to create a single-player or co-op experience. I'm not even talking QTEs or big COD setpieces, but simething as simple as having to set switches to open a door - and having a win condition for the level, and managing the flow of clients joining so they don't just spawn immediately. But it'd also be good to just do solid FPS Gameplay right, and not have the machine gun stutter and fire at uneven intervals.
  • It doesn't provide examples for most of T3D's included features. This has been remedied slightly with the inclusion of the Outpost level in 3.6, which aims to just chuck in as many stock objects as possible to make them easy to test. But they're not exactly used in a useful or attractive way. And there's so much more we could be using and doing with the existing features that are in the engine.
  • The code is structured in a way that makes it difficult to modify. Functionality is split between different code files (e.g. datablocks in one folder and scripts in another), at the same tie as being bunched up in monolithic classes (e.g. Armor). Even though the engine includes ways to make changes by composition (e.g. EventManager) instead of modification (e.g. adding more stuff to existing callbacks), they're not used. And there's a big dose of callback hell going on (e.g. the mission loading sequence), which could be replaced by something easier to understand or modify (e.g. a state machine).
  • It's just not any fun to play! I honestly think a template should demonstrate at least a glimmer of fun, something that needs to be polished, rather than something that needs to be replaced entirely.

So what do you propose?

Well, basically, to fix all these problems. I want to make a simple FPS game that can act as a base for people to make their own modern FPSs. I want to demonstrate the use of lots of stock classes, while avoiding habits that the current script templates fall into. I want to make something fun and useful. I want to provide a large chunk of high-quality, well-documented code that allows learning, rather than demanding that it be learned. And I want to do this all in 7 days (ish. see below).

Why do you get to decide to replace the current template?

Because I'm on the Steering Committee. Muahahaha. I'm not being serious, don't worry. Or am I? But really, this question is a straw man. I'm not aiming to replace the current template, so don't panic. I want to provide an alternative that's hopefully better. If it proves to be so, and adoption of this template means the old template isn't needed any more, well, I can't say I'd be sad to see it go, but nobody will be forced into using it.

This ties into some plans the SC have been making for increasing the ease of getting new content (like templates) into Torque, so watch this space for news on that exciting front. Ideally, this template will be the first in a new wave of many better stock templates that users will be able to easily pull down and start working from, and which will be maintained and improved independently of the main engine.

Are you even allowed to do this for 7DFPS?

Let me quote the entire 7DFPS FAQ here for you:
Quote:
Q: Can I- A: yes.

Okay, so what will this new template look like?

On a basic level, I want it to take the form of a single-level co-op game. You will make your way through a linear progression of script events (note, though, that the map will probably be nonlinear, except for locked doors), and co-op partners will be able to join you along the way. You'll fight through some really basic AI opponents (probably just turrets, unless someone really wants to write enemy AI), and eventually fight some sort of boss. At this point the game will probably just restart, but I'm open to other suggestions.

Within this framework there's a lot of freedom, but here are some things I want to accomplish:

  • Halo-like weapon pickups (i.e. you can carry two at a time, and pick up ammo from weapons on the ground), grenades, and items (you can carry one at a time, except maybe for special cases).
  • Iron-sights, dual-wielding, melee attacks, and grenades. I imagine these all working pretty normally. Refer to Halo for melee, though possibly not grenades (maybe they'll be a separate thing you switch to).
  • Some little vehicles, like the Ghosts (hover bikes) from Halo.
  • Enemies, which are important if single-player is a thing. Some ideas include a floating blimpy sort of thing, turrets (since they don't need much AI), and possibly foot soldiers with basic AI if time constraints allows, or if someone else wants to hop in and work on them. Maybe even some larger ground types. Also, enemies that are dropped off by dropship. All-time favourite.
  • Context-activated buttons! And other things. Can't decide yet whether they should be distance-activated like Halo, or whether you have to look at items.
  • Bunkers! Both above and under ground. They'll be important to the 'plot'.
  • Locked doors (or force fields, or whatever) and switches that open them. Basic FPS plotting, really. There may be 'cut-scenes' where all players are shown a door opening or something when you press the right buttons.
  • Juice! By which I mean, effects. Explosions, particles, and hopefully sound effects. None of them will be particularly good, I'm sure, but I hope that quantity will make up for quality.
  • Lots of guns. An improbable quantity of guns. Not quite the 50 bazillion that Borderlands had, as these will all be hand-tailored, but I want to cover the FPS staples and then some. And maybe separate melee weapons. We'll see.
  • Bombs. Sticky bombs, bombs that create physical zones, bombs that explode on impact, bombs that settle then shoot projectiles in random directions.
  • Recoil. Hopefully. It's kind of important.
  • Drop-in co-op, which means a master server. Don't worry, it should be a breeze. I might also get around to arena deathmatch or team deathmatch, which are important to demonstrate.
  • Using Twillex for stuff like thickening the level fog over time.
  • Full controller support, yeah.
And importantly, I want to achieve most of these with as little source-code-hackering as possible. Any hacks that do need to be hacked will be done so in as responsible and general a fashion possible. This means adding project-specific classes instead of modifying existing ones extensively, fixing bugs in ways we'd be happy to contribute back to T3D's main repo, and generally being responsible coders.

What about the art?

Aha, you've remembered that I'm not exactly the artistic type. I plan on using mostly textureless, low-poly assets with flat colours and an edge-detect shader to make a low-res graphic-art sort of look. The art assets, which I hope there will be many of, will focus on function. Animations will be the most important part, as well as just making sure everything has its own asset. I mean, I will attempt to provide decent quality that someone would potentially reuse in their own prototype. But when it comes to prototyping, having lots of assets is better than having good assets.


i.imgur.com/JkWJ9Nl.pngwww.mobygames.com/images/shots/l/41567-jsrf-jet-set-radio-future-xbox-screenshot-this-game-presents.jpg

Something like this, with more colour than the first and less than the second

That said, I do want to make the game look nice, and show off some of Torque's built-in coolness like HDR, glow, fog and so on. As well as new hotness coming in 3.7 like accumulation volumes and ribbons.

This sounds like a lot do to in 7 days

Especially with an exam at each end of the week. I don't necessarily intend to finish this thing completely in the 7 days which are allotted. For a start, I'm going to cheat a bit by doing as much research and design in advance as I can. Level design will hopefully be entirely done before the jam starts. Also, I've been meaning to write a master server tutorial for t3d-bones anyway, so that can hopefully be directly used in the template, assuming the code quality is good enough. Same deal for a default character mesh and some animations. And of course I'll keep working after the jam is over to make it into an actual template that someone might want to use (I'm sure some code cleanup will be required - and there'll be lots of documentation work to do).

But, most importantly, it could be significantly more finished with the help of you.

Me?

Yes, you. I'm hoping to make this a community affair. We so often talk about making a community game - and don't get me wrong, this is not that. I plan to be the supreme overlord of this project, and will make any and all decisions finally. But if you'd like to be a part of creating something great for Torque, with Torque, then I'd welcome you aboard.

You don't have to participate for the whole week. Want to contribute a single art asset? Cool. Want to write a single weapon script or enemy type? Awesome. A particle effect? Love it. If people are interested in coming aboard for a day or two, that'd be fun - or if they want to work on a feature over the entire week, just putting in a little bit every day, that'd be sweet too. If there's significant interest I'll work up some ways for us to collaborate, like having a formal task list and so on. We'll probably hijack a corner of the wiki to communicate and document our work.

But I must again stress, I won't be running this as a 'community game'. It'll be my project, subject to democratic feedback of course, and I feel like I'm pretty reasonable when someone gives me a good argument. But we won't have a lot of time for discussion or debate in a week-long project.

That doesn't sound like any fun at all

I'm saddened you feel that way, but I'll be doing this regardless! I'm going to try to force myself to release a video update every day, because the blog updates I tried during Monster Mash ended up being a bit tedious to write, but I liked sharing my thoughts.

EDIT: here's the design doc.

You haven't mentioned when this is happening

Oh! 7DFPS starts on November 8 and goes until the 15th. That's about three weeks from now. Reserve a place in your diary!

About the author

Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!

Page «Previous 1 2 3 Last »
#1
10/20/2014 (4:22 am)
sounds fun..I hope every things works out!
#3
10/20/2014 (5:50 am)
Why replace? Why not add? Leave the "full" template as maybe "basic" and add the proposed as "StarterFPS" like the old one from TGE. While the current Full Template is indeed boring to play it does start you off with some useful functionality - needs cleaning up, sure, but useful still.

Everyone points out the lack of information, but we still want to cut things out to trim downloads. Perhaps offer the templates as a single tarball, the engine as another, and a large combined tarball for those who don't care about download size. Also, split the templates into their own repository if they grow too large. And clearly document the layout, of course....
#4
10/20/2014 (6:32 am)
Ahem, the 'armor' script class has been long gone.

Twillex... wasn't that script driven? If so why not use (expose if necessary) the ease functions that are already in Torque?
#5
10/20/2014 (8:33 am)
@Michael Hall
It's not that simple, the easing functions are only 50%, you also need a manager to manage the ease functions.
I created a prototype for an engine side Twillex engine which I'm willing to share, I think Aswin has a more complete version of the C++ Tweening in his UI kit that he might be willing to share as well.

@Richard
What if the new template could do everything that the old one could, just in a nicer way and with better features? It gets a bit confusing if we have 3-4 different templates for each genre, we should IMO keep it to 1 template per genre.

@Daniel
Could this mean that you'd cut out some of the FPS-template specific code in the engine and either implement it in the scripts or isolate them into the project-specific folder (as described here)?
That would make me a happy T3D developer! I despise the FPS-template specific code thats in the engine atm.. I want to burn it with fire... But then I'd have to buy a new computer..
#6
10/20/2014 (10:13 am)
Daniel, you are *awesome*. Probably won't have time to contribute, but delightedly awaiting Nov. 15!
#7
10/20/2014 (10:56 am)
I like this. A lot. I'm also really interested in this sentence:
Quote:This ties into some plans the SC have been making for increasing the ease of getting new content (like templates) into Torque

When will we know more about that???
#8
10/20/2014 (1:08 pm)
Sounds awesome...Good luck, Daniel.
#9
10/20/2014 (1:10 pm)
Richard: IMO the stock templates have too much baggage. Starting afresh is the easiest plan for me. It's definitely a little bit of 'not invented here', but I spent a long time breaking down the stock templates to make t3d-bones and firmly believe their structure is not really the best.

Separate downloads are the idea. We've started doing that this release, offering the Full template separately. We want to go even further with that. Andrew, we'll talk more about that when we have the time ;P. I just wanted to be a tease.

Michael: good idea using the built-in tweening stuff. Also, thanks for calling out my Armor mistake, but my point still stands in reference to the PlayerData class... which arguably just means that you can't opt out of it now. I've long been unhappy that the only way to add features to the stock script classes was to edit player.cs. Meant that addons like UAISK had to have install instructions which required you to merge changes into those files rather than being able to add anything on in their own files. Subclassing is a thing, but only to a limited degree, and it locks you into a linear hierarchy.

Lukas - definitely want to make use of the project source folder. As for removing FPS-specific stuff from the engine, that's something I hadn't thought of. Will ponder that. Of course the problem is people might be using it, and not want to have to come get it back from this template. But it's a decent idea. My major misgiving with the method of replacing engine files with files in the source directory, while cool, is it requires you to manually edit the solution after the PG has run. If the PG had a way to let you specify engine files to exclude in .config files I'd be all over it.
#10
10/20/2014 (1:15 pm)
Then remove it in 4.0... Please just remove it! It's horrible! I don't care if people are using it! :P

Why can't we do that in the PG? Seems like it should be able to handle it..
#11
10/20/2014 (1:56 pm)
Daniel @ I've been playing around with the stock AI and recast -- will volunteer to help you get some basic AI functionality - so you don't have to stick with just turrets.

It's not too difficult to modify the existing AIplayer scripts and get them moving using recast to navigate. But would be so much better than watching them get stuck on the environment, when trying to straight line to their target.

Just would need to consider range of the AIs weapon and range to target, etc... so they move into range, then fire and so on.
#12
10/20/2014 (2:30 pm)
Lukas, that sounds like a viable approach. Good plan.

Jeff: that'd be cool! I have the basics of recast navigation but I've yet to really use it for much interesting. Note that I will probably dictate the use of state machines for AI, particularly this one as it's light and useful. Example at the top of this file. I take a lot of inspiration from Halo in this game's design, so I'd want to be doing stuff like leaping out of the way of grenades, and running away when lots of friends die.

Also, for the record, I know there's a ton of useful stuff in stock scripts, which I'll be attempting to pick out and use where appropriate. For example, the messaging functions like BottomPrint are great for prototyping.

EDIT: Another style reference from an earlier project I never got far with. I imagine adding a bit more colour, and having less complex assets, but this is the general feel I think.

i.imgur.com/JkWJ9Nl.png
#13
10/20/2014 (6:04 pm)
I love this idea.
#14
10/20/2014 (6:16 pm)
Quote:
What if the new template could do everything that the old one could, just in a nicer way and with better features?

What about just cleaning up the current Full template?

I'd really like something that is "boot to blank FPS" in there. There were many people complaining that the Empty template wasn't empty enough, now we're talking about the Full template being too empty.

In my opinion it would be better to compile (over time, of course) a library of templates. If there is a "Quake-like FPS" template and a "COD-like FPS" template, that's even better - it gives you the features you want and fewer things to rip out. In fact, I'd rather people were confused by too many choices than just confused by the two that they have now....

@Daniel and Jeff - hey guys, stock AIPlayer+ https://github.com/RichardRanft/AITutorial, feel free to use whatever - but they already close on targets that go out of LOS, and they move to get in range with grenade-like weapons too (but I managed to break something - the grenade launcher I think). The scripts also reduce "think" rates for units far from player cameras to save cycles.
#15
10/20/2014 (6:29 pm)
Richard, having a whole library of templates is exactly the plan. This is one of them. Empty is indeed too full, and Full isn't really a good place to start on anything. As for modifying Full, honestly, it seems like less work to start from scratch. I'd be modifying all of Full, so it wouldn't really be the same codebase any more anyway. It's not just about 'cleaning up'. Fundamentals need to change.

Thanks for reminding me of the AI template, though I would prefer to rewrite it with a state machine. Also, XML comments make me sad :(. Comments are for people, not machines! But props on being thorough.
#16
10/20/2014 (6:55 pm)
Love the whole push here. I think a "new & improved" FPS Template would definitely help out here.

I'm not sure if I'll be able to contribute during the time period, but something else to consider for the list. Y'might want to make sure that for ADS-ing on iron sights to improve accuracy versus not ADS-ing, kind of gives a more "modern-day FPS" feel to things.
#17
10/20/2014 (8:15 pm)
Oh right, I didn't see this quote by Lukas
Quote:It gets a bit confusing if we have 3-4 different templates for each genre, we should IMO keep it to 1 template per genre.
But we don't have 3-4 different templates! I think that if we did though it'd be good. People would have more options. Nobody will come up with a one-size-fits-all template, so viva la diversite!

EDIT: after some discussion with Jeff R, we have decided that the template shall visually take after Halo and F.E.A.R.. However, for the purposes of 7DFPS, we probably won't be able to have a high level of visual quality. Will depend who wants to contribute and whether they can be bothered making textures :P.
#18
10/21/2014 (4:16 am)
Modifying the templates in the main repository is not a good idea since there is already a lot of junk data in there because of the templates and art files and each time you commit big art files the repository grows in size each time you commit it.
In my opinion the main repository should not contain any templates, just one, mostly empty of art files, just with basic placeholders. But now where we have the things in there it does not make sense to delete them from there, since it will not reduce size. Git does not compare binary art files, the whole file gets added each time.
#19
10/21/2014 (5:46 am)
Quote:
Comments are for people, not machines!
They're for people and machines. Not many document tools will bother pulling C comments out - just doing my part for the automated document generator.

And I don't know if I'd call that one a "template." It was the script accompanying a tutorial that I wrote in my last week at GG - the tutorial never made it into the documents, though. It uses what was already there for "states" - tasks, really, which is pretty flexible (but I'm not sure if I added a way to flush the task list). David Montgomery-Blake and I spent a couple of hours "deathmatching" with it and found that you can have quite a few units in a mission with it as it stands.
#20
10/21/2014 (9:45 am)
Is it easy to make that shader? If not, could I suggest that you release the template as soon as possible with that shader and then keep updating it from there?

For me, the more templates the better. As long as each template comes with a very good explanation of what it comes with and what we can do with it.
Page «Previous 1 2 3 Last »