MODDING: - Modding since 2003 including Quake, Q2, HL, HL2. Singleplayer mapping, character skins and level textures - 3D Modeling since 2003 including Lightworks, 3ds max, Blender, mostly organic (character/vegetation) modeling and furniture - Photoshop experience since 2003 and still use it every day in my work
PROGRAMMING: - C basics (Visual basic, various applications from mIRC scripts to algorithmic architecture, including some simple HL2 code editing) - python basics including Ubuntu scripting and Blender GE scripts (mouseaim, dynamic WoW-style camera, turn-based combat, etc)
MUSIC: - playing and performing piano/keyboards, guitar and drums - digital music composing using e.g. Guitar Pro, Fruity Loops
GAME PROTOTYPES BY ME (unreleased): - 3D Lolo-type puzzle game with horror theme - 3D Co-op RPG with turn-based combat - RE style game - 3D nature theme puzzle game
OTHER LIFE: - Student of architecture since 2007 - Architect works since 2011 - Beautiful baby girl and wife :)
Portal for instance might be one of a few FPS games with a theme which perfectly explains why your interactivity with its world is limited.
Because Portal's game world where the player completed puzzles was in fact made to be just that: an artificial environment where the subject completes tasks that test thinking and timing. The AI could very well be talking directly to the player instead of the player character. Portal eliminated the need for real world environment by making their game about imprisonment and cruel experiment where the environment was built specifically for the testing purposes.
Another such example would be Tranquillity Lane from Fallout 3 that is a virtual world where people were being trapped. The player character knows it's not real so in this limited cases there's no room for immersion in terms of assessing the plausibility.
While these are nice examples of how some games with unique starting points were made quite plausible not every game can be about forced experiment, oppression and imprisonment to justify obviously limited environment. In a game where you want to involve realism, adventure or free will / open world themes it's impossible to find a comparable plausible explanation for the limitations in game world such as absolute boundaries the player is contained within that the he eventually bounces against.
Because the criteria for plausibility is not simply "imprisonment" like in Portal's case, but something much more complex. "There are no toilets in these shopping centers". "Nobody would want to live there next to motorway." "Where does the mailman deliver the mail in this city block?". "There's not nearly enough parking space in the city." "The cars never stop driving." As the game developers seek to emulate a city or other set that is involved with huge amount of people going through it in various roles it's bound to be incomplete and unrealistic when the viewer gets critical enough.
Portal was ingenious in many aspects but I wouldn't have all games try to find a reason for the unavoidable limitations in game design. I value the illusion and rather play games where I think I have a huge amount of choice than games that were reduced to environment that directly states there's only one thing for the player to do (as there mostly actually is).
Eventually this might help us creating more immersive themes and levels for video games.
Many of the things you list don't really hurt the immersion. Before you started to think whether you could use the empty barrel to jump on that fence and jump that awning so you can walk the rooftops to a building that had the door locked the immersion was already broken.
When you are traversing the environment looking for where they have used a gimmicky wall or wall-like structure to limit visibility and give occlusion culling a chance you are not immersed whether you can find any or not.
Indeed the more you know about game development, design and business the harder it is to relax and sink in to a game world while you are distracted by various things that peak your professional interest.
The immersion is not about "I am me, the player. I am here in this environment that I can freely interact with like I would in real world." At least it's impossible to build a game around this goal.
To me immersion is about assuming the role of the character and getting adapted into the game world rules however arbitrary they might be. "Oh shit, I will die if one more zombie bites me and I know I can't walk past this one because the corridor is so narrow he will always be able to grab me. I don't want to die. I don't have many bullets left but I have to spend some here..." If they weren't immersed they would just try it since they saved the game 9 seconds ago and can always try again.
For me, it's not the content or level of detail / effects but how the game is presented, again.
The feeling of rushing is because player is moving in too linear way. I know you have played this a million times and know what to do but as someone first laying his eyes on the game world you created I feel like I want to see more and that I have no idea where to go. I want to wander and explore. But the player on video snaps on the tracks and does stuff without stopping to think and the viewer can't relate to that.
Honestly when I said "gameplay material" I was thinking about your "feature set complete" statement and assumed you had some of this you wanted to show. You could do it in a way that supports building the atmosphere. For example first make camera drives in the pouring rain and then show small scene of fireplace being lit bringing warmth and juxtaposing the elements.
I like the end where you zoom back to the lighthouse. You could depict it from frog perspective to give it a little mystery and intimidation if that's your intention.
I feel like there's no real need to wait for later production stage with what you got, I'd be interested to seeing another version of the trailer with a bit more cinematic sections mixed in. But whenever you decide to go for it remember to slow down in the gameplay and do non-linear editing to break up the pace and bring variance in the trailer. Could definitely take more text to give the viewer something to chew on while enjoying the view.
I've been with indieDB since 2006 and honestly with what you've CURRENTLY got out there, not a chance unless I've under-evaluated the genre's appeal and supply-demand by a lot. But!
I can see you have a huge amount of content done but you just aren't really selling it. You should have maybe done some gameplay videos before you went for "feature complete alpha" to grow a better fanbase. But it's still a new project on the site and this is a perfect opportunity to test your marketing abilities. First focus on climbing indieDB popularity and see what works and what doesn't.
They just tackled the public from all angles, they did everything from indieDB to this site, Steam Greenlight, Kickstarter, facebook, Twitter... they had so much content fired all over the internet that nobody could miss it and once they got people interested they kept them tagged along by constant updates and video blog with in-game material, developer insight etc. I'm not saying that's what it takes but getting the public interested in your game enough to fund it even if you have a solid idea and good progress is hard work and you probably only get once real chance with the crowdfunding.
So get the trailer out there and start marketing the project. Update the indieDB site frequently (each update bumps the project back to top) and try to reflect your project status accurately because you are further than one could deduce from the screenshots alone. Currently the indieDB site is your only base on the net and you've got around 30 followers (now including me ) and if each of us were interested enough to chip in we'd have to donate quite large sums of money.
I think you should pay attention to establishing the "brand" of your game. Logos, fonts, colors, visual style. Maybe that'll come naturally as you complete the trailer.
When you get a growing fanbase and start to attract the masses you know you're on the right track. For indiegogo campaign It might be a good idea to dissect the $5,000 budget and really go over the costs to see if that's the right amount to make the game really happen. Prove people that your game is awesome, this is where you are, this where you want to be and this is what it takes to get there. After that it's just a matter of listing the right perks
I might be speaking just my personal opinion but even if you have a game that is almost playable I suggest you don't stress the fact that people are getting the game for their money or that they are buying the product. I feel like this only makes the audience more skeptical and critical. "Is he really going to finish it?" "What if he won't get all the money? Then I don't get the game and my money isn't returned" "Do I really want to play this game more than my favorite $20 game?" When they might just want to give you some money because they liked your project.
Yes, it is and I don't get these self-important Nazis. As if you insulted someones real-world aiming skill by saying this.It is used to emulate the stability of your aim AS WELL AS many other inconsistencies in determining the bullet path. For game development purposes it's the correct observation. And no, you don't need to spend your life hoarding firearms or listening to people that did just so you can design a mere game where shooting makes sense and is fun.
center of mass, humidity, gun powder, muzzle break...
I feel like the thread has drifted far away from actual game design into some theoretical gun discussion where you impress people by re-iterating Wikipedia articles you just read. It's beyond being even a resource for a pure gun firing simulation.
Don't make your crosshair move. Crosshair is not where the bullet hits, it's where you aim. If you must, find some other means like weapon model bob to indicate accuracy. No matter what you do though the players will learn by playing how the accuracy ramps up and down with various factors and as an FPS veteran I personally consider it a meaningful component in game learning curve.
I dislike isometric because it looks wrong. In real life things have perspective, objects near look bigger and further objects appear smaller. If you move, the objects in the front occlude different parts of the background.
If you are actually doing 3D game then it should be trivially easy to change between perspective and orthographic camera. Even if you do static camera the perspective is always going to look better, for me.
But as soon as you start baking your objects to 2D it doesn't work so good anymore and some developers opt for isometric. If that's part of your plan then I'd rather play 2.5D (where everything is rendered purely side/top view and depth is expressed via offset / scale) than isometric.
Yes, tablets are almost mandatory for any 2D / 3D artist unless you do strictly pixel art. Tablet makes drawing with a mouse feel like a total waste of time.
For 3D they are used for texture painting (color and normal maps) or digital sculpting that is used to bake textures for lower resolution. Seamlessly control the opacity/size/strength of strokes and use the pen drawing motions you've practiced since you were a toddler...again there is no way you could get same results with a yanky and inflexible mouse.
For me it hasn't replaced mouse but I know some of those cases too. I find navigating 3D softwares too hard since pen+keyboard lacks scroll which I find essential in my work. Pressure sensitivity isn't needed outside painting/sculpting so mouse+keyboard offers more suitable forms of input. Also many use tablet+pen but I use too many keyboard shortcuts for tablet use.
Every serious game project could use a GDD in my opinion. But write them after you have the rough gameplay /game idea figured out so you can start thinking how will different features scale and combine.
You can acknowledge not every part of the game development is driven and controlled GDD because some things you just need to try in-game and see what feels right like player movement speed. But at least you should think of story, graphical style, asset creation pipelines, schedule and aims...Ideally these are not things that you hack together as you go.
Sorry to hear about your bomberman project :/ Those things could go one way or the other.
So you're rendering it into 2D sprite(s) eventually? I think the 3D model pretty much wasted effort if you're doing barely shaded isometric front view like in the example. 64x64 pixels is not hard to get right so consider using pure 2D software for making your future assets if they are of that size.
I think why I get mixed feelings of your design is because it uses artistically stylized shape but conventional color scheme. I get it though: shape is hard to replicate (especially in 3D modeling but colors are not. You need to make a decision on your style, is it realistic or artistic?
For realistic-ish style I'd like to see some limbs and more definition in the wings, black eyes and some shading to give it depth.
If you're going for cute toon style then you should also take artistic freedom over the colors and go wild, try pink and lime green in bright or pastel shades, black and white, hot and cold, rocky road cookie dough... you get the point. In the process of thinking the colour schemes also think of how you are going to make the backgrounds and enemies that need to be distinguished from your character.
A GDD for a someone who is working alone is really just a place to work on the project and organize your tasks for when you can't dedicate to the tasks themselves. I don't see one format of GDD suiting everyone.
Think of all the assets you're going to need and where to get them. What challenges or dilemmas could you face when you're creating your AI, pathfinding or inventory for example. I believe every game developer asks themselves these questions sooner or later. Hard things can prove quite easy when you lift it on the table and start writing things down. Or vice versa. A GDD is nevertheless a place where you can start answering your questions and regard yourself better prepared than prior to writing it
In team projects it has more important job of communicating between members, things have much more strict schedule and priority order so that every member can progress fluently and purposefully within their field without having to wait other assets that haven't been finished or designed yet. In commercial projects it also links to the bureaucracy and budget: how the spent and spare resources are in balance compared to the budget and schedule.
Also a pointer about the detail level: it doesn't matter but don't plan too much ahead. There's no use designing every number and feature in detail before you've done rudimentary playtesting to see if the concept will fly at all. Expand on "width" axis meaning it's better to design 7 enemies on crude level (and scrap 3 of them later if they don't work out at all) than trying to polish 2 enemies in detail before you have anything playable.
TL; DR: It's for you, make it as it suits you, but understand what it's for
Also worth mentioning is that dying is not scary, but being afraid of dying is. Always try to keep the player on his toes but make sure there are no places where he has to actually repeatedly die to learn something. Dying takes away the fear of dying and also the mystery about the monster. Also, leads to repetition which is boring.
You'll probably need a certain rule set for the game that you convey the player. "It can't come here because it's well-lit area". "It can't jump so you're safe up here". Then, later in the game, take away that "safe spot" mechanic. "It ran into the fuse box outside the door and the lights went out". "It climbed on the boxes and broke the railing". "It shook the columns and the catwalk broke." "It went through the ventilation duct and now lunges at you from ceiling". Tell the player "that might have worked before but it doesn't mean it's going to work every time" but be rational about it of course. Make the player to be in lookout for places where it might ambush them.
Why don't you post some of your work and we can talk about how to make them more realistic?
It's perfectly possible to create realistic characters with Blender, you can head over to blenderartists.org and see some truly amazing works. Making them work for real time and game use is just a question of optimizing where you bake ambient occlusion lighting, normal maps and simplify mesh topology.
But the biggest issue of course is to have the skill needed to shape realistic human characters and make clothing look plausible. Even more skill is needed for rigging and animating proper looking organic animations so your characters don't look like robots defying gravity and other laws of physics. Such skillset is not owned by many individual people and bigger game studios have dedicated artists working for each of the areas to ensure maximum proficiency and best overall results.