Jump to content
  • Advertisement


Popular Content

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

  1. 2 points
    Usually everyone has their own game idea, that they think is great (just like you ). So if they work for free anyway, they will work on their idea, and not yours. Unless they think that the idea is extremely good and they like it more than their own ideas. What you wrote is not enough to be called "a game idea". You just described some characters. A full game idea has a lot more than that (gameplay, for starters)
  2. 2 points
    You don't need to snap every object at once. You can snap only some objects, closer to the player with higher frequency, for example. Similarly, you can know which objects are "touched" by the player entity, and thus are likely to be out of sync, and prioritize snapping those. Finally, when you "snap," you can remember the position/orientation of objects on the client, too, so you have something like: client position at time 120: 32, 18 server position at time 120: 28, 19 client position at time 130: 40, 5 Now, the client receives "at time 120, the position was 28,19." What the client does is calculate a delta (28-32 = -4, 19-18 = +1) and applies that to the current state (40-4=36, 5+1=6) This works best for position/orientation, you may want to do something more server-authoritative for velocity and spin. At least if the difference is big, it's probably better to apply the server value wholesale to velocity and spin, although if the delta is small, just applying the delta as per position would be OK. Finally, yes, this is one of many reasons why most large shooter games don't have tons of important interactive physics in their big maps 🙂
  3. 2 points
    The intended result is to transform the coordinate such that the range [Near,Far] maps to [0,1], but after the perspective divide. Ignoring the divide to start with, we start by translating by -Near, so that Near maps to 0. Zout = Zin - Near Now, in the given case, Z values at the near plane become 0, Z values at the far plane become 9. We rescale by 1/(Far-Near) to bring that to the range [0,1] Zout = (Zin - Near) / (Far - Near) To make this easier to calculate with a matrix, we want it in the form A * z + D, so we distribute and rearrange things Zout = Zin * 1/(Far - Near) - Near / (Far - Near) If it is an orthographic projection, we're done. If it is a perspective projection, we must take into account the divide by Zin that will happen. Zclip = Zin * 1/(Far - Near) - Near / (Far - Near) Zout = Zclip / Zin For Zin = Near, Zclip is 0.0, and nothing would change, but for Zin = Far, we would get a result of: Zclip = Zfar * 1/(Far - Near) - Near / (Far - Near) = 10 / 9 - 1 / 9 = 9 / 9 = 1 Zout = Zclip / Zin = Zclip / Far = 1 / 10 To get a Zout of 1, we have to scale things by Far, which will give the correct result of Zin = Near -> 0.0, Zin = Far -> 1.0. Distributing it across: Zclip = Zin * Far / (Far - Near) - (Near * Far) / (Far - Near) Zout = Zclip / Zin
  4. 1 point
    You're probably right. I was using the C# version. My mistake.
  5. 1 point
    Ok, i'll bite. Is Nick Killey a real person you know, who you want to make a game about? I'm just mentioning this because if it is, that could land you in massive hot water. I wanted to be absolutely sure about that, and you to be absolutely sure about that, before you pitch this idea any further, because something doesn't sit quite right with me about this whole thing. I could be wrong. Please let me know, if i am.
  6. 1 point
    You need to look into your country's tax laws. That's where you'll get your tax answers. You will have to pay UK taxes on your income. Since you're not an employee of the Swiss company, I imagine you don't have to pay any Swiss taxes but I'm not a lawyer or tax specialist. You need a contracting agreement (a contract) with the company who's paying you. They'll write it. You can try to negotiate its terms. Don't sign it if you don't like it (don't take the job if you don't like the terms). What is your insurance question?
  7. 1 point
    Really nice assets, guys. Art looks pretty cool! Keep working!
  8. 1 point
    I've had the pleasure working with @Brain on his game: Mr Boom's Firework Factory by assisting with some graphics as of recent. I'll post a link to his blog and gallery at the end so you can go and check it out. Long story short, @Brain had a container which he could use but it was over 260,000 Tris and had 5 texture sets, and 4 decal textures all 4k each. I offered to optimize everything but realized the meshes were too messy so I ended up just re modeling it all while maintain most of the same look (structure wise - not texture). I then baked, re-textured the container, and added the decals supplied by @Brain. The final mesh is only around 20,000 Tris, 1 texture set which is 4k (includes the decals within) which is a major reduction from the original. I did two different lighting setups to show case the containers. The first is more outside cloudy type HDR, the second is a clear blue sky one. Check out @Brain's blog, gallery, and project page below:
  9. 1 point
    It adjusts the frustum so that the near plane sits on the z-axis at 0. Be aware that the video isn't showing how to create an OpenGL projection matrix. It is close to a DirectX projection matrix, it might even be a proper DirectX projection matrix.
  10. 1 point
  11. 1 point
    Bionic Commando was chosen because I loved the NES game back when I was younger. I got the version for the GameBoy as well as the GBC version that updated a lot. The main mechanic is a claw that shoots out and grapples and pulls the player or lets the player swing. The player cannot jump, so the bionic arm is one of the main means of movement. It was this mechanic that I did not do well. Which makes this attempt a failure. I was able to get it working well enough but there were some game destroying bugs. These bugs around the main game mechanic could have been resolved if I redid it a better way, however, that is kind of the point of this RIP Method. Make mistakes, think of better ways to do them but move on without refactoring too much. Another issue I had this time was when I wrote out the gameplay elements, they didn't cover all the work that needed to be done. I will have to keep an eye on that to make sure I don\'t make that mistake again because that seriously messes up estimates... and hurts my motivation and my feelings. The rest of the game went well, learned a better way to handle enemy states, but I feel like it too can be improved a lot to make it even more reliable and efficient. There was some ways I thought of doing things but found better ways, for instance: I was working on letting an enemy type fall through a platform to drop down, but it was not falling. I turned off collision completely, but it was still not working right. Then I found that turning one collision channel made things work the way I wanted while still letting the enemy get shot by the player. It\'s a small thing, and something that makes sense when looking back, but when approaching a game engine with all its complexity, it takes some time to get used to not just finding functions but getting a feel for how the engine is designed to be used. The doors was another improved method that was made easier. But there are improvements I think that I can put in for those as well. Anyway, the third project is done. I learned more and feel like I've gotten a bit faster and more efficient even though it took longer, I spent less time working on it because it was interrupted by the game dev challenge I did which I'm counting as my fourth project. Which means that my next project is the last stage of the first level. I'm choosing Battle Unit Zeoth as the project, it's a game that I liked playing on my GameBoy when I was younger. It's a side scrolling shooter where you control a mech and shoot bad things while getting weapon upgrades. It was a short but tough game to get through.
  12. 1 point
  13. 1 point
    Hi GoliathForge Thank you for your reply I have checked improved version. but I have still difficulty understanding. // Compute unit direction vectors for the zenith, the view direction omega and // and the sun direction omega_s, such that the cosine of the view-zenith // angle is mu, the cosine of the sun-zenith angle is mu_s, and the cosine of // the view-sun angle is nu. The goal is to simplify computations below. vec3 zenith_direction = vec3(0.0, 0.0, 1.0); vec3 omega = vec3(sqrt(1.0 - mu * mu), 0.0, mu); Number sun_dir_x = omega.x == 0.0 ? 0.0 : (nu - mu * mu_s) / omega.x; Number sun_dir_y = sqrt(max(1.0 - sun_dir_x * sun_dir_x - mu_s * mu_s, 0.0)); vec3 omega_s = vec3(sun_dir_x, sun_dir_y, mu_s); comments just explain what is mu, mu_s and nu. I already know these variables mean I'm curious how equation compute sun direction's x. it may be simple math but it's hard for me
  14. 1 point
    There are several things to take into account: You have a laptop that might save the power consumption despite of your rendering (there might have some options to checks) You have a mobility version of a Geforce 920, it is less performant that the desktop version You have a Geforce 920, 20 means it is at the lower end of what the 900 series could do. In general middle range of the previous series (8xx) that are 850 and 860 will perform better. 200 fps on glxgears is very low. I have more than 12000 for example with a graphic card equivalent to a Geforce Gtx 1060 At the very least, if you still have doubt about the real performances of your hardware, try a benchmark and post results to compare (here is one). Also check this comparative, a 920 does not even have half of a 950 for example
  15. 1 point
    And now, with the scripting tool ready to be tested, and the beautiful placeholder as the main protagonist, it's time for some cinematic action. Remember: our goal was to make an rpg with a deep combat system and an entertaining story to follow (what else?!). The first thing you need to tell a story is having a story to tell. So, with a limited scope for lenght and complexity, I wrote two short scenes in my best adventure/fantasy parody style. The idea was connecting both scenes through the gameplay, making a short demo of what could be a game developed with these tools. The script is something along the lines of a couple of soldiers travelling through a desert to accomplish their super important quest, facing all kind of problems to continue their journey. What super important quest could that be? The omission of it makes it far more interesting than anything I could make up. I decided that two levels (two big scenes) was enough for a good demo. The first one being a desert, which I had to design. As the main goal wasn't a good level design, I didn't put much effort in it (altough in the next level, I tried hard making an interesting one). Even though, I think it's cute enough. So, in the intro cinematic we see these two soldiers talking about past adventures as they cross the desert. Of course, an enemy appears and then they have to fight it. The focus was not in originality, but entertainment. When I was happy enough about the script, I started translating it into the scripting tool. I splitted the work in two tasks: - Making the cinematic itself (controlling the behaviour of all characters and events in the scene). - Using a Unity plugin (Cinemachina) to "film" what the script was playing. So, on the one hand I had two characters talking for 30 seconds, and on the other I had to control from within Unity the camera behaviour. In retrospective, even if I liked the final result, I must confess I wouldn't do it like this again, mainly due to editing reasons (a living hell). Having the camera control independent of what's happening in the screen means that if I change anything (ANYTHING!) in the script, I must synchronize the whole cinematic again. That's a lot of testing and debugging. A LOT. In the following cinematics I made, I controlled the camera transitions and behaviour from nodes within the tree script, so unrelated changes usually don't affect camera behaviour. And after some work (the whole process took me a couple of days, I blame the camera issues), I finally had my first cinematic. Feel free to comment about it. So, we now have a combat system, a scripting tool, a silly story and a cinematic. The following step is using all of these things to make an actual game.
  16. 1 point
    The decision is mostly about what is most fair to players in different scenarios. If one person is on a low-resolution screen and one is on a high resolution screen, what is fair for your game? Should they show the same geography but the high res player see more detail? Or should they show the same detail and the high res player see more geography? If there are three different views, one is landscape, one is portrait, one is square, what is fair for your game? Should one see more data to the sides, one see more data up/down, one be clipped on both sides? Or should all of them be constrained to the same geography? Once you've decided those, you can implement different features. That can mean adding different quality settings based on the display, or it can mean implementing black bars (or decorative borders) so different screen sizes see the same window of the world. Exactly what is fair depends on the game. Displaying a different view, displaying more buttons or data, displaying a different shape, displaying higher resolution images, each can affect the fairness of different games, or have no difference at all in different games. Bars and borders plus a scaled viewport inside that constrained area can give you the same display on each screen, but that is also the most unpopular way to do it. Many people absolutely hate bars and borders, others will scream at you for scaling the viewport since it can blocky on their high resolution screen. Open and flowing to the screen size tends to be least fair across multiple players since bigger monitors and smaller pixels reveal more of the world. Fewer people complain about them, except in highly competitive games.
  17. 1 point
    A brief follow-up. After considerable snooping around it turns out it's possible to use Direct Manipulation in client mode - eg as a standalone source of gesture (zoom, scroll) inputs (for example, the code that comes as part of the Windows classic sample pack uses DM in conjunction with D3D and separating the two appears impossible at first). Since it took me considerable time to figure all this out, I thought I'd share how you can accomplish this: 1. CoCreateInstance an instance of IDirectManipulationManager (CLSID_DirectManipulationManager) 2. Get its update manager - you'll be using this from now on (I'll refer to it as the manager from hereon) 3. Use the manager to create a dummy viewport with some arbitrary size 4. Set the viewport configuration and call SetViewportOptions(DIRECTMANIPULATION_VIEWPORT_OPTIONS_MANUALUPDATE) 5. Add your event handler to the viewport (derive it from IDirectManipulationViewportEventHandler) 6. Activate the manager 7. In your message loop listen for DM_POINTERHITTEST. When you receive this message and the message comes from a touchpad, start polling the manager by calling Update() (the frame info provider can be NULL). Respond to the OnViewportStatusChanged() and OnContentUpdated() functions in your handler 7.1 I think polling is only necessary for touchpads since there's no event that would tell you when the user places their finger(s) on or removes their finger(s) from the pad. DM handles this internally and lets you know via OnViewportStatusChanged(). In order to tell whether DM_POINTERHITTEST is from a touchpad, get the GetPointerType() from user32.dll (it has the signature: BOOL(WINAPI*)(UINT32, POINTER_INPUT_TYPE*) ) and see if the returned type from GetPointerType(GET_POINTERID_WPARAM(wparam), &type) is PT_TOUCHPAD 8. If it is, call viewport->SetContact(GET_POINTERID_WPARAM(wparam)) 8.1 Stop polling when you receive the current status DIRECTMANIPULATION_READY in OnViewportStatusChanged() 9. In OnContentUpdated() call content->GetContentTransform() to get the floating point transform 9.1 You can make the transform relative within a gesture by calling ZoomToRect() on the viewport and resetting the coordinates in response to DIRECTMANIPULATION_READY A couple of notes: In a naive implementation scrolling by clienting DM like this seems is less smooth than what the MS-provided compositor does. However, the latter is purely DirectX-based and handles drawing/input handling in some complicated mulithreaded way If you don't want to wrap the DM code, it should be possible to use something like ANGLE to relatively easily get your GL FBO into D3D (or I guess you could manually download->(convert?)->upload the frame buffer). However this still requires your display surface to be DX-based. My knowledge of DX in general is poor so I won't comment further. Have a look at the link above for an official example how to do this if you're working with DX natively I wrote my own input accelerator on top of the data received from DM. However the results should get better once I transition away from WM_TIMER-based polling, optimize the draw code (framerate/smoothness really matters for a natural scrolling experience) and implement a floating point scroll accumulator that feeds directly into my accelerator as opposed to marshalling DM input through WM_MOUSEWHEEL messages (which only supports integral coordinates) If you have some time for a fantastic read on a topic that seems extremely simple and mundane, have a look at the article Scrolling With Pleasure by Pavel Fatin I hope this helps saves some poor soul a few days of in the future.
  18. 1 point
    This interview was conducted by Indie Ranger. Check out their interviews and indie games coverage at https://indieranger.com. Also learn more and read about the progress of Something Ate My Alien from @RoKabium Games on their GameDev.net blog. Looking at the credits for a AAA title can give an idea about how many people it takes to make a video game. With that in mind, it’s easy to think video games require a huge staff and budget to get produced. However, indie games often prove it can take only one or two people to create amazing games. Rob Donovan and Kat Langwagen are two such people. They founded RoKabium Games and began their project, Something Ate My Alien, simply because they wanted to create it. “We wanted something to call our own,” Donovan said. “I worked most of my career at huge international companies. When we felt we broke away from that contracting market and had a pause we thought we should try doing something ourselves.” Kat Langwagen (left) and Rob Donovan (right). The duo dev team and founders of RoKabium Games. (Photo: Courtesy of RoKabium Games) Something Ate My Alien is RoKabium Games’ first project. Donovan says he had little experience designing games besides a level he made for Portal,but he has been coding his entire career. Kat Langwagen went to school for a teaching degree but says she was always drawn to artistic projects. First she became interested in digital art after reading about it in 2005. “I was absolutely blown away with what you could do with art on a computer,” she says. “From that point on I knew I wanted to focus on digital art.” After she felt confident enough in her abilities as a digital artist, Langwagen began working on videogame assets. “From there on it just went forward,” she said. “I started picking up more and more work on games and getting a bigger and bigger interest in it. I really enjoyed it.” After brainstorming some other ideas—including a much larger, 3D sci-fi mmo—RoKabium Games settled on creating Something Ate My Alien, a digging game inspired by games such as Terraria and Spelunky. Digging up the Dirt on a Digging Game Along with the more contemporary titles, Something Ate My Alien was also inspired by the retro Boulder Dash series. Langwagen said the decision was largely based on the style of games she liked playing. Langwagen said she wanted the gameplay of digging for treasure and fighting monsters of the retro game but done in a modern style. “For me, digging and finding stuff as you fought through enemies is something I haven’t seen a lot of since Boulder Dash,” she said. “There are a few, and when we found Terraria, I really loved that style. It reminded me of those retro games.” A look at one of the later levels. Complete with particle and lighting effects. (Photo: Courtesy of RoKabium Games) The simple execution but super fun gameplay of the digging game is what Langwagen said she really likes. “It has something to do with the gathering in a 2D-fashion,” she said. “You don’t need anything complicated. The simplicity, I think, is what really attracted us to this style of games.” Donovan said he thinks he spent about one-thousand hours playing Terraria, which may be the reason he likes digging games. The Duo on Game Design Other than a few sound and visual effects, Something Ate My Alien is 100 percent developed by Donovan and Langwagen. “Because he can code and she can do the artwork and assets,” Donovan said. “We started the project without realizing we could manage to do everything,” he said. “Of course, it would be way easier with more people, but there are other problems with bigger team.” Donovan described the workload as about 50/50 and Langwagen agreed. “I think we compliment each other well,” she said. “We have the two major parts of the game sorted. It’s worked really well with just the two of us.” Something Ate My Alien is developed with the Unity engine. Donovan said they chose it because it was free, downloadable and user friendly. “[Unity] is probably the reason we’re able to produce the game,” he said. “Although I would like to build my own engine, that would probably add another three or four years to making a game.” A game engine is the software framework a video game is built around. The engine renders graphics and make the game’s AI work. Doing All the Art Solo Coding a game can be complex, and art and asset design is a tough task as well. Langwagen said she loves making art and designing things for the game, but it’s a lot of work. “I think the most difficult thing about making the art is the scope of it,” she said. “There are so much art and assets in a game.” Langwagen has worked with a larger studio before. On a team, she said, you get divided into groups and you work on a smaller part. However, doing all the artwork solo for a game from start to finish is a massive challenge. “It’s not just the tiles in the game,” she said. “It’s also the enemy designs, the logos and promotional stuff. It’s everything that’s seen. There’s such a wide variety of artwork.” Langwagen said her folder of art and assets has over 6,000 different files. Even after an asset is created, getting it into the game is also a challenge. Donovan said lighting effects often change the colors and he needs to tweak it to get things looking right. “The lighting is one of the hardest areas,” he said. “It can be quite frustrating at times getting the lighting exactly right to get the art how Kat wanted the actual colors to be in the game.” Donovan and Langwagen also spent a lot of time getting the HUD and GUI looking and working well. The HUD menu in Something Ate My Alien. Designing these things is harder than it seems. (Photo: Courtesy of RoKabium Games) Art is Langwagen’s passion. She loves painting and drawing and says if you love what you do, it hardly feels like work. “Doing [this] everyday—no matter what it is—it’s fun,” she said. “I have fun everyday at work. If you’re going to pull off a project like this, you have to have fun.” The Duo on Being a Two-Person Team Bigger games have bigger teams so they can be released within a certain time frame—usually under a publisher’s deadline. On the other hand, indie games are worked on at the developer’s discretion. RoKabium Games and other small indie teams show the secret to creating a great game is the time and dedication put into it. Something Ate My Alien is a lot more work than Donovan and Langwagen were expecting. “We were working easily seven days a week,” Donovan said. “From nine in the morning to 11 at night. It’s been a continuous slog for two-and-a-half years.” Even devoting so much time into the game, it’s a lot of work for just two people to do. “If you’re going to do a project like this with so few people, you have to be able to work well with each other,” Langwagen said. The work is divided fairly evenly between the two. Since Donovan does the coding and Langwagen does the artwork, the two stay somewhat segmented and, according to Donovan, the system works well. “It’s good we don’t interject too much on each other’s side,” he said. “We don’t have too many disagreements because we’re each our own department.” The two developers said time management is one of the most important things needed to make a video game. With all the time and effort need to create Something Ate My Alien, the thing that drives them forward is seeing people enjoy what they made. Sometimes, things aren’t going to go well. Langwagen said using social media and promoting the game can be like a roller coaster. They don’t always get the reaction they were hoping for. “You get days when you get very little feedback and you feel down,” she said. “Then you get very good days and it evens all that out. But we know, as long as we keep doing the work, we will get there.” This interview was conducted by Indie Ranger. Check out the rest of their developer interviews and indie games coverage at https://indieranger.com.
  19. 1 point
    Welcome to our third blog post! In this, we'll be showing off some of the innerworkings of our Structures. This includes a full overview of both integrated and planned content. We'll discuss each Structure's purpose and how they tie into Moonrise's RPG-like system. But before we dive into the Structures, we need to talk a bit about Resources… --- Resources allow for the construction of new structures, spawning and advancement of units, and eventually- researching upgrades. Nature is the easiest and most abundant to collect. Water is also fairly abundant, but just a little more difficult to acquire. Pages are much more difficult- there are many ways to gather them, but the most common is by slaying enemies. They are the main resource. --- In regards to resources, Harvesters are used to automatically gather from the world around. The most basic of them is the Harvester. It allows rapid collection of Nature. Greater Harvesters emphasize gathering Water. And Master Harvesters allow for consuming Nature and Water resources to create Pages. --- Now, with resources complete- The quintessential structure is the Home. With it, life can be created, and the warriors can assemble. Disciples are the most basic of which- they only cost Nature. Magicians, however, are much more advanced, but well worth their cost of Nature, Water, and Pages. --- Defensive Structures include the Sanctuary, Haven, and Evaporator The Sanctuary is used for health regeneration of any ally nearby. Similarly, the Haven is used for mana restoration of nearby allies. And the Evaporator is for defense against nearby foes. It casts both powerful spells and emits a harmful aura, damaging nearby enemies. --- Our last set of Structures are our most important. They are the Libraries and the Lecture Hall. These Structures will be used for advancements. This can include anything from bonus statistics to unlocking new classes and spells. The Library is used for advancing unit stats- health, mana, regeneration, and so on. Bear in mind- all these advancements are permanent, and go across all warriors. The Great Library is for advancing units, and unlocking new ones. Within the world, you can collect powerful artifacts called Tomes. These artifacts are used for taking units beyond their basic tiers and into their most powerful state. The Dark Library is used for utilizing a unique and obscure unit type- the Narya. This includes being able to summon said Narya, alongside emplacing its spells on your regular units for even more customization than current. Last comes the Lecture Hall. This is for acquiring new spells on your units, costing resources and requiring tomes or other unique artifacts. --- That concludes our list of Structures. Thank you for viewing our page! Thank you for viewing our post!
  20. 1 point
    Despite a strong start time is already creeping up on me with the end of the challenge at the end of May. I actually have to go away before this so I have even less time. However I'm confident I can have a couple of playable levels. Android I managed to waste a week trying to convert the project to Android. Support for OpenGLES 2.0 is new in Godot 3.1, and well, it's a bit flakey. This is not entirely Godot's fault, the GLES2 scene is a nightmare in general I know from writing GLES2 code. The problem is mostly down to a lack of standardization in what features devices will support, and bugs in the devices and drivers. Really they should have standardized a number of tiers for GLES2 devices, and mandated support for certain elements in each, and had rigorous testing. But instead, the situation is like the wild west, with devices picking and choosing features to support. This makes development and testing a nightmare. So my current situation I have an Android phone which Godot doesn't support at all (too early Android version, godot had to update the signing method, something to do with security at google play not allowing older APKs), and on my tablet, I can run the game up until a skinned character appears on screen and then it crashes. The godot skinning method is not supported on all devices. Open source of course means that the onus is on ME to fix these bugs .. and I have Godot compiling in QT Creator and the export templates, but clearly a significant investment in time will be necessary to be able to fix such things in the renderer. Unfortunately the core team don't seem to be working on ES2, perhaps more working on Vulkan now. That would be one thing I have noticed about the Godot project, is that there is a lot of effort towards implementing new features, however some would argue that bug fixing should take greater priority. This is perhaps a feature of open source, where people will work in preference on interesting new features rather than boring bug fixes. Anyway I have decided fixing Godot has to take a back seat for now and I am concentrating on getting working gameplay. Some things I have been working on: Improved terrain rendering / collision Procedural level generator Artwork for platforms, health and fuel generator platforms Camera improvements I still haven't decided on the objective for completing the levels. It may be just crossing from A to B, or it may be transporting an item with the tractor beam. Or destroying a certain number of things .. perhaps I could have varying requirements on different levels. I'm not sure what is going to happen on the artwork side, it depends how much time I have. Ideally I'd like to create a full set of specific space models, but if no time I can reuse some of the frogger ones. Once again, 3D Paint is proving awesome on the artwork creation front. I must get around to making some windows builds.
  21. 1 point
    Thanks! I remember having a Magic the Gathering port done on my graphing calculator. Good fun!
  22. 1 point
    Really nice work Rutin. I love the way the face texture looks from different angles. Loving all the Python-esque comments too. Reminded me I'd still got my old programmable calculator from my school days lying around... Reckon it still works too if I had the right batteries to hand.
  23. 1 point
    PC too? Not only mobile? $100K is too low. Expect it to be 5 times that, at minimum.
  24. -1 points
    Godot is in alpha and it shows. Edit: take a look at Xenko https://xenko.com/ it's more mature than Godot. And thanks for the downvote, just sharing my opinion, I've had Godot on my system for a few weeks and I'm yet to even be able to get it to run, it's not ready for prime time. They even say on the front page - Don't use this for commercial projects - It's not ready.
  25. -1 points
    I have a game idea. Is there anyone willing to make it for free? You may sell it! So, My friend and I have been fantasizing about a villain name Kick Nilley who is extremely fat and the size of the empire state building and eats everything in sight I want it to be about a crew named the Otings who train and fight to finally one day defeat the great Nick Killey. Their leader is Lord Oting and Lord Fatape who is basically King Kong but fat. What do you guys think? Is anyone willing to do this game for free? You may sell it!
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
    • Most Online

    Newest Member
  • 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!