Jump to content

nick.ace

Members
  • Posts

    647
  • Joined

  • Last visited

Blog Entries posted by nick.ace

  1. nick.ace
    This is my first blog post for Crime Closer.
     
    Greenlight
     
    This was my first time submitting something to the actual Greenlight program. I did this to force myself to continually develop my game. I felt that the scope of Built from Ruins was too large for what I wanted to achieve with it. Built from Ruins would have been a better Early Access game that Crime Closer, but I want to finish Crime Closer completely before releasing on Steam. I think Early Access gets abused too much, and for a game like mine that doesn't use procedural content (and has unique missions and a storyline), this would be a bad idea. The only way this would be beneficial would be if the Early Access period were very short. Anyway, that's assuming my game gets Greenlit.
     
    I learned a lot about submitting on Greenlight. A few things I learned from my mistakes (hopefully others can learn from this as well):
    Have amazing screenshots since people mostly go on this. I had some decent screenshots, but nothing amazing, so I could have done better in this regard. Also, make sure you have at least 4 screenshots and a video. I initially didn't have that and took a lot of heat for it. IDK why Steam doesn't force these limits though since they aren't all that visible.
    Submit once you have more stuff done (I feel like I submitted too early. I was hoping to get a lot of feedback, and I initially did, but it's not as useful when you have less done). I was hoping to sort of shaping the development of the game around what people wanted. I think people sometimes don't know what they want exactly, but there are certain things that they will want.
    Use the first few days to your advantage as much as possible.Like I said, I put it up to vote too soon. Your game goes on the front page of Greenlight for a few days, and then you get hundreds of votes for or against it. After a few days, however, your games gets sort of lost in the array of other games. The trick here is to remain active and to advertise in other ways. This is something I need to improve at. One good thing, however, is that your game gets closer to the top 100 constantly since games are being Greenlit faster than ever.

    Idea
     
    Well, I wanted to create a game that focuses on positive aspects of society. I know that this may not be the best time to create a game about police (being in the U.S.), but I feel that the crime closing theme helps to give a bit of backdrop and allows for some interesting gameplay mechanics. This was an idea I had when I bought Leadwerks, and it was originally the idea I wanted to pursue with Leadwerks, until I learned LE3 didn't support vehicles at the time . Anyway, I don't want to make political statements with the game, but I feel that the police are sometimes objectified and made the villains in a large number of games, so I wanted to take the opposite side for once.
     
    Trailer
     
    I made my first actual trailer using some gameplay footage. I think it turned out pretty nice compared to other videos I've made in the past. Hopefully, it'll help a little with Greenlight.

     
    Demo
     
    I entered a demo for Crime Closer into the Winter Games. I'm actually kind of happy that this existed because it forced me to get more of a working game done. I wanted to release something that had applicable content and a few new features. Specifically, the game is evolving from a purely vehicular-based game into a third person game as well. I got some useful bug feedback, and this is great for going forward.
     
    Anyway, I'm not going to reveal the demo on the Greenlight page because I don't really want people messing with it too much right now. I mean, the Leadwerks community, their friends, even some random people are fine, but I want to keep everything under control as much as possible.
     
    Mods
     
    There was a suggestion to allow for mods on the Greenlight page. I need to be careful in how much I allow to be modded, mainly due to the Leadwerks license (which is quite reasonable in this regard). I think mods for vehicles (and their statistics) and other aesthetics and stat-based things would be great and seem to be allowed within the Leadwerks license. What I take isn't allowed is allowing for a scripting system, at least one that's as open-ended as Lua in Leadwerks. Possibly, I could introduce a custom scripting system that limits this so that it's not possible for a user to develop their own game, but again, I need to be careful.
     
    I would also need to figure out Workshop integration, but I'll cross that hurdle when I come to it.
  2. nick.ace
    Not too much in terms of visible gameplay has been accomplished (a lot of backend stuff and still doing level design ).
     
    Anyway, the game is starting to take shape in terms of setting up for more gameplay. The level design is important to me because the patrol routes of enemies and such need to be calculated in order to provide sufficient coverage so that it isn't too easy to grab items.
     
    Respawning:
     
    Items respawn using a region based system. Different regions will respawn after a certain amount of time, as demonstrated in the video. It's kind of cool seeing the items react to the physics as well as they respawn, but you won't see them actually respawn because it's partially distance based. This means that if you are too close to a region, nothing in that region will respawn. Also, items can't double spawn. I want to also randomize what gets spawned (so unlike in the video, the pickaxe might be a different tool). This is trivial, but requires a bunch of planning with item codes and such. I'll probably make this sort of level based.
     
    Enemy patrols:
     
    The way I implemented this was by creating child pivots attached to enemy meshes. Basically, these pivot values are stored in a table on start up and then iterated through so that the enemies can walk in a loop. If they break their loop to follow the player or something, they will return to it once the player is out of range.
     
    GUI:
     
    The last few days have been mostly doing this. I need a GUI to work for crafting. Right now, text displays over items so I know what they are, but these will likely be replaced by pictures. Also, you can drop items, but they won't be in the game world anymore (I think I'll change this, at least for tools).
     
    Inventory:
     
    So I unfortunately just missed Aggror's wonderful series on this kind of stuff, but I sort of created my own implementation, for anyone who is interested. Basically I have 3 Lua tables: one for an unorganized pile of items, one for grouped items (basically item and quantity), and the last one for item names (it maps item codes to names). The reason for the last table is to prevent issues with naming mistakes, such as if I make an item called "bricks" and another one names "brick." Instead, there is a number string that is associated with it.
     
    Interactive environment:
     
    Now you can chop trees to get wood, although this isn't very exciting. I think I need to redo this system because it's pretty poorly implemented. This will probably be one of the very few materials you can get from the wild.
  3. nick.ace
    So, I'm creating a blog to show how I'm approaching certain things (maybe this will be helpful to some people?).
     


     
    Stealth:
     
    This is a set of features that I wanted to go all out on, so that's what I'm doing right now.
     
    Shadows: Someone asked about how to implement shadows, and Josh gave a simple answer (kind of made me feel dumb lol). Anyway, the implementation for my game works for directional lights (the sun) right now, but it should be easy to extend to other lights if I choose to. Anyway, the way I calculated whether a point is in a shadow is by performing a raycast to the a vector generated by the light's rotation and scaled so that there would virtually be no building tall enough to evade the raycast.
     
    Crouch: This was pretty simple. The character controller needs to be changed using SetInput(), and the camera height needs to be changed while in crouch mode. That's it.
     
    Cover (Bushes): This was simple as well. I just performed a distance calculation to check if the player is near the center of the bush.
     
    Distractions (Rock): The AI doesn't actually "hear" the sound. Basically, each time the rock makes a sound, the rock the location of that sound is recorded and if it's close to enemy, the enemy will follow it.
     
    Buildings:
     
    I'm not sure how exactly I want to handle navigation due to building placement. I saw that there are recast commands accessible via C++, but I like to use Lua so hopefully these will be exposed through Lua in the future . But for now, these buildings have physics attached to them that scale as the building is constructed.
     
    Sounds:
     
    I sort of organized this like how a radio plays. When one ambient track finishes, another picks up. The way a randomly select the next track is by using the player's position data, but I found a way to change this in the future by using the system's milliseconds instead, but I don't know what to use!
     
    Day/Night:
     
    I wrote my own Day/Night script (I tried to use Shadmar's implementation, which is much better than mine, but I my weird lighting preferences made the colors of everything mess up). Anyway, it's simply a directional light that changes as time changes. Also, the ambient light changes as well so that the night becomes VERY dark! So, you must use your flashlight or find light!
×
×
  • Create New...