And so began the work on "Game":
Bugs did crawl (twas kind of lame)
And though a raycast rework brewed,
Our merging process remained shrewd.
Beganeth a trial of walls and rays:
Which absorbed the time of many days,
And though my octree builds were slowing,
No team was blocked: our features flowing
The collision system needs more tweaking,
It works, but Bert would like to do some peeking,
Into things like normals, which he needs
To slide against walls with grace and ease.
Oriented boxes are the next request,
No breaks for me, I shall not rest!
We've built one puzzle, more on the way.
At least we've got a game to play.
—Dexter Friedman, Deceleration!!Structured
This was the week of video games! We finalized our network transmission system, further optimized and extended our collision system, worked on collision-based movement, and implemented a basic puzzle creation system using Blender as our level editor of choice (OK, most of us didn’t choose Blender, it was just sort of forced upon us).
Here’s a shot of what the wireframe box colliders look like in that awesome hallway from last week! Hopefully we’ll have time to show you this cool hallway in action tomorrow.
Here’s a donut that spins if you step on a pressure plate! It’s hard to see in the GIF but there’s another cubeman in the background stepping on the other pressure plate.
My goal for this week was to get it so that the player could collide with walls.
I was able to mostly accomplish this using a couple of methods, but neither would have worked well for the final game. The first one I tried was the “bounce” method where, upon entering a wall, the player would be “bounced” back to the location they were at before the
collisionEnter. The problem with this is that, while it mostly worked, sometimes they would not successfully exit the object (despite being in the location they were at before they entered), and would therefore be able to “slip” inside it. This may have been related to floating point precision? I was able to fix this by bouncing them back further, but this created an unacceptable “jitter” that was very noticeable and would have been bad to leave in, especially as the player will be constantly colliding with floors.
The next plan was to use raycasting to slide the player along walls (probably using this method: http://www.gamedev.net/page/resources/_/technical/game-programming/general-collision-detection-for-games-using-ell-r1026). However, raycasting wasn’t working until Sunday so instead I tried messing around with other methods in case we couldn’t get raycasting working. On Friday I was able to hack together a method to prevent the player from moving towards the collider’s origin as soon as they collide. However, this had a lot of corner cases where it didn’t work well, so now that raycasting is implemented I’ll abandon that line of work and focus on the original plan.
This coming week I will implement the method described above, and then move on to getting the levels we’ve designed in-game.
My individual morale is quite good. While my attempts this week ultimately failed, it wasn’t for lack of trying. I was able to spend quite a bit of time on 125 to make up for my lack of contribution the week before.
Editor’s note: I didn’t *force* Dexter to write a poem, I just gave him an offer he couldn’t refuse.
One of the concrete goals for the week was to get a preliminary puzzle working and continue to increase the robustness of the Network code.
I continued to increase the robustness of the network code and added support to more components to them. Now Lighting component data is being sent over the network.
Right now we are all still completing core functionalities of the code. Jason is working on his “Activator Registrator” which logs events that can be used to make switches, pressure plates, and other things that trigger switches.
Furthermore, Dexter is merging his raycasting into develop branch. Once these things get added together, we will begin working on the gameplay and implement our puzzles. As I am typing this, we are currently implementing the first puzzle with the Activator Registrator.
Currently I am feeling OK in terms of morale. My other school work and commitments, however, are beginning to pile on. Since we are on the verge of moving from Engine building to game making, I am feeling excited.
Say it with me,
We’re getting to a point where we can finally start working on gameplay, and a big part of that is actually creating levels. Jeff’s done a great job of physically modeling levels, but how do we actually hook them up to be interactive? How exactly does that lever on the wall open that door?
This week I worked on being able to use Blender as a level and puzzle editor for our game. Essentially, we have two types of objects, Activators and Targets. Activators are like levers, buttons, pressure plates, or even esoteric things like timers. Targets are things that are activated, such as doors, chests, gates, lasers, flying death traps, spinning monkey heads, etc.
I worked on making it such that if you name objects in Blender a certain way, in a preprocessing step the game will automatically connect all Activators with their specified Targets using scripts that we write through the power of interfaces; there are literal
Target virtual classes that have base functionality written (i.e. they know how to connect to each other, and how to send activation events between each other). You then write components on top of these that tap into their events, and boom, you have a modular, extensible puzzle creation system! It’s magic!!
I’m feeling good! This week I’ve settled into more of a managerial role, doling out tasks to everyone and prioritizing priorities. I’m also proud to say that less than 5% of my workload this week was networking code! Woo!
This week I did not accomplish as much as I would have liked because of midterms in other classes. While I had intended to help to get the first couple of puzzles working, I was not able to do very much there. What I did do was art and many smaller changes to the engine. For art, I textured the prison starting area, and created models for buttons, pressure plates, and levers. I also improved object loading to be more flexible and fixed some bugs. For next week I am going to mostly focus on art as well as small improvements to the core engine that make other people’s jobs easier. My morale is lower because I didn’t do much this week, but that should hopefully improve now that I have more time again.
My goals for the week were to add some logging to the network code so that in the future we could view certain stats about the network while we play the game. I also wanted to help complete the first puzzle by making sure all events were broadcasted throughout the network properly.
I was able to implement some basic logging when the “n” key is pressed on the server to see the breakdown of bytes being sent to all clients. I also implemented a client connect retry mechanism that would try to connect to the server for a configurable amount of time before giving up and exiting. I was able to help send camera data and active/visibility data across the network so that when Jason finished his work on plates, he would have a simple API to call into in order to activate/deactivate the lasers in the puzzle.
I was able to meet most of my goals this week but I did feel like I had a good amount of idle time. I spent this time by going over the Engine code so that once collision detection was working properly I will be able to help with gameplay logic. My goals for next week are to start working on gameplay logic, while continuing to send whatever data is necessary over the network. I feel like this week was a little slow for me, but I can sense that it will pick up very quickly and I want to be ready so that I can help with a lot of gameplay features in this upcoming week.
Last night, I dreamt of boxes and spheres,
Breakpoints alone could not sway my tears.
Colliders rebelled and deafened my cries,
My debugger cackled: its numbers were lies.
How foolish was I—to think that alone,
I could code for them all—even a cone!
No, the price of hubris was far too great,
For collision detection, I surely now hate.
Those of you who seem to relate,
Harken my words: before it's too late!
The networking stack has now coalesced,
The boxes are working (but my spheres aren't the best)
More time will be needed, to wrangle these,
As errors linger like an infectious disease.
—Dexter Friedman, Nodes from an Octree
Author’s Note: The poet would like to inform readers that after a temporary loss of his sanity, he has made a full recovery. Collision detection is working well enough to start programming game logic, and it is fully integrated in the core engine. Tune in next week, for another epic tale filled with adventure, intrigue, and romance!?
Besides all of that, we also worked on furthering the network integration within the engine. Now objects magically sync their own data across the network (including not just movement, but their creation and their visual representations). We also prettified the graphics even more (of course), and made input more modular (we really want that controller support).
Stepping out of pure engine additions, we all spent most of Tuesday on game design, essentially white-boarding out the entirety of our game’s floorplan, including creating fun puzzles for the most of the map. We’re essentially 90% on the design intricacies of the game we’re making, so now that collision detection is done in some regard, we’re happy to sit down and actually implement some gameplay.
It’s kind of funny—we all feel like we’re falling behind, but if you check out our project schedule, we’re actually almost 100% on track (even down to silly things like point light shadows in week 4, wow). We spent a lot of time solidifying the underlying infrastructure, and even though there was a steep cost, we feel that this effort will result in less regressions in the future.
Hey, here’s a cool in-engine picture. Look at how pretty it is!
This week I was planning to help Dexter with collisions, but that didn’t end up happening. Instead, I worked a lot on design, finalizing the floor plans for the spaceship and introducing a new puzzle that we’re prototyping. I also implemented jumping in-game, which included sending the “fire” data to the server. My current implementation is a bit hack-y in that it lacks collision so it assumes that the “floor” is at y position 0, but that can easily be fixed.
My not helping Dexter was because Jeff did that instead while I did design and jumping.
Next week my goals will depend on whatever the team needs me to do. There isn’t an obvious “next thing”, so I’ll probably just fine whoever needs help and help them.
My individual moral is quite good.
(re-read the intro of this blog post)
One of our concrete goals was to finish the network code and the overall robustness of it.
I completed a separate goal of making button maps load from a config file, so that I can increase the modularity instead of having it hardcoded.
Originally we thought making the network code more robust would be quite trivial, but because of the complexity of the engine there were a lot of things that the network code has to account for. For example, mapping the network code to the engine components, and the creation and destruction of objects, which would be more involved than simple transforming of objects. And since we became a group of three in the network side, only Jason and Pavan have been really working on the network code. And since the code is built on top of itself and it would be unfeasible and inefficient to sit three to a computer, I have not been able to be a part of the network coding.
If the network code and the collisions come together completely, I plan on working on gameplay as soon as possible. I have a couple of puzzles in my mind that I would like to create.
It’s already week five and I’m beginning to feel behind. And since I can’t be as useful as I would like on the networking side, I’m beginning to feel a little bit low in morale. However, I remain hopeful and I am excited to be able to begin on gameplay soon.
At the beginning of this week everybody worked together on floorplan design and puzzle design. I submitted some ideas I had, as well as worked on furthering other peoples’ ideas. I really like the puzzles and environment design we have in mind, and am excited in progressing in that regard.
My major goal this week was to further the component registration system–essentially getting all of the parts of the game to talk to each other across the network automatically without us having to scatter
sendAcrossNetwork() and such throughout our game code.
It took a while to get working, but I’m quite proud of how it’s coming along. We can now start from a completely blank, logic-less scene on the client-side and have the server do all of the heavy lifting when it comes to creating objects, assigning models, and positioning things in 3D space. The ideal is that the code one writes for a multiplayer game will be almost exactly the same as the code one writes for a single player game. If done well, this should help immensely later on–we won’t have to worry if we ever forgot to send network data for an event, because the engine will do that automatically. Real cool stuff.
This week, Pavan and I need to extend it to send lights and cameras over the network as well (right now it just sends concrete objects). As we finally have collision detection working, we can finally work on gameplay as well! I’m going to continue something I started working on a while ago before I joined the networking team—a system that registers all pressure plates, levers, buttons, doors, gates, etc. through the names we give them in Blender, and then hooks them up so we can start getting some puzzles going!
I’m kind of burnt out at the moment; networking code really isn’t my favorite, but as the person with the most engine experience who isn’t tied up (i.e. Jeff and Dexter on Physics) it was necessary for me to join the networking team to fully design integration. Because of that I’m really happy that we now have prototyped physics so I can do what I signed up for, gameplay programming.
Besides that I’m decent morale-wise. I think our team needs to do some reworking with both priorities as well as doling out tasks–we’re running into issues where some people are stuck with a lot of stuff to do, and others aren’t really given anything, which doesn’t help anybody.
This week I worked on creating the art for the first puzzle, improving the lighting system, and helping Dexter with the collision. For the art, I created the main models and textures for the first puzzle that we were trying to finish this week. I then improved the system for point lights, the most notable improvement was adding shadows (directional lights already had shadows). With the collision, I created a way to edit and load colliders from Blender into the engine. Later in the week I also helped Dexter to debug his collision code and had a small part in finally getting it working.
For next week, I am going to mostly step away from art and graphics, as other areas are falling a little behind, while art and graphics are slightly ahead of schedule. I aim to have the first to puzzles mostly working by the end of next week. This will mostly entail helping to tie together different areas, as well as gameplay programming. As for my morale, I am slightly disappointed to have to stop doing visuals, but am happy in what I have been able to do.
My goals for this week were to be able to create and destroy objects across the network. I was able to write an initial basic implementation of this, and helped Jason to further extend it. We were eventually able to do the initial setup of our basic world with all of the objects being created on the server, which would then tell the clients what it was creating, what meshes/transforms it was applying to those objects, and it was able to keep these consistent across all clients using unique IDs.
We were unable to finish the destructions of objects in this way, but knowing what we know now, I think it will be much easier. We ended up spending a lot of time on one bug in particular that had to do with the way that meshes were being applied to certain objects, but we were able to fix it. This prevented us from moving forward with the delete functionality, but we may postpone that further until we actually do need to be able to delete objects from our game. I was also gone this weekend, so I was unable to help as much as I normally could have. In addition to the create/destroy side of things, I was also able to ensure that the clients were only sending messages when they received input (instead of all the time which is what it used to do).
My goals for next week are to continue working on the message passing between client and server to get a fully consistent world, and then hopefully begin integration with the collision detection branch that Dexter has been working on.
I am still feeling confident that we are moving at a good pace. Collision detection is taking a little longer than I thought it would, but I think we have a good grasp of what exactly our game looks like and what puzzles/traps it has so that we will be able to hit the ground running once we integrate the collision detection branch.
Other things striked back as well, but Jeff told me to make this the title.
This week we spent a lot of effort integrating networking into the game engine. We now have TCP-based networking integrated, as well as a general purpose message sending and framing system that’s easily extensible for when we need to send custom messages in the future (right now we’re only sending input events and transform data). There are some issues, but that’s what the next six weeks of debugging are for!
We’ve also added some cool graphical features, made more strides in terms of art assets, and gotten further along in our physics/collision detection system (although we’ve hit some roadblocks in the latter).
Morale is good again. Everyone seems to have stuff do, and even though we’ve already had a couple of occasions where team members had to duck out, everyone was always notified ahead of time.
Here are some more screenshots of graphical stuff (the second and fifth are in engine, others are Blender), as well as a video of networking in action.
OK, W3 Progress Update:
My concrete goals for the week was to work on animating models, and to skin the player model.
I accomplished both of those, though the animations do seem a bit unusual. Basically, I determined that the file exporter from Blender doesn’t… well… work. But the good news is that we won’t be exporting files in that way so we shouldn’t have to worry about that. Still, there may yet be some issues with animated models being rotated for no clear reason. If that happens though, it should be easy to correct for. Just keep an eye out if animated models aren’t visible as they may have rotated under the ground. Importing the objects separately from the scene should fix that though.
Next week I will help Dexter with the collisions, and do whatever else needs doing.
I’m doing quite well, I think I did a lot more useful work this past week.
Last week’s goal was to implement the entire collision detection system for the game. This included implementing axis-aligned bounding boxes, spheres, raycasting, capsules, and an octree. I pretty much only finished the octree, and I’d say as of now most of the system is untested. Raycasting should be fully functional, at least for boxes and spheres contained in the octree. There are still lots of holes to plug throughout the system, and since I was traveling for the weekend, I wasn’t able to get as much done as I would’ve otherwise.
That being said, a lot of time went into designing and thoughtfully crafting the collision system. I’m very confident that the work I’ve begun can effectively be split up into smaller pieces and spread out to others on the team. What began as a monolithic task is now a short list of unimplemented methods in appropriately named classes.
Getting collision detection working this week is imperative. I may not need to cover all the possible cases (I doubt we will need capsule-capsule collisions immediately) in order to provide a usable API for the gameplay programming team, but the sooner this code works, the sooner we can start building the actual game.
After I finish making the collision detection system usable, I’ll transition to gameplay programming. By that time, we will have enough puzzles designed to get started on building them in-game.
I’m feeling very good about where the collision code is, and about how well our group is progressing with respect to the networking integration. I’m reserved, but optimistic. My airplane has plenty of fuel, and nothing appears to be on fire. Yet.
Last week, we tried to get the Server to able handle multiple clients as we had previously achieved basic single client functionality.
We were able to have multiple clients running using a select like functionality!
We were not able to integrate it to the rest of the engine because we are still making our messaging system more robust, since we have to handle multiple components of the engine. E.g. Inputs and Objects. However, since the basic networking is finished, it won’t be particularly difficult. Also, right now each client does not have complete autonomy over its inputs, because the server broadcasts all messages and the client does not yet know how to process its specific messages.
Next week we will increase the robustness of the engine, so that each specific client will be able to have its own autonomy. But the main goal of the week will be the actual game design: what are the puzzles and how will they be integrated into the overall game?
Right now I am still feeling pretty confident about the network side of things as my partners for networking, Pavan and Jason, and I have finished most of the functionality. However, since we are thinking about the game this week, we will have to think about the gameplay design. And that means a lot of decisions.
Networking! From low level socket interactions to high level messaging, I worked primarily with the networking team this week. I specifically worked on having the server and client process as many messages as possible per tick (rather than leaving extra messages in the TCP buffer), handling receiving messages from multiple clients simultaneously, as well as how to properly delegate messages.
The engine we’re using (Jeff’s) has the general idea of a “component”, essentially a script that’s attached to every game object. There are built-in components for things like Transforms and Materials, but you write your own components to implement game logic (all components have callbacks for things like frame updates or collisions).
What I worked on is giving every component the ability to register an ID as well as serialize and deserialize itself. The hopes are that the server and clients will synchronize component IDs at the start of the game, and from then on it’ll be as easy as cycling through every registered component and sending/receiving their serialized forms across the network. We have this working with Input and Transforms at the moment, but it needs a bit more work to be fully general purpose.
Along with that, I also want to work on solidifying the puzzles and floorplan of our game this week (in fact this’ll be my main priority). Once Dexter finishes collision detection and the basic physics system, we’ll be immediately jumping into actual game implementation. Jeff also needs to know the “final” layout of things in order to properly model the rooms and props of the game.
I’m doing fine morale-wise. I kind of wish we were further ahead in some regards, but given how ahead we are on the core engine as well as graphics support, I think that overall we’re making great time. Hopefully we’ll be able to present a puzzle next week!
This week I did more art and graphical effects for the rendering engine. As far as art, I finished up a model for the starting prison room, and created the basic layouts for the security room, control room, and escape pods. I planned to do more rooms, but as we haven’t finalized the room layout or puzzles yet, I don’t know what we need yet. Instead, I did more programming work and implemented Screen Space Ambient Occlusion, and Parallax Occlusion Mapping. Next week I intend to do more room art and possibly implement point light shadows. My morale is improving as Jason only bugged me about it once this week.
My goals for the week were to help get the networking aspect of the game working with multiple clients. This included being able to tell which messages were for which client, as well as making sure that all of the clients were communicating their actions with the server.
We were actually able to accomplish all of these goals and now have a game that is working with a server and multiple clients in which each client is able to move around independently and see other players move around as well. The clients were sometimes a little laggy, so we were planning on fixing this next, and then moving on to communicate other messages between the client and server.
I think the reason we were able to meet these goals was just by putting in a lot of work during the week and weekends, and we are probably going to have to continue doing so to continue our pace going forward.
My goals for next week are to work on a component registration system that allows the server to assign unique ID’s to each component that is in the game. In the game initialization, the server will send a table of each component and its corresponding IDs to the clients, and these IDs will be updated while the game is running.
I feel good about the work we did this week and I feel like our team is moving forwards on schedule if not a little faster than I had anticipated. I think that if we continue this pace, we will be in great shape for the rest of the quarter.
Note: Individual check-ins are at the bottom.
We’ve made progress!
We’ve started toying around with the general engine that Jeff brought in from CSE167. We’ve learned how to use it on a basic level, and we’ve also learned some of its quirks (and fixed some bugs!). Fully understanding his engine is going to become paramount when it comes to integrating networking.
We also have fleshed out game design (including some puzzles), began work on client/server architecture, and modeled a few assets out. When it comes to our schedule, we’re mostly on track except for acceleration structures, which is essential for both collision detection as well as point-light shadows.
Besides the normal class meetings, we also have scheduled meetings on Mondays and Wednesdays at 2pm.
Morale is good. Everyone is contributing, and we’re playing to our strengths. Everyone is coming to meetings, and Slack is working great for out-of-meeting communication. Any morale problems we’re having are due to the lab computers (lack of software, general slowness), but we hear that some of that is being fixed.
Here are some screenshots of art we’re working on! All of these assets can be loaded into the engine with basic lighting effects.
My goals for the week were to work on basic movement and physics, as well as to do some art and puzzle design.
I ended up focusing entirely on art and puzzle design, with a bit of time spent futzing with the engine. (see initial email for full list)
This week most of my goals didn’t pan out because other people ended up working on the code I was gonna write, so I wound up working on art and design instead (partly that’s my fault for not being “aggressive” enough at finding work).
My concrete plans for next week are to help you work on movement, help Dexter work on physics, write any other code that we need, and texture the player models.
- Primary goal was to get configuration files up and running in our engine.
- The config files are working fine, and I had plenty of time to read up on collision detection algorithms and data structures. Started implementing an octree.
- I probably should’ve done more last week.
- We have naive collision detection implemented (although I haven’t tested it.) This week’s goal is to get efficient collision detection implemented. If I get time, I want to get started working on basic game physics, and hopefully improve our particle system. I’d like to build a particle viewer, with some minimal UI so we can quickly prototype and deploy particle effects. The current particle system is VERY hardcoded.
- Collision is going to be tough. I took the easy road the first two weeks, now it’s time to get my hands dirty, so to speak.
I worked on the client code this week, taking basic Windows socket code and encapsulating them in higher level easier to use class with corresponding class functions that can be used to send messages over to the server, and receiving messages from the server. Instead, of needing to maintain how client code is manipulated to send arbitrary bytes of data, a user can use this new client code to send over a C++ string. This means the user doesn’t need to worry about the lower level and more unsafe C code, as it abstracts both the memory management and the sockets code. Once this code is integrated with the game engine, connecting and interfacing with the server should be seamless and easy.
Next week I plan to integrate it into the rest of the game. I currently feel pretty confident and I do not feel particularly stressed about the game, although there is a feeling of impending urgency.
My primary goal was to get FPS movement within the existing engine, as well as design some puzzles.
As I will be a gameplay programmer, I spent most of my time becoming familiar with Jeff’s game engine. I was able to implement standard FPS controls (mouse-look, WASD movement) within it, and through this learned how future gameplay logic should be implemented within the confines of the engine. I also had to dig into the actual engine a couple of times to fix bugs, or add features that I anticipated we’d need.
Concerning game design, I worked with Bert on designing a few puzzles that will be strewn about the map, as well as the general interaction system that puzzles will be built upon.
I also spent a good amount of time learning Blender. Initially I just wanted to construct a simple scene and player character (i.e. boxes) so that I would have assets of which to use the engine with, but gaining some basic skill with Blender will make it easier to make and edit simple props that I might find myself needing in the future.
My goal for Week 3 is to implement a general-purpose system for hooking up pressure plates, buttons, and levers to doors, gates, chests, etc that we can build on top of for puzzle design. If Elton and Pavan finish the client/server message framing early, I’ll also start working on the server game-loop, and how to handle event-passing. Finally, I want to work with Bert and Dexter on designing a floormap for the main level of the game.
My morale is good. I learned that if we’re going to be working on someone else’s engine, it’s almost necessary to have them nearby in case any problems arise.
This week I worked on art and asset loading and managed to accomplish my goals for the week. I created a corridor, and engine prop, the character robot model, and am just finishing up the prison room. I have not textured them yet, but I did rig the player. The asset loading system now uses .ini files to control materials and can automatically reload them and textures when they change. I also created a viewer to test out how models look in the engine. Finally, I spent time helping people to learn to use my rendering engine. Next week I intend to try to do the art for four more rooms, help to integrate networking and a scene acceleration structure if necessary, and possibly work on extra graphics effects such as parallax occlusion mapping of screen space ambient occlusion if I have extra time. My morale is doing fine for now but is dropping every time Jason nags me to write about it.
This past week I worked on getting the client and server communicating on both windows and linux (for testing purposes), and breaking them out into their own network utility classes. I also helped to refactor the code along with Elton to allow a client to reuse the same connection for all of its sending and receiving of messages. Our next steps are to allow multiple clients to connect to the server, and then start working on a serialize/deserialize function to send/receive meaningful messages. I feel good about the position that we are in with regards to the network. This coming week’s work will definitely be a lot harder than the previous one, so I plan to put in more time to compensate for that. I think our team has been working well together so far, and I look forward to continuing our progress as the weeks go on!
Table of Contents
- What kind of game?
- What are the goals?
- How is it unique?
- Who We Are
What kind of game?
The game we have in mind is a multiplayer puzzle-platformer with a mix of both cooperative and competitive elements. Set on a Space Prison set to crash, four robot inmates have to work together and escape before time runs out. However, there’s a reason the robots are in prison, and they might have ulterior motives that prevent them all from making it out.
What are the goals?
The primary goal is to escape the ship before it explodes. There will be an assortment of puzzles throughout the ship that the players have to find and solve (some solo, some cooperative) if they want to successfully escape. However, the players will be individually given a secret mission of their own that they have to complete in order to escape–even if the escape pods are primed and ready to go, a player cannot leave (and therefore win) unless they’ve completed their secret mission.
The secret missions can be completely benign, such as extracting some data from the Space Prison via a terminal, or maybe destroying that data so it cannot be extracted by a salvage crew. It can also be insidious, such as preventing another player from escaping by any means necessary. Regardless, secret missions will be antagonistically designed–players’ missions should work against each other such that it’s not realistically possible for all players to escape.
To accomplish this, there will be traps throughout the ship that players can secretly trigger. Be careful, as you cannot escape the ship by yourself–cooperation is necessary.
How is it unique?
Our game blends cooperation and competition. The puzzles will require multiple players to work together if they wish to solve them, so no single player can go rogue at the beginning in an attempt to save everyone else. The threat of the secret missions is constantly looming over the players though, which means you can never fully trust your fellow escapee.
The nature of the game also lends itself towards some form of randomness and procedural generation, whether that be in the secret missions given at the start, or the puzzles that players have to solve, which means that every round of the game will be a different experience.
The Bare Minimum
- First-Person controls (mouse and keyboard)
- Different colored boxes for each player
- Players can move and jump around
- A basic cooperative puzzle (i.e. having everyone stand on different pressure plates)
- A simple trap (i.e. being able to trigger a trap door)
- An “exit” area that if everyone reaches ends the game in a win
- A timer that ends the game in a loss if it runs out
- Joining a game hosted by a fixed server instance
- A singular robot model that has different textures for each player
- Some basic prison-esque hallway environment for players to navigate
- Collision with walls
- At least three puzzles that need to be solved in order to escape (we want rounds to last 10-15 minutes at the minimum)
- At least three traps that can be triggered
- A basic “don’t let player X escape” goal given to each player
- Beginning screen that explains rules
- Persistent UI displaying timer
Would Be Awesome
- Shadows and other more detailed lighting effects
- Some non-linearity in prison environment (not just a straight path to end)
- Modeled prison cell for start room
- Modeled escape pods for exit room
- Controller support
- Player collision (cannot walk through other players, possibly can jump on top of other players)
- At least six different puzzles present with varying difficulty
- At least six different traps present throughout
- “Interactable” props, such as Computer Terminals or Storage Containers
- More complex secret missions (such as “retrieve data from Terminal” or “destroy files in Container”)
- Persistent UI for displaying secret objective
- Respawn mechanism (you don’t die, you just get delayed)
- Ambient spaceship sounds (machinery, air vents, that kind of stuff)
- Lore-friendly way of displaying countdown timer (can be on an electronic sign, or displayed on computer terminals)
- Voice-over for introduction
If We Have The Time
- Works on Windows, Mac, and Linux
- Separate models for each robot
- Walking and interaction animations for robots
- Large non-linear prison environment (easier to get separated and launch traps)
- Detailed environments with non-essential props (for design and world-building)
- At least ten different puzzles present
- At least ten different traps present
- Interactive computer terminals that let you access security cameras, disable lighting, trigger traps
- Can host and join games (rather than hard-coded server IP)
- Random missions assigned each round of the game
- Some procedural generation in map design (perhaps pre-designed rooms that are randomly connected)
- Background music and interaction sound effects (i.e. walking, traps being activated, buttons being pressed)
- Awesome Main Menu
Who We Are
Our team features
- Bert, our gameplay programmer and artisan
- Dexter, our other gameplay programmer and touring voice talent
- Elton, the first networking expert (both client and server!)
- Jason, yet another gameplay programmer, possible composer, and chief blogger of the blogosphere
- Jeffrey, our graphical guru and 3D modeler
- Pavan, the second expert in networking (both TCP and UDP!)
We’re working on a consensus–we vote for all decisions, but give credence to those working in the particular field being discussed. In the event of a catastrophic tie, Dexter is tall and imposing and therefore probably will be the tie-breaker.
We have a Slack room set up for all communication. Besides normal class meetings, we’re also currently planning a meeting on Monday (full details to be decided by an outgoing Doodle poll). Jason and Jeff are also coincidentally roommates, which means the drama of 125 will never truly escape them.
We’ll be using Slack for communication and GitHub for collaboration, so anyone who needs to disappear will alert us on Slack, and perhaps file an issue on GitHub if there’s a problem that they cannot finish on their own time.
We’ll be following our schedule as tightly as possible. As we already have a general consensus on must/should/hopefully features, we’ll be trimming features in that order if time doesn’t permit us to finish absolutely everything.
As chief blogger, Jason is in charge of writing these lovely and lengthy status reports.
Our specific development roles are mentioned above under Who We Are.
Our project will be developed in C++ using the OpenGL graphics library (and the latest-and-greatest at that). Specifically, our graphics expert Jeffrey has a really nice graphical engine that he developed during the course of CSE167. Not only does it have very pretty (and performant) visual effects, it was also designed to be modular, which means that it hopefully won’t be terribly difficult to use it for our project.
For programming our Windows developers will be using Visual Studio, and our Mac developers XCode. Thanks to the power of OpenGL, we hope to have our game running on multiple platforms.
We’ll be using some common libraries in our development, such as GLFW for windowing and input, SOIL for texture loading, ASSIMP for mesh loading, GLM for math, and FMOD for sound.
|Week One||General Idea/Concept||Modularize Graphics Engine||Art-Style Research||CSE124 Review||Gameplay Research|
|Week Two||Puzzles||Asset Loading||Environment Art, Basic Character Model||Basic Client/Server TCP Architecture||Acceleration Structures||Local Movement||Configuration-based Setup|
|Week Three||Puzzles, Level Design||Environment Rendering||Environment Art||Design Framing (General Packet Structure)||Naive Collision||Local Basic Puzzle|
|Week Four||Puzzles, Level Design||Point-Light Shadows||Character Design||Game Engine Networking Integration||Better Collision||Multiplayer Movement||Basic UI|
|Week Five||Puzzles, Level Design||Lighting Enhancements||Character Design, Prop Design||Debugging Networking Integration||Debugging Multiplayer Collisions||Multiplayer Basic Puzzle||Controller Support|
|Week Six||Puzzles, Level Design||Particle Systems||Environment Polish, Music Composition||Implementing Extra Messages As Required||Debugging Multiplayer Collisions||Environment Implementation (Keylocked Doors, Passworded Terminals, etc.), Puzzle Implementation|
|Week Seven||Puzzles, Level Design||Graphical Effects Polish||Environment Polish, Music Composition||Implementing Extra Messages As Required||Puzzle Implementation, Trap Implementation||UI Polish|
|Week Eight||Game Balance, Testing||SSAO||Character/Prop Polish, Music Composition, Sound Design||Debugging Full Networking||Puzzle Implementation, Trap Implementation|
|Week Nine||Game Balance, Testing||SSAO||Character/Prop Polish, Character Animation, Sound Design||Debugging Full Networking||Random Puzzle Selection (Procedural Generation), Puzzle Testing||Cross-Platform Compatibility|
|Week Ten||Game Balance, Testing||Configurable Graphics||Character/Prop Polish, Character Animation, Sound Design||Hostable Servers||Random Puzzle Selection (Procedural Generation), Puzzle Testing|