Search the Community

Showing results for tags 'DevLog'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Idle Forums
    • Video Gaming
    • Wizard Jam
    • Movies & Television
    • Books
    • Idle Banter
  • Shows
    • Tone Control Episodes
    • Important If True Episodes
    • Idle Thumbs Episodes & Streams
    • Idle Weekend Episodes
    • Three Moves Ahead Episodes
    • Twin Peaks Rewatch Episodes
    • Something True Episodes
    • Idle Book Club Episodes
    • Terminal7 Episodes
    • Designer Notes Episodes
    • Old Shows Home
  • Wizard Jam
  • Babysitter's Club's History of the series
  • wrong club's no


  • Community Calendar







Favorite Games

Found 64 results

  1. [DevLog] NEON Shell

    For a few weeks now I've been working on a full release version of my Wizard Jam 3 game, Rogue Robot Rogues. I'm taking the original game as a prototype for this new version. This will not only be more complex with more enemies and systems but hopefully incorporate multiple levels of play, in order to create a more fulfilling gameplay experience. To go along with this full release I've changed the name and art style to better suit the new direction of the project. In this first dev log I'm going to be introducing the new project and outline the main problems with the current build of Rogue Robot Rogues. NEON Shell is a cyberpunk bullet hell defender in which the player has to construct and control ICE security systems in order to protect the valuable data of their employer from cyber attacks. Most media in the genre is concerned with fighting against the corporations that control cyberpunk society. With NEON Shell however, I want to explore the other side of the coin; placing the player in charge of a corp's security systems, instead of against them. In Rogue Robot Rogues I focused on prototyping the main mode in the game, mainframe defence. In this mode there are data orbs, which act as health points positioned around a turret, or ICE construct. The player needs to take control of the turret in order to protect their data from incoming enemies who are completely invisible. This means that the player either has to guess their location or disable them and their cloaking with an EMP before shooting them. If you haven't yet played Rogue Robot Rogues you can do so here: and if you're interested the dev log for Rogue Robot Rogues can be found here which details my original development process. I explored a number of variations on the basic gameplay loop. Adding in enemies with shields (Shield programs), who are immune to the player's EMP until they are shot. This was intended to reverse the gameplay loop of the basic enemy type (Rogue programs) which the player has to EMP to remove their stealth before shooting them, in order to introduce some variety. This worked well as a start but the game gets quite samey with extended play; clearly more enemy variety is needed. The other main variation I introduced was time limited power ups which were intended to provide a change of pace and to be used as a balancing mechanic to increase average playtime. This worked in essence but the power ups introduced were very limited in their scope, effecting only reload speed (purple), EMP recharge time (yellow) and health (green). In addition, the time limited factor of the power up mechanic only serves to emphasise the lack of power that the player has while not boosted by a power up. To remedy this I'm intending to include a building and upgrade system into NEON Shell which should hopefully even out the power curve of the game into a more steady progression. Lastly, I've also redesigned the art of the game into a more striking, neon inspired style. This change simplifies the visuals of the game and should help to better separate the game elements by only needing to differentiate the basic shape and colour of each element. This new style also, I feel, ties in nicely with the new name and theming of the game, taking inspiration from the neon cityscapes of classic cyberpunk settings like the depiction of Los Angeles in Bladerunner. I've been on a month or so break from the game in order to better define the direction but should be back on track now. I'm planning on hopefully posting to this thread every week or so when I've got something to show throughout development. Thanks for reading! - Sam (@Mythalore)
  2. Hiya folks! I'm Juhani from Sleepy Sentry, a young indie studio from Finland. We're a three-man team, and we've previously published a couple of simple mobile games that we created while studying. In 2016 we took the step to working on the company full time, and started development on a PC game; in many ways the game we wanted to make: Check out our story trailer and/or gameplay trailer! Indiegogo campaign page. Stirring Abyss combines deep ocean exploration, squad strategy and Lovecraft-inspired storytelling. You take charge of the surviving crew of the USS Salem, U.S. Navy submarine that sinks while on a top secret research mission during the early years of the Cold War. They find themselves surrounded by the ruins of a forgotten civilization, their vessel too badly damaged to escape the depths. Some things we're especially proud of include: Our beautiful underwater environments, in a classic 2d isometric perspective. Varied strategic combat. Diverse character traits and skills, as well as gruesome mutations unlocked during the game. Unsettling and fully original soundtrack. Interactive and chilling story with truly meaningful choices. Some pre-alpha screenshots: I'll be posting updates here as we go, although since it's manual work it may take a moment after stuff gets posted on our blog and social media. If you have any questions I'd love to answer them, and at this point any feedback is welcome but I imagine there will be more opportunity for that as we can actually show more of the game. Feature Spotlights: Spineskulker "Darkness and silence hang upon the abyss like a funeral cloth, but what truly terrifies me is that this place is not lifeless. It is asleep, and something stirs in the gloom..."
  3. DEVLOG - Pilule

    I have a working game and don't honestly know where to go from here. The game is a relaxed real time strategy game. No conquering armies or bloodthirsty soldiers. You are the CEO of a drug company and must expand. What makes the game unique, I hope, is that you play with your mobile phone on your computer. You can have multiplayer with one screen, as long as everybody has a phone. It can be cooperative or competitive, or both. The game is working as I stated, but it needs a hell lot of testing and tweeking, and everything (I am thinking about remaking it from scratch, so for the DEVLOG). I am interested in first impressions and advices. You can visit my website to know more. Thank you.
  4. Update: This project is abandoned for now, I keep having to do more important things this week, I probably won't be able to finish anything this time around. ----------------------------- Hey wizard jams! After throwing out several hopelessly overambitious ideas I've decided to make another surreal walking-simulator/vignette thing. (I made Zombie Train last jam, the 3D one.) The title is derived from the episode "Cool Blob Future" and the recurring robot-news discussions of the podcast. I've been exploring this idea of robots with a big screen for a face that I can display things on: Diversifiers: Wizard Jam Shared Cinematic Universe Building A Legacy (There will be Dot Gobbler) Box art Nice Segue
  5. [DevLog] EverEnding

    Hi. I've been working on a game called EverEnding for like five years now, give or take. Most of this time has been taken by developing the base code for the game alongside the editors necessary for developing its content -- the room editor (tile data), map editor (arrangements of rooms), entity editor (all interactive data in a room), and detail editor (all non-interactive data in a room). This may have been a bit of an ass-backwards way to work -- I am still a while away from having a vertical slice -- but I did things the best way I could figure by myself. I've realized that's a problem though. Doing things by myself is an extremely inefficient way of doing things. And I'm not talking about getting other people to work on the game, which I couldn't afford to hire for and wouldn't feel comfortable asking people to volunteer for, but being willing to open up my process in a way that lets me give and receive advice and generally participate in a development community outside of my own brain. But I digress. Let's talk about the game. EverEnding is a story-focused 2d platformer, somewhat in the vein of Cave Story. I don't want to give everything away, since a big part of the game will be discovering what's going on as you go, but it takes place in a surreal post-apocalyptic setting. The player controls some sort of angelic character named Eve (the original title of the game, which I changed for reasons both numerous and obvious), tasked with collecting all of the stray souls left behind after the end of the world. Many of these are just lost, but as the game progresses those who remain become increasingly warped and malignant. The project is being developed in Haxe and compiled to AIR. This is subject to change, as one of the reasons I chose to switch to Haxe from AS3 was the flexibility in compile target, but for now AIR is suitable to my needs and from my brief experimentation with OpenFL (an open-source project that mimics the behavior of Flash's built-in classes) I would have to completely rewrite the rendering code to match or improve upon the current AIR performance. I'm targeting a 960x540 resolution with the intent that it will look nicely crunchily pixely at standard 1920x1080 resolution, and though I have no particular restrictions in the art pipeline I am attempting to minimalize the color palette within each asset. The hope is to capture the restrained abstraction of pixel art without hewing too closely to any particular era of retro gaming. As will become obvious, I'm not shying away from using certain non-retro effects, such as transparencies and blending layers, but want to maintain the tooth and style of the pixel while I do so. This is Eve, and one of the few pieces of concept art I've made and which I made four years ago: And here's a little look at what the project looks like right now: Here's a little bit of music that is probably going to be in the game: Falling Angel The current state of the project is that most of the basic programming is done and I'm working on getting some good art assets made for the game: Final character animations, final tile sets, and soon extra details and particle effects. Once this stuff gets a bit further along I'll be making the enemy entities, which all the groundwork is laid for (including pathfinding, a notably tricky challenge) but which still need a lot of work to be finalized. Once the character animations, tilesets, details, and enemies are done, I'll have everything I need to construct the first chapter of the game -- well, everything except for some special effects programming and the first boss, which I expect to be a task beyond the scope of the enemy entities, who will hopefully be old-hat by then. I'd say realistically that's probably a goal I can aim to achieve by the end of next year, if everything goes very smoothly. I've been posting regular progress DevBlogs on my blog for the last four years or so, and am now going to start mirror-posting them in this thread as well. Thanks for taking the time to check my project out!
  6. [Dev Log] Rogue Robot Rogues

    Hi all, I'm going to be working on updating my Wizard Jam game, Rogue Robot Rogues. The plan is to get it to a somewhat final version ready for exhibiting to EGX in September, so as part of this I'm going to be releasing regular updates building up to the leftfield submission at the end of the month and then after that until the conference. So without further ado here is the first update. Rogue Robot Rogues, Version 4.1 - Health Up The main focus of this new version is a power up system. The power ups have a chance to be dropped by shielded enemies, after which they need to be shot and then they will activate an effect. Currently there's only one power up, a health drop which gives back one data orb when collected. The idea with this system is to add longevity to each run of the game, so it's not just entirely downhill from the first loss of an orb. I've got plans for two other power ups at the moment that I'll be working on over the next week. Link: Wizard Jam Post:
  7. Rogue robotic ninjas from a rival company are trying to steal the data on your company's mainframe. You are the mainframe's automated defence system, and its last hope... I had my last exam for the year on Monday and after that I didn't really feel like continuing with my first wizard jam game. However, after seeing the title for yesterday's Idle Thumbs, I had this idea and now I can't stop thinking about it so I'm going to see what I can get done. In the game you play as a turret fighting off robotic ninjas armed with cloaking devices, which renders them completely invisible, so you have to use an EMP to disable them in order to reveal their locations. I started development yesterday, so far I've got the turret in along with bullets and the EMP wave, next I'm going to work on the enemies.
  8. Hi all! Me and a bunch of friends including Zerofiftyone* are making Frozen Fracas, a homage to the ice level gamemode from Crash Bash. For those of you unfamiliar with Crash Bash at all, the basic premise of this game is: you are a seal. four players. stay on the ice. push your opponents off the ice. We're planning to add various power-ups, and an AI Orca that swims underneath the ice, occasionally tipping it / bashing into it etc. Movement code is going well: * you might notice he is doing two games this jam, because he's daft.
  9. Get It Here Fellow Readers and Jammers: We are on our way to creating the next exciting entry in the qwop-a-lunk-a-like genre. You control a human, who is controlling their own thumbs, which are controlling Santa, in the form of a mobile game. Santa must navigate chimneys whilst continuously eating cookies to sustain his own impossibly rapid metabolism lest he perish. Please to enjoy this artist's rendition of the primary game screen in action*. *Actions and screens may or may not contain placeholder assets borrowed from a team of diverse websites.
  10. [RELEASE] Button Frenzy

    Hey folks. I've been meaning to write one of these threads for a little while so here goes. I'm making a game inspired by the gameplay loop of old-school Simon toys, and the universal ritual of inputting video game cheat codes using a controller. It's a fast-paced score-attack game whereby the player has to watch a randomly generated button sequence and then repeat it under a strict time limit. Enter in sequences quickly and you'll score more points and rack up a score multiplier. As the game continues it gets faster and more difficult. Think WarioWare in terms of basic structure and pace, and you're not too far off. Diversifiers used: "It's a Baby Game" Super Briefly UPDATE Play it here: Another update: This game is now on Steam Greenlight! I decided to keep working on it and make it into a full thing. I just launched the Greenlight page a few minutes ago and I'm pretty terrified! The page is here, if you're interested:
  11. [DevLog] Honeycomb

    This started off a bit of a silly project. There wasn't really much "game" to this, it originally started as experimenting with Graphics2D in Java. That's the new beta release, with all the updates listed below and on that page. Milestones ALPHA (DONE) :: The initial goal was something simple, get a renderer on its own thread running the game graphics. Add a game state for each render group; pre-game, ingame, end-game, etc. Mess about with KeyListeners and the like, develop a system to delegate them down to the data model. At this point I was just testing it by adding fun spinning 2D shapes that spin. Let's make it so you can click on them too! As the game idea formed in my head, I added a variable lifetime to each shape so they "die" eventually. BETA (IN-PROGRESS) :: Make the UI not terrible. (DONE) Make the ingame art not terrible. (DONE?) Build a graphical font system! (DONE) Add a tiny amount of balance to the gameplay. Clicks give more points than dragging. (DONE) Add bigger shapes that have unique effects (for <good marketing> and <player retention> ). Add a countdown to game start. Add more art, a friend suggested bees. OH GOD THE BEES. RELEASE :: Polish? Performance pass (game is quite CPU-bound, fixed step renderer struggles on low-clocked CPUs) Java Stuff I'm not here to blow any minds, really. My next developer (b)log will probably be more around the art side of things, building interfaces, practising complicated pixel art scenes, and so on. I've got a lot of that I need to do to build a working game with some of the tech I have. The developer intent behind this was to explore the Graphics2D API, and to push my knowledge with that forwards. I'm pretty adept in building data-driven systems (my day job is web services over Tomcat, etc, and many other bits and pieces) and I've done enough work with the javax.Swing library to never make me want to do any more work in Swing (you only need a few hours in this to put you off for life, but I've managed a few years). Will probably add more posts to this with the details of some of my nicer (?!) classes. Art Stuff I mainly do pixel graphics; I don't have a tablet nor do I have the time to justify that kinda purchase. Pixel art I can do on my phone (found a great app for it) and I can practise it well enough when bored at my home PC. I don't always expect it to be great, but it matches up well with simple geometry, so why the hell not?
  12. [DevLog] Laika

    Hello Thumbs, this is my first log about an Android game I'm making. As in, I'm making it in Android Studio. The game is mostly an interactive fiction game about being a solo human traveling through space to seek out life. You pilot a ship with a dog your only companion, hence the working title being Laika. But that's all you need to know about the premise for now (and it's subject to change). This first post is going to be about how I'm setting up a system to randomly generate planets. A significant part of this game will involve randomisation, including the planet sprites. The game will be made with pixel art, as I think it can work as a naive space look. Since it's an Android app, I'm concerned about making the generation overly heavy on resources, as well as trying to avoid an approach that will involve storing tons of pictures on someone's phone. At the end of the game I intend to save a big chart of all the visited planets, so it's important to be able to recreate all the previously visited places. Since undirected random generation without any sense is a mess, I decided on a pretty simple approach. Each planet is comprised of a palette which contains 2-4 colour values. Then some pre-drawn sprites are coloured to match the palette and layered on top of each other. There's a set of specific base images that will always form the bottom layer of the image, and then each base has a corresponding set of textures to randomly choose from. I could technically make textures base agnostic, but I think that would be harder to do and lack a satisfying degree of specificity. The process, in simple terms is: One of the palettes is randomly chosen. A base is randomly chosen and coloured to match the first colour of the palette. Textures matching the base's size are chosen and coloured one by one until there's a layer for each colour in the palette. This essentially leaves me with a set of images that can then be layered into one picture, creating a planet. Here's some examples: Of course, there's immediately one big issue with this approach. When randomly combining assets it's harder to determine if one of them is bad or ill fitting. How can I quality control the palettes, bases and textures that I'm plugging into my generator? I thought of a pretty simple way to manage this and it's essentially tindr, but for planets. I set up a simple screen with , and buttons. I quickly evaluate the overall quality of a sprite and click the corresponding button to say if it's bad, acceptable or good. That button will then accordingly affect the 'score' of every asset used in the current planet. The idea is that bad assets will recurringly show up in bad looking planets, and a negative aggregate score will indicate that I should remove it, and more importantly look at why it might have been a bad one to include, to avoid making the same mistake on future assets. Likewise I can look at overall trends that seem to be going poorly. So even if there isn't a specific bad one, maybe I can detect that 4 colour palettes all have poor scores and there may be a problem there. Here's how the basic gif gist of how this process looks: spoilered for size) Also here's a still of a brief results screen: It's early, and I have quite few assets actually in the mix so there's obvious repeating already. But it does seem to be indicating that a 4 colour palette is overdoing it with the way I've been approaching textures. So maybe I stick to only 2/3 colour palettes? Or maybe my colours are just a hot mess (they are). Whatever the problem, I have a good feedback loop to plug in a bunch of assets and test them. Instead of humming and hawing, I can get a clear set of results from a quick simple blast through a ton of generated planets. That's all for now, next I'm hoping to work on directing the look and feel of this hot mess into a cool mess. That means whipping random assets into shape as well as the style of the UI elements and how you actually interact with the game.
  13. [DevLog] Cwine!

    So.. I started redoing the code for my Public Domain Jam, an interactive comic called Die Sieben Raben (still available here, but dreadfully slow to load) (it's responsive and all!) But it wouldn't be fun to just make a more efficient runtime code for this and call it a day, I'm also making a messily coded, probably inefficient, visual editor for making similar comics. I'm dreadful at naming things, so it's just called Cwine* for now. The editor runs on the web server along with the runtime, just because it felt like a natural choice. That means I'm messing about with lots of EaselJS and shit, which I've never done before. Saving to a JSON file also took me ages to figure out. But, I now have a simple node setup. Just the panels with speech bubbles for now. Black lines are for when a panel automatically shows a new panel, white dotted lines for when a choice is to be made. It's all hugely messy, but the code is up on github albeit a few days old. My hope is I can get a functional version of this editor finished before the Big Winter Wizard Jam of Jollies, so I can make a new interactive comic for that! TO DO's Get that property panel actually working; It is currently not working meaning I can not change any properties (except the position of the speech bubbles and how the panels are linked up) Load images from the /img folder, so you can drag and drop new panels in. I broke the saving to JSON file, but HOW HARD CAN THAT BE TO FIX RITE?! More nodes besides panels (e.g. Random, Condition, etc.) Make a comic about toblix *Comic Twine
  14. I had an idea on the train this morning as I was relistening to this week's podcast. I think I want to make Jake's suggested interpretation of "I Like the Hair" as a joke minigame. Basically it'd be a game in which you're presented various portraits and asked if you like the hair or not. And I thought it might be even better if the game featured pics of folks from the Thumbs community. What do you all think? Is this a good idea? If people are prepared to do this I'll set up some kind of webform for submitting your pics. Edit: Alright, I've put up a quick webform for picture submissions. Here it is: If you want your beautiful mug to appear in a video game about hair, send me a picture! I guess it's worth saying just for clarity that I won't be distributing any of these pictures to anyone or using them for anything other than this. THANKS GUYS Edit #2: This game is done and you can play it! It's accessible via a cheat code in my other game, Shoot That Pizza. In the main menu, type in the secret code "puffin"!