Jump to content
  • Advertisement

Blogs

How and Why my world Turns.

Continuing my rewind for Unsettled World: Time to give some detail on the foundations of my game environment.  The planet I've created and how it mechanically works within Unity. Here is a 2d view of the editor interface with the "canvas" highlighted sitting at 0,0,0.  The planet object has a 30000m radius and it is sitting @ 0,-30000,0. The object parentage looks like this.  Generic GameObject "PlanetHolder", non-rendered mesh w/collider "Planet" (used by the procedural terrain system mostly), followed by the camera, player, water sphere and the actually visible surface mesh.  Now, this arrangement may change somewhat, I may figure out a way to combine the "Planet" with the visible surface, but it is how it is for now.  And it works. The PlanetController script is responsible for keeping the player and camera close to Origin, 0,0,0.  This is necessary because once your player/camera cross the 10000m distance boundary the underlying floating point mathematics loses enough precision that your meshes begin jumping around the screen.  The PlanetController script contains this logic: public class PlanetController : MonoBehaviour { public GameObject Planet; public GameObject Player; Rigidbody rb; void Start() { rb = Player.GetComponent<Rigidbody>(); } void FixedUpdate() { if (rb.velocity.magnitude < 1) { Planet.transform.localRotation = Quaternion.FromToRotation((Player.transform.localPosition - Planet.transform.localPosition).normalized, Vector3.up); } } } Keep in mind I omitted a lot of extra stuff from that code, for example, it doesn't actually run EVERY FixedUpdate, but as a timed event inside the fixed update, every few seconds or so. Also Important to note, I still have a minor amount of vertical jitter that is caused by the planet sitting at 0,-30000,0.  I am actively working at ways to reduce this, in fact, as I type I'm having more ideas on how to fix the issue.. So keep posted.  ^Solved and NOT related to the size/positioning within the 3D space, see comment below. The visual look of the planet(Before the procedural code kicks off and repaints it with textures/objects).  Is a split up version of the planet mesh(will be split up MUCH more than this eventually)..  And the water is a simple sphere object(also broken up and non-visible sections removed) with a water texture. My Gravity "system" is also very simple(Just a script, like this one, attached to the objects that need gravity applied to them): public class GravControl : MonoBehaviour { public GameObject planet; private Rigidbody rb; public Vector3 upVector; void Start() { if (planet == null) { planet = GameObject.Find("Planet"); } rb = GetComponent<Rigidbody>(); Vector3 upVector = (transform.position - planet.transform.position); transform.rotation = Quaternion.FromToRotation(transform.up, upVector) * transform.rotation; } void FixedUpdate() { upVector = (transform.position - planet.transform.position).normalized; rb.AddForce(-upVector * 9.81f, ForceMode.Acceleration); } } I may incorporate this into a "controller" type script that isn't attached to every object at some point for simplicity, but for now, it works just fine. So that, just a few pics and sentences, well summarizes at least 2 or 3 solid weeks of 8+ hour days... hahaha!

Septopus

Septopus

The Balcony 50% off!

Our first game 'The Balcony' is turning one this month and that is why we are having a special sale for 50% off. A lot has happened in just one year and we have learned so many things related to game development. We are currently working on our second game which is going to be a 3D platformer where your mission is to climb a tower all the way up to the top avoiding falling down. The game is very much different from our first game since this time we are focusing more on the graphic side of the game as well as the game mechanics. Many have said that 'The Balcony' was too challenging so our new game will have four levels of difficulty from easy to insane. That way everyone will have a chance to enjoy the game no matter how great gamer you are. Thank you for your support so far. If you have any questions we are here to answer them! Here is a gameplay video of our game 'The Balcony' from Play Pals. If you are interested in the game here is the link to the store page.  

Holotna

Holotna

 

Mobile Update to version 1.6 “Coin Rush” Game Mode

Hey All, So Roll and Throw Game Mode is complete and Coin Rush is almost complete as well. Couple things I’m adding to it. I think I may include 1 more Game Mode before I release this update so most likely looking at another week before release. After that I will concentrate on chapter 3 and conclude the story. Here is a sneak peak at Coin Rush Mode. This is not final product.     View the full article  

SOS-CC

SOS-CC

 

Monetization best practices (and a new Ad Tutorial!)

New tutorial! First, we would like to take this opportunity to let you know about a new tutorial on implementing advertising in your Corona apps. The tutorial covers code and common code to implement an ad plugin in your app. You can view it here! Read the Implementing Ads tutorial Monetization best practices A great question was asked in our Community Forums about using in-app purchases (IAP) to turn off advertising. It may seem like a simple idea but there is more to it. When you sell your app for a fixed price, that person pays you once, ever. When you use ads, you get a continuous stream of income as long as your app or game is being used. If someone uses IAP to turn off ads, you get continuous income until they pay for the IAP, then you get the one-time fee and that’s it. For some apps, IAP subscriptions can provide ongoing income, but an app has to be pretty special, with lots of new content to convince users to continuously pay for it. Let’s look at the financial considerations in answering this question. Let’s say that you end up setting the IAP fee to turn off ads at $0.99 (or an initial purchase price with no ads). Because the app stores take 30% of your sales, that means you will make $0.69 from that user when they make the purchase. But the question is: Will you make more from advertising? Using Appodeal as an example and information from Appodeal’s E-Book “Monetizing Casual Games”, banner ads typically pay about $0.43 per thousand banner ads shown. To earn that same $0.69 from app sales, you need to display over 1,600 banner ads to your app user. Assuming your banner ads rotate every 45 seconds, it will take over 1,200 minutes or about 20 hours of view time to earn that same amount of money from the user. Note: eCPM values for the United States and Europe were averaged together from numbers in the e-Book. Banner ads may not be the best way to implement ads. If you’re using other ad forms, like interstitials which pay an average of $4.59 per thousand ads, you need to show about 150 interstitial ads to earn the equivalent purchase income. Note, video interstitials pay more than static interstitial ads. Let’s say you can show 2 interstitial ads per session on average, the user only has to play about 75 times to make up that income. You don’t want to over-show ads to keep it from becoming an annoyance causing your user to just quit your app. Rewarded video pays about $10 per 1000 rewarded videos. That means the user only needs to view 7 rewarded videos to earn you that same $0.69. How do you get to that many ad displays? Most users tend to play a game a lot at first, then over time, they play less and less. All games have a usage “tail”. If you view this generic usage graph, it looks like a dinosaur: Picture by Hay Kranen / PD The left side is your initial usage spike (the head) and then as time passes it gets used less and less (the tail). Some games will have a long tail, but many will have a short tail. No one can really predict in advance how long your game’s tail will be. Successful apps will have a longer tail and a taller tail. It indicates that you are retaining users longer. Games and apps with a long tail will make more money from advertising. If your game doesn’t have any longevity to it, you want to convert them to paid as soon as possible. This combination of retention and revenue is your game’s LTV or Lifetime Value. If your game is too short, offering an option to disable ads won’t be effective because you won’t have any retention to motivate them to disable ads. If your ads are too annoying, people may get turned off to your app and give up on it early. You have to strike a proper balance between advertising and entertainment or utility value of your app. Even short-lived apps can monetize successfully by … Using Rewarded Video Rewarded video is clearly the winner in the eCPM value for you, but you have to use them wisely. Rewarded video is the user volunteering their time in exchange for some in-game reward. You can’t just throw a rewarded video in front of a user automatically. That’s the job of an interstitial ad. If you force the user to watch an ad, even if you reward them, it’s still forcing them to watch the ad. Consider they have played your level and lost. Your game logic shows them an ad and resets back to the beginning. That is an Interstitial ad placement. If you prompt them “Would you like to view an ad to continue to the next level?” and if they agree, you should show them the video and let them move on to the next level. If they choose no, simply take them back to the beginning, but don’t force them to watch the ad. Rewarded ads encourage players to continue playing, either by not losing progress or by gaining some in-game feature which can extend your app’s LTV. Using these techniques, even games with shorter tails can be quite successful. Conclusion Every app is different. You should make the most entertaining game you can or the most useful business or utility app that brings real value to the user, then balance your advertising, in-app purchases and in-app currency to maximize your income.
View the full article

CoronaRob

CoronaRob

Inception, or How I Lost My Mind.

Well, this is the first post for a project I've been working on for a few months already.  So, let me rewind a bit.... A few months back I started toying with the idea of making a game with an actual spheroid planet as the core of the environment.  Yay Unity and Blender!!  A few weeks of toying around and I had a pretty neat little 5000m diameter spheroid planet with custom gravity and a player character(UMA v2) running around on it.  Well, that was way easier than I expected... It was at this very point, the actual madness began to set in.  Well, it's working, I guess I should make a game out of it...  Okay.  Hmm, online?  Of course!  Hmm, mmoYES!  Oh, damn, I've really lost it now.  Crafting, well, certainly.  Mining and hunting?!  Don't be silly, yes yes yes yes, all the yes. Bigger? hmmm.... hmm... yes? Let's try 10000m radius..  hmmm...  Jittery character movements.. and jittery everything... hmm...  9000m radius?  all good... hmmm... And this is where I learned all about the floating point precision problems of 3d engines at great distances from 0,0,0..  Fun stuff.  Only slightly maddening.  But, in the end, also easily solved by rotating the entire freakin planet periodically so the player character and camera stay close to 0,0,0. Let's pump this guy up to 30000meter radius and call that good for now.  I ran across a few other jitter problems along this winding path but those were solved through the careful use of the "FixedUpdate" vs "Update" method selection.  Moving anything that involved my custom gravity or physics in general to a FixedUpdate method was the solution for most cases. So, we got a character and a planet...  I guess we need stuff to do.  And from here the rabbit hole only started lengthening, until there really was no beginning or end. So, there's one of the nutshells...  The inception! Over the next few days I'm going to try to detail as much of the current guts of this beast as I can for anybody who's crazy enough to follow along, while trying to not distract myself from creating more of them of course.    Project Stats: Unity Game Client Lines of Code: 24,032 Avatar Server Lines of Code: 2,480 Economy Server Lines of Code: 387

Septopus

Septopus

Pathfinding Navigation Mesh : Wall Collision Avoidance

Subscribe to our subreddit to get all the updates from the team! Introduction In our 3D game (miimii1205), we use a dynamically created navigation mesh to navigate onto a procedurally generated terrain. To do so, only the A* and string pulling algorithms were more specifically used until our last agile sprint. We recently added two new behaviors to the pathfinding : steering and wall collision avoidance. In this article, I will describe how I achieved a simple way for agents to not walk into walls. Configuration 3D or 2D navigation mesh, as long as the 3D one is not cyclic. Navigation cells and their : polygonal edges, connections (other cell), shared edges (the line intersecting between two connected cells), centroids and normals. An A* and string pulled (not tested without string pulling) generated path consisting of waypoints on the navigation mesh. The Algorithm The agent is the pink low-poly humanoid and the final destination is the flag.   The ideal algorithm (yet unoptimized) would be to cast an oriented rectangle between each consecutive waypoint where its width is the two times the radius. Think of the agent's center position being in the middle of the width. Anyway, this algorithm is too complicated, too long to develop for our game, too big for nothing and so I thought about another algorithm, which has its drawbacks actually. However, it's more suited for our game. Psss, check this article if you haven't seen it yet. The algorithm is the following : For each waypoint, pick the current one and the next one until the next one is the last. Iterate over the current navigation cell's edges, which is defined by the agent's 3D position. To do that, you need a spatial and optimized way to determine the closest cell of a 3D point. Our way to do it is to first have have an octree to partition the navigation mesh. After that, get all the cells that are close to the point plus an extra buffer. To find the cell that is the closest to the point, for each picked cell, cast a projection of the position onto each one of them. This can be done using their centroids and normals. Don't forget to snap the projected position onto the cell. After, that compute the length of the resulting vector and pick the smallest one. Convert each edge to a 2D line by discarding the Y component (UP vector). For each side left and right, which are defined by the agent's position and direction towards the next waypoint, cast a 2D line that start from the agent's position, that goes towards one of the two perpendicular directions related to the direction to the next waypoint and that has a length of the defined radius. If there's an intersection on a connection and that it's on the shared part of the connection, then continue with the connected cell's edges. If there are any intersections other than #5, create a new waypoint before the next waypoint. This new one's position is defined by the intersection's position translated by a length of two times the radius and projected towards the agent's current direction as a 2D line. The same translation is applied to the next waypoint. Cast two 2D lines, one on each side of the agent as described before, starting from the sides, going towards the same direction as the agent and of the same length between the current and next waypoint. Check for #5. If there is an intersection on a connection and that it's on the unshared part of the connection, then do #6 (no if). If there's an intersection on a simple edge, then translate the next waypoint as described in #6.   Here's a video of the algorithm in action :   

Simple organic and brute force dungeon generation

Subscribe to our subreddit to get all the updates from the team! Last month, I made a pretty simple dungeon generator algorithm. It's an organic brute force algorithm, in the sense that the rooms and corridors aren't carved into a grid and that it stops when an area doesn't fit in the graph. Here's the algorithm : Start from the center (0, 0) in 2D Generate a room Choose a side to extend to Attach a corridor to that side If it doesn't fit, stop the generation Attach a room at the end of the corridor If it doesn't fit, stop the generation Repeat from steps 3 to 7 until enough rooms are generated It allowed us to test out our pathfinding algorithm (A* & String pulling). Here are some pictures of the output in 2D and 3D : 

Unit Vision

Subscribe to our subreddit to get all the updates from the team! First off, here's a video that shows the unit vision in action :    So, what is the unit vision? It's a simple mechanism that notifies a unit when another unit enters its vision field. It also takes into account if the vision is blocked by entities. This is how it is implemented step by step : A cone ghost control is attached to the unit's head All units intersecting with the cone's AABB fire events (AABB because of how Bullet Physics work) Cast a ray towards the visible unit and then adjust the angle so that it fits in the cone If the ray cast touches the supposedly visible unit, then it is truly visible   Using the debug view of Bullet Physics in the jMonkey Engine 3.1, we're able to see what the vision cone actually looks like.   And when inside the cone we can't see it because of culling. However, we can see the enemy's arm moving, which is a test I did for when a unit see another unit.   Behind a box, the enemy does not move its arm because he can't see me.   But when I leave my hiding spot, he can see me again.

Zone generation

Subscribe to our subreddit to get all the updates from the team! I have integrated the zone separation with my implementation of the Marching Cubes algorithm. Now I have been working on zone generation. A level is separated in the following way : Shrink the zone map to exactly fit an integer number of Chunk2Ds, which are of 32² m². For each Chunk2D, analyse all zones inside its boundaries and determine all possible heights for Chunk3Ds, which are of 32³ m³. Imagine this as a three dimensional array as an hash map : we are trying to figure out all keys for Chunk3Ds for a given Chunk2D. Create and generate a Chunk3D for each height found. Execute the Marching Cubes algorithm to assemble the geometry for each Chunk3D.   In our game, we want levels to look like and feel like a certain world. The first world we are creating is the savanna. Even though each Chunk3D is generated using 3D noise, I made a noise module to map 3D noises into the 2D to able to apply 2D perturbation to the terrain.   I also tried some funkier procedural noises :  An arch!   The important thing with procedural generation, it's to have a certain level of control over it. With the new zone division system, I have achieved a minimum on that path for my game.

Zone division

Subscribe to our subreddit to get all the updates from the team! A friend and I are making a rogue-lite retro procedural game. As in many procedural rogue-lite games, it will have rooms to complete but also the notion of zones. The difference between a zone and a room is that a zone is open air whilst a room is not. Rooms are connected mainly by corridors while zones are mostly naturally connected / separated by rivers and mountains.   Because we want levels with zones to be generated, we need to tame the beast that is procedural generation. How can we generate each zone itself and also clearly divide them? Until now, I had only been using the Java noise library called Joise, which is the Java community port of JTippetts' Accidental Noise Library. I needed the zone data to be generated with basis function modules, i.e. Perlin noise, but in contrast I needed a more structured approach for the zone division. Joise library does have a cell noise module that is a Worley noise. It looks like this depending on its 4 parameters (1, 0, 0, 0) :    Using math modules, I was able to morph that noise into something that looks like a Voronoi diagram. Here's what a Voronoi diagram should look like (never mind the colors, the important parts are the cell edges and the cell centers) : A more aesthetic version :   The Worley noise that I had morphed into a Voronoi-like diagram did not include the cell centers, did not include metadata about the edges and was not enough deterministic in a sense that sometimes, the edges would around 60 pixels large. I then searched for a Java Voronoi library and found this one called Voronoi-Java. With this, I was able to generate simple Voronoi diagrams :   Relaxed : 1 iteration   Relaxed : 2 iterations The relaxation concept is actually the Lloyd's algorithm fortunately included within the library.   Now how can I make that diagram respect my level generation mechanics? Well, if we can limit an approximated number of cells within a certain resolution, that would be a good start. The biggest problem here, is that the relaxation reduces the number of cells within a restricted resolution (contrary to the global resolution) and so we need to keep that in mind. To do that, I define a constant for the total number of sites / cells. Here's my code : private Voronoi createVoronoiDiagram(int resolution) { Random random = new Random(); Stream<Point> gen = Stream.generate(() -> new Point(random.nextDouble() * resolution, random.nextDouble() * resolution)); return new Voronoi(gen.limit(VORONOI_SITE_COUNT).collect(Collectors.toList())).relax().relax().relax(); }   A brief pseudo-code of the algorithm would be the following : Create the Voronoi diagram Find the centermost zone Selects X number of zones while there are zones that respect the selection criteria Draw the border map Draw the smoothed border map The selection criteria is applied for each edge that is connected only to one selected zone. Here's the selection criteria : Is connected to a closed zone, i.e. that all its edges form a polygon Does have two vertices Is inclusively in the resolution's boundaries   Here's the result of a drawn border map!   In this graph, I have a restricted number of cells that follow multiple criteria and I know each edge and each cell center point. To draw the smoothed border map, the following actions must be taken : emit colors from already drawn pixels and then apply a gaussian blur. Personally, I use the JH Labs Java Image Filters library for the gaussian blur. With color emission only : With color emission and a gaussian blur : You may ask yourself why have we created a smoothed border map? There's a simple reason for this, which is that we want the borders to be gradual instead of abrupt. Let's say we want rivers or streams between zones. This gradual border will allow us to progressively increase the depth of the river and making it look more natural in contrast with the adjacent zones. All that's left is to flood each selected cell and apply that to a zone map.

Low poly terrain

Subscribe to our subreddit to get all the updates from the team! Recently I've been tackling with more organic low poly terrains. The default way of creating indices for a 3D geometry is the following (credits) :   A way to create simple differences that makes the geometry slightly more complicated and thus more organic is to vertically swap the indices of each adjacent quad. In other words, each adjacent quad to a centered quad is its vertical mirror.   Finally, by not sharing the vertices and hence by creating two triangles per quad, this is the result with a coherent noise generator (joise) : It is called flat shading.

Behavior Tree - Follow, Search And Retreat

I integrated LibGDX's Behavior Tree AI module into our roguelite, vaporwave and procedural game, which is made use the jMonkey Engine 3.1. I then created the following behavior : - Follow enemy - Search the enemy's last recorded position - Return back to initial chase position - Stop the chase after a certain amount of time - Attacking the enemy resets the timer   Here's the behavior tree logic. Beware that it's possible there are still bugs. subtree name:"notIsReturningToInitialChasePosition" invert isReturningToInitialChasePosition subtree name:"notIsMovingToFollowingEnemyLastPosition" invert isMovingToFollowingEnemyLastPosition subtree name:"notHaveSpottedEnemies" invert haveSpottedEnemies subtree name:"followEnemy" selector parallel lookOutForEnemies alwaysSucceed lookAtClosestSeenEnemy alwaysSucceed (isPlayingAnimation animation:"look_around") stopAnimation animation:"look_around" followClosestSeenEnemy parallel policy:"selector" alwaysFail wait seconds:10 attackClosestSeenEnemy root selector $followEnemy (isFollowingEnemyAlive) (knowFollowingEnemyLastPosition) ($notHaveSpottedEnemies) sequence resetLookAt moveToFollowingEnemyLastPosition parallel policy:"selector" alwaysFail playAnimation animation:"look_around" lookOutForEnemies alwaysFail resetLookAt returnToInitialChasePosition
I'm new to AI programming and still have a lot of work to do for making better behavior trees. I think it's really easy to make spaghetti behaviors. Do you have any tutorials on how to create a "good" behavior tree?
 

Migrating and Porting

Migrating the Database For some reason I thought it would be a good idea to migrate the database from MySQL to PostgreSQL. Installing PostgreSQL on Debian (in my case Debian 8 Jessie) is just one command line. I also made a simple backup script which is run by a chron job, I have a similar script for MySQL: #!/bin/sh # sudo crontab -e # Backup all PostreSQL databases every day 3 am #* 3 * * * /mnt/sda1/bak/pgsqlbak.sh TIMESTAMP=$(date +"%F") BACKUP_DIR="/mnt/sda1/bak/pgsql/$TIMESTAMP" USERNAME="my_name" export PGPASSWORD="*********" find /mnt/sda1/bak/pgsql/ -maxdepth 1 -type d -mtime +7 -exec rm -Rf {} \; mkdir -p $BACKUP_DIR databases=`psql -h 127.0.0.1 -U $USERNAME -q -t -c "SELECT datname FROM pg_database" | sed -n 4,/\eof/p | grep -v rows\) | grep -v template0 | grep -v template1 | awk {'print $1'}` for i in $databases; do /usr/bin/vacuumdb -z -h 127.0.0.1 -U $USERNAME $i >/dev/null 2>&1 /usr/bin/pg_dump -U $USERNAME -i -F c -b $i -h 127.0.0.1 -f $BACKUP_DIR/$i.backup /usr/bin/pg_dump -U $USERNAME -i -F p -b $i -h 127.0.0.1 -f $BACKUP_DIR/$i.sql done Migrating the database structure required some manual work, but fortunately the database is still very small. So I just used mysqldump to get a SQL file, changed some types and syntax and imported it into PostgreSQL. Because I use a caching data server, which is the only program that accesses the database, and this data server is database agnostic (so i can just switch back to MySQL with changing the configuration file), I can not use any advanced database features anyway. This made the migration of the database much easier. I can't even use auto incremented values for primary keys or other database generated values, instead it uses UUIDs as primary keys. The PostgreSQL backend was never tested before, so it surprised me a bit that the data server worked without any changes with PostgreSQL. Porting the Data server I am developing this with MSVC 2015 on Window 7 64 Bit, x86_64 architecture (I also tried VC2017 but the linker crashes all the time). The target is Debian 8 on ARMv7 (32 Bit) architecture. So, not just that the target is a different tools chain, but also the OS and architecture is different. To generate the make files (and VS solution, project files) I use premake5, because I'm not smart enough for CMake. Compiling I didn't compile anything on Linux in ages, so I thought this could be fun. Getting the source to compile with GCC and Clang was not hard, every library I use is also available for Linux, or also compiles on Linux (Lua, SQlite, Asio). What I needed to do was: Just ignore many unknown pragma warnings. Get rid of MS' secure CRT functions (e.g. sprintf_s() -> sprintf()). Get rid of the nifty #pragma comment(lib, ...) and add the lib files to the project and make files instead 😟. Throw out the ODBC database driver. I thought about also targeting MSSQL, so it seemed to be a good idea to have support for ODBC, but it's not used. Turn off Linktime Optimization (full program optimization). Took me a while until i realized my compiler does not support it. Linking So making the program just to compile was very easy, but making it also link was a pain, especially the PostgreSQL client library has many dependencies (e.g. libldap2-dev, libssl-dev, libgsasl7-dev). So I ended up having something like this in my premake5.lua: if (_TARGET_OS == "windows") then links { "abscommon", "abcrypto", "sqlite3", "libpq", "libmysql" } elseif (_TARGET_OS == "linux") then links { "pthrerad", "abscommon", "abcrypto", "sqlite3", "dl", "pq", "ssl", "crypto", "mysqlclient", "z", "gssapi_krb5" } end Finally it complied and linked, but there are still some problems as you can see on the screenshot. It runs now on the same machine as the database server. The data server is very lightweight (without load 🤣😞 Update The linking issues have been solved with upgrading VS2017 to version 15.8.6. Now everything (18 projects) compile, link and run fine with VS2017. Also the obvious bugs on Linux have been solved, but the Linux version of the data server is still not reliable.

trill41

trill41

Fall 2018 GameDev Challenge: Frogger

The votes have been case for your next GameDev Challenge and Frogger came out ahead as the winner. Your challenge is to create a game with the gameplay elements of Frogger. Frogger is considered a classic from the golden age of arcade games. It was originally released as an arcade game in 1981 by Konami. The object of the game is to move frogs to their homes one by one across a busy road and a river of hazards. The gameplay of Frogger is relatively simple. From Wikipedia:   The gameplay has proven to be popular. Most recently, mobile hit Crossy Road brought Frogger-like gameplay via chicken.   Challenge Requirements The game must have: Menu menu and a way to return to the main menu Frogger gameplay mechanics, including but not limited to: At least one character Must maneuver the character across obstacles, moving and stationary The character must have a goal to achieve - location-based, point-based, or otherwise Score system Game over screen Audio: 1 music track and/or sound effects (firing, enemies being hit, etc) Game may be in 2D or 3D Dates The official Challenge period starts on October 2, 2018 and ends on November 10, 2018 at 11:59pm IDL. Submission Create a new topic in the GameDev Challenge Group Forum as a submission announcement and include: Link to project posted for download in GameDev Projects (you can use itch.io too, but no award without it on GameDev Projects!) Upload your files to the project so other members can download and play Please contact me if your submission is a web-based game (GameDev Projects does support them!) Screenshots should be included on the GameDev Project page and/or the Gallery Album for your project. Embedding screenshots in the topic announcement is encouraged. Embedding YouTube or Vimeo trailers is also encouraged A small post-mortem in a GameDev.net Blog associated with your GameDev Project (select Project when posting blog), where you can share what went right, what went wrong, or just share a nifty trick you learned Source-code link is encouraged for educational purposes Github link, zip download in GameDev Project, or otherwise Challenge Award Participants who complete the challenge will receive: 1,000 Pixels Mentions in the GameDev.net Direct weekly newsletter Most important: the Frogger Award for your profile    

khawk

khawk

First screen from my new game

Some days ago I have started working on a new game. I have decided to go for an NES graphics (my goal is to make it look exactly like an NES game). I have already spent a lot of time to make the movement as fluent as possible. The movement is a bit similar to Contra when you are on the ground, but when you jump, you have 100% control over your moves. You can also decide how high you want to jump. The main characters (Vampire) can do wall jumps. The movement is very easy to grasp, but I want it to be deep at the same time, because I want speedrunners to speedrun this game. Let me know what you think about the graphics (it's pre alpha, the final game will look different, hopefully better).

Look what I found....

Haha!  Take a look what I uncovered the other day while digging through my books.... It even came with a good old floppy disk!  (I couldn't even use it if I wanted to now)... This book was my very first on 3D graphics programming, before 3D graphics card were even a thing (for the mainstream masses anyway).  Published in 1994, it's a book that served as a really good primer to understanding 3D geometry and programming even if I never bothered with the later chapters on curved geometry.  All the code samples were in C (not even C++) and there was no such mention of things such as texture mapping (although it did cover shadows, reflections and refraction!).  It took you right from the beginning; from the equation of a straight line, translations, matrices etc to projections (viewing pyramid) and clipping algorithms.  Great stuff! I still find it useful now as I re-read the introductory chapters and refresh myself on a few basics. My other go-to book is "Real Time Collision Detection" by Christer Ericson - an absolute diamond of a book! Do you guys and girls have any books that you rely on or hold in high regard for your game development?  It would be interesting to know if anyone has ever seen or read the Georg Glaeser book above. Anyway, I'll soon have another update on The Berg, but it's bed time for me now.  Night all.  

Greedy Goblin

Greedy Goblin

Warfront Infinite Dev Blog #20: Drastic Changes to The Theme

This week me and my graphics designer have decided to drastically change the theme of the game. Instead of generic military-based theme for enemies, we decided to go with something more fun... ALIENS. That's right. The enemies will now be aliens and your mission will be to defend your base from these monsters: Although as of now these aliens aren't animated and won't appear in the screenshots below, I'm positive that next week they will be implemented into the game. Regarding the programming side of the game, I have implemented few new features: Player can now fix damaged towers using a wrench tool Implemented in-game options menu and got rid of the Unity's generic resolution/quality settings menu. Added information windows which will be shown at the beginning of the game. These windows will contain information about new enemies and towers As well as this, I fixed some bugs and started preparing the project to support multiple levels.  This week I'll be working on adding more levels to the game and will be thinking about what kind of enemies could be implemented.

EddieK

EddieK

Tales of Vastor - Progress #8

Tales of Vastor - Progress #8 Content What's done? Music What's next What's done? Cover image Refactored backgrounds This week, I refactored a few backgrounds to match the color scheme and the overall style. Here are a few of them. As you can see, I created a border and a fixed image resolution of 1600 x 800 for the progress updates to provide some sort of consistency. It looks pretty neat as well. The images in the game will be displayed without a border and the actual resolution.   Refactored black knight model I wasn't happy with the current model of the black knight, as it looked way to messy. So I blended the light a little bit on his armor and added small highlights. Defeated black knight As you progress in the story, you will meet this pal right here. Want to know what he does? Subscribe to the beta version by sending me an email and play it, as soon as it is released. Music I am happy to announce, that Andrew LiVecchi is working on the music. He definitely is a musical genius and worth a visit. Be sure to take a look at his YouTube channel: Youtube.com What's next? A new enemy is planned this week Some backgrounds still need refactoring A few improvements regarding the usability If you have feedback, you can contact me via mail or direct message whenever you want. Be sure to take a look at Twitter as well, since there will be more frequent updates. Thank you!  

LukasIrzl

LukasIrzl

 

This Week in Game-Guru - 10/01/2018

I notice (@LeeBamber) that I'm still not showing on the news section.  Not that it's any skin off my back.  I do this for fun, but I wouldn't mind a followup so I'm not twisting in the wind (nudge nudge).



Official Game-Guru News:


This week we got a PBR update to some assets in the Sci-Fi pack and also a new 'ally' AI delivered via a drone.  I'll be interested to dig into that one to see what's different as the current AI is a bit of a slush pile that can be difficult to interpret.

You can find the official news release here: https://www.thegamecreators.com/post/gameguru-scifi-pack-dlc-update-released-2

On the note of AI, it appears that's Lee's primary focus right now and so far I hear the results are promising.  Those results can be found in detail here but essentially there's a demo level out there with a lot of cover objects.  The AI *SEEMS* to be productive and functional, but time will tell.  That said if the vast majority of users are claiming it's improved then I think that's a fair litmus.  I watched the demo video and I noticed a few good changes, notably that it won't shoot through walls and will path far better than it used to.

What I'd like to see:
A system for enemy accuracy; right now they still hit 99% of the time and that's just absurd. Better synching of the movement to animation, which often times is a configuration setting but should be the default.   A system for enemies running away when injured/hiding/etc. A module in the AI itself that allows us to 'hook in' as modders, as it is it's more of a black box with a few function calls outside of it. Forum AI link:  https://forum.game-guru.com/thread/220075 (AI)
Now for those of you who are using the EAI Weapon Pack, which is phenomenal mind you, you may have noticed some errors or bugs with assigning said weapons to enemies or NPCs.  This apparently is going to be resolved in a future release after verification by EAI himself. 
Forum link for EAI Info:  https://forum.game-guru.com/thread/219912

What's good in the store:
You know I was going to say there was nothing going on and just move on, but this week has been a big drop of lots of really great assets.  Of course as the quality goes up you may notice the price increasing but some of these are ... top shelf stuff.  I don't know any other way to put it.  Stuff you'd see in a AAA game.

Let's go over a few.
First of all, Gtox is really into fish... Well, that's true but apparently he's also into porpoises as well.



If you're making a sea-world game, this is probably right up your alley.

What's really intriguing to me is that Teabone, Robert Fitzy and Gamepoly (A new challenger appears!) all created fantastic high quality models this week.  I mean just look at this:



I really like GamePoly's work, this is a new level of quality that is desperately needed in Game-Guru's overly-asset flipped environment.  You can also see some new models by Mad Lobster and Pasquill at the bottom (the exacavator). 

Not bad for a single week!  Make sure you swing by http://en.tgcstore.net and check out the latest for yourself!




Third Party Applications and Tutorials
This week I was poking around on a project I can't discuss at this moment (wait till next week!) but I did end up at this wonderful tool - https://tangrams.github.io/heightmapper/
This is a free heightmapper that I found worked a bit better than the one for terrain.party.  Definitely give it a look, the values on it are fantastic for use with the game-guru 'Heightmap to MDAT' tool.

Also in the forums, Wolf showed an older tool that I wish I'd have had in the past for my own imports - an import scaler tool to help adjust the scale on your FPE files: https://forum.game-guru.com/thread/218348

And lastly there was a pretty nice video posted by Bugsy in the discord chat discussing how Mirror's Edge used lighting:  https://www.youtube.com/watch?v=B0sM7ZU0Nwo


Free Stuff Nothing free that I could find this week.  Sorry guys!

Random Acts of Creativity So in the WIP section we have some things from VincentHendriks who continues his use of the stock assets in the only way they could ever potentially be used - as a desert combat game.  It's looking ... well, like a reasonably good desert combat game!

Reminds me of the photos my buddies would send me from Iraq.
It's coming along well, I'd say.


There's also a new asset flip for us to look at on Steam.  Now I will say while the game itself was a fairly bland and boring flip, the demo video for it was interesting - the guy took live video with some basic video modding to provide a little more oomph to a Game-Guru game than I'm used to.  That said, it's not worth the price asked for and apparently is a buggy mess.
See it here:
https://store.steampowered.com/app/798710/Voltage/

Also another new user showed up, this time with an odd cyber-punk style game where I guess you're on a rooftop?  He took some of the advice I offered him but it needs a lot more polish.  Regardless though it's getting there and at least it doesn't look like the same old same old.  I can respect the effort.

In My Own Works This week I've been working on a special project, which but it's allowed me to focus on getting another segment for the book done - specifically a 'how to do a forest in Game-Guru'.  This is a difficult topic that I think most will benefit from a little personal understanding on.

That said though I'm still behind the curve here.  I need to bang out like 20,000 words this month to stay on track and that's no easy feat.

I also aggregated all the new Lua commands since 5/12/2017 for you here:
http://gamegurureport.blogspot.com/2018/09/new-lua-commands-since-5122017.html

See you next week!












View the full article

Unity Weekly Update #14 - High Stakes

Last week was another modelling one, although there were some coding to be made in the last 2 days. Basically, I've continued the implementation of the pawnshop. Also, I had time to add a new room. The Pawnshop Although already functional, the pawnshop still needed some details props here and there. Here's a bunch of pictures showing the (almost) final version: As of now, the pawnshop's stock mainly consist of either prop from previously added rooms or even models of previous blender scene that went nowhere (take it as recycling I guess) I also want to point out that the cash register is modelled after classical mechanical cash registers like these ones:   There are also various guitars hanged on the back wall... Here's the actual reference I've used for the whole room: There's still the lighting to take care of... Also, keep in mind that I want to add more props from other rooms in the shop. So I still need to keep on moving along and get back to it when new props were added in the game. The Casino There's also a whole new room: the casino. This room acts like a giant slot machine for stats. Like traditional slots machines, the player simply pulls its lever to stop the currently active slot. There are 3 slots: one that states which stats the bonus applies, another one stating whenever it's actually positive or negative and finally the actual bonus amount. I won't lie: I kinda wanted to mimic Mario Party's mythical Chance Time. For those who aren't familiar, Chance Time was an event in the Mario Party games in which two players are forced to give/exchange specific items between each other. The player involved and the actual items are given by a slot machine-ish process. Here's a compilation of Chance Time events: As for the casino, I'm not quite sure whenever the player needs to buy in before the slots start spinning. What I'm sure of is that this process is only once per casino and that the bonus/malus is permanent. Also, the room is not fully decorated nor is lighted, but as of right now the main goal is to debug the actual slot mechanic. Next week Like before, next week is going to be room-centric again. There are also bugs with those slots that need to be fixed. They don't always line up correctly and sometimes even decides to give the player a completely different outcome.  Once most rooms are either fully or partially implemented, then maybe the next step would be to either fix animations or complete AIs. Afterwards, we still need capacities and relics... Some code refactoring wouldn't hurt either.

jb-dev

jb-dev

How to look hot at 30? A Sprint 30 reports!

Today starts our new sprint 30. During the last sprint, we did get much work done. 😊 We can’t publish that much pics these days, since we don’t want to spoil the new video scenes. But, I tell you something. 😄

We finished modeling all objects for the kitchen, also for Clearwaters home-office and main hall. We offer you a lil’ glimpse 😉:   We need more special textures for some of these objects. It’s a work item for the current sprint. We designed furniture and had fun. We finished texturing some houses from Clearwaters world-outside. We’ve to continue, anyway. We finished modeling all animations relevant for the new video as listed in the script from the last sprint. We made a first-scene animation where he realizes something is weird. We modeled a look-out-of-the-window animation, a looking-around animation, a sneak-animation, and so on. We also modeled several facial animations for the above-mentioned body animations. Some new faces can look left, right, up and down, etc. Clearwater is therefore able to move his eyes and to blink. But we still need to test ALL of these newly created animations in the current sprint. Now, we can throw all necessary-for-the-new-video ingredients in a big bowl. It’s our mission henceforth to make a tasteful soup out of it. How euphemistic! We want to start creating some video sequences, i.e. positioning the cameras in Clearwaters apartment, set light, test all animations, fix all Bugs and issues, adapt Clearwaters appearance, and make everything looking good. After having eaten all Bugs, the video is ready for YouTube. Furthermore, we modeled a hot animation for Clearwaters full body 4K Pic. It’s supposed to be a promotional pic that will appear on social media and on our new game blog as appetizer. 😉 During the current sprint, we want to test and render the pic of him, just minutes before we publish it.  This week, I swear, I’ll continue writing the book BIZARRE Episode I! Charly Men’s website charly-men.com gets a new design, too. Our software developer started writing code. I get my own new Content Management System called BeeMS. Don’t ask me why it is so called. 😛 The new game blog for BIZARRE is included in the chaly-men.com website as it is now. The Charly Men website get’s expanded and will later include the Charly Men’s BIZARRE game blog, all Charly Men’s books, paintings, lyrics and songs. It gets published hopefully before the sun used up all its helium. I sum all up: We want to texture houses and objects in the apartment. We want to create some video sequences to test all animations and textures. We want to fix all issues and Bugs seen during the video sequence tests. We want to continue writing the book BIZARRE Episode I. We want to render a nice 4K Pic of Clearwater and publish it. We want to continue programming the new Charly Men website as well as the new game blog.   I have a great appetite for soup now!  

GameDev2017

GameDev2017

User engagement metrics: what is retention rate?

As an app developer, your final goal is to make your app profitable and visible in the app store. You may be pouring a lot of resources into ASO, which can produce good results. However, your rank-building efforts will not be complete without retention rate improvement. Retention rate is one of the most important user engagement metrics, which makes an app sticky and illustrates the way users interact and engage with your application. It also has an impact on ranking in App Store and Google Play — the algorithms favor apps that are able to engage users. To improve app performance and make sure users return to your application time after time, you need to optimize retention rate.   What is retention rate? In general terms, the retention rate is the number of users that return to complete a designated action in a certain period of time. This definition is vague, but that is because marketers assign different meanings to the notion of retention rate, depending on the type of the app, business model, user base or industry. For mobile applications, retention rate most often denotes users interacting with the app after the install. The formula for calculating retention rate is the following:   Retention rate = # of users who completed the action on day x after day 0 / total # of users who installed the app on day 0 This is the most basic calculation pertinent to the mobile application. Note that the formula is valid for the users from the same cohort, that is who installed the app on the same day. User segmentation and grouping per the day of install, sign up or first interaction with the app is the baseline for determining app retention rate. Overall, RR helps to measure the efficiency of the app per user and over time; gives important insights about the app performance and helps locate the points, where users drop out. With this information, app developers can optimize both the user experience and their monetization strategy. How to find out what is good retention rate? As mentioned above, RR differs per industry and app type. Therefore, there is no threshold for an optimal retention rate. Obviously, the higher the percentage of users that return to the application and perform target actions, the better it is for app monetization. However, the return of 100 percent of users is an unattainable result. Arguably, it’s better to compare RR with the previous results demonstrated by the app, rather than with other apps in the same category. The data has too many variables, such as the platform type of the app. Thus, the metrics without the context might be obsolete. Improving RR for the application   Considering the fact that 21 percent of users abandon the app just after using it once, the focus on retention rate is essential. Higher RR improves the lifetime value (LTV) of the users and decreases the overall cost of customer acquisition. The first two steps to ensuring good RR for the app is to think about the value that application for the users and the quality of the user experience. When it’s clear what users are getting from the app and the churn due to bugs and crushes is eliminated, it’s time for additional strategies to increase the retention rate. Personalization and individualization of mobile experience Users crave the experience that would be individually tailored to their needs. This might include using the user’s first name in in-app communications, saving the data for more convenient sign-in and in-app purchases, keeping track of the user preferences and interests and offering relevant products and services. Personalization can drive up the conversion rate by almost 40 percent, if the individual behavior is taken into account. Onboarding strategy Introducing new users to the app features and functions is what helps to get them through the initial stages. Additionally, it will decrease the churn rate of first-time users due to confusion with new app experience. A simple, yet effective guide through the app should point out information fields and the main actions in the app. When done right, onboarding can increase LTV by 500 percent and RR by 50 percent.   Push notifications Notifications that appear on the home screen of mobile phone are great for reminding users to return to your application. The smart use of push notifications can increase retention rate by up to 180 percent and significantly improve engagement. For the apps in the Ecommerce, Music, Travel and Food & Drink categories, engagement is getting more than a 100 percent increase after the implementation of push notifications, according to Localytics. Remarketing For the users that opted out the push notifications, there is another tactic in line. Try to remind them about your app via remarketing, locating and targeting users on other channels, such as email or social media. Usually, users need to provide those in order to sign up. The strategy is reported to be successful, when marketers take into account users’ personal preferences. In conclusion Optimizing an app for increasing retention rate is well worth the effort. It decreases the overall worth of acquiring a customer and increases the LTV of the user. Mobile marketers and app developers should that keep track of the retention rate, have better chances of locating app crushes in time and optimizing their user engagement strategies on the go. Accordingly, retention rate is a crucial metric and one of the main KPI for any advertising campaign and is equally effective for increasing app visibility in app stores.

Clickky

Clickky

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!