First Person Shooters as I remember them

I grew up with video games in the late 90s, and one of my favourite genre of games was the First Person Shooter. Since then games have come a long way, both from a technical standpoint as from a design perspective. There's a lot of layers in modern games, different ways of  rewarding the player for doing well, and many different ways to keep the player engaged through the ups and downs of the game, or its story.

However, something isn't quite right with FPS in recent years. I feel that, although the industry has made great strides, something has been lost in polishing and pushing the genre forwards. Even modern titles that are said to harken back to the shooter days of old seem to miss certain elements that I enjoyed in shooters growing up.

There's always plenty of build up starting out. We get a cut-scene, either in-engine or pre-rendered, introducing us to the character cast, the universe. Often times there's some introductory phase where we, as the player, are introduced to the game's mechanics and systems. Slowly but surely we're brought up to speed on the game and the world our character inhabits. The story arcs dramatically and is inter cut with a variety of different gameplay sequences. Some of these sequences bring us particular weapons, carryable or stationary, to resolve the situation at hand. Health often times regenerates over time, necessitating the use of cover, and our objectives are clearly marked, and usually straight ahead of us, albeit in varying distances from where we are now.

While I don't want to say that any or all of these are bad, they make an FPS a very different beast from what it was. And I miss the beast that FPS used to be.

I miss shooters that let me jump in and get to the action right away.
I miss not having to invest in a character cast, or a storyline, in order to enjoy some gameplay.
I miss when the only break in play was when I decided to go back to see if there's anything I missed.
I miss trying to find secrets and alternate routes through levels.
I miss building up an arsenal of weapons, each giving me different ways to approach a combat situation.
I miss having to manage my health, heading into a new area with plentiful health because I worked for it.
I miss moving around, trying to get good shots off and evading damage, instead of hiding behind cover.

It sounds like many different companies are working on bringing back this sort of game. Cliff Blezinski is said to be working on an Arena Shooter, word is that the new Doom looks to be much higher paced than its predecessor, there's a new Unreal Tournament in production that looks to fill that hole as well.

I don't yet feel comforted, knowing that what I loved is making a return, but it seems I'm not the only one who seems to think we might've thrown out a bit too much under the veil of innovation and moving forward with the genre. It's to this end that I decided to try my hand at a prototype, to see if I could capture something of what I've been missing in FPSes.

The prototype comes in the shape of a Source mod. you can download the prototype below. Simply extract the folder called 'SpaceCorridors' to your Steam/SteamApps/SourceMods directory and restart Steam.

Download Link

I would love to hear any feedback on what this prototype does and does not manage to achieve, as well as any thoughts you may have on modern and classic first person shooters.

General Topics - Game Design

A lot of people read the term 'Game Design' and begin filling in what that means to them. For some people it's an umbrella term to describe the development process of a videogame from inception to completion, others refer to story boards and character outlines when talking about the tasks of a game designer. It seems to me that a lot of people and institutions have this spectrum of things in mind that relate to game design.

And all of these fail to do the term justice.

Game design is a very specific part of the game development process. It's a part of this process that begins at the inception of a game and lasts throughout the game development process into well after the game is released. The designer(s) work to make every aspect of the game, every individual element, support the overal themes and goals set out for the game in question. It is a highly iterative process, and affects the entire project at one point or another.

A capable game designer can make a game feel like a cohesive whole, something more than just the sum of its parts. A well designed game will explain its mechanics, the lore and central themes of the story to the player, without having to explicitly verbalise these. In much the same way that cinematography can tell you a lot about a character, without them having to speak any dialogue, in a film, the same can be done through each of the elements that make up a video game.

If you have ever played a game that did not explain itself clearly enough, a game where you get stuck because you don't know where to go, a game whose confusing interface did not help make the game a smoother experience, it is a failing of the game's design, and by extension, its designer.

Now obviously, there are more people involved in game development to consider in all of this. A game designer is dependant on the skills and cooperation of the rest of the team. If a designer has no voice in the process, their efforts may be lost. The same goes if a designer is unable to clearly communicate the design, and its ramifications for each discipline, to the varying team leaders and/or team members. It is therefore extremely important that a designer has some insight into each discipline. The better they understand the work being done, the more accurately they can communicate their wishes to the people involved, and as a result, help these elements support the design ideals.

I belive that a good designer is marked by these properties; an understanding of design principles, the ability to effectively communicate, willingness to re-evaluate design decisions and personal assumptions, and an insight and appreciation of the varying game development disciplines.

It is my belief that a capable game designer, coupled with an able team, are the bare essentials required to create a succesful game.

Results and changelogs

I've been pretty busy over the past few weeks with a lot of things related to Game Development, but not necessarily CubeWars. We're currently working on getting this set up as a business which is pretty time consuming but also a very cool and promising prospect. Because of this I haven't had the greatest amount of attention for CubeWars.

That doesn't mean that I didn't spend any time on it however!


The past 2 months I've spent a lot of time getting the Interface handling done and today I can finally say that the framework stands! Again! I've done some cleaning to prevent a lot of duplicate code and to make it easier to add new Interface elements in the future, though I'm pretty confident that won't be necessary... or at least that much.

On the functionality side I've finished up the multi-layer gizmo which let's you turn on/off layers for viewing and sets which layer you're currently editting. I've also added in a 'solid color view mode' which draws tiles as colored rectangles representing the layer they're on.

Below you'll find an *extensive* changelog of all the things I've been doing since the last update. It can get pretty technical, so consider this a disclaimer for the uninitiated.

Until next time!

---

(Most recent commit at the top)

- Added Toggle group functionality, only 1 toggle will be on in each group
- Added animationstep(level*, player*) to the Window Manager
- Moved existing animation code from putscene(level*, player*) and draw(int) to animationstep(level*, palyer*)
- Moved level::animstep() and player::animate() calls from Main.cpp and Editor.cpp to animationstep(level*, player*)
- Renamed level::animstep() to level::animationstep() for consistency
- Added a command line option to the editor to disable all animations ('--noanimation')
- Added "super secret" command line option from CubeWars to the Editor as well
- Added window::putlayer(level*, int) to draw specific layers only
- Added window::putactors(level*) to draw the actors only
- Rewrote window::putscene(level*, player*) to use the new putlayer(level*) and putactors(level*) functions
- Added editorinterface::putscene() function to draw only the visible layers
- Added editorinterface::toggleviewlayer(int) and editorinterface::setdrawlayer(int) functions
- The editor now only renders the visible layers as indicated by viewlayers
- Hooked the Layer Gizmo toggle buttons to the triggers for setting drawlayer and viewlayers
- Added 'solid color' mode to window::putlayer(level*, int, bool)
- Added layercolor variable to editorinterface to determine whether or not to use 'solid color' mode
- The amount of 'clip' entries for blitting is now determined by MAX_CLIP and MAX_MINICLIP
- Changed MAX_MINICLIP from 64 to 256, giving us 8 rows of 'mini' tiles instead of 2
- Added new 'eye icon' graphics to the tileset
- Added new 'eye icon' toggle button on the Layer Gizmo
- The 'eye icon' now toggles layercolor, the drawing of each layer as a solid color

- Replaced 'Layer Gizmo' items with Toggles
- Added icon drawing for Toggles
- Created all the 'Layer Gizmo' button artwork (CTRL+C - CTRL+V)
- In Layer Gizmo set up, changed thisbuttoncount to thisbuttonnum
- Added Toggle group functionality. Each group always has 1 member set to 'on'
- Toggle's initial/zero state is now 'Off'. Drawing logic now abides this

- The rendering of an ui_element's base is now a seperate function
- The rendering of a ui button is now a seperate function
- The rendering of a ui slider is now a seperate function
- The rendering of a ui toggle is now a seperate function
- Changed button's offsetonclick to offsetondown for consistency
- Restored button rendering
- Restored slider rendering
- Added rudimentry toggle drawing
- Reworked the mouse handling code to use ui_elements
- Added basic handling for toggles
- Added back the slider's customised handling
- Adjusted the Editor version number in the roadmap

- Fixed render segfault, was a problem with pointer init for the ui_element array
- Render code currently uses just ui_element information, but it works for all of them
- Changed sliders to have 'drawbase' set to 'false' by default, fixing their apppearance with the new code

- More GUI graphics
- Fixed a bug where Guiclip would wrap around to the next row too soon
- Introduced abstracted communication with interface elements
- Fixed an overflow problem with the new method of interface communication
- Init'ing elements will still be done the old way now, changed code accordingly
- Element init routines now share the code for basic error checking
- Finished set up and init routines for Toggles
- Looked at the rendering code and decided to redo this :/
- Broke the rendering code, it segfaults. Better commit.
 

Interfacing... more of it!

The past few weeks have been fraught with distractions, regardless I've been able to get some things done. I've drawn out what the new interface will look and function like and have begun bringing it into the Editor. Some elements are working and in near-final shape (the Main Menu is one) while others are bare bones or not there yet.

A lot of time has gone into adding the 'Slider' interface element. This will allow the user to scroll windows or change values easily. I actually had a bit of difficulty getting the math right for that one. It's all working now so I can get back to putting the Editor together again.

I've set myself the goal to have the Interface done by the end of this year. It may be a bit bold, but I think I can make that.

Until next time!

Interfacing

After a couple of weeks of dredging through 'ground work' I've finally come out above ground level. I've got the inner workings of my 'Interface' class working properly and it's looking to work pretty well! Right now it handles just panels and buttons. The window manager knows how to draw 'em in all their states (like, if you mouse over a button etc.) And the proper 'hooks' are in place to connect buttons to certain events.

Initially I was going to have the buttons 'perform events' by providing them with a function pointer to the function they need to execute, an idea by a friend of mine. However I found, having implemented most of this already, that function pointers cannot point to parenthesized functions. Quite a problem considering most of my code is designed with a reasonably strict class hierarchy. The interface class, for instance, doesn't 'know' about any of the higher level classes like those part of the Editor.

In stead of this method I decided to do a crude implementation of an 'event' structure. I have an array of booleans which correspond to 'actions'. A button is supplied a pointer to a particular boolean, this defines which action it'll perform when pressed. After the interface has been handled each cycle, the Editor will see if any of these booleans where set to true and then perform the function associated with that boolean. Pretty simple stuff.

The next step will be to design the UI using my existing (and probably some new) Interface elements and hook it up to functionality. Most of this will rely on the foundation I've been building the past few months.

Also, good news for me and anyone keeping track of this, I recently took an internship in a nearby town and thus will have a regular commute over there and back. This provides ample opportunity to do more coding. Couple this with the fact that I'm back into 'not boring foundation work' zone and it should make for some productive times!

Until next time!

Still Alive...

This is just an update to let everyone know I'm still alive and work on CubeWars is still ongoing.

Most of the work is currently going into the Editor at the moment. I'm working on a redesign of the Interface class and the way it's going to work in both the Editor and the Game itself. There's not a lot to talk about since it's very basic stuff, which is also why it's taking me so long. Doing it right is going to make my life easier down the road though.

I don't have a real estimate on when I'll have this done but judging by how long it's been taking me it could be a few weeks, though work has been picking up pace in the past week!

I'll try to post updates here whenever something mentionable happens, it's just difficult in this stage because most updates of the past week would've been stuff like "this class now inits properly" or "I made a change and had to fix the destructor, it works fine now though" which isn't particularly interesting to read for anyone not working on the thing.

Anyway, I'll hopefully post another update soon!

Dynamics & Triggers

Finally! After weeks of infrastructure I finally got Dynamic_Actors working!

Thanks to the help of the people in #C++ on freenode I was able to solve some lingering issues with my set up. Turns out that defining functions in a class derived from another class doesn't necessarily override existing functions from it's parent class. Thanks to virtuals I managed to solve that.

After the basics worked everything else was a breeze. In no time I had the Door functionality working exactly as I wanted and Dynamic_Actors are, at long last, a fundamental component of CubeWars levels! It's weird how fast coding goes once you have your fundamentals up.

In addition to that whole ordeal I've put in place a system that allows you to chain switches and use them as a rudimentry sort of logic gates. So you can have a switch somewhere that only works if another is in a specific state. This also makes the amount of stuff you can trigger with a single button virtually unlimited.

I'll be playing around with that a bit more in the future, try to get as much functionality out of that as possible, but for now I'm focussing on redesigning the Editor. It's long overdue and with my final type working (and the time it's taking to build levels partially with notepad) it seems like the best thing to do at this point.

A special thanks goes out to my new whiteboard with whom all of this would've taken considerably longer.

See you next irregular interval!