Blogs

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
    • 0 comments
    • 1051 views
  • 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
    • 0 comments
    • 955 views
  • Node Graphs and the Terrain Editor

    By JTippetts

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

Our community blogs

    • 2
      entries
    • 0
      comments
    • 73
      views

    Recent Entries

    Meteor Bombardment Series Devblog 01

    • Genre: Fixed Shooter
    • Engine: Unity
    • Platform: TBD
    • Art Style: Pixel Graphics
    • Games Planed: 3
    • Meteor Bombardment: Technical Design Phase - 20% Complete
    • Meteor Bombardment 2: Technical Design Phase - 80% Complete
    • Meteor Bombardment 3: Conceptual Phase - 50% Complete

    The Meteor Bombardment Series is a project intended to represent the technical aspects and art style of games spanning over multiple past game eras. Starting with Bombardment, done in an 8 bit style and limited mechanics. Then moving onto Bombardment 2 using a 16 bit style and with added mechanics. Ultimately ending with Bombardment 3 using a 64 bit style with even more mechanics added.

    Design for the series has begun, and initially started with what is now Bombardment 2, saving more complex ideas for that game's sequel. After consideration it was decided that even the core concept could be scaled down to its base elements, with the more complex mechanics added to a sequel. Thus ultimately creating a trilogy.

    The development blogs titled "Meteor Bombardment Series" will follow the series development as a whole, with development blogs started for each specific game.

    The long term goal for the series is to create an arcade game pack including this series among other developed games. In the short term each game will be released as a standalone game. For information regarding each game, check out the developers blog relating to the different games in the series. The first game specific developer blog is scheduled to post tomorrow!

  1. Corona’s engineers have slipped a couple of really cool features into recent daily builds that may have not caught your attention.

    Emitter Particles and Groups

    Previously, the particles emitted from an emitter became part of the stage until they expired. This would create problems with the relative positioning of the particles if your app needed to move the emitter. If you moved the emitter as part of a parent group, it didn’t create a natural look. Emitters can now have their particles be part of the parent group the emitter is in. This was added to daily build 2018.3199.

    emitter.gifTo use this feature, you can set emitter.absolutePosition to the parent group of the emitter. Previously you had the options of true or false to determine if the positioning was absolute or relative to the emitter. By passing a group, it’s now relative to the group. You can download a sample project to see the feature in action.

    Controlling iOS system gestures

    On iOS when you swipe down from the top, it shows the Notifications panel. When you swipe up, you get the control panel. If you have UI elements in your game that are near the top of bottom in areas that are likely to result in swipe gestures, it would be nice to be able to control that. Now you can! Starting with daily build 2018.3193, you can use native.setProperty( “preferredScreenEdgesDeferringSystemGestures”, true ) to have those swipes just show a swipe arrow and a second swipe to activate the panels.

    We have more great things in the pipeline so watch this space for news and updates.


    View the full article

  2. I'm a man on a Mobile Gaming Quest (MGQ) to play a new mobile game every day, and document my first impressions here and on YouTube. Below is the latest episode.

    A decently difficult 20-level action platformer set in a steampunk universe with a nice story, plenty of weapons and equipment to acquire, and a simple $5 IAP to unlock all equipment immediately.

    Sounds great, and it is, BUT the game shows 15-seconds FORCED video ads every so often without any option to disable these through an IAP. 

    For that reason, I'm not giving this game a glowing recommendation at this point, although I actually had fun playing it.  

    My thoughts on Into Mirror:


    Google Play: https://play.google.com/store/apps/details?id=com.lemonjam.intomirror
    iOS: https://itunes.apple.com/us/app/into-mirror/id1072600030?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

  3.  

    Mobile games still represent the highest growing niche among apps. The mobile game market worldwide is supposed to touch $46 billion in the present year. In spite of this staggering growth, just 10% of the game apps can actually be called commercially successful as per the growth and ROI they achieved. Naturally, rethinking the strategy and planning for something effective to market mobile games will continue. Based on the experience of the near past, what are the key marketing tips for mobile games we can consider in 2018? Let us have a look.

    5a2b8e97bcf6b_8WaysYouCanRetainYourGamePlayerforLonger-Nimblechapps.thumb.jpg.af5d3f68ecb1632c34f9da7a2710d244.jpg

    1) Localization will be key

    To make your game connect its audience in different parts of the world your game needs to speak the language of your audience in different local markets. There are many markets that are far from dominated by any single language, and often these markets offer the bigger untapped potential for new game apps. While localising the game language is crucial, there are other considerations as well.

    Localisation should also be offered through a selection of payment methods. The selection of payment methods should be made available as per the penetration of such methods in respective markets. For instance, markets having lower credit card penetration should be given other methods of payment for the game players. In some markets, third-party payment solution or third party publishing rights may be good solutions while in others they may not.

    2) Consider the latest In-app purchase (IAPs) trends

    Throughout 2017 In-app purchase has dominated the mobile app marketing space, and it has been the most effective and revenue earning strategy. In-app purchases have earned $37 billion in app revenue in 2017 alone. In spite of the fact that just 5% of game players actually end up spending money through IAPs, this monetisation avenue is credited for 2000% more profit compared to other avenues.

    In the months to come, In-app purchase (IAP) will be more specific in targeting game players with new tools and tweaks like limited period events, behavioral incentives and dynamic pricing. We can also expect more games to adopt several different types of virtual currency for payment. Specially targeted offers for some game playing audience will also be a key trend.

    3) Consider these social media hacks

    Social media will continue to feature more prominently in the mobile game marketing. There will be a few effective social media hacks and effective strategies that will dominate mobile game marketing in 2018 and beyond.

    When planning marketing for your new game apps on social media, you need to prioritise social platforms based on the type of user your game app will be entitled for. There are plenty of social platforms, but the app that can work on Facebook may not work well on Pinterest. It obviously depends on the audience.

    When it comes to marketing your game on Facebook, you need to build up excitement for the game for several months prior to your launch and based on the reaction of your launch should launch the game app to generate maximum buzz.

    Pinterest can be a great medium if you can register various screenshots and app related images in an appealing manner to the visual database of the platform. Pinterest works great if you have a separate website for the app to draw and engage traffic.

    Reddit, on the other hand, can be a good platform to track information and spot marketing opportunities of your game app. Lastly, make use of social analytics to track and monitor your game playing audience and activities.

    4) Paid games

    You may have discarded paid apps already as a monetisation strategy, but in the last year only there have been several highest grossing paid mobile games. In fact, there has been $ 29 billion revenue from the paid apps alone. Yes, we know that nearly 98% of paid apps in Play Store are free apps, but to your surprise, many of these apps are now coming with a mix of strategies by offering paid sister apps. Often value additions like new graphic contents with these paid sister apps can actually boost engagement from the audience.

    5) Game ads rewarding players

    Mobile game players are more habituated with promotional contents compared to other app users. With the traction and engagement for in-app ads to garner any substantial revenue often a game needs a huge audience or players to earn a substantial value. This is why game ads need to be thought in a completely new light. Rewarding game players for watching game ads have come up with a really effective strategy. Around 80% of game players prefer watching video ads for game rewards.

    6) In-game sponsorship

    Sponsored contents within mobile games continued to remain another popular aspect of many mobile games in the recent years. It started way back in 2015 when Angry Birds players were allowed to kill the awful pigs by Honey Nut Cheerios as long as for 2 whole weeks and thus promoting another game app. Soon, several other games followed this trend which incorporated elements of other game apps in the gaming actions for the purpose of sponsorship. It works great specially for developers who have multiple game apps with a few successful ones across the board. In the present year, we can see mobile game developers to reduce dependence on the in-app purchase by embracing these rewarded and sponsored ads.

    7) Merchandising game products

    Merchandising your game-related products to the game players is still effective for too many mobile games. But it needs at least a certain level of commercial success for the game app. Only when your game has a widespread following and enjoys a niche branding, you can come up with the marketing of in-game characters shaped into real life products like t-shirts, stuffed toys, game-inspired cars, and even notebooks or coffee mugs.

    In conclusion

    All these strategies and avenues seem to have one thing in common, and it is more about connecting audience more specifically and in a targeted manner. In 2018, we can expect these strategies evolve further.

    • 1
      entry
    • 0
      comments
    • 1161
      views

    Recent Entries

    It's been awhile since I've been on this site.  Been busy at work, but as with all contracting, sometimes work gets light, which is the case as of the new year.  So I saw this challenge, and thought it might be fun to brush up on my skills.  I've been working mainly with embedded systems and C#, so I haven't touched C++ in awhile, and when I have, it's been with an old compiler, that's not even C++11 compliant.  So, I installed Visual Studio 2017, and decided to make the best use of this.

    Time is short, and I don't exactly have media to use, so I decided to just go out and start to learn Direct2D.  I have little experience with any modern form of C++, and zero experience with Direct2D and XAudio.  Whereas I didn't mind learning Direct2D, I fully admit XAudio presented a bit of problems.  In the end, I blatantly stole Microsoft's tutorial and have a barebones sound system working.  And unlike the Direct2D part, I didn't bother to spend much time learning what it does, so it's still a mystery to me.  I'm not entirely sure I released everything correctly.  The documentation said releasing IXAudio2 would release objects, and when I tried to manually delete buffers, things blew up, so I just let it be.  There are most likely memory leaks there.

    As you can plainly tell, this is by far the worst entry in the challenge.  This is as much of a learning experience as an attempt to get something out the door.  I figured, if I couldn't be anything close to modern, at least be efficient.  And I failed at that miserably.  Originally I wrote this in C.  Excluding the audio files, it came out to a whopping 16 KB in size, and memory usage was roughly 6 MB.  And then I decided to start to clean up my spaghetti code (I said start, never said I finished), and every time I thought I was getting more clever, the program grew in size and memory usage.  As of right now, it's 99 KB and takes up roughly 30 MB RAM on 720p resolution.  I haven't really checked for memory leaks yet, and I'm sure they exist (beyond just the audio).  In reality, I'd prefer to clean up a lot of the code.  (And I found a few errors with memory management, so I need to track down where I went wrong.  I removed allocating memory for the time being and pushed everything onto the stack.)

    The other thing is, this code is ugly.  Towards the end, I just started taking a patchwork approach rather than keeping it clean.  I was originally hoping for modularity, but that got destroyed later on.  And I'd love to replace the pointers that are thrown liberally throughout the code with smart pointers.

    Unlike the other entries, I only have missiles for the gameplay.  I didn't include UFOs, airplanes, smart bombs, nor warheads.  I just don't feel I had enough time.  Yes, there's still a couple weeks to go, but I'd prefer to cleanup what I have than add new features.  And unfortunately, I was a bit shortsighted, which caused problems later on.  There are multiple places where the code is far more verbose than it needs to be, because I wasn't properly focused on the correct areas.  I wanted to make it scalable, and I focused making the game a 1:1 ratio internally, yet displayed 16:9 to the user, which caused massive problems later on.  I ended up having to do math on pretty much every piece of graphics and game logic whereas if I had just displayed it as 1:1, or handled the internals in 16:9, I could have shaved off a thousand lines of code.  And it also caused problems with hit detection, which is another reason I didn't bother adding in anything but missiles.

    The hit detection was a mess.  I had everything mapped out.  The game was going to work whether a missile went 1 pixel a second, or 1000 pixels a nanosecond.  Calculating moving objects and collision with circles or boxes is easy.  Unfortunately, I was using ellipses.  And while there are formulas for that, I'll admit my eyes started to glaze over at the amount of math that would be required.  In the end, I decided to leave it buggy, and only detect if it was currently in a static ellipse, which is easy and fast enough to calculate.  I mean, I guess if the program freezes up, the user was going to lose a city/silo anyway, or lose it if the missile was traveling at light speed, but it's still a bug, and still annoys me, especially since everything else was calculated regardless of what the user sees. (*EDIT* Thinking about this more, the solution was right in front of me the entire time.  Just squish the world back to 1:1 and do the hit detection that way).

    Controls:

    1,2, and 3 control the missiles, and the arrow keys control the cursor.  Escape for the menu, and Enter for selection.  I've only tested this on Windows 10, as I'm pretty sure it requires those libraries.  It's a 64-bit executable.

    MCDemo.png

  4. Latest Entry

    Riverbanks, trees, floating stones

    ANDREJ KREBS, DOMEN KONESKI

    Riverbanks

    Riverbanks and (under)water are now filled up with more content such as grass, stones, chorals, ruins, tires and more. I’ve developed a spawning system that allows quick and easy setup for new game objects. You want to spawn a game object only in water at certain depth? You want to spawn trees at certain slope angle and then change its height on the fly? This system now allows you – without coding – to do such things with ease.

    ruins_riverbank_lowpoly_floatlands.png?f
    ruins on the riverbank

    New trees

    We decided to rework the tree tops, so I experimented with techniques and stiles, until we got to something we all really liked. This really changes the attitude of the game and creates more immersive but still somewhat abstract feel. The solid blob treetops are now being replaced with bunches of textured alpha transparent planes.

    lowpoly_environment_trees_floatlands.png
    new trees implemented

    Floating stone

    Lastly, here we have a timelapse video where I modeled a floating stone with a crystal. These stones will float above the crater where the floating islands were raised. I sculpted the basic shape and applied a decimate modifier, after that I added a crystal made in a similar fashion.
     


     

    Exponential grass level of detail

    DOMEN KONESKI

    I’ve been tweaking our new grass renderer a little bit and asking myself if I can increase the grass draw distance without ruining the overall performance. I came up with an unique solution by decreasing the amount of rendered grass, having in mind maximum grass distance and current camera position.

    New LOD logic allows subtle decrease of rendered grass meshes over the distance between the player and the final render distance. With this system we can now increase the render distance and allows us to add more content into the world of Floatlands

    lod_test_lowpoly_floatlands.png?fit=728,
    LOD comparison

    Terrain minimums and maximums

    VILI VOLČINI

    Finally I set out to improve the tools for terrain. It’s not much, but I did a function for local min/max search and slope of terrain. Local maximums should be useful for spawning bigger objects that need visibility. Local minimums could be useful for resources that need to be more hidden from the player.

    minmax_terrain_lowpoly_floatlands.png?fi
    local min/max search

    Critter concepts

    MITO HORVAT

    To further enhance the world we’ll add tiny critters that will roam around the environment. Critters will be friendly animals or mechanical creatures that will move around specific territories. For example you’ll encounter turtles near the sea/shore line, chickens near villages etc. If you decide to kill the critter, there will be a chance that it will drop loot or crafting materials. Although, what kind of heartless person could possibly kill a tiny cute crab dragging around a tin can house.

    critters_concepts_lowpoly_floatlands.png
    critter concepts

     

  5. Hi guys and gals! :3

    Here's my third blog entry for Forest Strike. This week I was designing the AI, which give me more struggles than expected. So, there's not much graphical stuff to show this time. That's why I am going a little bit more into detail and explain the game a bit.

    Forest Strike - Title


    Project Idea

    Forest strike is a 2D round-based strategy game in pixel-art style featuring animals as characters. Each round is divided into multiple phases, such as:

    • Pre Phase
    • Dice Phase
    • Move Phase
    • Action Phase
    • Post Phase

    Pre phase is resetting and initializing needed variables each round.

    After the pre phase (which is handled within a single step), the dice phase randomly picks the number of steps you can move.

    Now, after we got the number, we finally will be able to move the characters. Moving the characters is limited to an amount of steps (dice phase). During the Move Phase, you can move your characters and use items, such as the simple bomb.

    Items are split into two groups: "active" and "passive". Active items will be shown in the inventory and can be used during the Move Phase, while passive ones will influence different values of the game.

    The active items are not handled instantly, they get a sequence number and will be handled in the next phase, the Action Phase. If there are items placed (like a bomb), the action phase handles every item sequentially (by their sequence number). This way, the game provides a great variety regarding building your own strategy.

    Lastly, the Post Phase checks some stuff and jumps to the Pre Phase.


    So, what is planned:

    • a bunch of items, characters and maps
    • different game modes
    • local multiplayer
    • local singleplayer (with AI opponents)

    Optional features:

    • online multiplayer
    • story mode
    • boss battles

    Technology

    The game is running in Game Maker 2 in order to deploy the game to multiple platforms. Additionally, I really love working with Game Maker, because of its simple, yet powerful, UI and features. The software I use to draw the resources is Aesprite. Also, I am learning how to use Pyxel Edit to create awesome tilesets.

    Regarding platforms, I want to cover at least Windows, Linux and Mac. Eventually, a mobile export will be done as well with slight modifications.

    Currently, no music or sound is included in the game. In future, I will compose a few tracks in Cubase with a few external VSTs (depending on the genre). I'll keep you up to date as soon as I have a few tracks.

    Creating sounds has never been one of my strengths, so I’ll have to buy a bundle or hire a composer. Eventually, I’ll try creating a few sounds on my own.


    Key Features

    New explosion animation

    Forest Strike - New explosion animation

    I changed the explosion quite a bit. Instead of blowing up the things in one way, I added a small delay to the single explosion.

    Random starting player

    If you start a game, the starting player is now randomly chosen. Should be a general thing... and this week I implemented it. :D

    New character

    Forest Strike - Mouse Character

    Here we go with another character. I was thinking about a mouse, which reminded me a little bit of forests. Currently, I only did the "idle"-animation.


    Thank you for reading! :D

    If you have questions or any kind of feedback feel free to post a comment or contact me directly.

  6. I am looking for a programmer who is interested in making an indie game called Space Hockey. The design document can be downloaded from my blog on GameDev.Net. There are also over 600 pages of material relating too my 14-game Pirate Dawn Universe on this blog.

    For now I am only looking for a programmer who is capable of making Space Hockey, and together we can assemble the rest of the team from there. I am looking for someone who is at least near 30 years old and has finished at least one game before. I don't want to distract younger people from establishing themselves in a career with the lure of making games, and I want someone who has made at least one game before so that they understand going into it how much work that entails even for a simple game like Space Hockey. It doesn't have to be a game that was published, the whole point is just that you understand how much work it is to actually finish it.

    I am not looking to just make something to post on an indie site somewhere, the goal here is to eventually have Space Hockey for sale on Steam. As can be seen in the design document, once that has been achieved there is a lot of expansion of this that could take place resulting in half-a-dozen or so DLC expansions. This would begin as a hobby/indie project but will, hopefully, someday become a commercial game company. Assuming that Space Hockey and its DLC expansions were successful, the goal would be to transition into a commercial game company and begin work on the 14 games of my Pirate Dawn Universe.

    I have been designing games and simulations since before the computer game industry existed, for about 40 years now. I don't say this out of arrogance. It is simply a fact of time that today, in 2018, I am one of the most experienced and knowledgeable game and simulation designers in the world. Although the very simple Space Hockey does not use it, a physical construct that I call “Rube” is the fundamental basis of what you know as “The Matrix”. Rube is also the fundamental basis of cyberspace, an insubstantial holodeck, and a self-programming computer with omniscient communication. The later games of the Pirate Dawn Universe such as Territories, Mission, Clash of the Titans, and the Struggle of the Ancients games are all based on Rube.

    The Pirate Dawn Universe is a sci-fi universe focused on space ship games. Lost Art Studios games are based on the 300 years of game design that came before computer games. They are not, for the most part, based on past computer games. This is only one of the things that makes these games unlike any computer games that have ever existed before. As a former member of the SFB Staff, there is no competition out there for Lost Art Studios when it comes to making space ship games for the computer. If LAS can get off the ground, competing within this genre in the modern game industry would be like hunting rabbits with a 120mm cannon.

    This will begin as a hobby/indie project to create Space Hockey, and we can establish a typical deal where those who contribute to the creation of the game receive some form of payment if and when the game actually makes money. I really don't care about the money very much and am open to anything that works. The true goal, however, is to get Lost Art Studios off the ground as a commercial game company that will very easily dominate the space ship game genre with its 40 years of accumulated knowledge of the Star Fleet Universe community. And, of course, Rube... which also partly comes from the SFU. Even if Lost Art Studios manages to get off the ground, we would not attempt to develop a truly large or complex game at first. Part of the plan within the design of the games of the PDU is that the first three games are smaller and more simple games to make.

    Territories is a prequel, that “Civilization scale war game” is first chronologically but can be made at any point during the telling of the PDU story. The actual first three games are intentionally simple to make. As an MMO Pirate Dawn is “massive” from the player's perspective, but it it is actually a fairly small and simple game too make. The “massiveness” of Pirate Dawn is an illusion too the player. The game itself isn't actually “massive”, the simple arcade game maps are. Manifest Destiny and The Trade Wars, what would be the second and third games, are both smaller and easier to produce than Pirate Dawn is. They are both intentionally minimalist strategy economic war game “scenario generators” where the focus is heavily on the tactical combat resolution (which is not 3D). Lost Art Studios would not even attempt to make a “big game” until we were on our fourth release.

    If you are interested in helping to create Space Hockey, with a plan already place to keep going from there, you can contact me through my blog on GameDev.Net or my e-mail address:

    From Astral Invasion...

     

  7. I've created a project page for the U3DTerrainEditor I have been working on. Project now includes a downloadable Windows binary so you can try it out. Warning: rough code ahead. It's still a pretty unpolished project, but you can do some cool stuff with it regardless.

    Your first terrain:

    1) Download the archive, unpack, and execute either run_opengl.bat or run_d3d11.bat. Alternatively, you can execute TEdit.exe or TEdit_D3D11.exe directly, passing arguments on the commandline; ie, 

    TEdit.exe LuaScripts/terraineditor.lua -w

    to run windowed instead of borderless. The batch scripts execute in borderless windowed mode.

    2) Click on the NodeGraph button in the toolbar, represented by 3 boxes linked by lines. A window will popup in the lower right. Click new to create a new Node Group, then click Edit to edit the new node group. An overlay window will popup with a + button to create nodes, and an output widget.

    3) Click on +, navigate to library, then click on ridged. A node for a Ridged fractal should appear. Change the value of the Frequency input to 3. Click and drag on the output link of the node, and drag the link to the input of the output widget. When the link is established, click the Preview button. The preview pane should fill with a preview image of the node function.

    4) At the bottom of the output widget, ensure that Terrain is selected as the Output Target, then click Execute. After a brief processing pause, you should see the terrain change in the background. Press 'm' to close the node window.

    5) Click on the Filters button. (It looks like a magic wand). From the list of filters, select Erosion. In the Power box, enter an erosion power (or just stay with 0.3, which is a decent choice). Power values can range from 0 to 0.5. Click Execute. After a brief prcoessing delay, the terrain should change again showing the results of the erosion applied.

    6) From filters, select the Cliffify filter. In the dropdown box for Layer, select Layer 7. Press execute. After processing, the terrain should change so that steep areas show a cliff-like texture.

    7) Select the Cavity Map to Layer filter. In the Layer dropdown box, select Layer 2, then press execute. The terrain should change again, showing sandy texture in the bottom of hollows and depressions.

    8) Press the Terrain Options button (represented as a gear wheel). Select the Save button next to the Terrain: label, enter a filename, and hit Save to save the terrain heightmap to a PNG file. Heightmap will be saved as a standard RGB PNG, with height stored in the Red and Green channels. Red is the coarse height, and Green is finer detail data, allowing the heightmap to represent more than just 256 levels of elevation and making a smoother heightmap. Height can be extracted as Red + Green/255.0f.

    Of course, there is a lot more you can do with it. There are brushes for manually editing terrain, texture layers and masks. You can use masks to protect areas from being edited or modified. You can create a spline (use 'q' and 'e' to remove and create knots) then use the Road filter or River filter to create areas of road and river. You can export the texture blend layers as well as a normal map. Some stuff still might not be hooked up right, and as always this is a work in progress.

    If you have any feedback or suggestions, let me know.

    • 1
      entry
    • 0
      comments
    • 77
      views

    Recent Entries

    devlog_title.png

    A 3D platformer in the world of pastries.


    Hello! After 4 months of work, it's time for us to start a devlog for our new project!

    STORY

    You play Choconoa, the prince of the chocolate world, and you must grab back the sugar stolen by the princess of the candy world.

    GAMEPLAY

    The 4 gameplay pillars are:

    • You need to collect basic ingredients (chocolate, flour, eggs and milk) and recipes, and thanks to the magic of your wooden spoon, you can create a catapult.
    • The bonus collectible is a chef's hat wich allow you to bounce and be invincible for a limited time.
    • Next are the sliders which allow you to access different areas and grab extra collectibles.
    • Last is the chantilly on the floor which makes you go faster.
       

    giphy.gif

    giphy.gif

    giphy.gif

    giphy.gif

    FEATURES

    • LINEAR LEVEL DESIGN - SEQUENTIAL ORDER
    • SINGLE PLAYER AND LOCAL MULTI UP TO 4 PLAYERS SPLITSCREEN
    • COLORFUL STYLIZED ENVIRONMENTS
    • KID-FRIENDLY
    • PASTRY THEME
       

    WHAT'S DONE

    • PROTOTYPE
    • BASIC MENU AND HUD
    • CORE GAMEPLAY
    • HERO BASIC ANIMATION SET
    • SOME ENVIRONMENT PLACEHOLDERS
    • SOME SOUNDS AND FX PLACEHOLDERS

    TODO

    • LEVELS
    • CHARACTERS MODELS
    • ANIMATIONS
    • ART
    • SOUNDS AND MUSICS
    • TEST

    TOOLS

    • UNREAL ENGINE 4
    • ZBRUSH
    • BLENDER
    • GIMP

    TARGET PLATFORMS

    • WINDOWS, MAC AND LINUX
    • NINTENDO SWITCH
  8. Hi everyone!

    It has been more than two months since I released I Am Overburdened and since I wrote a devlog entry. Please accept my apology for this, I was super busy with the release and support of the game. But now I’m back with an in-depth analysis how the overall production and final numbers turned out ;) .

    Summary

    I want to do a fully detailed breakdown of the development and business results, but I don’t want break it up into a typical postmortem format (good, bad, ugly). I’ve drawn my conclusions, I know what I have to improve for my upcoming projects, but I don’t want to dissect the I Am Overburdened story this way, I want emphasize how much work goes into a game project and focus more on how a journey like this actually looks and feels like. If you really want know my takeaways, here it goes in a super short format: I consider the game a success from a development perspective (good), but I failed from a marketing and sales standpoint (bad and ugly).

    Now I go into the details, but will focus more on the objective “what happened, how it went, what it took” parts.

    Development

    The game started out as a simple idea with a simple goal in mind. I partially abandoned my previous project, because it ballooned into a huge ball of feature creep, so I wanted to finish a more humble concept in a much shorter time period. The original plan was to create a fun game in 4 months. I really liked the more casual and puzzle-y take on the roguelike genre like the classic Tower of the sorcerer game, or the more recent Desktop dungeons and the Enchanted cave games so I set out to create my own take. I designed the whole game around one core idea: strip out every “unnecessary” RPG element/trope and keep only the items/loot, but try to make it just as deep as many other roguelikes regardless of its simplicity. From this approach the “differentiating factor” was born, a foolishly big inventory, which helped me to define and present what I Am Overburdened really is.

    A silly roguelike full of crazy artifacts and a “hero” who has 20 inventory slots.

    Most of the prototyping and alpha phases of the development (first two months) went smoothly, then I had to shift gears heavily…

    2017_02_11_screenshot_1

    Reality check

    After 3 months of development, when all of the core systems were in place and when I deemed big parts of the content non-placeholder, the time came to show the game to others. I realized something at that point, forcing me to make a huge decision about the project. The game was not fun :( . The idea was solid, the presentation was kind-of ok, but overall it was simply mediocre and a month of polishing and extra content in no way could change that!

    2017_04_01_screenshot_3

    Back than I was super stressed out due to this and I thought about this as my hardest decision as a game maker, but looking back I think I made the right choice (now I feel like I actually only had this one). I decided to postpone release, explore the idea further even if it doubles!!! the originally planned development time (and it happened :| ) and most importantly I decided to not make or release a “shovelware”, because the world really isn’t interested in another one and I’m not interested in making/publishing one…

    Final scope

    So after 4 months of development, feeling a bit glum, but also feeling reinvigorated to really make the most out of I Am Overburdened I extended the scope of the design & content and I also planned to polish the hell out of the game :) . This took another 4 months and almost a dozen private beta showings, but it resulted in a game I’m so proud of, that I always speak of it as a worthy addition to the roguelike genre and as a game that proudly stands on its own!

    screenshot_2

    Some numbers about the end result:

    It takes “only” around 30 to 40 minutes to complete the game on normal mode in one sitting, but due to its nature (somewhat puzzle-y, randomized dungeons & monster/loot placements + lots of items, unlocks and multiple game modes), the full content cannot be experienced with one play-through. I suspect it takes around 6 to 12 full runs (depending on skill and luck) to see most of what the game has to offer so it lends quite a few hours of fun :) . There are 10 different dungeon sets and they are built from multiple dozens of hand authored templates, so that no level looks even similar to the other ones in one session. They are populated by 18 different monsters each having their own skill and archetype (not just the same enemy re-skinned multiple times). And the pinnacle, the artifacts. The game has more than 120 unique items, all of them having a unique sprite and almost all of them having unique bonuses, skills (not just +attributes, but reactive and passive spells) and sound effects. This makes each try feel really different and item pickup/buy choices feel important and determinative. The game was also localized to Hungarian before release, because that is my native language so I could do a good job with the translation relatively fast and this also made sure, that the game is prepared to be easily localized to multiple languages if demand turns out to be high.

    boxart_animated_art_portrait

    Production numbers

    How much code I had to write and content I had to produce all in all to make this game? It is hard to describe the volume/magnitude with exact numbers, because the following charts may mean a totally different thing for a different game or in case of using different underlaying technologies, but a summary of all the asset files and the code lines can still give a vague idea of the work involved.

    2018_01_09_chart_files

    Writing and localization may not sound like a big deal, but the game had close to 5000 words to translate :o ! I know it may be less than the tenth of the dialogue of a big adventure or RPG game, but it is still way larger than the text in any of my projects before…

    2018_01_09_chart_text

    I’ll go into the detailed time requirements of the full project too after I painted the whole picture, because no game is complete without appropriate marketing work, a super stressful release period :P and post-release support with updates and community management work ;) .

    Marketing

    If you try to do game development (or anything for that matter) as a business, you try to be smart about it, look up what needs to be done, how it has to be approached etc… I did my homework too and having published a game on Steam before I knew I had to invest a lot into marketing to succeed, otherwise simply no one will know about my game. As I said this is the “bad” part and I’ll be honest. I think I could have done a much better job, not just based on the results, but based on the hours and effort I put in, but let’s take it apart just like the development phase.

      • Development blog/vlog
        I started writing entries about the progress of the game really early on. I hoped to gather a small following who are interested in the game. I read that the effectiveness of these blogs are minimal, so I tried to maximize the results by syncing the posts to at least a dozen online communities. I also decided to produce a video version because it is preferred over text these days + I could show game-play footage too every now and then. I really enjoyed writing my thoughts down and liked making the videos so I will continue to do so for future projects, but they never really reached many people despite my efforts to share them here and there…
        icon_simple_mono_round_small
      • Social media
        I’ve tried to be active on Twitter during development, posting GIFs, screen-shots and progress reports multiple times a week. Later on I joined other big sites like Facebook and Reddit too to promote the game. In hindsight I should have been more active and should have joined Reddit way earlier. Reddit has a lot of rules and takes a lot more effort than Twitter or Facebook, but even with my small post count it drove 10 times more traffic to my store page, than any other social media site. Since the game features some comedy/satire and I produced a hell of a lot of GIFs, I tried less conventional routes too like 9gag, imgur, GIPHY and tumblr, but nothing really caught on.
        icon_twitter_small
      • Wishlist campaign
        I prepared a bunch of pictures up-front featuring some items and their humorous texts from the game. I posted one of these images every day starting from when the game could be wishlisted on Steam. I got a lot of love and a lot of hate too :D , but overall the effectiveness was questionable. It only achieved a few hundred wishlists up until the release day.
        2018_01_08_wishlist
      • Youtube & Twitch
        For my previous Steam game I sent out keys on release day to a 100 or so Youtubers who played any kind-of co-op game before, resulting in nearly 0 coverage.
        This time I gathered the contact info of a lot of Youtubers and Twitch streamers upfront. Many were hand collected + I got help from scripts, developer friends and big marketing lists :) ! I categorized them based on the games they play and tried talking to a few of those who played roguelikes way before release to peak their interest. Finally I tried to make a funny press release mail, hoping that they will continue reading after the first glance.
        I sent out 300 keys the day before release and continued the following weeks, sending out 900 keys total.
        And the results?! Mixed, could be worse, but it could be much better too. 130 keys were activated and around 40 channels covered the game, many already on release day and I’m really thankful for these people as their work helped me to reach more players.
        Why is it mixed then? First, the videos did generate external traffic, but not a huge one. Second, I failed to capture the interest of big names. I also feel like I could have reached marginally better results by communicating lot a more and a lot earlier.
        icon_youtube_small
      • Keymailer
        I payed for some extra features and for a small promotion on this service for the release month. It did result in a tiny extra Youtube coverage, but based on both the results and the service itself all in all it wasn’t money well spent for me (even if it wasn’t a big cost).
        icon_keymailer
      • Press
        This was a really successful marketing endeavor considering the efforts and the resulting coverage. I sent out 121 Steam keys with press release mails starting from the day before release. Both Rock Paper Shotgun and PC Gamer wrote a short review about it in their weekly unknown Steam gems series and the game got a lovely review from Indiegames.com. Also a lot of smaller sites covered it many praising it for being a well executed “chill” tongue-in-cheek roguelike :) . The traffic generated by these sites was moderate, but visible + I could read some comforting write-ups about the quality of the game.
        2018_01_09_press
      • Ads
        I tried Facebook ads during and a bit after the release week + in the middle of the winter sale. Since their efficiency can not be tracked too well I can only give a big guesstimate based on the analytics, sales reports and the comparison of the ad performances. I think they payed back their price in additional sales, but did not have much more extra effect. I believe they could work in a bigger scale too with more preparation and with testing out various formats, but I only payed a few bucks and tried two variants, so I wouldn’t say I have a good understanding of the topic yet.
        icon_facebook_small

    Some lifetime traffic results:

    2018_01_09_traffic

    So much effort and so many people reached! Why is it “bad”, were the results such a mixed bag? Well, when it comes to development and design I’m really organized, but when it comes to marketing and pr I’m not at all. As I stated I never were really “active” on social media and I have a lot to learn about communication. Also the whole thing was not well prepared and the execution especially right at the release was a mess. The release itself was a mess :( . I think this greatly effected the efficiency! Just to be more specific I neglected and did not respond in time to a lot of mails and inquiries and the marketing tasks planned for the launch and for the week after took more than twice as much time to be completed as it should have. I think the things I did do were well thought out and creative, but my next releases and accompanying campaigns should be much more organized and better executed.

    Time & effort

    I don’t think of myself as a super-fast super-productive human being. I know I’m a pretty confident and reliable programmer and also somewhat as a designer, but I’m a slowpoke when it comes art, audio and marketing/pr. For following my progress and for aiding estimations I always track my time down to the hour level. This also gives me confidence in my ability to deliver and allows me to post charts about the time it took to finish my projects ;) .

    Important thing to note before looking at the numbers: they are not 100% accurate and missing a portion of the work which were hard to track. To clarify, I collected the hours when I used my primary tools on my main PC (e.g.: Visual Studio, GIMP), but it was close to impossible to track all the tasks, like talking about the game on forums & social media, writing and replying-to my emails, browsing for solutions to specific problems and for collecting press contact information, you get the idea… All in all these charts still show a close enough summary.

    2018_01_09_chart_time_final

    2018_01_09_chart_time_final_pie

    2018_01_09_chart_time_implementation

    2018_01_09_chart_time_content

    2018_01_09_chart_time_marketing

    288 days passed between writing down the first line in the design doc and releasing the game on Steam. I “logged” in 190 full-time days. Of course more days were spent working on the game, but these were the ones when I spent a whole day working and could track significant portion of it + note that in the first 4 months of the project I spent only 4 days each week working on I Am Overburdened (a day weekly were spent on other projects).

    Release

    So how the release went? It was bad, not just bad, “ugly”. After I started my wishlist campaign, close to the originally planned date (2017. Oct. 23.) I had to postpone the release by a week due still having bugs in the build and not having time to fix them (went to a long ago planned and payed for vacation). I know this is amateurish, but the build was simply not “gold” two weeks prior to release :( . Even with the extra week I had to rush some fixes and of course there were technical issues on launch day. Fortunately I could fix every major problem in the first day after going live and there were no angry letters from the initial buyers, but having to fight fires (even though being a common thing in the software/game industry) was super tiring while I had to complete my marketing campaign and interact with the community at the same time. The game finally went live on Steam and itch.io on 2017. Nov. 2 :) ! I did not crunch at all during development, but I don’t remember sleeping too much during the week before and after launching the game. Big lesson for sure :| .

    2018_01_09_steam2

    I saw some pictures about the game making it to the new and trending list on Steam, but it most probably spent only a few hours there. I never saw it even though I checked Steam almost every hour. I did saw it on the front-page though, next to the new and trending section in the under 5$ list :) . It spent a day or two there if I remember correctly. On the other hand, itch.io featured it on their front page and it’s been there for around a whole week :) !

    2018_01_09_itchio2

    With all the coverage and good reviews did it at least sale well, did it make back it’s development costs, if not in the first weeks at least in the last two months?

    Nope and it is not close to it yet…

    Sales

    In the last two months a bit more than 650 copies of I Am Overburdened were sold. Just to give an overview, 200 copies in the first week and reached 400 by the end of November, the remaining during the winter sale. This is not a devastating result, it is actually way better than my first Steam game, but I would be happier and optimistic about my future as game developer with reaching around 3 to 4 times the copies by now. To continue as a business for another year in a stable manner around 7 to 8 times the copies total (with price discounts in mind) during 2018 would have to be reached. I’m not sure if the game will ever reach those numbers though :| . If you do the math, that is still not “big money”, but it could still work for me because I live in eastern Europe (low living costs) + I’m not a big spender.

    2018_01_09_sales

    Of course this is an outcome to be prepared for and to be expected when someone starts a high-risk business, so I’m not at all “shocked” by the results. I knew this (or even a worse one) had a high chance. No matter how much effort one puts into avoiding failure, most of the game projects don’t reach monetary success. I’m just feeling a bit down, because I enjoyed every minute of making this game, a.k.a. “dream job” :) , maybe except for the release :D:P , but most probably I won’t be able to continue my journey to make another “bigger” commercial game. I may try to build tiny ones, but certainly will not jump into a 6+ months long project again.

    Closing words

    It is a bit early to fully dismiss I Am Overburdened and my results. It turned out to be an awesome game. I love it and I’m super proud of it. I’m still looking for possibilities to make money with it (e.g.: ports) + over a longer time period with taking part in several discount events the income generated by it may cover at least a bigger portion of my investment. No one buys games for full price on PC these days, even AAA games are discounted by 50% a few months after release :| , so who knows…

    If you have taken a liking to play the game based on the pictures/story you can buy it (or wishlist it :) ) at Steam or at itch.io for 4.99$ (may vary based on region).

    icon_steam_small icon_itchio_small

    As an extra for getting all the way here in the post, I recorded a “Gource” video of the I Am Overburdened repository right before Christmas. I usually check all the files into version control, even marketing materials, so you can watch all the output of almost a year of work condensed into 3 minutes. Enjoy ;) !

    Thank you very much for following my journey and thanks for reading.
    Take care!

    • 1
      entry
    • 1
      comment
    • 63
      views

    Recent Entries

    I've always loved video games.  As a child, I spent hours playing on my Atari 2600, on our home PC, or at a friend's house on his Nintendo and Super Nintendo.  As time went on, I discovered QBasic and started to learn to make simple programs.  It clicked - this is how the creators of the games were doing it!

    From there, I became very interested in learning about the creation process.  I experimented, read articles in magazines, and as the World Wide Web took off I ventured online to learn more.  Games got bigger and fancier, and some of them in special editions with documentaries about the creation, and I loved all of it.

     

    Well funded teams of hundreds of people were now working to create fantastic games with hours of gameplay and breathtaking visuals.  I read articles and watched "making of" documentaries which described how developers would work long hours, forgoing days off, working late nights, and sometimes even sleeping in the office to meet deadlines.  I was so impressed with the effort and dedication they put in.

    How much must you love a product to give up your nights and weekends, and spend time away from your family to finish it off?  This was how great games were made, and I was in awe of the industry and the process.  This was what I idolized.  This was what I aspired to.

     

    I was wrong.

    The process I have described above is not necessary, and it is not cool.

    Developers do not need to sacrifice their free time, their sleep, and their health to create great games.  The science is in.  Numerous studies have shown that well-rested people are more productive and less prone to mistakes.  The stress of this schedule and lack of sleep is profoundly damaging to people's health, causes burnout, and drives talented developers away from our industry.

    Just think about a cool feature that you loved in a AAA game.  If the team went through a period of crunch, the developer who created that feature may have burned out and left the industry - they might not be creating awesome things for gamers anymore.

     

    We should not idolize a process that is harmful to developers.  When we hear about crunch, the overwhelming reaction should be that this is not ok.  Crunch is not cool, and developers still using this process should work towards a better way.

    Happier, healthier developers will produce better work, and in the long run, they will produce it more efficiently.  Happier, healthier developers are more likely to stay in our industry rather than seeking greener pastures, resulting in more people with extensive experience who can then work on more advanced tasks and ideas, and push the industry forward.

     

    Thankfully, a growing number of developers have moved on or are moving on from this toxic culture of overtime and crunch, and a growing number of people are willing to speak up.  Unfortunately, it's far from everyone, and there are many developers still exploiting workers.

     

    I'm putting my foot forward to say that I do not support a culture of overtime and crunch.  We can do better, and we need to do better.  I'm not the first person to share these sentiments, and I'm not an influential person, but I hope I won't be the last, and if I can convince even one more developer to stand up for better treatment of workers, then hopefully I've made some small difference.

    If you agree with me, next time you hear someone discussing crunch as if it's just a normal part of the process, let them know that there's a better way and that you don't support crunch and overtime.  Let them know that crunch isn't cool.

  9. Comic book inspiration

    I want to make it clear that the game is highly inspired by my comic book experience. I am a big fan of Garfield, Gaston LaGaffe and Charlie Brown. I find the 9th art to be a very subtle, intelligent way to make people think and smile. Doing cartoon was always something I was proud of. I first started doing them when I discovered about Nabuchodonosaure  cartoon and "Le concombre masqué". They triggered something inside me to start producing my own. My graphic style was Charlie Brown and Garfield as it was very simple and efficient. I want the game to feel like you are part of that background. I like how things look graphically, how anything can happen. More specifically I produce the Recontre du 3e type cartoon book which was self publish and sold locally in my home town. 500 copies were sold, which is not bad considering the market. Despite the book didn't make it to the big league, it was show case in the International comic book fare of Quebec and at the Salon du livre jeunesse. I was very proud of it and had a lot of very good feedback on the work from the readers. The book wasn't necessarily really strong artistically. The core story was great, but It wasn't fully exploited and my skill at the time wasn't strong enough. I'll gladly share part of the original book in the upcoming weeks. What is important about that book is that it serve as a starting point of this project. I have 2 tome of prewritten scenario to start with. I don't know about other indie developer, but I think having a scenario draft is really important. I want to develop things around a story and not squeeze a history inside of a confine set of feature. Those two book gave me the opportunity to know my character. This is a lot of character background to work with ! It's cool. It's like if I had started that game a couple of years ago without even knowing I will ever produce that. That said, things have change for the best and I am not sticking to a simplistic adaptation of an old unsuccessful cartoon. This is a complete rewrite, remaster, recreated, new, unique and super wow bing bang history inspired by the original work ! I think it is very important to have a good story a good plot, we want to tell a story, we want a start, a reason to play and the goal to be clear. We want a strong story to support game feature and we have one. 

    So graphically you can expect things in 3D but with a cartoon style approach. I want this game to be more like how Pixar does thing. Cartoon but with a realistic look... ok hold it here. I am not Pixar, but if I have to aim at something, i'de rather aim as high as possible. I don't want the inspiration to stop there. I want the game to feel like a comic book, not by having super great 3D simulation of  a page being turn, I don't want it to feel like a gimmick. What I am saying is that I want it to be funny, colorful, action packed and for all age. Everything will be, from a design stand point, inspired by that.

    Designing a character is also very complex to me. Designing a character is not only how it look it is how it live, how it walk, how it talk, how it react to certain situation etc. You have to create, in your mind, a full feature humanoid. I remember working up at night to write down idea and redraw stuff that wasn't working well. All this data is part of me now. They were born and lived in my head and they still do. I'll make various blog entry regarding each character

    Game inspiration

    I can't really pin point what game would be the closest similar game to the our. I am not necessarily inspired by 1 game or a set of game, but i'm inspired by some game feature of the old days. At the time of classic arcade, colleco and nintendo NES there were some stuff about these game that make them good even 30 years later. They were very addictive, they required complex pattern learning, skill and you had to be really crazy devoted to finish a game. I remember the adrenaline rush and excitement of finishing a game meant at that time. I find today's game to be more on the easy side, very forgiving, very beautiful and cinematic but also very short and almost no replay-ability. Replay-ability is a big word that a lot of developer said to aim at but very few actually achieve it. We will try to achieve that in various way by implementing a lot of game mechanic we will talk in future blog post. What game had

    1. They were hard and frustrating
      1. To a certain degree this is not so good as we want stuff to be fun, but if you want to have this adrenaline rush we all like,  you have to go through painful moment. A mix  of nice easy moment and hard impossible level that draw the line between care-bear and hardcore gamer ! I know that I treat the "hard level" of todays game as the "normal level". How difficulty work in our game will be shared in a futur blog entry.
    2. They had a LOT of replayability
      1. Yes, people still play Mario 1. It will always be fun. Q*Bert, still very fun, even though every level look the same. PacMan ! 256 level of frustration. We will not have only 1 level repeating itself at higher speed indefinitely until the game crash, but we will give you reason to restart the game even if you ever finish it. We will give you reason to restart the game if you are  stuck at a certain level that is too hard. We will give you reason to start many game in parallel just to do thing differently. I can't wait to share more about it later !
    3. They were unforgiving
      1. Ever played Rick Dangerous ? This is one of the most sadistic experience (still a very gun and good game) as everything in this game kill you instantaneously and this Indiana Jones inspired game had all of impossible to detect death trap every where. Each path was design to kill you each and every single time. Ever played the NES version Dragon's Lair ? (ok this one is a bad exemple, as the game was really bad, and the control were terrible) There is a funny episode  from the angry game nerd about it.( go to 2:46 https://youtu.be/00xIvTOLrYA  ). We don't intend to have a game that frustrating, That is not fun at all. But even in mario everything kill you in 1 shot. It's hard, some level require a Epic level of eye finger coordination. Today's game give you plenty of health, and health typically regen etc. We have our own thinking on how to draw the line between those two extend. More info soon ;)
    4. They were fun and had their own signature
      1. As easy as it sound, this is the hardest part. Make it fun ! You will be be the judge of that and you'll be able to judge the more you discover about the game.

    Stay tune as the next blog post will be about the game story and what will be the humorous approach of this crazy universe. Follow us !

    What do you guys think about today's game difficulty level ? Are they just right or are they too easy ? 

  10. Every game has to start somewhere, and mine will be the concept development phase.  I've laid out a personal time line that I am striving to follow for my development process and I will be discussing the process for the Concept model.

    Sadly, this concept model is going to be more of a gameplay feel concept and not a game concept.  My objective is to create a working arena for combat, for the player to practice sparing with a single enemy.

    Practice Arena
    In order to begin developing, I need an environment to play and test in.  For this purpose, and to offer a place to practice gameplay mechanics for players in the future, I've come up with the Practice Arena.  The Practice Arena will consist of 7 game objects. 
    1 Floor
    4 Walls
    Player Spawn Point
    Enemy Spawn Point

    Using unity, this will take me roughly 15-30 minutes to fully configure to my liking.  I have no intentions of creating visually appealing content until achieving a "beta" state for the game.  After attaching coliders and placing spawn points I can move forward to the Player Prefab.

    Player Prefab
    For the player prefab, I will be using some of the free models I found on reddit.com/r/gamedev created by /u/QuaterniusDev.

    (Full URL for model: https://www.reddit.com/r/gamedev/comments/7jobpt/free_lowpoly_animated_woman/)

    For the player, what I want to do is import the asset into unity and drag it into my game world.  We will be focusing on developing the player as a Prefab and not a game object.  By doing this we can easily create the player in new worlds without a lot of extra work.

    Controls
    A game is quite literally just an animated movie without user input.  The next major step will be defining the user controls for movement.  As an engineer, I have a very object oriented mindset which is why I have decided to build a "ControlHandler" class.

    The control handler will handle input from all sources and trigger events in responses.

    I'm choosing event driven input vs direct input so that I can easily seperate what triggers each event/movement and give myself easier control/management over the entire game by not having to spend hours scouring for code.

    Single Spell
    A single spell sounds boring but with the intricacy of the spell system, and the future talents, building just one extendable spell will be a great start to an intricate spell system later on.

    Both the player and the enemy will have access to this ability and it will be the primary source of combat in the early stages of the game.  

    Enemy
    I will also be building an enemy in the same manner that the player was created, I'll be using a model borrowed from our good friend in /r/gamdev and using the low-poly zombie model

    link: https://www.reddit.com/r/gamedev/comments/7pla8z/free_lowpoly_animated_zombie/

    Enemies will have their own customizations in the long term which is why enemies will also be built as prefabs.  The goal is the create EVERY object in the game in a generic expandable form.  Enemies will be hanlded via an AIController.  The AI Controller will handle all active game AI in the scene. 

    Hit Detection
    In order to provide a small combat experience I will have to build hit detection.  The hit detection module will be implemented inside of spells, spells will register everything they come into contact with and register it as a hit.  
    If the spell was from a friendly targe the hit will do no damage.  

    Dodge Mechanics
    The hyperactive/reactive nature of the gameplay will be ever present inside of the dodge mechanics.  Each class has unique ways to defend and protect themself but the most common will always be their dodge mechanic.  The first dodge mechanic that will be implemented is a roll to left or right.  Dodge mechanics will be expanded as the class system is built out later on.

    1v1 Battle Mode
    In order to create a battle mode, I will add health to both enemy and player characters.  Whoever drops from 100 to 0 first is the loser.

    I will be playing in this version for a while trying to get a better feel for the movements and upgrading.

    I look forward to writing development posts about all the topics I just discussed, and I greatly appreciate you following on this journey.

    Outro

    Nothing in the world is free and I immensely respect anyone willing to take time working on products that they release for free.  On that note, I just wanted to share the Patreon for /u/Quaternius.  Thanks for all the models you make and I wish you as much success as your heart desires!

    https://www.patreon.com/quaternius


     

  11. Hello,

    My Name is Olivier Girardot, I am a music composer and  a sound designer.

    I am working with a friend and great artist Gero Doll on a VR project called DreamArtVR. Gero is doing all the design and programming, while I am creating the Sound.

    Gero has by far the hardest part. Plus he is not a programmer so he has been struggling a lot to achieve this first level, and there are some imperfections, but I think he did a great job.

    We would very much appreciate if you could try the demo and give us your honest opinion. We know there are a lot of things to improve, but we hope we are on the right path to create something unique, and interesting for the players.

    We are also hoping to get some financial help to finish this game and hire a programmer.

    We are looking forward to reading your impression on this game.

    Here is the video teaser: 

    And here is the webpage where you can download the playable demo: https://limbicnation.itch.io/dreamartvr

    Thank you for your time !

    Olivier Girardot

    http://www.ogsoundfx.com

    http://www.ogmusik.com

    http://www.limbicnation.com/

  12. Art is one of the most important aspects in Noahmund. Everything that includes our videogame is conceived from the vision of beauty and inspiration. For that, the department of art works unceasingly so that the most innovative ideas that arise in the studio have a true reflection in the final content that, after all, is what players are going to experience when they finally enjoy Noahmund.

    Miguel Guzmán is one of our 3D modelers, who has been working very hard during the last weeks for our second demo available from the 16th of October. In this demostration you will be able to see the city of Shinn and Costa Penumbra, so that Miguel’s work has been centered in modeling both scenes/settings. 

    UgOV37F.png

    In the seaside site it has been recreated all of the props, such as stones, vegetation or the collectible elements, that are essential for the creation of catalysts (potions) in the advance of the adventure. In the same way, Miguel has elaborated all of the objects of dungeons that you will see in the final version of the game, which contains many details of a huge artistic importance, especially to contextualize the player with the place where they are. These kind of elements, like monuments or big size elements, comprise the greatest difficulty, since they need a more exhaustive and thorough treatment in order to perfectly reflect their characteristics.

    To Miguel one of the biggest satisfactions is the composition of collectible elements, such as herbs, flowers or bushes, which, despite of appearing very homogeneous between them, they offer the possibility of doing the task with more dynamism, providing their personal touch, something that does not happen in other types of compositions more attached to the conception of the script.

    QcI2HY5.png

    About the city of Shinn, Miguel has been working on a striking area of this mythical location. A restful place, full of spirituality, surrounded by forests and separated from the bustle of the city and its population. This forest, inspired by the zen gardens for its design, is a rest and repose area within the city, a place where mysticism and mourning come together with familiarity.

    The work is continous, but without any doubt it is made with great ilusion so that everybody can enjoy it. Next week we will come back with another devblog especial for the release of the second demostration.

    You can download the second demo of Noahmund in www.noahmund.com

     

    • 2
      entries
    • 0
      comments
    • 97
      views

    Recent Entries

    Latest Entry

    Ищу спутников опытных net программистов за разработку игры подводные бои

  13. When doing any largish project, you need various support infrastructure. You need to be able to track your changes, and because working with multi-thousand line files is a right pain - you need some way to combine multiple files into one, and finally, you need to be able to run tests to ensure your code is valid.

    This means we need: 

    • A Version Control System
    • A build system
    • A Test system

    I'm a fan of git, and so the project is already up on github. Don't bother to have a look there yet - there's not really anything to see. But it takes care of the first requirement.

    For a completely different project, I wrote a small dependency resolver in python. Coupled with a small command line interface it makes a minimal (<300 line) build system. For a project that isn't "just" building code, this allows a lot more flexibility than things like Make, and because it's python it probably doesn't require people to install anything they don't already have.

    And because I haven't worked in javascript extensively before, I don't have a particular test system yet. I'll probably end up going for Jasmine. I'll be playing with that this evening (unless someone comments with other suggestions)

     

    There is also also have other non-project code that needs to be written. We need some way to get models and assets into our new engine, and like a complete n00b, I went and modelled all the models already. I also wrote an export script for blender! The great thing about blender is that it is python scriptable, and it is trivial to iterate through the vertices and write an export plugin. So we already have a way of getting all the vertex data that we need. 

    So what do we have currently? We have a system where you can type "./build.py --all" and it will spit out the sprite texture sheet, export a json file representing the modles, and merge some javascript files together. Awesome. After checking out some test frameworks, we can get started on the actual engine (or rather, the math behind the engine).

    Below you can see the sprite-sheet with the face outlines in white (and the physics outline of the ship in red). You may notice the weird color-spectrum: those are baked in blur levels that are useful for making a bloom effect in the meshes fragment shader without needing screen-space post processing.

    theship.png

  14.  

    Originally posted on Troll Purse Dev Blog

    Recently, Troll Purse setup a public invite for the Troll Purse Discord Server. And, as with all things, we decided to test out using Discord Webhooks to push updates to our members in realtime. This is by far the most effective realtime pushing we have conceived yet. It was so easy, sharing it will be just as easy.

    Discord Logo

    Using A Simple Webhook

    Usually, the pattern at Troll Purse to push to third party accounts follows this pattern:

    1. Sign up for the third party account
    2. Register an application
    3. Find an API wrapper library for said third party account
    4. Publish an AWS Lambda
    5. Post about it!

    This time, we decided to skip step 3. For the most part, the developers at Troll Purse recognized that this push would require very little data transformation and authentication routines. In fact, all of the work was done in one POST request to the Troll Purse Discord Server.

    The Code, Kind Human

    public async Task<string> FunctionHandler(SNSEvent input, ILambdaContext context)
    {
        try
        {
            var messageJSONString = input.Records[0]?.Sns.Message;
            context?.Logger.LogLine($"Received({input.Records[0]?.Sns.MessageId}): {messageJSONString}");
            if (messageJSONString != null)
            {
                var messageContent = JsonConvert.DeserializeObject<BlogContentUpdated>(messageJSONString);
                using (var httpClient = new HttpClient())
                {
                    string payload = $"{"content":"{messageContent.PostTitle}. {messageContent.ContentSnippet}... {messageContent.PostLink}"}";
                    var response = await httpClient.PostAsync(Environment.GetEnvironmentVariable("discord_webhook"), new StringContent(payloadEncoding.UTF8, "application/json"));
                    return response.StatusCode.ToString();
                }
            }
            else
            {
                return null;
            }
        }
        catch (Exception e)
        {
            context?.Logger.LogLine("Unable to Discord the SNS message");
            context?.Logger.LogLine(e.Message);
            context?.Logger.LogLine(e.StackTrace);
            return null;
        }
    }
    

    Notes:

    • BlogContentUpdated is code defined in an external Troll Purse binary.
    • WE USE SECURE ENVIRONMENT VARIABLES!!! THIS IS IMPORTANT!!!! (As opposed to plaintext credentials in our source code.)

    The Joy of Lambda

    All of these features that Troll Purse has blogged about are done within a few hours. This is easily aided by the idea of serverless programming. There is no overhead of provisioning servers, testing different server environments, and configuring a network for these functions. It removes a lot of network infrastructure and enables Troll Purse developers to create fast, reactive, internal services.

    Please, if you spend too much time configuring and setting up, try using AWS Lambda to speed up development time.

    Would You Look At That

    In two lines, without a library or API wrapper, our developers can now push blog updates to our Discord server. This is a nice quick feature that we plan on integrating in our automated build environment to push updates about new versions released to the public. Enjoy!

    Originally posted on Troll Purse Dev Blog

  15. I am finally ready to release the first demo for my next game Mine Seeker. I ran into a bunch of issues with gitlab, which I was using to host my code. They did an update and I lost the repo for this game. Thankfully it hasn't been released yet so I was able to create a new repo and migrated the code and issues to the new repo. Then I ran into issues pushing my code up to gitlab. I was unable to resolve that so I made the switch to Perforce. I've never worked with it before so there will be a bit of a learning curve as I go, but I have it set up so I can change files and submit them to the depot. I lost about a week maybe 2 because of this.

    On to a brief overview. The game play is similar to Minesweeper. You have to click tiles and try to avoid clicking on a mine. The first area of 20 levels is available in the demo. I plan 8 more each with an increasing level of difficulty to make it harder as you play. If you click on Quick Play you will be able to choose your difficulty and a game screen will be show. The Quick Play is similar to the original Minesweeper except there is no time or scoring. Clicking on the Play button will load the single player adventure with (eventually) 9 areas of 20 levels each. So far I have 1 area with all 20 levels. 

    main.thumb.png.f4fefb086e40682b5282b7fa4c5de919.png

     

    Choosing the Play button will load the level selector screen. Each area is divided into 2 sections. This shows the second section of the first area so these are levels 11 through 20. The next and previous buttons will take you to the next and previous worlds if available. Click on a blue level button and the game will load. If the button is grey the level has not been unlocked yet. You must complete a level before the next one is unlocked. 

    levels.thumb.png.994dc15d85310b608192d8de7ecdd697.png

     

    Here is a quick look at the game screen. The buttons I think are fairly self explanatory. The score of the game starts at 1000 and decreases over time plus you get 1 point for every tile uncovered. It tells you the number of mines remaining as well as how much time has passed since the game started. 

    game.thumb.png.dd37e2da459dd61890c1c1ac5b62bdf6.png

     

    So because of the git issues I currently only have the windows demo available. I will add the Mac version as soon as I figure out how to get my Mac to connect to my Perforce server to checkout the code. If you have any suggestions, ideas, comments or issues of any kind let me know. You can either comment on this post, email me at support@hunter-gaming.com or contact me through my website. Here is the demo for Windows. You may need C++ or Direct X dependencies but being developers I'm sure you may already have it. I believe it should ask you if you want to install any dependencies you don't have installed already but if you have issues getting it to open let me know.

    MineSeekerWindows-x64.zip

  16. In hopefully the first blog of a (fairly!) regular series I would like to introduce the game I've been working on for a while now.  With a working title of COG, the game is a 3D action adventure game with a Steampunk theme and strong platformer elements.

     

    This is very much an indie project ... the coding of the home grown engine is done by me, the 3D modeling is (largely) done by me, the level design is done by me and ... well you get the idea!  About the only support I'm getting is from my kids who are doing the 'QA' (and who are super critical when something doesn't work!).

    Blog1shot3.jpg.89774e61ea06e98a3090ebe935f93c11.jpg

    So where am I with this project?   The game engine itself is pretty much 'feature complete' and the game playable even if there is still a lot to do in optimising and polishing the different components.  Most of the standard platformer elements (conveyor belts, lifts, moving platforms, spike traps, switches, etc, etc) are already working and available through the level editor with the 'levels' (more accurately map sections) loading on the fly to create a continuous, seamless world.  Basic monster code is already in place with it being pretty easy to add new monster types as needed for the game.  The lighting and particle systems are  currently being reintegrated into the game (the code is complete, but was deactivated while creating the first builds) so hopefully the landscape will soon be full of splashing water and rising steam and smoke (pretty important to have rising steam in a steampunk game!).  

    Blog1shot1.jpg.ed7a1a2aca2b2c6e1384699a6f9ccb42.jpg

    The camera system is nearing completion - it allows the player to have full control of the angle of the camera with objects close to the camera position fading out to improve player visibility (this is the last bit being worked on here with the drawing order of semi-transparent buildings being tightened up and optimised).

    Blog1shot2.jpg.06630cf64387fbdc0b1025434da887e3.jpg

    Looking at the content there is currently some placeholder content being used with the worst offender being the player's character which is currently a (not very steampunk) Kiwi rather than what will eventually be a small robot.  In addition, while the 3D models are almost all self created, the textures used are a mix of those I've created myself, that I've purchased and a handful of temporary placeholder textures.  These placeholders have allowed for rapid prototyping  (especially as creating textures is a slow and painful process for me), but will obviously need to be replaced in the near future.  Fortunately this shouldn't be a huge task as I'm using texture atlases that allow for easy swapping in and out of new textures ... there should be relatively few cases where it may be necessary to tweak the texture mapping.  For information the screenshots and video contain this placeholder content.

    Blog1shot4.jpg.92427aa9302eb331555eceecb050d0ea.jpg

    As a result of all this there is now quite a nice library of 'Lego bricks' available including a range of basic building blocks (platforms, towers, walls, pipes, etc), more exotic props (the already mentioned spike traps, barriers, lifts and switches as wells as the mandatory barrels and movable crates), plants, rocks and other landscape elements.  Finally, there is a series of animated models including waterwheels, steam engine, pistons and so on whose clanking and whirring will helpful give the impression of a living world around the player.

    So things are going pretty well at the moment (especially given the limits on the time I can devote to this) and COG seems to be getting to a stage where it is moving from a process of writing code to one where the current task is to complete the game - a pretty rare thing for me!

    Please let me know you think of the screenshots and video - one of the main reasons for starting this blog is to start getting some feedback to help shape the remainder of the game ... all constructive comments would be very much appreciated.  Also if there is interest in a particular aspect of the game development process I would be happy to share more details in a later blog entry.
     

    Thank you for your time!