Jump to content
  • Advertisement
Sign in to follow this  
  • entry
    1
  • comments
    0
  • views
    257

PC Preparing Space Game GoE for our Alpha 2 Release!

GearsOfEden

568 views

2018 has already been a busy year. The Gears of Eden team has been hard at work as we prep for our Alpha 2 release. For our art and dev team, that means designing and implementing in-game resources. For our writing team, that means research and planning. But, combined, that means we get the chance to test our cool new toys and show them off for everyone to see.

To accomplish this, our team recently held our first Gears of Eden Discord Day. In case you don't know, Discord is an app that allows gamedevs to make their own chat servers and share images and info with people who join (here's YOUR invite). We shared our new rover design, talked about influences for the game, explained how this project got started, and streamed the first meeting between our old rover and the new one. Check out the first meeting: https://www.twitch.tv/videos/208097308?t=12m04s

Since then, the art team has been hard at work on base design and updating our UI. We've gone over quite a few models looking to find the right fit for our game. Because the bases are to be used by rovers, and modular (read expandable!), we decided that design must be functional rather than just aesthetically pleasing.

GearsOfEden_SmallBase_Form-Langu.thumb.jpg.c80456b2dc2e538cf3b0dc9d51e7b26f.jpg

The images above were just a few samples that we reviewed, and we are getting closer and closer to deciding what the base design will be for Alpha 2. Based on these images, our team was able to render a sample of the base in-game.

DRLh22sUIAAvY8k.thumb.jpg.7e35a5a415186f74d311a87a29f4d4da.jpg

As mentioned, our UI is being updated to be more intuitive and provide better information for players. Instead of clicking on the gears to craft using the inventory, there will be separate tabs implemented. The Crafting tab will show all blueprints collected, which you will then be able to craft from if you have the resources.

 

With that in mind, we've been doing some more Twitch streaming. Some of that has been development videos, and some of that has been members of our team showing off some games we enjoy playing. Here you can see Sledge going over the new UI, testing out the new rover, and doing some crafting: https://www.twitch.tv/videos/210491947?t=02m54s

 

We're making a lot of progress, but Alpha 2 is going to be a critical phase for us. Right now, we're doing all our development at our own costs, with a small team. Once Alpha 2 is out, we're going to have to find a way to secure some financial backing if we want to finish our demo in a reasonable timeframe. That's where you come in. We really, really need your help in growing our audience. Please engage with us, and follow us on our various social media accounts to help spread the words to others. Like, comment, share. And, if you're able, you could always support our endeavors at our donation rewards page, or through Patreon. We literally cannot make this game with you. Thank you so much!

This is going to be so fun! We can't wait to show you everything we've been working on these past few months, and it'll be a great stamp on this stage of development! If you want to see how we get all this done as we get it done, follow us on Twitter, Twitch, and Facebook for all the latest and greatest news on Gears of Eden.



0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Defend
      Obligatory disclaimer - Yes this is for academic purposes, not for making actual games.
      I've been employed as a Software Engineer for 2 years but still feel like a beginner when it comes to writing a game engine (and much of coding in general). What little experience I have with writing 3D software from scratch is from super rough university projects (which we called "engine" but that's definitely debatable). Meanwhile, my current job doesn't really take me down this line of learning.
       
      This thread is to ask for advice; mainly pointers to good guides, or comments on what structural approaches are considered to be good ones. I'm looking for something that teaches me about how to structure a game engine so that:
      it's good for learning about writing an engine it's not completely devoid of modern techniques it will be usable for later feature learning; networking, AI, unit testing, etc. (I imagine this criterion is typically a given anyway.)  
      Some things I'm aware of so far (you may want to comment on any of these):
      https://www.gamasutra.com/blogs/MichaelKissner/20151027/257369/Writing_a_Game_Engine_from_Scratch__Part_1_Messaging.php I also have the book Kissner recommends: Game Engine Architecture by Jason Gregory. From what little I've read of it, it appears more advice than structural guide. ECS was a buzzword back when I was at uni, but the more I google it the more it appears to have become a dirty word. Unreal Engine's source  
      Regarding ECS: For all the flak it appears to generate nowadays, it is at least a structure. If ECS isn't recommended I'm interested in what other general structural approaches there are.
      Regarding Unreal: I'd love to jump in and learn how Unreal Engine's structure works, but it might be biting off more than I can chew. 
      Language of choice is C++.
       
      Thanks
       
    • By Ikkon
      Hi guy , i wanna really quickly introduce myself , So i'm a 18 year old Highschool student that have been for a while really pationate about video game (i have been doing Esport , Streaming all that really fun stuff) but lately i had to made a choice about what i wanna do in life and i'm pretty sure its going to be in the video game industry. Last year i started learning to use UE4 , pretty much only for fun trying to recreate cool stuff i was seing in the game i was playing at that time. But now , i wanted to trie creating something of my own so i wanna show you what a got in the head. Also , I'm french so sorry if my spelling is quite right.. 
       
      So in Short , i was playing lately alot of FPS (Quake champion , Law Breaker and bunch of other cool game). I was talkinh with my friend and its pretty much their that a got the global idea of what this game is going to be. I wanted to take little simple game mecanics from every game and put them i one unique game. For exemple , Player could Strafe Jump like in quake , while other Start randomly Wall running like in Titanfall 2. After i came up with what would be the game objective , because player won't start playing a game for no reason . I didn't played CTF game for a long time so , i decided why not make this a CTF game , But ctf is kinda mainstream and really linear in term of game play, 
      This is when my friend had this idea of <<Why not let the player decide if the want to play it ''Run it down to the flag'' or ''let's just #*@! the other team'' (sorry for the bad words) >>. at this time i had a clear idea of what would exactly be the Core ''gameplay'' (if we can call this gameplay).  To win you have two option :
      1- Capture the flag and bring it back to your's. If you managed to do so , the game instantly stop and you win. 
      2- Kill all the enemy team.
      Now you most be thinking , <<Well how? they will just respawn right?>> well no , because i came up with the idea of limiting the number of time player can respawn using some kind of respawn point system. 
       
      i'll came up with more details later (i have to go to my next class) , but let me know what you think about my idea? what should i add or ajust? 
    • By EnderStaffExe
      Hello! I'm new to the scene of video game developing and was wondering if anyone here has any experience developing 2D fighters and are up for making a little test demo to see if the idea would catch on to the public? I have no way of paying but I want to put the demo onto Kickstarter and I will pay a good amount if I get a good amount. Please, if you want to contact me for more info, add me on my Discord or Twitter. Thank you, and see you later!
      (Twitter: @enderstaffexe
      Discord: EnderStaffExe#3193)
    • By Mapet
      Hi, I started implementing 2D board game. I have concept of how to write rules, controlls etc, but i dont want to write another all-in-app. So i decided to do it "right". I divided my code into reuseable modules - ResourceManager, Renderer, Core, Math (for now). All modules use SDL2.
      ResourceManager(RM) - loads textures, audio etc without duplicating them in memory. Resources are gathered in TextureResource, AudioResource (...) objects, handled by std::shared_ptr. For textures I have prepared Texture class that wraps SDL_Texture and I RM serves this Texture objs for Core module.
      Core - The main game module, contains game loop, gameobject / component implementation and event handling. Core requests for data from RM and sends them to right components.
      Renderer - Creates window and knows about render range (in core represented by camera). Takes info about texture, position, rotation and scale to render images (just this for now).
      Its time for my questions:
      is this architecture good? After I end this board game I want to extend renderer module for example for rendering 3D objects.  Loading resources while ingame is good idea? I mean single textures, models, sounds etc.  As I said, for handling resources I am using shared_ptr, is it good cleaning cache every (for example) 3 minutes? By cleaning i mean removing not used resources (counter =1). And the hardest thing for me right now - take a look at this flow: Core create a T1 token Component Renderer2D is connected to T1. Core requests a texture /textures/T1.png from RM. RM checks if /textures/T1.png is in map, if not, loads it. RM returns a std::shared_ptr<Texture> to Core. Core assign texture to T1 Renderer2D component.
      Now i want to pass this object to renderer. But I wont pass all gameObjects and checks which have renderer2D component (i also cant, because only Core know what is gameObject and component). So i had an idea: I can create Renderable interface (in Renderer module) and inherit from it in the renderer2D component. Renderable will contain only pointers to position data. Now i am able to pass renderer2D component pointer to Renderer and register it.

      Is this good way to handle this? Or im overcomplicating things? If point above is right I had last question - registering object in Renderer module. I dont want to iterate over all objects and check if I can render them (if they are in render range). I wanted to place them in "buckets" of - for example - screen size. Now calculating collisions should be faster - i would do this only for objects in adjacent buckets. But for 2D game i have to render objects in correct order using Z index. Objects have to be placed in correct bucket first, then sorted by Z in range of bucket. But now i have problem with unregistering objects from Renderer module.
      I think I got lost somewhere in this place... Maybe You can help me? Of course it this is correct way to handle this problem. I would love to read your comments and tips about what can I do better or how can i solve my problems.
      If i didnt mention something but You see something in my approach, write boldly, I will gladly read all Your tips :).
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!