f13rce

Started integrating online multiplayer.. Needs some polishing but it's getting there Lobby: (the number is the current time in milliseconds to differentiate eachother) Perspective blue team: Perspective red team:

on this line: if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end Try removing the "windowstyle+" before the "window.FullScreen" part (so make it windowstyle=window.FullScreen). Also make sure System:GetProperty("fullscreen") is gives you "1".

It might also help to change the first value (the 90) into self.camera:GetFOV() so that the lerping will work better

Not as in health, but more to prevent virusses/keyloggers/etc @Sakru looks good! Are you going to keep it high poly or convert it to a detailed bump map?

It's made with C++ so I cannot put it on the launcher (due to safety reasons) :/ But I will release it on November 4th where you can download it from here

Cool. Will be getting on of those.

Changed the atmosphere, commanding of units, UI, added a free camera and more.. I'm pretty proud of this so far Full album here

Got some camera movement and unit selection working. Commanding them is the next part Bonus: Arrows added

Will be participating in the Halloween Game Tournament Had an idea where I could reuse some assets I made before... so why not? Here's some AI progress (no gameplay yet): Blue team vs Red team, people who die come back as zombie to kill anyone who is still alive. Every unit has different stats. Also started making a design document for this game (you can comment for feedback). I'm almost completely good to go.

How I did it for a different game I made: Setting up: 1: Have pivots set up as waypoints. This is also useful to see if people actually did race the entire track. 2: Whenever a player is near the next waypoint (using a distance check), add 1 to the waypoint variable. Reset the variable to 0 whenever the player is back at the start. The waypoint variable displays how many waypoints it has passed. Algorithm: 1: First check the amount of laps, sort by that 2: Secondly, sort by amount of waypoints 3: At last (if needed), do a distance check towards the next waypoint So for example: Car 1 finished 2 laps and is at waypoint 2 Car 2 finished 1 lap and is at waypoint 8 and is 5 meters from the next waypoint Car 3 also finished 1 lap and is at waypoint 8 and is 15 meters from the next waypoint Car 1 is first place because it has more laps Car 2 is second place because even though he has completed as many waypoints as Car 3, he is closer to the next waypoint.

Awesome, plenty of spare time as well to make something cool!

Game polishing is one of the most important factors to grab someone's attention. It also makes the gameplay feel smoother and generally makes the game look more done. But how do we do it? Here are 5 ways to add polishing into your game: Lerping Lerping is a term to make transitions smoother. This is commonly used in animations, where you linearly interpolate one frame into another. Animations and transitions will stop looking 'choppy' and will actually blend into the smooth gameplay. I quickly made an example with Ravage Online: http://gfycat.com/ImmenseHalfItalianbrownbear Notice how the M4A1 zooms in smoother than the AK47. It adds a bit to the game feel and immersion. Lerping can be used with animations, loading screens/bars, replay systems, particles and many more. Adding ambiances Ambiances are sometimes forgotten in games. They add a bit to the game feel and add meaning/immersion into the world the player is playing in. Examples of ambiances can be some torches, clouds, wind effects, sound and fog. The key to proper ambiance is to make sure there's always something moving or happening on the screen. In FPS games you usually see piece of papers flying around, or some smoke/fog through in the level. This screenshot is a great example of it. Grass, trees and plants keep moving, the sky is animated, people are walking around, you can hear ambiance sound and the light of day is changing. There's always something happening on the screen. It's not really hard to implement it either - just a lot of little things that greatly increase the immersion and feel. Balancing games Balancing is actually a bigger topic to talk about, but it's mainly tweaking values until it feel right. In competitive multiplayer this is a different story, but for singleplayer you want to try to make items and mechanics unique in their own way. In Ravage Online I wanted to make the M4A1 and AK47 feel way different from eachother, but still fall into the category 'Assault Rifle'. Sometimes it's easy to look at their own unique characteristics such as the AK47 having a lot of damage and recoil, while the M4A1 is usually known as being accurate and have a lot of stability. In conclusion of this I made the M4A1 4-shot kill in the chest and the AK47 3-shot kill. Because the AK47 has a lot more damage now but is known for its high recoil, I added a lot of kickback in the animation. This makes the AK47 less efficient on medium to high range combat, making the M4A1 more favorable in those situations. I can talk a lot more about these kind of changes, but the key points is just changing values and have them tested by others to make your final changes. Particles Particles are an extremely easy way to add polishing to the game. They give instantaneous feedback and add a lot more to the game feel. Because particles are easy to make, tweak and render, you can pretty much use it for anything: Footsteps, gun smoke, fire, impacts, water splashes and a lot more. This does add a bit more to the ambiance and immersion but the extra feedback makes it nice as well. In this screenshot you can see the muzzle flash, indicating the player that the gun has fired (sound also helps). The tracers help players to see where the bullet came from and where it landed. The shooter gets feedback on how accurate the weapon at that range is and the victim is aware of where it came from. The blood also is an indication for both the shooter and the victim that the victim has been hit. I'm still planning on a hitmarker so that the shooter has an easier time indicating the the victim has been hit. Game pacing Sometimes a player can be bored by the game because of the lack of game round/match speed. In 4-player games where players can die (like Super Smash Bros and Towerfall Ascension) players have to sit idly by watching the game go over. If you create quick and fun games, the player will only have to sit and realize what they did wrong instead of waiting for the round to end. This also has to do with the scope of your game. Quick games that only take 5-10 minutes (per round) have proven to (usually) be very fun because it's so polished (like Mario Kart 8 and many indie games). Another way to use game pacing is by spawning more objects. An example of this is where a gun is supposed to deal 50 damage with one shot, but only shoots one bullet. A way to use pacing is to make the rifle fire 5 times as fast, but let the bullets do 10 damage each. It kinda affects the balancing but the gun might feel better now. I want to end this topic with the very useful video by Jan Willem Nijman from the company Vlambeer with their video "The art of screenshake". The video contains a lot more info about what I did and didn't talk about. It's worth watching the whole thing: Thanks again for reading! - Ivar / Evayr

Been working on implementing particles, feedback, aiming down sights and gun movement (like recoil and stuff). Results are very satisfying... Will implement Steamworks as soon as the gameplay is solid

Ah, right. Sound had to be mono in order to work. This should be documented though.

I was trying to get sources spawned at positions where you can hear where it's coming from, but whenever I try to spawn a listener and a source (regardless of position), the sound would still sound 2D. Steps to reproduce: Start a blank C++ project Replace the App.cpp's code with this (from the wiki page) Find a sound to play (blank project doesn't have the sound from the wiki) Compile and run Use arrow keys and hear no difference Would be nice if this could get fixed soon. I'm using the latest Beta version. Haven't tested it with Lua though. Example project can be downloaded by downloading the attachment below:

@Gamecreator that's a fantastic article. Thanks for the share

@Josh When I heard that sound in the video I got reminded of goals and motivators, which motivated me afterwards to write this blog post

Felt like writing another blog... So here we go! Goals, motivators and progression are crucial in order to keep your player playing for a decent amount of time. Goals are usually represented with objectives or progression, engaging the player into the game and let them have a reason to keep playing. Like I talked about in the previous blog post, progression matters a lot when it comes to engagement. It gives the player a sense of achievement which keeps the player motivated to play. Rewards for progression give the player a good vibe and will most likely continue. Rewards can be anything: A chest full of gold, the newest weaponry, but also a small little sound that plays whenever you pick something up (like coins!). I noticed with the recent playerbase playing mobile games: people want to be rewarded as many times as possible. (A sound or a bit of score could be enough already.) Now I doubt anybody here is making mobile games, but you can process this concept in PC, Mac, Linux and console games - any type of game really. Example Let's take a look at the following game: Super Mario 64 (N64) The game is constantly rewarding you for progression. Here we see: 1: Breadcrumbs (Motivator) Coins are leading to a path towards the end of the level. Coins reward you by adding score, restoring health and giving a star and life at 100 coins. The coin rotates, giving the player some feedback that it can be interacted with. It also plays a little sound when picking up, this gives the player some extra positive feedback. Because coins actually help you, the player is motivated to pick them up - which is exactly what the developers of the level want you to do. 2: Exploration (Goal) The player is now familiar with the coins, but this one is red! Woah! When the player picks the coin up it gives a different sound which gets higher pitched if you collect more of them. The coin also is worth two yellow coins (restoring two health as well), giving the player another reason to pick them up. But because a number pops up indicating how many red coins you've picked up, the player will be eager to find more because there might be a reward for collecting them all. This adds up to the exploration of the level so the playtime of the game gets extended without having to add extra features or mechanics - while it is still fun! 3: Camera angle (Progression) This game isn't the best example of it, but sometimes games try to aim you towards the end by having the camera point at them. As soon as you get closer and closer you can feel the reward coming to you. "I'm so close, let's just finish it!" A good example of this is Journey, where in the intro you see this giant mountain. The game helps you towards your goal while the player doesn't necessarily notices it. Game flow The game can be simplified into this triangle: The player gets a goal (obtain a ), gets challenged by obstacles and eventually gets rewarded with a fancy, shiny . *insert progression sound here* So how do you keep a player challenged? There are ways by introducing new mechanics, but that will increase the scope of your project. However, the mechanics don't have to be unique or difficult. Portal has a good example of that: First they introduce a player to a fail-proof area. The player can't die here, nor is there an ability to fail the level in any way. As soon as the player knows how the certain mechanic or obstacle works, (s)he can progress to the next level. In the second level the player won't have a safety net: It's time to put it to the test. The player gets challenged with his new knowledge and has to try to succeed using the knowledge he just gained. Usually it's somewhat the same puzzle but a little bit more difficult. If you try to change the way the newly learned mechanic is used in the second level, the player might get confused and punished too much by dying all the time - resulting in the player quitting the game. So don't. In the third level the player knows the mechanic and has proven that (s)he can use it effectively. Usually you add a new way of using the mechanic by getting a bit creative where you also hint the player using signposting. An example could be breadcrumbs, arrows or particles popping up like "Hey, maybe you can use this!" (or just an NPC helper saying it). A safety net is not required, but helpful. You don't want the player to be punished for trying to learn - but that depends on the challenge as well. You can see this coming back in this video: So coming back to the question, you keep a player challenged by either introducing new obstacles or new mechanics. Rewards can help the progression of the player. In RPGs if you level up your combat stats so you can eventually get new weapons and armor. With this new gear you can kill new monsters, get new unlocks and adventure. It's actually an infinite loop of goal, challenge and reward if you think about it. Summary So to summarize this all up: - Have clear goals (and have the player know his goal at all time) - Give the player a sense of progression (feedback on coins collected, etc) - Give the player an appropriate reward so he can advance in the game (sometimes a sound, sometimes a chest of gold) - Have a clear game-flow (goal -> challenge -> reward -> goal) Thanks for reading! My next blog post will be about juicing up the game. Oh, and here's your reward:

Haven't written a blog before, but things have always come into my mind about certain subjects.. Figured I should finally start writing a blog. This blog is mainly about my personal experience and advice on making games in general. Even though I've made some games like Ravage Online (RO) and the potential Grievous Grounds (GG); the games aren't really done and I'll be elaborating how this has happened. Scope The scope of both of these games are pretty big. For Grievous Grounds it was a little big too big. But why? I basically wanted to do something challenging, something I could work on for months and have a super shiny professional result, bursting out of my portfolio website. The problem here is: I don't have the time. I got accepted on the NHTV (best school in the Netherlands) and have to prove myself worthy by getting all the ECTs. We have to do a lot of cool stuff like making games, studying history and managing projects (and teams). The scope of RO and GG are way too big where I can show little progression after every session of programming. I DO like Leadwerks and I definitely want to become a video game programmer in the future, but school has the priority right now. The solution: If you want to make games, keep the scope very small. Something that can already have a prototype in a week. You won't be able to make an advanced game like Minecraft in a week. In fact, even Notch started his project small. All you could do is place and remove blocks in the world of 3D Pixels. After that you have all the time to add in extra functionality and increase the scope little by little. Just look at Minecraft now: Crafting, story mode, mobs wandering around... If you wanted to do all of this from the start, Notch probably wouldn't have finished the alpha in the first place: It's too much work. Example of a small scope For GameLab at school (project based learning) we have to make a game where we got two random themes: Chain and Flat. We came up with the idea of a very simple game where you have to blow stuff up (by using chain reactions). After day one we already got a working prototype with the core mechanics: Place bombs, blow stuff up. This gives a relieve because you know you can achieve it because you just proved it. The scope it small, it's easy to prototype (to see whether it's fun or not) and you can easily add features to it (like in our case a replay system). Define a finish line If you don't define what the finish line is, you'll be running a marathon with no end. You'll get exhausted and bored of your project and disregard it. Make sure you know what has to be in the game in order to be complete. This is primarily the reason why RO and GG haven't been finished. Working on a project Progress takes time and has to be rewarded. You nowadays constantly see games rewarding the player for every move he makes. Example: It might sound really weird, but rewarding yourself for every progress motivates you. Progress in general motivates you - all you have to do is make it visible to yourself that you made progress: Now how do you do this? (Tip: Reward the player in games! Give them a reason to progress and keep progressing. If you don't the player might feel lost because of the lack of (positive) feedback. Examples of rewarding: +5XP's all over the screen, unlocks, achievements, progression bars, etc.) SCRUM This technique is used to show what to do, what's in progress, what needs to be tested and what's already done. We use this technique during the development of our explosion game (in GameLab). SCRUM allows yourself to show a lot of progress and displays what others are doing as well. We use Trello for our SCRUM. As you can see on the screenshot everything is clear, organized and displays progress at any time: There are other ways to display progress, like a Google Docs document where you mark everything green of what's done - that works as well. As long as you can display progress to yourself (and your team). Finishing a game This is the hardest part. Finishing a game takes so much time because you have to do all kinds of stuff like polishing, reviewing and bug fixing. The only way to prevent a lot of polishing and reviewing, I'd suggest to playtest your game as soon and as many times as possible. This shows your game's strengths, weaknesses and bugs you wouldn't find out on your own. Don't be afraid to show it to your friends! They might be harsh on some parts, but if you take the most important feedback out of it you'll improve your game's experience by at least 50%. Polishing also takes a LOT of time, this might eventually take about 15% of the actual development time. You want to deliver an enjoyable experience towards the player, not a buggy one where it can break once every 3 times. This can make the player frustrated and put down the game. Polishing is really important and do take your time for it. At last, I'd recommend working on the game at least once every week. This prevents confusion of what you've written before and how your game's pipeline works. Example: "How do I modify the AI's thinking again?" ------------------------ Recap: Keep your scope small. Define a finish line. Display progression (like using SCRUM) and motivate yourself with it. Playtest as much and many times as possible. ..And finish your game! Thanks for reading!

I did notice that debug mode in C++ takes away a LOT of fps. Maybe this has to do with it? Still it's pretty weird that just the screen resolution gives you this drop.

Sure, I can help along every now and then

Got a birthday party then, seems like I'll have to miss it this time as well :/

I'm willing to implement a post-game screen where you can select the type of soldiers before you spawn. Grenades would also be nice for this game, especially smoke grenades. Maybe a quick-menu like in BF2 (when holding Q) would do too. Thanks for trying it out Edit: Added controls in the download page

Swipe is a tactical FPS where you have to command units to complete the objective. You will look at your troops in commander mode and control them from there. The unique feature about this game is that you can control any soldier at any time in order to assist yourself with your tactics. Using commander mode gives benefits where you can control allies and look where the objective is or where enemies are. In first person you can control your own soldier in order to execute a task more efficiently, or just get immersed with the situation. Demo I've put up a demo on Leadwerks and IndieDB. Feel free to try out and provide feedback! Screenshot Video

Take a look at SetInput() using the camera's Y rotation on the model you want to move. That should do the trick.