Jump to content
  • Advertisement

Leaderboard

The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 01/05/19 in all areas

  1. 3 points
    Why hello there, and happy new year! I feel like 2019 is gonna one of those years where change is imminent, and let's just hope it's not a bad change but rather a pleasant one. With the new year comes a new schedule. I've decided to write the Weekly Updates (and consequently ends sprints) on Saturday from now on. This way I can synchronize all of my updates. But anyways, I've also decided to take a 2-week hiatus, hence the radio silence for the last weeks. It was a nice well-needed break and I feel overall revigorated and well rested from it all. With that said, I have a whole lot to talk about, so without further ados, let's get right to it! Minimaps Markers First, there's been a significant upgrade to minimaps. Now the minimap can display the position of collectables items, interactable props and other notable landmarks. Each point has their own type of minimap markers so players can easily locate any collectable items they missed. Each marker is also kept straight no matter the map's orientation, giving them the appearance of some kind of GTA-like map markers. Mainly an aesthetic choice but I like it like that anyways. Quite handy if I say so myself. Stores, Stores, STORES! Another upgrade worth mentioning is that I've revamped the level generation code so that the appearance of malls won't depend on the player's luck anymore. This means that it's the seed that decides malls position. This effectively means that during normal gameplay players can still encounter shops no matter if they're lucky or not. Aside from that there's also been a significant upgrade in special rooms constraints. Now special rooms are more likely to spawn due to less strict constraints. Overall this means a more seasoned level, of which the game is in dire need of. Rests areas Second, I've decided to add a new type of interactable props: the rest area. These are actually modelled after rest area found in most shopping centers and malls. (because of aesthetics) The player can actually use these to rest and restore some of their health. Each rest areas can only be used once, as the player actually "trashes" it when they use it. However, there's a catch: every enemy also gains their health back. This means that players have to be careful when using these, especially if they're facing a boss. Rest areas only spawn in regular rooms if the player is lucky, and there's only one rest area per rooms. There are two types of rest area: a common one and a rare one. Common rest areas This common rest area only heals 50% of health to any active entities Rare rest areas This is the rarest variety of rest areas. It fully heals any active entities Bosses Range Attacks Previously I've talked about how bosses were in, and now I've enabled that boss the ability to do range attacks. The way it works as of right now is similar to a melee attack, but it also produces some kind of "shockwave" that moves towards the enemy. A skilled player can actually try to either jump over it or simply avoid it altogether. Bosses choose to do range attacks whenever their target is far enough, otherwise, they'll either try to get closer or do a melee attack depending on its distance with its target. Item agglomeration Third, let's talk about items in general. I've previously said that I've started to do playtesting among my closest friends and family, and have been taking notes on some matters here and there. One of the most noticeable things was the fact that most players disliked walking around the room to try to collect most items that were either drop as loot or from a treasure box, especially if it was money. So, after thinking about it I've decided to implement an item agglomeration mechanics where collectable items can "fuse" together, much like how it's made in Minecraft. Each item agglomeration has some kind of "notification pill" on the top right corner telling how many items it has inside. If two items that can agglomerate together are near enough from each other, then a magnetic force will pull each item towards each other, creating some kind of magnetic/gravitational forcefield. Most aglomerated items will also have different sizes based on the amount of agglomerated items. Larger agglomerations mean larger sizes and vice versa. The item's mass also gets bigger and bigger the more items it has. There's also a limit on how big an item agglomeration can be. If the limit is reached then another agglomerated item is created. Item agglomerations that are full won't agglomerate anymore, and there won't be any pull forces applied to them. When the player grabs an item agglomeration, then they get the specified amount of items. With this, it was significantly easier and less time to consume to collect every item, as they now group themselves together. It's also quite mesmerizing to see items get pull towards each other. Right now only money, keys and bombs can agglomerate, but I'm sure there's gonna be a whole lot more different type of agglomerate items in the future. Minor updates I've decided to nerf the bow by removing the ability to the bow to induce knockback. Fixed bugs with items orientation when placed on their pedestal There are now many more different distinct types of notification, each with their own designs and colours Added a "box breaking" effect that shows the "health" of breakable boxes I'm still working on it though. It seems that I'm not really satisfied with it, to begin with... Consequently, I've also fixed some bad geometries on the breakable box model here and there too. Added a velvet-ish shader for some types of props that are made of cloth or similar substances I've decided to balance movement speed a bit. After a series of playtesting that shows that the player moved too fast. It was a wonderful thing to do. Now the speed seems more reasonable and manageable. Changed how much damages bombs do (slight buff). I've also changed the actual damage distribution. It is now a linear one (might change it in the future though). This means the closest an entity is to the bomb the more damage it gets Same thing with the explosive force Next Week Next week will be a really hard one. With all that free time of mine during countless car trips and what not I decided that some brainstorming was in order (especially with all that playtesting. It's really eye-opening and all) One crucial idea I had was to diversify the room's landscape a bit. I hope that with that it's gonna make the game a wee bit more exciting and captivating. Technically this is currently in WiP and that's why some of the pictures taken may have holes here and there. I'm currently working on an algorithm that will enable me to have varied types of grounds (like grassed, iced or even chasms). I'm currently working on it and it would probably be the main theme of next weeks' sprint. Aside from that, there's also the idea of adding many more enemy types and perhaps more weapons and even more balancing. There are also other relics, activated items and perhaps pieces of equipment to add. In other words, there's no shortage of work to be done!
  2. 2 points
    Needless to say, i made a lot of research on best time and best ways to launch the campaign. Here’s the graph from medium.com on Kickstarter campaigns from 2014. Kickstarter campaign success per monthObviously, i missed the train for December, which is one of the best months for launching the campaign. It makes sense, people spend more money in the holiday season and they’re a bit dry in the following month, which is January, and the worst month for crowdfunding campaigns. I don’t have time to wait for March, which is the next decent month before summer, so i suppose i’ll be biting the bullet, launching in mid January, maybe beginning of February and hoping for the best. Project duration is a typical 30 days. It’s silly to make it last shorter than that since i don’t have a lot of visibility anyway, but lasting longer is also not an option. Why? Psychology is a strange science, shorter durations increase a sense of urgency in people and may help them decide earlier so they don’t miss the deadline. I believe i shouldn’t press myself to launch as fast as possible, but once the wheels start turning when you press that big pre-launch button, there’s no going back and you should work on making as much people as possible subscribing for the regular e-mails that will lead to the official launch and the notification of the launch itself. They say that the conversion rate from the subscribers is a mere 5%, so if everyone leaves a basic pledge of 10 USD, i need about 6000 subscribers if i want to be sure i will reach my goal. I don’t think i’ll manage that big of a number, but i’ll keep tracking the numbers and when the number of daily subscribes start falling down, i’ll announce the campaign start. So far, i collected 24 e-mails in a few days, which is a number i’m quite happy with to be honest, considering the scope of the project and the type of the game i’m making – a niche arcade shooter. But, to be realistic, that’s not nearly enough, especially when you take the conversion rate into account. When you’re having a project like this, it’s quite natural to pay attention to even the smallest details. That said, even the time of the day when you launch the campaign is of utter importance. In my case, that will be 7 o’clock in the morning, which is just the time people get back from lunch on the east coast in the United States, which account for the largest crowdfunding contributor in the world. You get back from lunch, and before you get back to work, you decide to check IndieGoGo a bit if there’s something interesting, and there it is – just launched! Wednesday also looks like a promising day. On monday, people are in a grumpy mood and they need to get to speed to work, not much time for stuff like this so it’s a big no-no. Tuesday’s better, but not as good, and Thursday is too far off, you are usually starting to wind down and think about the weekend. So Wednesday it will be. One of the most discouraging facts from the Kickstarter statistics is that two thirds of the campaigns fail miserably. I try not to think about it too much. Maybe their goals were to far off? Maybe their campaign was lousy? To be honest, there’s a lot of campaigns out there looking for much too money for what they’re offering or having a campaign that’s written poorly. Asking for too much money is one of the main issues people tend to overlook. It’s better to ask for a smaller amount since people will pledge for something that seems achievable, fair and has constant income of pledges. If you’re on a train that’s going to be hard to catch – nobody will want to ride it. The funny thing is – when you fund the project, even more and more pledges will usually start coming. People want to give their pledge to something that already succeeded and they know they’ll get the product they pledged for. First 48 hours of the campaign are crucial on IndieGoGo, since the campaign will only appear in search results for the first 48 hours after launch. After that, you need to have at least two pledges to keep it searchable. Not only that, they recommend that you already have 30% of the funds needed secured and pledged in the 48 hours of the campaign, which, in my case, is 1.000 USD. It’s big bucks for me, and i don’t think i’ll be able to provide this via friends, family and so on. Where i live, it’s 3 monthly wages so i think it’s better that i prepare that demo for launch so i gain more traction and attract more people. So, the thing i need to do is to step up on gaining subscribers by regularly posting the progress, work on the demo and shout everywhere. Here’s the list of the stuff i did lately: I opened the account on itch.io, but the game is not showing up in search since there’s no downloadable content. There was a small surge of visitors from Twitter on the day i listed the game, but since then no views at all, only one follower and that’s it. I opened the accound on GameJolt (few moments ago), the game is also invisible there, so i don’t expect anything. I posted a teaser on r/shmups on reddit, there’s only few likes and that’s it. It’s a small subreddit, so i plan on posting the teaser and some text on few other subreddits like gamedev, indiedev, and unity2d. I posted a devlog with teaser on tigsource, hutonggames (makers of Playmaker which i use), shmups.system11 forum, there has been no significant response. Obviously, the way to increase visibility is to publish a demo which will be downloadable on itch, gamejolt and steam (when i make the profile) and then we’ll see how it goes. Launching the campaign now would fail 100%. So, off to make the demo! Posts View the full article
  3. 1 point
  4. 1 point
    Just the other day I was thinking about you and your game wondering why I hadn't seen any updates in awhile. Good to see you're well rested and back at it. Those mini-maps look great btw.
  5. 1 point
    @a light breeze That was just a picture I snipped off my desktop. Here's the finished product Thanks for informing me that it's hard to look at... I bdly wanted orange because it's supposed to be an emergency tent, but that won't work with my background will it?
  6. 1 point
    I'm excited and nervous for you. Keep us updated and best of luck.
  7. 1 point
    I like the explosive snowballs. Very nice!
  8. 1 point
    Look what I can do! Look what I can do! (Imagine some explosion sfx) Oh this is wicked fun! They don't do any "damage" as yet(nothing does actually..hmm..), but they cause some serious chaos, especially during races. And propulsion, I'm getting pretty good at moving some distance just using the flip and explode maneuver, especially with airBoost! hahaha!! They are kinda touchy too, so go blow yourself up! and Live in v0.3.6 try out the latest new game mechanic, explosive snowballs, for yourself right here: https://www.kongregate.com/games/WilliamOlyOlson/slingbot-boarding Also in this build I've improved my ground detection method a bit so I'm back to using just the one (set of split ground mesh objects). I was previously using these for the visual meshes only and a full undivided mesh for the collider as that would allow seamless physics interaction with the ground without adjusting my code.. lol. I'm now just simply ignoring raycast attempts that don't return anything.. Duh!.. and it seems to be mostly working so far.. Easy enough for now and saves me almost 30mb in the final build! So, smaller build(quicker load time), exploding snowballs, first run at the explosion sounds(just a mix of cco specials for now).. Let me know what ya think! P.S. My audio setup is crap, so let me know if something sounds way terrible...
  9. 1 point
    Been working on my project for the Dungeon Crawler challenge for about a week now. I think I'm fairly happy with the maze generation I have. I'm using the Accidental Noise Library to basically generate some initial chambers to a tile map. Then I iterate through the map, flood fill any open chambers with an ID value, decide a Hotpoint for the chamber (the middle'th(?) tile that gets filled) , and then try to connect each chamber's Hotpoint to the next nearest chamber's Hotpoint. Using another flood fill, I check if I've connected every chamber sufficiently. If not, start again. From another project, I've moved over all the classes I need to get a humanoid instanced. I'm able to move him around the maze, colliding into walls accordingly. Only thing is though, the way my "walls" have their edging done you can't have it so that an actor is peeking over walls drawn on the south edges. Actors just end up standing on the edging spoiling the look of the wall. I could adjust my collisions so that actors don't stand on those edges, but the reminder and temptation is just too great to spend a bunch of time trying to make it so you can look over the edge of the south walls. So I instead I went with reversing my edging so it looks as though the player is walking on a raised path instead like you're walking on a path surrounded by something lethal. Not sure what that something will be just yet, if I decide at all, but I'm satisfied with it the way it is. So for screenshot here, your character would be walking on the grey part. The green I was thinking might be swamp or like sewer water or maybe I figure on a different setting yet. The character's clothes all come out pink at the moment and I'm not sure whether a trench-coat will be part a potential piece of equipment or not but it gives a bit of an indication of where things are. Lots of ideas for things I want to add but it'd probably be a good idea if I can get myself onto implementing fighting enemies as soon as possible. I'm still not sure just what combat will involve or look like.
  10. 1 point
    Inspiration The game Objects in Space has been demoing their game at shows such as PAX with a giant space-ship cockpit controller, complete with light-up buttons, analog gauges, LED status indicators, switches, etc... It adds a lot to the immersion when playing the game: They have an Arduino tutorial over on their site, and a description of a communication protocol for these kinds of controllers. I want to do the same thing for my game 😁 For this example, I'm going to spend ~$40 to add some nice, big, heavy switches to my sim-racing cockpit. The main cost involved is actually these switches themselves -- using simple switches/buttons could halve the price! They're real hardware designed to withstand 240W of power, and I'll only be putting 0.03W or so through them. Also, as a word of warning, I am a cheapskate, so I'm linking to the cheap Chinese website where I buy lots of components / tools. One of the downsides of buying components on the cheap is that they often don't come with any documentation, so I'll deal with that issue below, too Main components Arduino Mega2560 - $9 Racing ignition switch panel - $26 A pile of jump wire (male to male, male to female, etc...) - $2 + + Recommended Tools A soldering iron (a good one is worth it, but a cheap one from your hardware store will do) Solder (60/40 lead rosin core is easy to work with, though bad for the environment...) Heat shrink (and a hot air gun, hair dryer, or cigarette lighter) or electrical tape A hot glue gun (and glue sticks), or some epoxy resin A multimeter Wire cutters / stripper, or a pair of scissors if you're cheap. Software Arduino IDE for programming the main Arduino CPU For making a controller that appears as a real hardware USB gamepad/joystick: FLIP for flashing new firmware onto the Arduino's USB controller The arduino-usb library on github For making a controller that your game talks to directly (or appears as a virtual USB gamepad/joystick😞 My ois_protocol library on github The vJoy driver, if you want to use it as a virtual USB gamepad/joystick. Disclaimer I took electronics in high school and learned how to use a soldering iron, and that you should connected red wires to red wires, and black wires to black wires... Volts, amps and resistance have an equation that relates them? That's about the extent of my formal electronics education This has been a learning project for me, so there may be bad advice or mistakes in here! Please post in the comments. Part 1, making the thing! Dealing with undocumented switches... As mentioned above, I'm buying cheap parts from a low-margin retailer, so my first job is figuring out how these switches/buttons work. A simple two-connector button/switch The button is easy, as it doesn't have any LEDs in it and just has two connectors. Switch the multimeter to continuity mode ( ) and touch one probe to each of the connectors -- the screen will display OL (open loop), meaning there is no connection between the two probes. Then push the button down while the probes are still touching the connectors -- the screen will display something like 0.1Ω and the multimeter will start beeping (indicating there is now a very low resistance connection between the probes -- a closed circuit). Now we know that when the button is pressed, it's a closed circuit, and otherwise it's an open circuit. Or diagrammatically, just a simple switch: Connecting a switch to the Arduino Find two pins on the Arduino board, one labelled GND, and one labelled "2" (or any other arbitrary number -- these are general purpose IO pins that we can control from software). If we connect our switch like this and then tell the Arduino to configure pin "2" to be an INPUT pin, we get the circuit on the left (below). When the button is pressed, pin 2 will be directly connected to ground / 0V, and when not pressed, pin 2 will not be connected to anything. This state (not connected to anything) is called "floating", and unfortunately it's not a very good state for our purposes. When we read from the pin in our software (with digitalRead(2)) we will get LOW if the pin is grounded, and an unpredictable result of either LOW or HIGH if the pin is in the floating state! To fix this, we can configure the pin to be in the INPUT_PULLUP mode, which connects a resistor inside the processor and produces the circuit on the right. In this circuit, when the switch is open, our pin 2 has a path to +5V, so will reliably read HIGH when tested. When the switch is closed, the pin still has that high-resistance path to +5V, but also has a no-resistance path to ground / 0V, which "wins", causing the pin to read LOW. This might feel a little backwards to software developers -- pushing a button causes it to read false / LOW, and when not pressed it reads true / HIGH We could do the opposite, but the processor only has in-built pull-up resistors and no in-built pull-down resistors, so we'll stick with this model. The simplest Arduino program that reads this switch and tells your PC what state it's in looks something like below. You can click the upload button in the Arduino IDE and then open the Serial Monitor (in the Tools menu) to see the results. void setup() { Serial.begin(9600); pinMode(2, INPUT_PULLUP); } void loop() { int state = digitalRead(pin); Serial.println( state == HIGH ? "Released" : "Pressed" ); delay(100);//artifically reduce the loop rate so the output is at a human readable rate... } More semi-documented switches... An LED switch with three connectors The main switches on my panel thankfully have some markings on the side labeling the three connectors: I'm still not 100% certain how it works though, so again, we get out the multimeter in continuity mode and touch all the pairs of connectors with the switch both on and off... however, this time, the multimeter doesn't beep at all when we put the probes on [GND] and [+] with the switch "on"! The only configuration where the multimeter beeps (detects continuity) is when the switch is "on" and the probes are on [+] and [lamp]. The LED within the switch will block the continuity measurement, so from the above test, we can guess that the LED is connected directly to the [GND] connector, and not the [+] or [lamp] connectors. Next, we can put the multimeter onto diode testing mode ( symbol) and test the pairs of connectors again - but this time polarity matters (red vs black probe). Now, when we put the red probe on [lamp] and the black probe on [GND], the LED lights up and the multimeter reads 2.25V. This is the forward voltage of the diode, or the minimum voltage required to make it light up. Regardless of switch position, 2.25V from [lamp] to [GND] causes the LED to come on. When we put the red probe on [+] and the black probe on [GND] the LED only comes on if the switch is also on. From these readings, we can guess that the internals of this switch looks something like below, reproducing our observations: [+] and [lamp] short circuit when the switch is on / closed. A positive voltage from [lamp] to [GND] always illuminates the LED. A positive voltage from [+] to [GND] illuminates the LED only when the switch is on / closed. Honestly the presence of the resistor in there is a bit of a guess. LED's need to be paired with an appropriate resistor to limit the current fed into them, or they'll burn out. Mine haven't burned out, seem to be working correctly, and I found a forum post on the seller's website saying there was an appropriate resistor installed for 12V usage, so this saves me the hassle of trying to guess/calculate the appropriate resistor to use here Connecting this switch to the Arduino The simplest way to use this on the Arduino is to ignore the [lamp] connector, connect [GND] to GND on the Arduino, and connect [+] to one of the Arduino's numbered pins, e.g. pin 3. If we set pin 3 up as INPUT_PULLUP (as with the previous button) then we'll end up with the result below. The top left shows the value that we will recieve with "digitalRead(3)" in our Arduino code. When the switch is on/closed, we read LOW and the LED will illuminate! To use this kind of switch in this configuration you can use the same Arduino code as in the button example. Problems with this solution Connected to the Arduino, the full circuit looks like: Here, we can see though, that when the switch is closed, instead of there being quite a small current-limiting resistor in front of the LED (I'm guessing 100Ω here), there is also the 20kΩ pullup resistor which will further reduce the amount of current that can flow through the LED. This means that while this circuit works, the LED will not be very bright. Another downside with this circuit is we don't have programmatic control over the LED - it's on when the switch is on, and off when the switch is off. We can see what happens if we connect the [lamp] connector to either 0V or +5V below. When [lamp] is connected to 0V, the LED is permanently off (regardless of switch position), and the Arduino position sensing still behaves. This gives us a nice way of programatically disabling the LED if we want to! When [lamp] is connected to +5V, the LED is permanently on (regardless of switch position), however, the Arduino position sensing is broken - our pin will always read HIGH Connecting this switch to the Arduino properly We can overcome the limitations described about (low current / LED intensity, and no LED programmatic control) by writing a bit more software! To resolve the conflict between being able to control the LED and our position sensing getting broken by LED control, we can time-slice the two -- i.e. temporarily turn off the LED when reading the sensor pin (#3). First, connect the [lamp] pin to another general purpose Arduino pin, e.g. 4, so we can control the lamp. To make a program that reads the switch position reliably and also controls the LED (we'll make it blink here) we just have to be sure to turn the LED off before reading the switch state. Hopefully the LED will only be disabled for a fraction of a millisecond, so it shouldn't be a noticeable flicker: int pinSwitch = 3; int pinLed = 4; void setup() { //connect to the PC Serial.begin(9600); //connect our switch's [+] connector to a digital sensor, and to +5V through a large resistor pinMode(pinSwitch, INPUT_PULLUP); //connect our switch's [lamp] connector to 0V or +5V directly pinMode(pinLed, OUTPUT); } void loop() { int lampOn = (millis()>>8)&1;//make a variable that alternates between 0 and 1 over time digitalWrite(pinLed, LOW);//connect our [lamp] to +0V so the read is clean int state = digitalRead(pinSwitch); if( lampOn ) digitalWrite(pinLed, HIGH);//connect our [lamp] to +5V Serial.println(state);//report the switch state to the PC } On the Arduino Mega, pins 2-13 and 44-46 can use the analogWrite function, which doesn't actually produce voltages between 0V and +5V, but approximates them with a square wave. You can use this to control the brightness of your LED if you like! This code will make the light pulse from off to on instead of just blinking: void loop() { int lampState = (millis()>>1)&0xFF;//make a variable that alternates between 0 and 255 over time digitalWrite(pinLed, LOW);//connect our [lamp] to +0V so the read is clean int state = digitalRead(pinSwitch); if( lampState > 0 ) analogWrite(pinLed, lampState); } Assembly tips This post is already big enough so I won't add a soldering tutorial on top, I'll leave that to google! However, some basic tips: When joining wires to large metal connectors, do make sure that your iron is hot first, and take a moment to also heat up the metal connector too. The point of soldering is to form a permanent bond by creating an alloy, but if only one part of the connection is hot, you can easily end up with a "cold joint", which superficially looks like a connection, but hasn't actually bonded. When joining two wires together, make sure to slip a bit of heat-shrink onto one of them first - you can't slip the heat-shrink on after the joint is made. This sounds obvious, but I'm always forgetting to do so and having to fall back to using electrical tape instead of heat-shrink... Also, slip the heat-shrink far away from the joint so it doesn't heat up prematurely. After testing your soldered connection, slide the heat-shrink over the joint and heat it up. The thin little dupont / jump wire that I listed at the start are great for solderless connections (e.g. plugging into the Arduino!) but are quite fragile. After soldering these, use hot glue to hold them in place and move any strains away from the joint itself. e.g. the red wires below might get pulled on while I'm working on this, so after soldering them to the switches, I've fixed them in place with a dab of hot glue: Part 2, make it act as a game controller! To make it appear as a USB game controller in your OS, the code is quite simple, but unfortunately we also have to replace the firmware on the Arduino's USB chip with a custom one that you can grab from here: https://github.com/harlequin-tech/arduino-usb Unfortunately, once you put this custom firmware on your Arduino, it is now a USB-joystick, not an Arduino any more So in order to reprogram it, you have to again re-flash it with the original Arduino firmware. Iterating is a bit of a pain -- upload arduino code, flash joystick firmware, test, flash arduino firmware, repeat... An example of an Arduino program for use with this firmware is below -- it sets up three buttons as inputs, reads their values, copies it into the data structure expected by this custom firmware, and send the data. Rinse and repeat. // define DEBUG if you want to inspect the output in the Serial Monitor // don't define DEBUG if you're ready to use the custom firmware #define DEBUG //Say we've got three buttons, connected to GND and pins 2/3/4 int pinButton1 = 2; int pinButton2 = 3; int pinButton3 = 4; void setup() { //configure our button's pins properly pinMode(pinButton1, INPUT_PULLUP); pinMode(pinButton2, INPUT_PULLUP); pinMode(pinButton3, INPUT_PULLUP); #if defined DEBUG Serial.begin(9600); #else Serial.begin(115200);//The data rate expected by the custom USB firmware delay(200); #endif } //The structure expected by the custom USB firmware #define NUM_BUTTONS 40 #define NUM_AXES 8 // 8 axes, X, Y, Z, etc typedef struct joyReport_t { int16_t axis[NUM_AXES]; uint8_t button[(NUM_BUTTONS+7)/8]; // 8 buttons per byte } joyReport_t; void sendJoyReport(struct joyReport_t *report) { #ifndef DEBUG Serial.write((uint8_t *)report, sizeof(joyReport_t));//send our data to the custom USB firmware #else // dump human readable output for debugging for (uint8_t ind=0; ind<NUM_AXES; ind++) { Serial.print("axis["); Serial.print(ind); Serial.print("]= "); Serial.print(report->axis[ind]); Serial.print(" "); } Serial.println(); for (uint8_t ind=0; ind<NUM_BUTTONS/8; ind++) { Serial.print("button["); Serial.print(ind); Serial.print("]= "); Serial.print(report->button[ind], HEX); Serial.print(" "); } Serial.println(); #endif } joyReport_t joyReport = {}; void loop() { //check if our buttons are pressed: bool button1 = LOW == digitalRead( pinButton1 ); bool button2 = LOW == digitalRead( pinButton2 ); bool button3 = LOW == digitalRead( pinButton3 ); //write the data into the structure joyReport.button[0] = (button1?0x01:0) | (button2?0x02:0) | (button3?0x03:0); //send it to the firmware sendJoyReport(joyReport) } Part 3, integrate it with YOUR game! As an alternative the the above firmware hacking, if you're in control of the game that you want your device to communicate with, then you can just talk to your controller directly -- no need to make it appear as a Joystick to the OS! At the start of this post I mentioned Objects In Space; this is exactly the approach that they used. They developed a simple ASCII communication protocol that can be used to allow your controller and your game to talk to each other. All you have to do is enumerate the serial ports on your system (A.K.A. COM ports on Windows, and btw look how awful this is in C), find the one with a device named "Arduino" connected to it, open that port and start reading/writing ASCII to that handle. On the Arduino side, you just keep using the Serial.print functions that I've used in the examples so far. At the start of this post, I also mentioned my library for solving this problem: https://github.com/hodgman/ois_protocol This contains C++ code that you can integrate into your game to act as the "server", and Arduino code that you can run on your controller to act as the "client". Setting up your Arduino In example_hardware.h I've made classes to abstract the individual buttons / switches that I'm using. e.g. `Switch` is a simple button as in the first example, and `LedSwitch2Pin` is the controllable LED switch from my second example. The actual example code for my button panel is in example.ino. As a smaller example, let's say we have a single button to be sent to the game, and a single LED controlled by the game. The required Arduino code looks like: #include "ois_protocol.h" //instantiate the library OisState ois; //inputs are values that the game will send to the controller struct { OisNumericInput myLedInput{"Lamp", Number}; } inputs; //outputs are values the controller will send to the game struct { OisNumericOutput myButtonOutput{"Button", Boolean}; } outputs; //commands are named events that the controller will send to the game struct { OisCommand quitCommand{"Quit"}; } commands; int pinButton = 2; int pinLed = 3; void setup() { ois_setup_structs(ois, "My Controller", 1337, 42, commands, inputs, outputs); pinMode(pinButton, INPUT_PULLUP); pinMode(pinLed, OUTPUT); } void loop() { //read our button, send it to the game: bool buttonPressed = LOW == digitalRead(pin); ois_set(ois, outputs.myButtonOutput, buttonPressed); //read the LED value from the game, write it to the LED pin: analogWrite(pinLed, inputs.myLedInput.value); //example command / event: if( millis() > 60 * 1000 )//if 60 seconds has passed, tell the game to quit ois_execute(ois, commands.quitCommand); //run the library code (communicates with the game) ois_loop(ois); } Setting up your Game The game code is written in the "single header" style. Include oisdevice.h into your game to import the library. In a single CPP file, before #including the header, #define OIS_DEVICE_IMPL and #define OIS_SERIALPORT_IMPL -- this will add the source code for the classes into your CPP file. If you have your own assertions, logging, strings or vectors, there are several other OIS_* macros that can be defined before importing the header, in order to get it to use your engine's facilities. To enumerate the COM ports and create a connection for a particular device, you can use some code such as this: OIS_PORT_LIST portList; OIS_STRING_BUILDER sb; SerialPort::EnumerateSerialPorts(portList, sb, -1); for( auto it = portList.begin(); it != portList.end(); ++it ) { std::string label = it->name + '(' + it->path + ')'; if( /*device selection choice*/ ) { int gameVersion = 1; OisDevice* device = new OisDevice(it->id, it->path, it->name, gameVersion, "Game Title"); ... } } Once you have an OisDevice instance, you should call its Poll member function regularly (e.g. every frame), you can retrieve the current state of the controller's output with DeviceOutputs(), can consume events from the device with PopEvents() and can send values to the device with SetInput(). An example application that does all of this is available at example_ois2vjoy/main.cpp Part 4, what if you wanted part 2 and 3 at the same time!? To make your controller work in other games (part 2) we had to install custom firmware and one Arduino program, but to make the controller fully programmable by your game, we used standard Arduino firmware and a different Arduino program. What if we want both at once? Well, the example application that is linked to above, ois2vjoy, solves this problem This application talks to your OIS device (the program from Part 3) and then, on your PC, converts that data into regular gamepad/joystick data, which is then sent to a virtual gamepad/joystick device. This means you can leave your custom controller using the OIS library all the time (no custom firmware required), and when you want to use it as a regular gamepad/joystick, you just run the ois2vjoy application on your PC, which does the translation for you. Part 5, wrap up I hope this was useful or interesting to some of you. Thanks for making it to the end! If this does tickle you fancy, please consider collaborating / contributing to the ois_protocol library! I think it would be great to make a single protocol to support all kinds of custom controllers in games, and encourage more games to directly support custom controllers!
  11. 1 point
    I should watch what I say.. I think it was yesterday I posted about new animations and how little time it took me because there were only two. And today my animator looks like this.. mhmmmm! Here's some visuals, use your imagination when I say snowball.. it's not there yet. Collecting Snowball. Riding around with a big'ol Snowball and throwin it! (the throw animation is distorted a bit in this gif, I've fixed it since). ... and throwing while in mid-air! This game is finally getting some juice! Only a few more days of programming/modeling before we have snowballs, exploding ice bombs, chairs, kitchen sinks, and who knows what else I'll rig up to throw around. Oh man, this is getting to the fun bits now!! Game Link(no throwin yet): https://www.kongregate.com/games/WilliamOlyOlson/slingbot-boarding/
  12. 1 point
  13. 1 point
    Whilst a lot of people find programming to be a stimulating activity, for others, traditional programming can be very intimidating; needing to remember what seems like arcane symbology, and seemingly endless streams of specific keywords into an editor can be very off-putting. As many of us know, this actually gets easier with practice and soon becomes a less daunting task, but fortunately for those who struggle, there are other options available. Many modern game engines offer different types of visual interface with which you can set up an environment and characters, and input the logic required to turn those pieces into a functioning game. In this article, I aim to give a brief overview of some of the currently available options for creating games without traditional programming. This list will not be exhaustive, but instead, aim to cover a few of the more popular and capable options, and I will leave it as an exercise for the reader to further research those options and choose what may be most suitable for their own goals. Features and prices listed are current at the time of writing in October 2018. Many of the options presented offer free trials, which I would encourage you to try out before spending your hard earned money -- in the case that no trial is available I would suggest checking out some written and video tutorials of the software to see if it looks like something you could understand and work with, as well as some games made with the software to see if it may be able to create the types of games you have in mind. The first option I'm going to introduce is a simpler one suitable for introducing programming to younger would-be developers and is more limited in its capabilities, so if you're interested in more complex options please don't be put off and keep scrolling to the following items. Below the list of options you'll find a few thoughts on visual systems. Scratch Scratch is a freely available programming environment created by the Lifelong Kindergarten Group at MIT Media Lab, and allows you to create games, interactive stories, and animations. There is also an active online community of people sharing their creations and giving positive feedback. Programming in Scratch is done by snapping building blocks together to input your logic, and although it's usable by people of all ages and abilities it's specially designed for younger learners ages 8 to 16. Scratch works right in the web browser via the Flash plugin, so there are also no large downloads. If you prefer working offline, there is also a downloadable version available. Honestly, you're not going to create a smash hit video game with Scratch, but it's the perfect introduction for a child with an interest and may be a valuable starting point for people who find other systems intimidating. Working with the visual system in scratch will encourage logical, structured thinking that can be applied to more complex systems or even to traditional programming at a later stage, and although it's fairly basic children will be excited to see and play with their own creations. You can view (and play with!) some projects created with Scratch in the Explore section of their community. Note that while you can share and play your creations with the Scratch community, but won't be able to deploy to other platforms such as mobile, consoles, etc. Game Maker Game Maker is a popular option amongst hobbyist and indie developers and is able to create games for a wide variety of platforms including mobile and many of the consoles. The engine has only rudimentary 3d capabilities and is not intended for making 3d games, but is very capable when it comes to 2d. A number of very successful games including Hyper Light Drifter, Hotline Miami, Risk of Rain, Nuclear Throne and more have been created with Game Maker. Check out the Game Maker Showcase for examples of what the engine is capable of. Developers can use a simplified programming language called GML (Game Maker Language), or with a visual "drag and drop" system, and almost anything that can be done with GML can also be done with drag and drop -- albeit sometimes it might be a bit more clunky. As a popular engine, you'll find plenty of tutorials (including lengthy series of officially provided video tutorials), sample projects, and people willing to help with learning and creating your projects. You can get started with an unlimited free trial, and publish to additional platforms with a yearly subscription starting from US$39/year for Windows, up to US$1500/year for all available platforms. Construct Construct is a browser-based game engine that allows you to create games with a visual editor - in fact, in this case, programming is not even an option. Games are created by applying and configuring "behaviours", and by using a visual "event sheet" that runs commands in order, and you are able to create most types of 2d game. Because the editor runs in a browser you can create your game from any platform with a suitable browser, including mobile -- although you'll find it awkward to work with on a smaller screen. A downloadable version is also available, and many functions of the editor are able to work offline. Note that Construct is strictly a HTML5 engine, so exports for other platforms are provided via wrappers -- essentially packing your game up with a cut-down web browser to create an executable for the platform in question. Their is an active community using the software, and plenty of tutorials and examples available to help you get started. A free trial is available with some limitations, with full features available via subscription starting at US$99/year for a personal license or US$149/year for a business license (which you'll probably want if you're planning to monetize). Stencyl Stencyl is another visual editor aimed at creating 2d games, and able to publish to a range of platforms. Stencyl's editor uses logic blocks similar to those available in Scratch, but also allows more advanced users to write some code if they wish to do so. You can view some games created with Stencyl is the showcase. Stencyl seems to have a slightly less active community than some other options, but there is some help available, and plenty of tutorials. Some of the tutorials seem to be for previous versions of the software. Unity + PlayMaker Unity is an incredibly popular and very capable engine that can be used to create great games. By itself, Unity doesn't provide visual scripting capabilities (programming is done with the C# programming language), but a third party add-on called PlayMaker comes to the rescue by adding a visual system and allowing developers to create games without writing code. PlayMaker will currently set you back US$45.50 (or cheaper with a Unity Plus or Pro subscription). PlayMaker games are created with a flow-based system that involves toggling settings on nodes, which you connect in different orders to achieve the desired behaviour. You will find PlayMaker more limiting than programming Unity with C#, but the experience you gain with the visual system may encourage you to try to C# and give you some fundamental logical thinking skills to build upon. Unreal BluePrints Unreal is another popular engine used by professional developers. In this case, a visual system is built into the engine in the form of Blueprints, intended to allow non-coding designers to work with the engine and create interactive content. You can get started using Unreal with no upfront cost, and pay just 5% of your game's earnings once you surpass a certain threshold. Like many of the other options, there is an active community using Unreal, and plenty of tutorial content available, although most users do the majority of their Unreal development via C++ programming, with Blueprints used by non-coding team members. Are There Limitations? Honestly, yes. Just as those using an engine might find themselves more limited than those developing their game "from scratch", you will often find that visual systems are more limited than traditional development. Some things may be difficult or more time-consuming to implement in a visual editor, or if the creator hasn't exposed some data or a function you need your idea may be impossible. However, many find these options to be more approachable, and some very impressive and successful games have been created using them. Just be sure to do your due diligence about any limitations you might face before spending money hoping to create your dream game. Other Options The above are just a few of the popular options that can allow you to create games without traditional programming, but there are other options available if you're willing to do some further research. Some others you might wish to look in to include GameSalad, RPG Maker, Unity + uScript Professional, Buildbox (,I found this editor to be especially limiting), and more. Why Do I Keep Calling It "Traditional Programming"? You may have noticed I keep saying "traditional programming" rather than just "programming". Some people don't consider visual systems like those provided by the engines above to be programming, but I would disagree. Wikipedia describes programming as: and goes on to say: I would argue that you are still doing the same task with a visual system, just via a different input method where you join blocks (or whatever the system in question provides) rather than typing special keywords. Although some people find this type of visual programming less intimidating and easier to understand, you'll find that you're developing the same skills of logical thinking, planning out solutions, and finding (hopefully elegant) solutions. After some time with visual systems, you may find the concepts used in traditional programming more familiar and approachable. Conclusion There are numerous options available to create games without traditional programming, and with the right selection you can likely find something capable of the type of games you wish to create. Remember to research your options carefully, and don't be bothered by those who try to tell you it isn't "real game development". I hope the above list helps to get you started with finding a suitable option for your project.
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
      260723
    • Most Online
      6110

    Newest Member
    Jeny Roy
    Joined
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!