• Advertisement


Featured Entries

  • Game Design Document, Scoping, Prototyping

    By Stefan Hendriks

    In the monthly progress post I figured I needed a Game Design Document (GDD) before working on extra features. It would be a waste of time working on features when I have no clearer picture where the game should evolve to.   The first thing I did was searching for online resources. I have found a bunch, and decided to share those on a page dedicated to Game Development Resources for other game developers.   While working on the GDD I noticed it takes quite a lot of time and it is easy to get lost into details for a long time.   Then, after a week or so, I came into contact with a guy named Richie and he had the tip that I had to scope my game into 5 minutes of gameplay.   So in 5 minutes, the player has to know: what the game is about the basic mechanics if it is fun to play   With that I began to look at the GDD I made so far. I immediately noticed that I had way too much material for 5 minutes of gameplay. Obviously this is because a RTS game has several phases. It would be easy to discard the 5 minute thing, but I wanted to follow it though: what would be the essence, the end goal of the game?   Together with Dorus Verhoeckx, someone I work with together on our own products and dreams, I started stripping all stuff that might be ‘distracting’ from the main objective. This meant base building is minimized (2 buildings left). Resource gathering was cut – just get money from structures. Have only 1 unit type. Etc.   This was done on paper. A lot of stuff stripped and the core objective exposed. Then I started writing down what was left to do to get this into a working prototype: Prototype, with todo’s on the right. Lots of the has been crossed, since I worked on them lately     So what is the essence? Domination in RTS games. Conquer specific structures, hold out long enough to score domination points. Resource gathering? I ditched that in favor of getting money for specific captured structures. (not all captured structures give you ‘domination points’ though). You play 5 rounds of 1 minute. After 5 rounds – the player with the most domination points wins!   Is it a good idea? Is it fun? What about all the other cool stuff I wanted in my RTS game?   Well lets first see to finish the prototype – I want to get it out before the end of the month. I’d love to hear how you guys think about this kind of game. And if you’re interested in testing out the prototype just let me know at stefan[at]indienamic.com. Then, after that I will decide if I miss stuff, want to re-add things and further iterate. My expectation is that there will be quite some iterations / prototypes / refinements before the final ‘game’ mechanics are there.
    View the full article
  • Games Look Bad, Part 1: HDR and Tone Mapping

    By Promit

    This is Part 1 of a series examining techniques used in game graphics and how those techniques fail to deliver a visually appealing end result. See Part 0 for a more thorough explanation of the idea behind it. High dynamic range. First experienced by most consumers in late 2005, with Valve’s Half Life 2: Lost Coast demo. Largely faked at the time due to technical limitations, but it laid the groundwork for something we take for granted in nearly every blockbuster title. The contemporaneous reviews were nothing short of gushing. We’ve been busy making a complete god awful mess of it ever since. Let’s review, very quickly. In the real world, the total contrast ratio between the brightest highlights and darkest shadows during a sunny day is on the order of 1,000,000:1. We would need 20 bits of just luminance to represent those illumination ranges, before even including color in the mix. A typical DSLR can record 12-14 bits (16,000:1 in ideal conditions). A typical screen can show 8 (curved to 600:1 or so). Your eyes… well, it’s complicated. Wikipedia claims 6.5 (100:1) static. Others disagree. Graphics programmers came up with HDR and tone mapping to solve the problem. Both film and digital cameras have this same issue, after all. They have to take enormous contrast ratios at the input, and generate sensible images at the output. So we use HDR to store the giant range for lighting computations, and tone maps to collapse the range to screen. The tone map acts as our virtual “film”, and our virtual camera is loaded with virtual film to make our virtual image. Oh, and we also throw in some eye-related effects that make no sense in cameras and don’t appear in film for good measure. Of course we do. And now, let’s marvel in the ways it goes spectacularly wrong. In order: Battlefield 1, Uncharted: Lost Legacy, Call of Duty: Infinite Warfare, and Horizon Zero Dawn. HZD is a particular offender in the “terrible tone map” category and it’s one I could point to all day long. And so we run head first into the problem that plagues games today and will drive this series throughout: at first glance, these are all very pretty 2017 games and there is nothing obviously wrong with the screenshots. But all of them feel videogamey and none of them would pass for a film or a photograph. Or even a reasonably good offline render. Or a painting. They are instantly recognizable as video games, because only video games try to pass off these trashy contrast curves as aesthetically pleasing. These images look like a kid was playing around in Photoshop and maxed the Contrast slider. Or maybe that kid was just dragging the Curves control around at random. The funny thing is, this actually has happened to movies before. Hahaha. Look at that Smaug. He looks terrible. Not terrifying. This could be an in-game screenshot any day. Is it easy to pick on Peter Jackson’s The Hobbit? Yes, it absolutely is. But I think it serves to highlight that while technical limitations are something we absolutely struggle with in games, there is a fundamental artistic component here that is actually not that easy to get right even for film industry professionals with nearly unlimited budgets. Allow me an aside here into the world of film production. In 2006, the founder of Oakley sunglasses decided the movie world was disingenuous in their claims of what digital cameras could and could not do, and set out to produce a new class of cinema camera with higher resolution, higher dynamic range, higher everything than the industry had and would exceed the technical capabilities of film in every regard. The RED One 4K was born, largely accomplishing its stated goals and being adopted almost immediately by one Peter Jackson. Meanwhile, a cine supply company founded in 1917 called Arri decided they don’t give a damn about resolution, and shipped the 2K Arri Alexa camera in 2010. How did it go? 2015 Oscars: Four of the five nominees in the cinematography category were photographed using the ARRI Alexa. Happy belated 100th birthday, Arri. So what gives? Well, in the days of film there was a lot of energy expended on developing the look of a particular film stock. It’s not just chemistry; color science and artistic qualities played heavily into designing film stocks, and good directors/cinematographers would (and still do) choose particular films to get the right feel for their productions. RED focused on exceeding the technical capabilities of film, leaving the actual color rendering largely in the hands of the studio. But Arri? Arri focused on achieving the distinctive feel and visual appeal of high quality films. They better understood that even in the big budget world of motion pictures, color rendering and luminance curves are extraordinarily difficult to nail. They perfected that piece of the puzzle and it paid off for them. Let’s bring it back to games. The reality is, the tone maps we use in games are janky, partly due to technical limitations. We’re limited to a 1D luminance response where real film produces both hue and saturation shifts. The RGB color space is a bad choice to be doing this in the first place. And because nobody in the game industry has an understanding of film chemistry, we’ve all largely settled on blindly using the same function that somebody somewhere came up with. It was Reinhard in years past, then it was Hable, now it’s ACES RRT. And it’s stop #1 on the train of Why does every game this year look exactly the goddamn same? The craziest part is we’re now at the point of real HDR televisions showing game renders with wider input ranges. Take this NVIDIA article which sees the real problem and walks right past it. The ACES tone map is destructive to chroma. Then they post a Nikon DSLR photo of a TV in HDR mode as a proxy for how much true HDR improves the viewing experience. Which is absolutely true – but then why does the LDR photo of your TV look so much better than the LDR tone map image? There’s another tone map in this chain which nobody thought to examine: Nikon’s. They have decades of expertise in doing this. Lo and behold, their curve makes a mockery of the ACES curve used in the reference render. Wanna know why that is? It’s because the ACES RRT was never designed to be an output curve in the first place. Its primary design goal is to massage differences between cameras and lenses used in set so they match better. You’re not supposed to send it to screen! It’s a preview/baseline curve which is supposed to receive a film LUT and color grading over top of it. “Oh, but real games do use a post process LUT color grade!” Yeah, and we screwed that up too. We don’t have the technical capability to run real film industry LUTs in the correct color spaces, we don’t have good tools to tune ours, they’re stuck doing double duty for both “filmic look” as well as color grading, the person doing it doesn’t have the training background, and it’s extraordinary what an actual trained human can do after the fact to fix these garbage colors. Is he cheating by doing per-shot color tuning that a dynamic scene can’t possibly accomplish? Yes, obviously. But are you really going to tell me that any of these scenes from any of these games look like they are well balanced in color, contrast, and overall feel? Of course while we’re all running left, Nintendo has always had a fascinating habit of running right. I can show any number of their games for this, but Zelda: Breath of the Wild probably exemplifies it best when it comes to HDR.  No HDR. No tone map. The bloom and volumetrics are being done entirely in LDR space. (Or possibly in 10 bit. Not sure.) Because in Nintendo’s eyes, if you can’t control the final outputs of the tone mapped render in the first place, why bother? There’s none of that awful heavy handed contrast. No crushed blacks. No randomly saturated whites in the sunset, and saturation overall stays where it belongs across the luminance range. The game doesn’t do that dynamic exposure adjustment effect that nobody actually likes. Does stylized rendering help? Sure. But you know what? Somebody would paint this. It’s artistic. It’s aesthetically pleasing. It’s balanced in its transition from light to dark tones, and the over-brightness is used tastefully without annihilating half the sky in the process. Now I don’t think that everybody should walk away from HDR entirely. (Probably.) There’s too much other stuff we’ve committed to which requires it. But for god’s sake, we need to fix our tone maps. We need to find curves that are not so aggressively desaturating. We need curves that transition contrast better from crushed blacks to mid-tones to blown highlights. LUTs are garbage in, garbage out and they cannot be used to fix bad tone maps. We also need to switch to industry standard tools for authoring and using LUTs, so that artists have better control over what’s going on and can verify those LUTs outside of the rendering engine. In the meantime, the industry’s heavy hitters are just going to keep releasing this kind of over-contrasty garbage. Before I finish up, I do want to take a moment to highlight some games that I think actually handle HDR very well. First up is Resident Evil 7, which benefits from a heavily stylized look that over-emphasizes contrast by design. That’s far too much contrast for any normal image, but because we’re dealing with a horror game it’s effective in giving the whole thing an unsettling feel that fits the setting wonderfully. The player should be uncomfortable with how the light and shadows collide. This particular scene places the jarring transition right in your face, and it’s powerful. Next, at risk of seeming hypocritical I’m going to say Deus Ex: Mankind Divided (as well as its predecessor). The big caveat with DX is that some scenes work really well. The daytime outdoors scenes do not. The night time or indoor scenes that fully embrace the surrealistic feeling of the world, though, are just fantastic. Somehow the weird mix of harsh blacks and glowing highlights serves to reinforce the differences between the bright and dark spots that the game is playing with thematically throughout. It’s not a coincidence that Blade Runner 2049 has many similarities. Still too much contrast though. Lastly, I’m going to give props to Forza Horizon 3.   Let’s be honest: cars are “easy mode” for HDR. They love it. But there is a specific reason this image works so well. It is low contrast. Nearly all of it lives in the mid-tones, with only a few places wandering into deep shadow (notably the trees) and almost nothing in the bright highlights. But the image is low contrast because cars themselves tend to use a lot of black accents and dark regions which are simply not visible when you crush the blacks as we’ve seen in other games. Thus the toe section of the curve is lifted much more than we normally see. Similarly, overblown highlights mean whiting out the car in the specular reflections, which are big and pretty much always image based lighting for cars. It does no good to lose all of that detail, but the entire scene benefits from the requisite decrease in contrast. The exposure level is also noticeably lower, which actually leaves room for better mid-tone saturation. (This is also a trick used by Canon cameras, whose images you see every single day.) The whole image ends up with a much softer and more pleasant look that doesn’t carry the inherent stress we find in the images I criticized at the top. If we’re looking for an exemplar for how to HDR correctly in a non-stylized context, this is the model to go by. Where does all this leave us? With a bunch of terrible looking games, mostly. There are a few technical changes we need to make right up front, from basic decreases in contrast to simple tweaks to the tone map to improved tools for LUT authoring. But as the Zelda and Forza screenshots demonstrate, and as the Hobbit screenshot warns us, this is not just a technical problem. Bad aesthetic choices are being made in the output stages of the engine that are then forced on the rest of the creative process. Engine devs are telling art directors that their choices in tone maps are one of three and two are legacy options. Is it bad art direction or bad graphics engineering? It’s both, and I suspect both departments are blaming the other for it. The tone map may be at the end of graphics pipeline, but in film production it’s the first choice you make. You can’t make a movie without loading film stock in the camera, and you only get to make that choice once (digital notwithstanding). Don’t treat your tone map as something to tweak around the edges when balancing the final output LUT. Don’t just take someone else’s conveniently packaged function. The tone map’s role exists at the beginning of the visual development process and it should be treated as part of the foundation for how the game will look and feel. Pay attention to the aesthetics and visual quality of the map upfront. In today’s games these qualities are an afterthought, and it shows. UPDATE: User “vinistois” on HackerNews shared a screenshot from GTA 5 and I looked up a few others. It’s very nicely done tone mapping. Good use of mid-tones and contrast throughout with great transitions into both extremes. You won’t quite mistake it for film, I don’t think, but it’s excellent for something that is barely even a current gen product. This is proof that we can do much better from an aesthetic perspective within current technical and stylistic constraints. Heck, this screenshot isn’t even from a PC – it’s the PS4 version.

    View the full article
  • 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.
  • Code Reuse In Actual Practice

    By ApochPiQ

    It’s very common to hear engineers talking about "code reuse" - particularly in a positive light. We love to say that we’ll make our designs "reusable". Most of the time the meaning of this is pretty well understood; someday, we want our code to be able to be applied to some different use case and still work without extensive changes. But in practice, code reuse tends to fall flat. A common bit of wisdom is that you shouldn’t even try to make code reusable until you have three different use cases that would benefit from it. This is actually very good advice, and I’ve found it helps a lot to step back from the obsession with reusability for a moment and just let oneself write some "one-off" code that actually works. This hints at the possibility of a few flaws in the engineering mindset that reuse is a noble goal. Why Not Reuse? Arguing for reuse is easy: if you only have to write and debug the code once, but can benefit from it multiple times, it’s clearly better than writing very similar code five or six times…​ right? Yes and no. Premature generalization is a very real thing. Sometimes we can’t even see reuse potential until we’ve written similar systems repeatedly, and then it becomes clear that they could be unified. On the flip side, sometimes we design reusable components that are so generic they don’t actually do what we needed them to do in the first place. This is a central theme of the story of Design Patterns as a cultural phenomenon. Patterns were originally a descriptive thing. You find a common thread in five or six different systems, and you give it a name. Accumulate enough named things, though, and people start wanting to put the cart before the horse. Patterns became prescriptive - if you want to build a Foo, you use the Bar pattern, duh! So clearly there is a balancing act here. Something is wrong with the idea that all code should be reusable, but something is equally wrong with copy/pasting functions and never unifying them. But another, more insidious factor is at play here. Most of the time we don’t actually reuse code, even if it was designed to be reusable. And identifying reasons for this lapse is going to be central to making software development scalable into the future. If we keep rewriting the same few thousand systems we’re never going to do anything fun. Identifying Why We Don’t Reuse Here’s a real world use case. I want to design a system for handling callbacks in a video game engine. But I’ve already got several such systems, built for me by previous development efforts in the company. Most of them are basically the exact same thing with minor tweaks: Define an "event source" Define some mechanism by which objects can tell the event source that they are "interested" in some particular events When the event source says so, go through the container of listeners and give them a callback to tell them that an event happened Easy. Except Guild Wars 2 alone has around half a dozen different mechanisms for accomplishing this basic arrangement. Some are client-side, some are server-side, some relay messages between client and server, but ultimately they all do the exact same job. This is a classic example of looking at existing code and deciding it might be good to refactor it into a simpler form. Except GW2 is a multi-million line-of-code behemoth, and I sure as hell don’t want to wade through that much code to replace a fundamental mechanism. So the question becomes, if we’re going to make a better version, who’s gonna use it? For now the question is academic, but it’s worth thinking about. We’re certainly not going to stop making games any time soon, so eventually we should have a standardized callback library that everyone agrees on. So far so good. But what if I want to open-source the callback system, and let other people use it? If it’s good enough to serve all of ArenaNet’s myriad uses, surely it’d be handy elsewhere! Of course, nobody wants a callback system that’s tied to implementation details of Guild Wars 2, so we need to make the code genuinely reusable. There are plenty of reasons not to use an open-source callback library, especially if you have particular needs that aren’t represented by the library’s design. But the single biggest killer of code reuse is dependencies. Some dependencies are obvious. Foo derives from base class Bar, therefore there is a dependency between Foo and Bar, for just one example. But others are more devilish. Say I published my callback library. Somewhere in there, the library has to maintain a container of "things that care about Event X." How do we implement the container? Code reuse is the name of the game here. The obvious answer (outside of game dev) is to use the C++ Standard Library, such as a std::vector or std::map (or both). In games, though, the standard library is often forbidden. I won’t get into the argument here, but let’s just say that sometimes you don’t get to choose what libraries you rely on. So I have a couple of options. I can release my library with std dependencies, which immediately means it’s useless to half my audience. They have to rewrite a bunch of junk to make my code interoperate with their code and suddenly we’re not reusing anything anymore. The other option is to roll my own container, such as a trivial linked list. But that’s even worse, because everyone has a container library, and adding yet another lousy linked list implementation to the world isn’t reuse either. Policy-Based Programming to the Rescue The notion of policy-based architecture is hardly new, but it is sadly underused in most practical applications. I won’t get into the whole exploration of the idea here, since that’d take a lot of space, and I mostly just want to give readers a taste of what it can do. Here’s the basic idea. Let’s start with a simple container dependency. class ThingWhatDoesCoolStuff { std::vector<int> Stuff; }; This clearly makes our nifty class dependent on std::vector, which is not great for people who don’t have std::vector in their acceptable tools list. Let’s make this a bit better, shall we? template <typename ContainerType> class ThingWhatDoesCoolStuff { ContainerType Stuff; }; // Clients do this ThingWhatDoesCoolStuff<std::vector<int>> Thing; Slightly better, but now clients have to spell a really weird name all the time (which admittedly can be solved to great extent with a typedef and C++11 using declarations). This also breaks when we actually write code: template <typename ContainerType> class ThingWhatDoesCoolStuff { public: void AddStuff (int stuff) { Stuff.push_back(stuff); } private: ContainerType Stuff; }; This works provided that the container we give it has a method called push_back. What if the method in my library is called Add instead? Now we have a compiler error, and I have to rewrite the nifty class to conform to my container’s API instead of the C++ Standard Library API. So much for reuse. You know what they say, you can solve any problem by adding enough layers of indirection! So let’s do that real quick. // This goes in the reusable library template <typename Policy> class ThingWhatDoesCoolStuff { private: // YES I SWEAR THIS IS REAL SYNTAX typedef typename Policy::template ContainerType<int> Container; // Give us a member container of the desired type! Container Stuff; public: void AddStuff (int stuff) { using Adapter = Policy::ContainerAdapter<int>; Adapter::PushBack(&Stuff, stuff); } }; // Users of the library just need to write this once: struct MyPolicy { // This just needs to point to the container we want template <typename T> using ContainerType = std::vector<T>; template <typename T> struct ContainerAdapter { static inline void PushBack (MyPolicy::ContainerType * container, T && element) { // This would change based on the API we use container->push_back(element); } }; }; Let’s pull this apart and see how it works. First, we introduce a template "policy" which lets us decouple our nifty class from all the things it relies on, such as container classes. Any "reusable" code should be decoupled from its dependencies. (This by no means the only way to do so, even in C++, but it’s a nice trick to have in your kit.) The hairy parts of this are really just the syntax for it all. Effectively, our nifty class just says "hey I want to use some container, and an adapter API that I know how to talk to. If you can give me an adapter to your container I’ll happily use it!" Here we use templates to avoid a lot of virtual dispatch overhead. Theoretically I could make a base class like "Container" and inherit from it and blah blah vomit I hate myself for just thinking this. Let’s not explore that notion any further. What’s cool is that I can keep the library code 100% identical between projects that do use the C++ Standard Library, and projects which don’t. So I could publish my callback system exactly once, and nobody would have to edit the code to use it. There is a cost here, and it’s worth thinking about: any time someone reuses my code, they have to write a suitable policy. In practice, this means you write a policy about once for every time you change your entire code base to use a different container API. In other words, pffffft. For things which aren’t as stable as containers, the policy cost may become more significant. This is why you want to reuse in only carefully considered ways, preferably (as mentioned earlier) when you have several use cases that can benefit from that shared abstraction. Concluding Thoughts One last idea to consider is how the performance of this technique measures up. In debug builds, it can be a little ugly, but optimized builds strip away literally any substantial overhead of the templates. So runtime performance is fine, but what about build times themselves? Admittedly this does require a lot of templates going around. But the hope is that you’re reusing simple and composable components, not huge swaths of logic. So it’s easy to go wrong here if you don’t carefully consider what to apply this trick to. Used judiciously, however, it’s actually a bit better of a deal than defining a lot of shared abstract interfaces to decouple your APIs. I’ll go into the specific considerations of the actual callback system later. For now, I hope the peek at policy-based decoupling has been useful. Remember: three examples or you don’t have a valid generalization!
    View the full article
    • 1 comment
  • Dystopian Lights: Dev Blog #1

    By kostile

    So to start the day I am going to share with you guys how I use touch controls and touch "joysticks" in Dystopian Lights (previously Neon Android) to control movement and crosshair aim. Initially I had a floating joystick system where you would tap and hold in a certain area but the response to that system has been heavily negative, so I have redone the code running the joysticks and with refactoring I have made them static as well as extremely reusable. This code is tested in monogame for android and should work for iOS as well if you are using the mono and the monogame framework. What I wasn't aware of when I wrote my first joysticks, is that monogame has a cool feature for touchlocation IDs that allows for greater control without having to worry about which touch is which, we already know if we assign it an ID on touch. You can view the code and use however you want if you decide you like it. If you have ever used monogame and you look at the scaling in the draw method, you will notice that I multiply the scale by 0.001f. This is because the Primitives.circle texture has a radius of 500. There may be some other oddities in the code, if you do use it and have any questions, don't hesitate to ask. The code is at the end of the blog. So this is one of the updates for the game, as well as a proper title. I have been developing the game under a working title "Neon Android" for quite some time but I have always known that this isn't going to fly as the actual title of the game. Dystopian Lights rang a good bell for me when thinking about how I want the game portrayed. For now it sits as a very similar, almost clone of, Geometry Wars. This is intended for art and play style to some degree, but with many varying factors I think the two games will stand far apart from one another once Dystopian Lights is a finished product. One of the other upcoming changes for the game is the change in the GUI. It has been heavily improved on mobile platforms. Previously the GUI was tiny and fit for a computer, but now it looks okay on Android and you can actually navigate the menus when upgrading your weapons. Also I have changed the buttons for weapon selection to be highlighted when selected so you actually know what's firing without having to pay attention to your projectile.   So from here, the plan is to release an update on my website by this Friday, which will include the changes I have showcased here as well as a few other minor changes. Right now the game is only available on Android and is available for download from my website, https://solumgames.com so please head there if you want to check it out. I will have more Dev Blogs in the future and hope to do a minimum of one a week until the end of the year, when I will release it on the Android app market and then see about working for a PC release. The largest problem I have encountered so far while developing this game is the spawning pattern. If anyone has any recommendations for setting up a spawner that gets infinitely more difficult, please feel free to give your input. I have a system right now that works, but its scaling is terrible and it feels like end game within about 5 minutes. There is some obvious tweaking and balancing that I still need to work out as well, so if anyone trys the game and would enjoy something being different, feel free to let me know what I should change. Some of the ideas I have for the future of the game will be to include a story mode. My thoughts keep going around to scripted spawns, and then some animations with full screen-width chat boxes that show an avatar of the character speaking. There will be at least a few boss fights and some over the top story that would make this game seem like a space opera straight out of the cheesiest movie you have ever seen on the Sci-Fi network. I have also been working out this idea where your player has a capacitor that can only sustain so many weapons for so long. If I do add it, the shot weapon will probably always be available, when you use your missile and laser in tandem with something else, depending on your capacitor recharge rate and max capacitor, you will run out of energy which will cause your capacitor to short and then the only weapon available until it fully recharges will be the shot weapon. Health packs are coming as well. They will be random drops from enemies and they will heal different amounts based on the enemy killed.  So far I am happy to see that I have about 40 downloads of the game just from my website alone. I have not received any feedback from any users of the software that I don't know, so please if you are downloading it, speak up with any critique or recommendations. I would love to hear, the good, the bad, and the ugly.   public class Joystick { private Vector2 outerLocation; private Vector2 innerLocation; private Vector2 direction; private Color innerColor = new Color(0.2f, 0.2f, 0.2f, .5f); private Color outerColor = new Color(.5f, .5f, .5f, .5f); private float innerRadiusRatio; private float outerRadius; private int touchId; public Joystick(Vector2 location, int radius) { outerLocation = location; innerLocation = location; outerRadius = radius; innerRadiusRatio = 0.3f; } public Vector2 Direction { get { return direction; } } public void Update(TouchCollection touchCollection) { foreach (TouchLocation tl in touchCollection) { if (tl.State == TouchLocationState.Pressed) { if (AOneMath.Distance(outerLocation.X, tl.Position.X, outerLocation.Y, tl.Position.Y) <= outerRadius) { touchId = tl.Id; } } if (touchId != tl.Id) { continue; } if (tl.State == TouchLocationState.Moved) { float dirX = tl.Position.X - outerLocation.X; float dirY = tl.Position.Y - outerLocation.Y; direction.X = dirX; direction.Y = dirY; direction.Normalize(); float length = AOneMath.Distance(tl.Position.X, outerLocation.X, tl.Position.Y, outerLocation.Y); if (length > outerRadius - outerRadius * 0.5f) { length = outerRadius - outerRadius * 0.5f; } innerLocation.X = outerLocation.X + direction.X * length; innerLocation.Y = outerLocation.Y + direction.Y * length; } if (tl.State == TouchLocationState.Released) { innerLocation = outerLocation; direction.X = 0; direction.Y = 0; } } } public void Draw(SpriteBatch spriteBatch) { spriteBatch.Draw(Primitives.circle, position: Vector2.Subtract(outerLocation, new Vector2(outerRadius / 2, outerRadius / 2)), scale: new Vector2(outerRadius * 0.001f, outerRadius * 0.001f), color: innerColor); spriteBatch.Draw(Primitives.circle, position: Vector2.Subtract(innerLocation, new Vector2(outerRadius * innerRadiusRatio / 2, outerRadius * innerRadiusRatio / 2)), scale: new Vector2(outerRadius * innerRadiusRatio * 0.001f, outerRadius * innerRadiusRatio * 0.001f), color: outerColor); } }  

Our community blogs

  1. HTML5_Badge_512-150x150.pngGood 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.

    Please let us know your thoughts in our HTML5 forum.

    View the full article

  2. 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?

    sherif scared.png

  3. 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!

    View the full article

    • 1
    • 3
    • 64

    Recent Entries

    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










  4. Main characters concept art and rough in-game setup.


  5. 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.

    Let me know what you think about the feature or share your though about current game that use physics such as RB6  ?



    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/

    Press Kit: http://www.towardsthepantheon.com/index.php/press-kit/
    Steam Page link: http://store.steampowered.com/app/709510/Towards_The_Pantheon/
    Website: http://www.towardsthepantheon.com

    Social Media Links:
    Facebook: https://www.facebook.com/TowardsThePantheon
    Twitter: https://twitter.com/PantheonDev
    Tumblr: http://towardsthepantheon.tumblr.com/
    Reddit: https://www.reddit.com/r/TowardsThePantheon/
    Instagram: https://www.instagram.com/towardsthepantheon/
    Twitch: https://www.twitch.tv/connorort
    Google+: https://plus.google.com/u/0/114060823024573957788?hl=en
    Indiedb: http://www.indiedb.com/games/towards-the-pantheon

  7. Oops,today i'm so sad.

    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.



    Hope it won't take too much time.

  8. 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.



    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.


  9. 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 :) 


  10. orb.PNG.7c1f5afedced0d94b25a6fa5bae2f186.PNGmazeline.PNG.bf70d0d20b3505b8e437214ae8aef08e.PNGiceblock.PNG.342d626a2223660b062a624ede0c757c.PNG

    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. :D

    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:


  11. 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".


    I hope my mistakes help you out a bit in your tutorial. Cheers.

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

    • 2
    • 2
    • 111

    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! 


  12. 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:

    Google Play: https://play.google.com/store/apps/details?id=com.nerfgame.lostsocks.LostSocksActivity
    iOS: https://itunes.apple.com/us/app/lost-socks-naughty-brothers/id1074889855?mt=8

    Subscribe on YouTube for more commentaries: https://goo.gl/xKhGjh
    Or join me on Facebook: https://www.facebook.com/mobilegamefan/
    Or Instagram: https://www.instagram.com/nimblethoryt/
    Or Twitter: https://twitter.com/nimblethor

  13. 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
    • 5
    • 128

    Recent Entries



    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.



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

    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. healthbar.gif.1957d4583aba9f1bc021fb34f7fbbe6e.gif

    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.



    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. 



    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. 



  14. 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!

  15. 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!


    See the whole story here


    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!)


  16. 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
    • 4
    • 133

    Recent Entries

    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!

  17. 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. 


    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
    • 0
    • 169

    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. 


  18. 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:


  19. Latest Entry

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

    I added some basic UI:


    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.
    • Add status effects
      • Stun\Sleep (Each turn is skipped for x turns)
      • DoT (Every time a turn starts it does damage for x turns)
      • Stat increase\decrease (increase\decrease stat for x turns (Can't go to 0)
      • Stoned (Speed is 0, no turns get hit so no DoT and no moves)

    Here is the build: Dimins_2018.2.zip

  • Advertisement