Blogs

Featured Entries

• Game Design Document, Scoping, Prototyping

By Stefan Hendriks

• 1330 views

By Promit

• 1344 views
• Node Graphs and the Terrain Editor

By JTippetts

I've been working on the node graph editor for noise functions in the context of the Urho3D-based Terrain Editor I have been working on. It's a thing that I work on every so often, when I'm not working on Goblinson Crusoe or when I don't have a whole lot of other things going on. Lately, it's been mostly UI stuff plus the node graph stuff. The thing is getting pretty useful, although it is still FAR from polished, and a lot of stuff is still just broken. Today, I worked on code to allow me to build and maintain a node graph library. The editor has a tool, as mentioned in the previous entry, to allow me to use a visual node graph system to edit and construct chains/trees/graphs of noise functions. These functions can be pretty complex: I'm working on code to allow me to save these graphs as they are, and also to save them as Library Nodes. Saving a graph as a Library Node works slightly differently than just saving the node chain. Saving it as a Library Node allows you to import the entire thing as a single 'black box' node. In the above graph, I have a fairly complex setup with a cellular function distorted by a couple of billow fractals. In the upper left corner are some constant and seed nodes, explicitly declared. Each node has a number of inputs that can receive a connection. If there is no connection, when the graph is traversed to build the function, those inputs are 'hardwired' to the constant value they are set to. But if you wire up an explicit seed or constant node to an input, then when the graph is saved as a Library Node, those explicit constants/seeds will be converted to the input parameters for a custom node representing the function. For example, the custom node for the above graph looks like this: Any parameter to which a constant node was attached is now tweakable, while the rest of the graph node is an internal structure that the user can not edit. By linking the desired inputs with a constant or seed node, they become the customizable inputs of a new node type. (A note on the difference between Constant and Seed. They are basically the same thing: a number. Any input can receive either a constant or a seed or any chain of constants, seeds, and functions. However, there are special function types such as Seeder and Fractal which can iterate a function graph and modify the value of any seed functions. This is used, for example, to re-seed the various octaves of a fractal with different seeds to use different noise patterns. Seeder lets you re-use a node or node chain with different seeds for each use. Only nodes that are marked as Seed will be altered.) With the node graph library functionality, it will be possible to construct a node graph and save it for later, useful for certain commonly-used patterns that are time-consuming to set up, which pretty much describes any node graph using domain turbulence. With that node chain in hand, it is easy enough to output the function to the heightmap: Then you can quickly apply the erosion filter to it: Follow that up with a quick Cliffify filter to set cliffs: And finish it off with a cavity map filter to place sediment in the cavities: The editor now lets you zoom the camera all the way in with the scroll wheel, then when on the ground you can use WASD to rove around the map seeing what it looks like from the ground. Still lots to do on this, such as, you know, actually saving the node graph to file. but already it's pretty fun to play with.
• 1556 views

By ApochPiQ

• 1 comment
• 7254 views

By kostile

• 1160 views

Our community blogs

• 93
entries
• 6
• 2033
views

Recent Entries

Latest Entry

Good news! Today Corona is pleased to announce that HTML5 builds are in “Open Beta”. That means starting with daily build 2018.3238, you can now have Corona output a folder with the various HTML files and content necessary to run your Corona game or app in a web browser.

Simply upload the entire folder to your web server and access that folder through your HTML5 compatible browser. Due to JavaScript security restrictions, HTML5 builds only work if they are served from a web server.

If you have Python installed you can test locally by starting a web browser on your computer and accessing your HTML5 build folder in your browser. The easiest way to get it served on macOS is to drag your build folder on to Terminal.app then paste python -m SimpleHTTPServer into the terminal window. Then open http://localhost:8000/index.html in you web browser. For Windows, with Python installed, run cmd.exe and then use the cd command to change directories to your build folder and run the same Python command and then open your browser to the above URL. If you need to see the console log, please open http://localhost:8000/index-debug.html instead.

If your app makes calls to web servers, using API’s like network.request(), because of JavaScript cross-domain scripting rules, you can’t directly call REST type APIs. Instead you will need to write a local web script on the same domain that will make your REST API calls and then echo the returned data back to network.request().

We have opened a forum to discuss HTML5 builds. Please discuss your observations in the HTML5 forum.

Because this is still a beta product, we don’t recommend releasing your game the public yet. If you do, you should heavily test your game or app before releasing it. HTML5 build behavior is subject to change as we continue to work to bring it to a release status.

Most all current Corona-made and third-party plugins are not HTML5 compatible at this time. Many of our ad providers do not offer HTML5 SDK’s for us to build plugins against. Other plugins will take time for us to build HTML5 compatible versions where possible. For plugins in our Marketplace built by our community developers, it will be up to them to offer HTML5 plugins where possible or update existing plugins with HTML5 stubs where not possible. A tutorial on creating HTML5 plugins is coming soon.

This is a huge milestone for Corona. It will open the door for you to reach more consumers. It will make it easier to show your work off to early testers, prospective clients and more. Even game jams will rock even more. Our goal is to get this out of beta by the next public release where we will be including some other great features.

• 2
entries
• 0
• 21
views

Recent Entries

Latest Entry

I was surprised to hear that most reviewing websites either charge to review your game or give extremely small chance of actually being reviewed. How have other people found the promotion side of game development?

• 33
entries
• 3
• 530
views

Recent Entries

Latest Entry

Welcome to another weekly wrap-up on all things Game-Guru.  Things continue to shape up post-public preview v2 and we're seeing most of the artists develop a workflow around PBR assets which really add a level of depth and dimension pretty far beyond what Game-Guru has been known to do.

Official Game-Guru News:

Game-Guru now has a donation link for 3rd party development.  It's about time!  Remember, these monies won't go towards Lee & Company.  It will actually go for people who are doing contracted work outside of TheGameCreators to fix up long-standing issues in Game-Guru.  I've already put a few bucks towards it and encourage you to do the same to help reward those who are really getting this project moving again!

In other news, the Easter DLC is also free so grab it while it lasts!
It's also got some new models added so existing owners of it who bought it last year should have that in their inventory as well.

Beyond that, work continues on the pending 'regular' release of Game-Guru.  Bear in mind beyond public preview editions, we have seen NO real updates to Game-Guru since May of last year.  That's quite a long time to wait.  So I think a lot of us are really hoping to see something magical though I think it's fair to expect we'll run into some snags as well.  Hopefully Lee and team are agile after the fact and fix whatever whack-a-mole bugs pop up.

New Products on the Store:

This week we're starting to see the current crop of PBR related assets coming forward as more and more artists get used to working with the new medium.  Some of this stuff looks really great!

 Most, if not all of these are PBR enabled.
I noticed Mad Lobster Workshop's Mad Scientist Lair now has a second 'kit' to it which is an 'essentials/lite' pack.

 I love this brain in a jar, Mad Lobster!

This is a good idea to corral the ever-expanding inventory and help break it out though I still would have made pack 1, 2, 3 instead of his method.  To each their own though.

Graphix's work on a playground set is really turning out nice, about time for us to get an updated one.  I have been using an older one for years and it's about time to update.

Finally there's this way, way, way overpriced toilet from newcomer HomeWreckers Studio.  I mean I get it, everyone needs a good quality toilet for their games.  For the price though he's going to find it a struggle to sell this piece.  Probably.  My recommendation would be to offer it significantly reduced by itself (say \$3.50) or include it much reduced as part of a pack.

Free Stuff:

This week there's not a lot going on.  I will say though Bod has been working on updating his assets for PBR and they look phenomenal.

Though word in the winds is that a fix is coming to PP that will render a lot of his updates unnecessary.

Beyond that we see some new stuff from Graphix (notably a cabinet) and  some free music from the probably very-hard to pronounce "eluukkanen".

Third Party Tools:

This week we got to see a glimpse of something REALLY cool.  A third party tool called "Game Launcher Creator".  This program really allows some impressive things such as live updates, notifications, a WYSIWYG editor, and more.   You can find info on it here: https://forum.game-guru.com/thread/219455 ... lots of potential in this one.

Someone found a new PBR tool: https://forum.game-guru.com/thread/219467

Random Acts of Creativity:

This week Bugsy put up some new screenies of 'Direct Action 2' and it looks great.
He's really getting a handle on GG's lighting and it shows:
 Great use of a dynamic (RED) light with lots of soft blue static lights.
Also it's nice to see 'Len the Man' still working on his cowboy shooter game.

In my own works:

Sort of a lazy week for me.  I have a lot of life stuff going on.  Lately I've been playing Galaxy on Fire 3 on iphone, World of Tanks Blitz (iphone) and also Tera had an event for Male Brawler classes this weekend .. and I've been a founder in that since the dawn of time.  So not much going on.  Pounded out a few thousand words on the book.  Books are a process of constantly grinding out more material.  I did obtain licensure for a few more assets so that's coming along nicely.  I now have some custom models worth noting and am looking forward to revealing them as time goes on!

Eventually the book will come with:
A full set of level-building supplies (buildings, clutter objects)
A custom character (enemy/npc)
Custom Character Creator assets
Custom weapons and more!

I'm still looking for qualified artists.  Let me know if you have an interest in having some of your work included!

• 1
entry
• 3
• 64
views

Latest Entry

King Of Pirates

Development Diary

hello there my name is ROX and i'm a college student and i work on creating this game in my spare time

this is not the first day for me working on this project (Actually it's been almost a year now),but it was today

that i decided to start a diary(mostly to keep myself organised and to keep my mind from flying elsewhere)

and  also too show people what's going on behind the scenes.

I don't have a lot to say about the game as it's still in a very early development stage ( almost a year in

development and still in an early stage 😁😁, Yeah I Know I'm Lazy)

But i've decided to seriously start working on it from now on 😁😁

I Think I've Talked ( Or Wrote ) Too Much For Today , In The Days That Come I Promise I'll Talk More About The Useful Things

Farewell For Now

• 6
entries
• 6
• 509
views

Recent Entries

Latest Entry

Main characters concept art and rough in-game setup.

• 7
entries
• 4
• 570
views

Latest Entry

Breakable object physics

Let's talk about physics in the game. We will introduce breakable glass, door and wall to the game to make things not only more alive but also give you more choice about your path to reach each level goal. A building is locked down ? Maybe you just jump through a window to get in ! A door is lock and you haven't found the key ? Maybe you just blow that thing out of your way ! There's no exit ? Well crank your energy up and destroy that wall ! This is the kind of choice you will be able to do as long as you live with the consequence of making a lot of noise and attracting more attention to you and potentially increasing your awareness level. Remember that your global awareness is what make your next level harder and harder. Physics will allow for more interactive game play and better replay-ability. Let be honest to, when a game require you to keep a certain level of stealth, you will eventually want to go destroy everything and play careless so why not make this fun !

Frag, IEM and Gravity bomb

The player, depending on the active character, will have access to a limited amount of grenade. You get a sneek peak about it in the video below. Frag grenade will allow you to destroy glass, door and wall too. 1 character have access to frag, another one have electromagnetic device that will shut down most electronic device and the last one will have a devastating black-hole type of grenade that will serve as a way to grab item at a remote distance or to simply make things vanish in another dimension ! More to come on those soon !

C# Break in parts

Our script rely on unity internal physic engine, which is quite good. Physics can become very CPU intensive so a lot of testing will be required to ensure smooth gameplay. I don't intend to go to far away into destruction. This is not a procedural "red faction" destruction system ! So destruction will happen, but in a limited amount of location. Destroying everything to get through is NOT an option. That said, i'm happy with the script performance and how it work.

Magnitude of an impact

For of all, the script take into account the magnitude of a hit. If the hit is too weak, the object won't break. Each object have their own breaking point which me require to walk into, run into, shoot at it, trow a grenade or use a special ability.

Parts physics

Once an object is broken, it fracture into multiple parts. The glass in the example video is make of 160 rigidbodies and it still perform well. Each part take into consideration their surrounding. Depending on how many piece stick together, the script determine if the piece can hold in place. The system also check for "framed" part. For a window, the framed parts are the object around the edge that would be hold in place by its frame, for a door it would be the part connected to the hinge. Those part don't fall by them self since they are hold in place by another object. Those part need to be hit again to fall and each sets of broken part need to be connected, within a certain range, to a framed part to be considered structurally stable. Basically that mean that a broken part cannot float in the air if it's not link to enough pieces and that a large glass would break realistically even if you hit limited area because the weight and size of the part would make them fall in real life. Then again, this is not a fracture simulator and we can't go too far into reality. It remain a game, so the main goal is to have fun with the system and to have smooth gameplay. The focus is about the gameplay feature or having more choice, more path and more replayability.

Explosion shock-wave !

Each explosion in the game come with a shock-wave effect. The shock-wave, in my own unscientific terms, is the air getting compressed and the explosion expanding over time. That mean that an object closer to an explosion will get hit faster than an object located further. On top of that, we take into consideration the distance between the explosion and the object to determine the amount of force received by the affected object. Obstruction is also considered, if something explode and there is object between you and the explosion, you will receive less damage.

The shock-wave introduce a very important time factor to the game-play. Making thing explode at a distance and have a split second to get out of the way may be a life saver for you or the AI.

See and be seen

The video showcase a turret being able to see you through glass and it shoot at the player destroying the glass. This behavior will of course be extended to AI but be aware that militarised zone or city will benefit from upgraded unit that may have heat sensor and a turret may just decide to kill you through a wall or a door if you are not cautious enough ! Soldier may also be equiped with those special google.  The game AI have nightvision and heat sensor to track you down. More to come on that in a futur post.

• 2
entries
• 5
• 151
views

Latest Entry

• 35
entries
• 38
• 31665
views

Recent Entries

Latest Entry

After almost two years of grueling full time development the anticipated 2D RPG Towards The Pantheon has a release date of May 16th, 2018. While lead developer Connor O.R.T. Linning had been thinking of dates between April and June for quite some time, the date was solidified during a shower one morning and the Lagwagon song ‘May 16th’ from the legendary Tony Hawk’s Pro Skater 2 soundtrack began playing.

Development of Towards The Pantheon started when lead developer Connor O.R.T. Linning collected a long list of RPG clichés and decided to avoid as many of them as possible while designing his game. Gone are elemental types, elixirs, elves, inns, and generic love stories. Instead players of Towards The Pantheon will ride hamsters, journey through a survival horror inspired mansion, collect dead memories, make new friends, and partake in regular chats around the campfire. Artist Leandro Tokarevski joined soon after to create the pixel art for the entire world using a palette of only 16 colors resulting in a vibrant and distinct world full of charm.

Towards The Pantheon follows the journey of Freyja the warrior, Bam the cat, Mishima the electropunk, and Phenez the ghost as they strive to defeat the source of a malevolent regime The Sworn Light at The Pantheon. To make the gameplay of Towards The Pantheon more unique, elements of adventure and survival horror genres have been implemented. The standard HP/MP system for party members has been altered so that every character has their own stat system. For example Phenez the ghost only has Necropoints which means that he must hurt himself to be able to attack, and Bam the cat has Energy Points which are restored by snoozing or using catnip.

With a world containing over 10 distinct regions to explore, 45 enemies to battle, 80 soundtrack songs to experience, hundreds of items to collect, hundreds of NPCs to interact with, and over 15 hours of gameplay, Towards The Pantheon is the unique type of game for those looking for a new and fresh adventure.

In October 2017 the horror/mystery themed prequel game Towards The Pantheon: Escaping Eternity was released for free and received an 89% positive score on Steam. The game was praised by reviewers and streamers for its original premise and dark atmosphere.

Towards The Pantheons release date of May 16th also brings lead developer Connor O.R.T. Linnings journey full circle. 15 years ago he spent his time at school creating an episodic pixel art story accompanied by trading cards that he distributed among his friends named ‘May 16th’. Now at age 26, he’s bringing that same love and dedication to storytelling and game development to Steam, Itch.io, and Gamejolt. Towards The Pantheon can now be added to your Steam Wishlist! http://store.steampowered.com/app/709510/Towards_The_Pantheon/

• 2
entries
• 0
• 82
views

Recent Entries

Latest Entry

Because our computer classroom was requisitioned because of the "THUSSAT" examination.

And i have to move my projects to our e-book lyceum , and there's no Visual Studios installed.

Perhaps i have to pause my project for one day.

Unfavorable...

Hope it won't take too much time.

• 3
entries
• 10
• 284
views

Recent Entries

Latest Entry

This week I want to give you some technical insight into our project.

I want to start with recapping what happened over the last week: The player movement for the cell stage is implemented and the GUI is wired up, too. There is now a health-bar, DNA-bar and you can see your current compounds as well as your compound balance.

Currently I'm working with or rather exoerimenting with Unreal's UProceduralMeshComponent. My main goal is to create a mesh I can manipulate on runtime. The first thing I want to use it for are the compound clouds. When the player swims into them they should bend around him as if they were being absorbed while simoultaniously decreasing their value until it reaches 0 and the dissovle completly.

Once I'm familiar with how this class works I will use it for the creature editor. So far it's the best thing I know of for creating meshes that can be generated on runtime.

Currently I'm struggeling with writing an algorithm that creates a mesh that roughly outlines the shape for the compound cloud and mostly acts as a trigger and the bounds for the simulated clouds. On that point I discovered somethin you might be interested in this topic:

So far I haven't tried it but it looks exactly like the thing I need for this.

And something special: Version 1 of the Lyfe Main Theme is done. (Lyfe_Main.mp3)

That's it for this week. I want to focus on the cell stage for this devblog as long as I'm working on it. This might result in shorter entries but we want to keep you up to date.

We're also still looking for people to join the team if you're interested.

UPDATE:

I managed to create an actual cube with a procedural mesh

UPDATE 2:

We go some actual random shapes that will later function as the outline for the clouds.

• 4
entries
• 9
• 320
views

Recent Entries

Latest Entry

Good Morning everyone! I had to take a bit of a break from school/weekly goals to attend to some issues but I am back on track this week with another goal I have set for myself! I will say I love writing this in this blog. Its a great way to stay accountable. My goal this week will be to start working on learning C#. As I have mentioned in other/previous posts I am still new to all of this. I will say what I have learned so far has blown me away. I never knew how interesting all this was until I started doing it! Since I am going to be doing a bit of traveling this week it was recommended to me to download an app called Sololearn. Apparently it is a good way to get learn on the go. I'll update on my impressions about this app shortly

-LaurenDenise

• 3
entries
• 2
• 207
views

Recent Entries

Latest Entry

I'm a bit late on Part 3 which is a follow up to Part 2 which showcased the Robot player. I will post links to all the parts at the bottom of this entry.

Sadly I've been very restricted for time, but I've managed to create the three remaining in game graphics required for this challenge. There will be some alterations for Lives, ect... and indication that the monsters (enemies) have been frozen, but it's not a major creation by any means. Also I'll change the plastic color on the Robot as seen on top to other colors to indicate different players.

Above you will see the Orb which you must collect (very little effects here, but in the 2D version I used a soft brush to simulate better light emission), this is a direct replacement of Pac-Dots. Next you will see the graphic used to create the Maze itself (Line), and finally the Ice Block which will be in all four corners of the maze, and will temporally freeze the monsters skin, that causes them to shatter upon contact.

I've converted the Monster, Robot, and all the above into 2D Sprites with some modifications because post processing and environmental effects are not going to be available within the 2D platform. For those that are wondering, the game is being made using SFML with C++, I don't have the time to create this in a full 3D environment, but I'll keep that in mind for future challenges as I'm starting a bit late again.

The second part of this entry is about pathfinding. There are many ways you can find the "shortest path" either by using a "greedy" method, or "full search" method, and all have pros and cons. Pathfinding for this game only needs to be 4 directional as diagonal movement isn't possible, and it's also much more simpler considering each tile or passable 'node' holds the same movement value. In order to successfully complete this Pac-Man challenge requires that the Ghosts or in this case 'Monsters' can chase the player, otherwise there is no challenge. I coded a simple algorithm based on Breadth First Search that doesn't search walls, and exits once the path is made. You'll see a GIF below showing it in action as per my test grid. The first GIF shows a red square which represents the Start Point, and a green square that represents the Target Point. The cyan squares show which blocks have been checked, and the yellow squares are the path based on this algorithm. In the second GIF I add in maze walls, and show how the red square moves along the path to get to the green square, and also updates the path if the green square changes position.

So what is next? With the main graphics done, and the pathfinding system working, the only thing left to do is clean up the 2D Graphics, create all the menus, GUI, mazes, point system, and AI player, then add in sound effects and music. I'll have to double check the requirement list, but I don't think I'm missing anything. I'll add in Local M-Play as an addition to an AI team-mate, but if I'm running short on time I'll meet the requirement with just local.

Stay tuned for Part 4 where I will show a sample of the game in action!

If you've missed any of the earlier parts, check below for the links:

• 35
entries
• 65
• 46427
views

Recent Entries

Latest Entry

Refining the tutorial was probably one of the hardest part of the "later development". Everything was in place, but how to teach the player how to play the game was still a struggle.

The first time somebody tried my game, he was 15 minutes on level 1 and he couldnt even solved it. So this was a major issue. The game evolved from a "this is a full level, here are the controls, good luck", to "this is a much limited level, lets try the first feature first and will see how we go".

The things that helped me:

1. Limiting number of limbs.

On the original first level, you controlled all 4 limbs + head of the character. That was brutal for a first timer. Understanding how physic works on the character is not easy. So I changed that to only 1 limb, and the character starts tied up to a chair. You have to limit the degrees of freedom that you offer the players.

2. Explaining the movie, the poses, and how do they work.

Although the concept of a timeline is easy to understand now that everybody browses youtube, keyframes and poses needed to be explained. I tried explaining the bare minimum because I don't want to overwhelm the player on the first level.

Explaining that a pose is what make the difference in the movie.

3. Slowing down the player

Although it may seem weird, sometimes you have to slow down the player so they dont hurt themselves. At first, just standing on some point in the timeline and moving the character would create a pose. Very fast, very simple. Except that it lead to players creating poses everywhere, anywhere. Not realising where they are standing, and not giving importance to the appropiate time.

I had to slow them down, asking them to create the pose manually.

This simple creation with a button made the player pay attention where the pose was, and at what time was the movement happening.

4. Teaching by doing, not just showing.

This is quite straight forward, but players learn a lot more by doing the actions than just reading about them. In this case I showed an animated example of what the player was suppose to do, and waited for the player to do it themselves.

5. Gameplay before story.

I'm pretty sure some writers may hate me, but I was willing to destroy the story if that meant a smooth gameplay/learning curve. One of my biggest fights with players was gravity. It was not easy to teach someone to move and jump, beacause... well... most people don't realise "how" they walk, they just walk. And when they have to pass that expertise to a dummy character, they struggle becuase in their mind is just automatic. It's like tryin to teach a kid to tie their shoes. You just do it, and you would have to analise step by step just to make it work.

Original first level. Gravity can be a bitch.

In my case, the fact that gravity was such a hussle to overcome, I couldn't add it in the first levels where players were just getting the grip of the game. So I moved my story to space, and then to the moon, were gravity is lower. After several level then the player lands on earth and the gravity challenge appears. Does it make 100% sense as a story now? No. I tried to fit the changes in to the story, but the realism of the story is a little stretched out now. I'm not gonna win any writing prize for it. But I haven't received any of the complaints and struggles I use to see from new players.

After refining the tutorial several times, I haven't received a single complain about no understanding the game. Some people still don't like it, that acceptable, but at least now everyone gets to evaluate the game other than "too confusing".

If you want to know more about the game: Posable Heroes on Steam

• 2
entries
• 2
• 111
views

Recent Entries

Latest Entry

Morning guys!

Today I'll talk about some of the content in my game. Right now, it's still in early development, and I'm the only active artist on it right now. But I'm working on multiple aspects of it at once every day, so we're definitely making progress. Any default art you see from RM (rpg maker) will of course be replaced with my own. I'm designing maps first in RM then replacing the tiles I use afterwards.

This screenshot was taken not too long ago, where you can see that the majority of the tiles are the (hopefully) finalized art. I went with a clean, simple shading for all of it, with usually no more than three shades of the same color. The border for the text box is our own, though the color may change depending on what changes we make to the gui. There's also the character art of Marie of which I did myself, and is the template style for the rest of the art in the game.

Speaking of Marie, here's some emotion character panels!

Here's some of the tiles I've been busy with, replacing defaults with these. I have 100+ items scattered around 4 or 5 sheets, but this ones the most cohesive.

Here's one of our Void monsters, the Caterwaul. It's one of the antagonistic creatures that show up at night and it spews a deadly energy concoction known as Osu.

Here's the World Anvil article for it with full sized digital art.

This is the Frostbite, also with its own full sized art and article.

Here's some more creatures with full art, but no pixel art yet. Each of these has an article on my World Anvil Worldbuilder.

And that'll be it for today- juts wanted to show you guys some of the work I've put into it so far. Once more tiles are finished, I'll record a video of some game footage to show some of the things I've already implemented. For now though, thanks for taking a look!

• 228
entries
• 58
• 30438
views

Recent Entries

Latest Entry

I'm a man on a Mobile Gaming Quest (MGQ) to play a new mobile game every day, documenting my first impressions here and on YouTube. Below is the latest episode. Here's a quick overview of all games I've covered so far.

A visually stunning auto-run side-scrolling platformer (just like Rayman: Jungle Run) with great humor, a high difficulty level, awesome slow-mo explosions, and insane weapons.

There are no annoying forced ads (only incentivized ads to get double gold after each run), and the in-app purchases are never needed.

Honestly, I feel like this has game-of-the-year potential - at least for its genre!

My thoughts on Lost Socks: Naughty Brothers:

Subscribe on YouTube for more commentaries: https://goo.gl/xKhGjh
Or Instagram: https://www.instagram.com/nimblethoryt/

• 26
entries
• 0
• 1927
views

Recent Entries

Latest Entry

The new sprint starts today. We've done a lot during the last 4 weeks!

We deployed the game on our mobile phone and fixed some bugs. Charly Clearwater is looking good in UE4 now! All his textures and maps look fine. All his animations run fluently.

He's now able to walk and run when reaching some defined speed limits. (Blueprint)

He is also able to recognize a stair and to use the right animation when climbing upstairs or downstairs. (C++ and Blueprint).

Clearwater can now pick up objects from the environment and can save them in an inventory. (C++ and Blueprint)

For the new video, the main-character Charly Clearwater must also learn to shoot in all directions when a button is pressed. A topic for the current sprint.

Another thing is the game controller. We want to make it easy for the player to move the character, to open the inventory, for example, we want to make it easy to interact and play (on the mobile phone).

For that reason, we'll integrate a simple game controller, that is to use and to learn as easy as possible. Simple HUD's will stay in the background, won't disturb the player, but will be there when necessary.

The player will get introduced to these elements during the first scene of the game and can use them later whenever he needs them.

The new video is going to happen in his apartment, the first game scene. The place where the player is going to learn more about the character Charly Clearwater himself, more about how to play him, how to handle the game elements and the game controller, etc.

Plus, the apartment is still incomplete, so we need to model a lot of furniture and objects during this sprint to finish both the videos location and the first game scene.

Why the new video? We want to show you what kind of game BIZARRE is. Who main-character Charly Clearwater is. And what kind of quality the game is suppose to have.
Call the video "Get to know BIZARRE". :-)

That's our plan for the next 4 weeks.

• 1
entry
• 5
• 128
views

Latest Entry

Whoa! Our first Development Blog!

This is incredibly exciting for us, and hopefully will be just as exciting for you. Below you will be able to read some information on our up and coming game, 'Crazy Seas'. We have so much planned for this game and we are just in the very beginning stages, so before you read too much into anything, remember that 99% of what you see here is subject to change. A lot of the GIFs of in game footage you'll see here will be placeholder art or very Work-In-Progress. So again, take everything with a grain of salt. We are using a ton of temporary assets while we focus on development so try to look at the bigger picture. Alright with that said, keep on reading to find out more about 'Crazy Seas' and to even hear about some possible ways you can help out!

What is 'Crazy Seas'?

CS is a top down, 2D, pirate MMORPG that takes place in a fantasy pirate world. The game is planned to have a fairly large universe that is filled with player driven content. CS is a game that caters to you. If you want to be a total pacifist and stay away from any sort of combat, you can be a trader and stick to areas where you're unlikely to be sunken. Or, if you're battle hungry and lusting for loot, you can choose to be a fighter and dominate your enemies. Even if you're looking for a little of both, there's something for you in an Explorer like class. You can mix and match various classes of ships to fit to your liking until you're ready to take to the seas. You can earn treasure, gold, and experience  from traveling in the world, and there's so much more than just these basic things. But for now, let's stick to the basics. Stay tuned in DevBlogs to come to find out what else is planned for the game.

Ships

Right now, ships have basic movement finished. You can sail around, make turns, and even bump into other ships. Neat right?

We have two ships currently in game, the basic ship and the Dinghy. The Dinghy, or something similar, will be the starter ship for all players when you first join. It has one weapon slot, but can still pack a punch.

Eventually, there will be lots and lots of different ship types. We want there to be many tiers of progression and lots of different classes of ships. A trading ship should have more storage than a fighter, just as a fighter should have more storage than a trader. The goal is for each ship to have a set slot count, but randomized stats depending on what class its in. Each ship type will also have some different skins you can get to make it look cooler because let's be honest everyone wants a bad ass ship.

Ship Combat

Combat in ships is physics based. This way it requires some level skill to hit other players and doesn't automatically do it for you. This allows for even little ships to have a chance of surviving an encounter with a much larger ship. We have some things planned in the future to buff out weapons with various skills, (Fire cannonballs? Yes please!) but right now we have 3 weapons integrated out of a bunch that we have planned.

The first one is the Basic Cannon...

As you can see, this one isn't anything to fancy. It has medium range and in turn does medium damage. This is the most basic weapon and will probably be the most used. Just like ships, we plan to randomize that stat values of weapons and allow higher level players to use higher level weapons. Weapons will also have a unique skin system allowing them to function the same, but look 1000% more awesome.

We also have a Shotgun Cannon...

Currently, this is my favorite weapon by far. I mean just look at it. Shotguns fire in a cone and sacrifice range for high amounts of damage. Right now, a shot gun eviscerates a Basic Ship at close range. Obviously ships with more health won't be one shot, but smaller ships or ships that are low on health will be eaten alive. Here's a GIF of that.

Ships take damage in our game whenever they're hit, but there is a visual effect to it too. We want people to VISUALLY see the damage of the ship as it loses more health, that way you don't need to rely just on the health bar. When you hit another ship, it becomes combat tagged. Its speed becomes slightly slower and it's health bar becomes visible. This combat tag stops ships from speeding away (you'd have to use an ability to make a speedy exit now) and allows you to see how well they're faring. This also makes combat and aiming easier. Combat Tag will eventually be used to stop people from logging out or quitting the game mid fight as well. Here's a GIF.

And here's a GIF of some of the current cycle of damage ticks. We want to add some more, including some cool fiery effects.

Your health is reflected to you in your health bar, so if you take damage you can see it there.

The Combat Tag prevents us from having annoying health bars floating on all the ships 24/7.

Modular System

Wondering why you haven't seen any sails? Well there's a good reason. They don't exist yet. Ships are going to be modular. What this means is you'll be able to drag and drop different parts on to your ship depending on how many slots it has. A fighter ship probably won't have has many slots for utilities, like sails and a crow's nest, but in turn would have more slots for weapons. Right now we have a basic system for this, but you'll have an inventory full of all your stuff later. (Also take a peak at the Ram, the third weapon that I mentioned earlier. It's in the game but doesn't have a function yet.)

Wind System

We also have a dynamic wind and weather system in our game... or at least we plan to. Right now we have a basic wind system implemented. When you're not moving, you'll slowly, and I mean slowly, drift in the direction the wind is blowing. However, when you're moving, you'll receive a nice boost for following the wind. This allows players who want to utilize the wind to get a nice reward while at the same time not hindering players who need to travel in a different direction. We definitely want to incorporate sails into this system as well so that you'll be able to get an even bigger boost for changing your course to fit the wind. Here's a GIF of the temporary wind meter and demonstrating some basic wind.

The wind can change strength and direction, and does so randomly. The longer it has been since a wind change, the higher chance it has to change. The longer it has been since strong wind, the higher chance for there to be stronger wind. And vice versa. It's actually a fairly adept system. Weather will play a big role into the wind eventually as large storms and/or blizzards will have an effect on it.

Map

Right now, we have a basic Mini-Map as seen here.

It's nothing to special. and we're still deciding exactly how it will work. You will be able to see nearby points of interest and other ships by using your Crow's Nest, and probably will be able to track quests too. We're open to suggestions. We want to have a larger map as well that you can use to navigate across the very large world. The Map will be heavily decided by players, and various player made crews will be able to claim sections of it, but we'll get to that in a future post.

Docking

This is really the last major feature I have to talk about in this blog, but it's in its very early stages as well. In CS you'll be able to dock at ports at various islands to access the towns where you can receive quests, buy and sell, and lots more. We want our game to have a player driven Economy, and without getting to in depth (save that for later  , each island's trade goods will be different. You'll want to go where the best deals are. You'll be able to quick sell by just docking your boat at a port, but we also want you to be able to get out and explore the town or city. We're still designing this system, but here's a sneak peek.

The menu for switching your weapons opens up when you dock, but can be opened on the fly by using the "I" key. The opening of the menu at the dock is just temporary. You are locked into the dock once your there and you need to hit Undock to sail away. Eventually we want to have lots of space on the docks so you can see other players ported there. The islands and docks will be MUCH larger than they are now, this is just placeholder stuff for testing.

Eventually we want you to be able to toss an anchor up on an island that doesn't necessarily have a town or has a dungeon or other places to explore, but that's a heavy work in progress and there's not too much to share. Here's a tiny GIF sneak peek, but it's all placeholder for now.S

I'll have much more to share on land, treasure hunting, land combat, and AI in a future post.

So, What's Next?

Well first off, thanks for reading this far. If we caught your attention and this is something you're interested in, stay tuned for more posts and feel free to comment with questions and suggestions. We really want to be active developers and interact with out future community. If you have a genuinely good idea, don't feel shy. We may like it and it may end up in the game. In the next few update blogs, you'll be hearing about more developments on combat, skills, the map, land movement and interaction, and the economy. We have so much more on our road map than that, but it's going to take hard work and will be awhile before anything makes an appearance. We're open to the idea of a Kickstarter and are aiming to publish the game to an alpha version eventually, so please stay tuned.

I mentioned earlier about helping out and what you could do, and if you're skilled in anything, feel free to shoot us a message. We are looking to expand our team. Below are some specific examples of what we're looking for, but feel free to reach out in other ways. Our twitter is @venatus_games, and you can find updates there as well. Thank you so much for checking out our game, and we hope you stick around to help build a Crazy Open Sea created by the players.

Open Positions:

Artists - We are looking to expand our art team and break away from placeholder art. Here are some concepts/styles we'd like you to be able to draw in or close to. You need to be capable of drawing module pieces for ships, terrain, and buildings. Be prepared to work on some items and other sprites as well. We are flexible. You can contact us by commenting below or adding Jack#2228 on Discord.

Programmers - While we already have a strong development team, we are looking to add one or two more programmers. You need to be efficient and know what you're doing with Unity, and also have some Networking experience. If you're interested in being a part of an epic game, you can contact us by commenting below or adding Jack#2228 on Discord.

• 10
entries
• 11
• 7185
views

Recent Entries

Latest Entry

7DRL 2018 progress on "Demon Slayers" so far:

1. [~90% done] Introduce new graphics, possibly animated ones
2. [done] Introduce two player-controlled characters
3. [done] Dumb-down the ammo mechanic to the same approach that was present in XCOM (the player simply needs to reload a weapon after X shots; there will be no ammo items/drops in the game)
4. [done] Introduce "crates": tiles that are not passable, but ranged attacks are possible through them.
5. [done] Introduce % to hit mechanics. 85% is the base value. 0% if path is obstructed. 50% is the path goes through a "crate" that the target is next to.
6. [done] Remove the mechanics of merging the enemies from low tier into upper tier; alter the enemy spawning mechanics so that enemies of different tier can be spawned
7. [done] pure melee-type and pure ranged-type enemies
8. [done] randomize the level creation

Well, that was quite a long time with no update... but I did manage to create a lot!

I spent a lot of time to implement the cover mechanism. Even though it is working exactly as I wanted it to be, it turned out not to be as entertaining as I thought (well, simply put - XCOM did it better ).Basically if the character is standing next to a crate, it receives a cover bonus:

Red imp has only 50% to hit me!

As you can see I tweaked the graphics and added some animations. Also, there are now two types of enemies - the green one, which simply tries to perform a melee attack, and the red one that will always try to shoot you.

And, last but not least, I've put new winning conditions - the player needs to destroy the crystal that spawns on the other edge of the room, which is now randomly generated.

Crystal - destroy it, and you will win.

I am basically done with adding the gameplay mechanics. I mean I still have a lot of ideas that could be used here, but there is simply no time. I will try to add/improve the graphics, test the game and balance it if necessary, and that's basically it. I plan on submitting it to the jam on Sunday.

And here's another gameplay gif:

Take care!

• 10
entries
• 27
• 17843
views

Latest Entry

Welcome Agent Green...

And here we go, Red Cell: Agent Green is finally released on Itch.io!

Don't believe me?

Now you should!

It was quite the journey from simple gamejam entry for the Week of Awesome III to here, but I'm glad I stuck with it.

The game is now coop, has leaderboards (thanks Gamesparks!) and is a lot harder to deal with.

Hoping to add new modes in the future too!

I won't take more of your time, until I actually add more to it.

(If you DO play the game, do drop me a line, I'm always curious to hear what people thing!)

• 5
entries
• 9
• 571
views

Recent Entries

Latest Entry

Greetings!

The fifth devlog is a video demonstration of my experiment with post processing filters. I found the following result interesting, it can be an option in the main menu - the player can choose how his gameplay process will look. It looks completely different from the standard pixelated mode.

Here is the video:

• 1
entry
• 4
• 133
views

Recent Entries

Latest Entry

Hello all!

I'm here to introduce a game I've been working part time on for some time now. The game is tentatively titled "Death Race" although it's not the most creative name I know. My goal was to make a very paced, futuristic, gravity defying racer VERY similar to F-Zero and F-Zero GX. In this blog I'll post occasional progress and even some tips on implementation for those who like linear algebra.

So far I've managed to get the gravity and physics working very much like they do in the originals. Rather than staring off by boring you with the list of features and details, here is a demo of my latest track which has all of the latest features which should speak for itself (some of my older videos, are from before some key features were added).

I've loosely modeled this track after Big Blue in F-Zero GX. I've also been making all of the assets for this track in blender myself which I'm not the best at, but I don't think they look half bad for what I need so far.

You'll notice the health bar in the upper left corner which decreases any time I use boost power, hit a wall or get attacked by another player (demo here. The player's ship lunges at the AI if close enough). I neglected to place a healing area in this track however, but the mechanics of the healing areas in other tracks are almost identical to F-Zero and can be seen here. When the health reaches 0 the player dies in a big loud explosion.

Some of the other features worth pointing out are that walls prevent the racer from falling off (although falling off and returning to the track is possible in other tracks), the yellow boost circles that propel the player forward, and the dynamic enemy AI that works miraculously. There are even tracks that demonstrate racing off the edge and landing on another part of the track (although the driving looks bumpy on this demo track. It has improved since).

Below is a demo of a complete 3 track circuit. This video is almost a year old however so some of the bells and whistles aren't there yet. I actually have a hard time with beating the AI in the second track!

The general flow of the gameplay is pretty much like it is in any racing game. Circuits have many tracks which have many laps. You complete the tracks consecutively and whoever finishes the best overall is the winner of the circuit. However the game doesn't yet do anything like save records or give you a satisfying congratulations screen. As you'll also see in the video below, my racers don't exactly have very creative names either, and my menus are sill pretty bland and boring. These are all things I'm working on, but the core functionality of the game is there, and I'm willing to take creative advice/criticism from anyone who has suggestions!

• 2
entries
• 4
• 1446
views

Latest Entry

Introduction

The impetus for this research topic is concerned with a data structure that efficiently stores and queries scatter point data. These points may originally be neatly arranged on a grid, or randomly scattered across the surface of a sphere (e.g. the earth), but it makes no assumption in that regard. The data structure could have member functions such as add(point) or add(points, amount). The points themselves contain three scalar values: the longitude, the latitude, and the data value itself. This data value could be geographical data such as land height or weather data such as air temperature, but again, the data structure is agnostic about the data itself other than as a scalar value.

Data Structure

The purpose of the data structure is ultimately to efficiently and accurately query for point(s) that is(are) nearby another point, the reason being to compute the average value at that point. Suppose a requirement is to create an image representing the air temperature (or rainfall, cloud cover, whatever the scalar value of each point represents) - this data structure could be queried for each point (i.e. pixel) in the image. Once nearby points are queried, the algorithm to average the scalar values of each point is outside the scope of this, but a good candidate is the inverse distance weighed algorithm.

Within the data structure, the data points will not be stored in spherical coordinates, but as n-vectors. The reason for this is that the sampling algorithm - finding N closest data points - is more efficient and accurate using vector algebra. While it is outside the scope of this, to summarize: it is easier to determine how close two points are on a sphere if these points are represented by unit vectors than by latitude and longitude. For example, two points sharing the same longitude are farther apart at the equator than above or below the equator. Even if we are just concerned with relative distances, and do not need to compute the square root of the distance formula, for this reason it is still not as accurate. Also the international date line, where longitude "resets", presents a problem that would have to be dealt with. Also either pole. But you get the idea - vectors are more stable, accurate, and efficient.

I've always been a fan of Binary Space Partitions - each branch node of a BSP has two areas, one below and one above (or one left and one right, or one in and one out, however you like to think of it). To go along with storing points as vectors, branch nodes within the structure partitions their space also using a vector, which in this case forms the normal of a plane that bisects the unit sphere. All data points in a node (or children of the node) will either be above or below this plane (points that are on the plane can be allocated to either side as is appropriate). Points that are below the plane are placed in the first child of the node, and points that are above placed in the second child. We call this plane normal the split axis of the node.

Querying the structure for the closest N points then becomes trivial. For any branch node, compute the dot product of the point in question and the split axis of the node. If it is negative (the point is below the split plane), recursively query with the first child node, and if positive (the point is above the split plane), with the second child node. For a leaf node, compute the dot product of the point in question with each data point contained in the node, keeping a sorted list of the closest N points. The one caveat is that in branch nodes, after recursing into one child node, it may be necessary to recurse into the other child if the farthest point found so far is farther than the other child node, since there may be closer points in the other child node. But this is trivial as we are comparing dot products. No expensive computations are necessary to compute the N closest points - just a bunch of dot products. As dot products of unit vectors range from -1 to 1 (-1 being farthest apart and 1 being equal), two points are closer if their dot product is higher.

Once complete, and the list of N points found, the actual distances can be calculated if necessary, which in this case is done by calculating the angles using the already-calculated dot products. This angle can then be multiplied by the radius of the earth to get an exact distance, again only if necessary. But for averaging, these extra calculations are not necessary.

As a final note, the data structure lends itself well to graphics hardware. In my particular case, rendering an image using such a data structure on the CPU may take several minutes, but on the GPU takes a fraction of a second.

Problem

The problem - common to any space partitioning tree - is how to initially create the data structure. Again, the points are not assumed to be arranged in any specific way, and as far as we are concerned, are a "point soup". They can be specified one at a time - addPoint(point) - or all at once - addPoints(points) - or both. Specifically, how can the determination of the split axis of any branch be efficient and provide an even split (the same or similar number of points on either side). The problem is unique here because the points are not arranged on a two-dimensional surface or in three-dimensional space, but lie on a unit sphere.

My current solution to the problem is not terribly elegant. For each two data points, compute the axis that splits them evenly. This is done by computing the point between the two (subtract one from the other) and normalizing it, then crossing this with the cross product of the two points. This cross product comprises the normal of the plane that evenly splits the two points. This normal is then tested against each other point in the node to get 1) the number of points on either side of the plane and 2) the distances of the points to the plane. A good split plane is one that 1) splits points evenly, 2) has the same/similar distances on other side, and 3) has large distances on other side. As this test is performed for each two data points, some big-O notation shows that determination of the split plane for nodes containing a large number of points will become prohibitive.  However, I have not been able to determine a better solution.

But the advantages of such a data structure still outweigh this expense. In my particular case, the time spent initially creating the tree is worth the time saved during queries. I should mention that if the data points are known ahead of time, it is faster to specify them all at once, so the tree can re-build itself once, rather than one at a time which may cause the tree to re-build itself multiple times.

• 1
entry
• 0
• 169
views

Recent Entries

Latest Entry

The game in question will be a platformer and I hope due to its simplistic nature it'll reflect very well anything I learn. Starting with the Unity engine since that seems to be the go to for platformers, and I take all credit for my creation other than the art. The name at the moment is Bun's Cottage but that is of course subject to change. Right now I'm going through the process of animation and creating the player character, tying animations together and finding the smoothest way to implement animations.

• 8
entries
• 2
• 1136
views

Recent Entries

Latest Entry

The Balcony is going to be available on Steam on the 26th day this month!

Here is a gameplay video of the zombies survival mode:

• 22
entries
• 11
• 25281
views

Recent Entries

Latest Entry

This is a pretty small update focusing on UI and abilities.

It's all working off of a fairly simple UI system, all transitions are handled by transition components and all view controllers handle specific aspects. Essentially all of the view containers here (The inventory and potraits) are a small amount of C# code:

public class UIPortraitContainerView : UIBaseContainerView<UIPortraitView, MinionData>
{
}

This base class handles displaying a collection of model data (In this case MinionData) inside a list of UIPortraitView components. It also handles dragging items around to re-order and pooling the views. Then the views themselves (UIPortraitView) handles any specifics (I.e clicking on the portrait shows\hides the stats of that minion) and initialising\updating from the model.

I also went ahead and fixed a lot of abilities, here is Scratch and Spark.

and here is Ember and Rock Throw

My next step is to improve combat in the following ways:

• Change to a timer based, action point turn based combat system
• The basic idea is minions will have speed
• They will also have a pool of abilities (Starting with 4 at level 1-5)
• Each turn will happen based on each minions speed and any initiatives
• Each turn a minions action points will be replenished
• Each ability will cost a certain number of action points
• Optionally: You get a random draw of 3 abilities every turn.