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!
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.
Within this framework there's a lot of freedom, but here are some things I want to accomplish:


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.
But, most importantly, it could be significantly more finished with the help of you.
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.
EDIT: here's the design doc.
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.
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.

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!
#22
10/21/2014 (1:38 pm)
sorry, I mean the edge-detect shader.
#23
EDIT: New art style? Courtesy of Duion's suggestion:
10/21/2014 (1:50 pm)
Oh of course. It's pretty easy!EDIT: New art style? Courtesy of Duion's suggestion:
#24
10/21/2014 (3:06 pm)
In that article it says git stores binary files, all versions of it, so if you commit a 10mb file 10 times, you added 100mb to the repo, or much less if it can be compressed well, but it will add each time.
#25
10/21/2014 (4:47 pm)
Where are you reading that from? This is bullet 2 in the accepted answer:Quote:2. If I change the binary file, so that I have 100 binary revisions, will git just store all 100 versions individually in the repository?Of course it adds each time, so does committing a text file. I'm not saying this is a good practise but it's not as bad as you think.
2. No, Git will attempt to store delta-based changesets if it's less expensive to (not always the case).
#26
10/21/2014 (5:07 pm)
Yes, it says sometimes and sometimes not, but I would not want to risk it, once you commited big files of useless data it stays there.
#27
10/21/2014 (6:07 pm)
So in other news, can we use parallax mapping on objects, or only on the terrain? Having parallax-mapped greebles on shapes like the one above would be perfect.
#28
10/21/2014 (6:50 pm)
parallax is a standard material ability.
#29
10/22/2014 (2:33 am)
Yes, works, but only properly with png images and does not look as nice as in other engines.
#30
Need to do some tests.
Next week. Argh.
10/22/2014 (3:10 am)
Also, according to IRC discussion with Az, the parallax won't be represented in the z buffer, which means it won't show in an edge detection postFx AFAIK. Although, I do think the shader I've been using can take normals into account, so maybe it will work somewhat...Need to do some tests.
Next week. Argh.
#31
About the edge detect, didn't Ron come up with a tweak to that shader where it fades out with distance? The current shader makes objects far away look very dark, and also show through thick fog.
10/22/2014 (6:49 am)
Thought I posted something here last night ... so here's a quick recap.About the edge detect, didn't Ron come up with a tweak to that shader where it fades out with distance? The current shader makes objects far away look very dark, and also show through thick fog.
#32
10/22/2014 (7:28 am)
Thoughts on guns: Cover at least one of each of the major types in modern games: Full-auto assault rifle, sniper rifle(with zoom), semi-auto rifle(maybe?), Submachine gun, pistol(duh), grenade launcher(maybe even with smoke grenades as an option), rocket launcher, maybe a minigun with spin-up, and a shotgun(which the default FPS template sorely needed). Maybe also do different types of grenades like in Counter-Strike.
#33
10/22/2014 (8:12 am)
A lot of plans for such a short challenge... I would call it a win if we can get anything working.
#34
The game idea/layout I definitely can agree with and certainly would love to have an alternative to the 'Full' template for FPS needs. I think it would be safe to say that getting a prototype or an idea for the template during the 7DFPS would be the ideal goal than refining and revising said template into a more clean professional product after the fact.
I would also be interested in contributing some contextual systems as I've been playing with an interaction for the past 6+ months. I just hope I remember this challenge after I return from PAX.
10/22/2014 (12:18 pm)
I certainly would like to contribute, I'm primarily an artist to begin with so that side of things I certainly can contribute. I will state now that the visuals will be... not so great as it is a game jam and things will be rushed. I also feel that the coding side of things too will be... a hack job in areas.The game idea/layout I definitely can agree with and certainly would love to have an alternative to the 'Full' template for FPS needs. I think it would be safe to say that getting a prototype or an idea for the template during the 7DFPS would be the ideal goal than refining and revising said template into a more clean professional product after the fact.
I would also be interested in contributing some contextual systems as I've been playing with an interaction for the past 6+ months. I just hope I remember this challenge after I return from PAX.
#35
10/22/2014 (2:25 pm)
I'll have to agree with Duion here. That's a very ambitious project you're embarking on. Good luck, though.
#36
10/22/2014 (3:02 pm)
I think it is possible, but I can only speak for the art-side of things, my example terrains took me around 3 days to do, in 7 days I could build slightly populated levels, but then we will have no functionality, so we need more people that are familiar with scripting and other disciplines needed.
#37
Steve: that'd definitely be good. Might shoot Ron an email when I start looking at this seriously.
Chris: that's basically the gun plan. Good idea to have a spin-up minigun in there, though it may end up being a slightly different weapon (maybe a charge-up energy weapon).
Glenn: I should have some t3d-bones examples of context button pushes online by the time we start this. The jam will probably involve making nice UIs and sorting out how to cleanly provide lots of different context actions within a nice framework (like, doors say 'push e to open' whereas vehicles say 'push e to drive').
10/22/2014 (3:46 pm)
Yep, this is stupidly ambitious :P. And yes, it will probably take a bit of refactoring after the jam. Though as I said, I hope to have a lot of scripting systems done before the jam begins, and to spend the jam integrating, polishing, and extending the core designs. Basically, making a game from those systems.Steve: that'd definitely be good. Might shoot Ron an email when I start looking at this seriously.
Chris: that's basically the gun plan. Good idea to have a spin-up minigun in there, though it may end up being a slightly different weapon (maybe a charge-up energy weapon).
Glenn: I should have some t3d-bones examples of context button pushes online by the time we start this. The jam will probably involve making nice UIs and sorting out how to cleanly provide lots of different context actions within a nice framework (like, doors say 'push e to open' whereas vehicles say 'push e to drive').
#38
10/23/2014 (4:19 am)
I am not a fan of this edge detect shader, to me it is more an excuse for bad graphics, so you can later say "Hey it is intended to look like this"
#39
10/23/2014 (5:14 am)
Actual intent is to make it possible to see what's going on when there are no textures. At doing that, I think it's very successful. It also lets me focus on what's important in the game without worrying much about the look.
#40
10/23/2014 (6:04 am)
You just throw up new problems, if you want to develop a whole new art style, in such a short challenge I would stick to what is already there. 
Torque Owner Daniel Buckmaster
T3D Steering Committee
Richard: ah yeah, I didn't mean to call it a template but I have that word on the brain :P.
Jose - what shader?