Jump to content
  • Advertisement
  • entries
    7
  • comments
    6
  • views
    1802

Developers Diary #2 Material research for game.

Clarus Victoria

863 views

Hello everyone!

Oh, I'm so delighted with the number of views! And gamedev.net even featured our entry on their Facebook page! Thank you for finding this blog interesting! 

In the last entry, I made a brief introduction of our Egypt: Old Kingdom game. It's not just based on history, we're basically trying to recreate the history in a game form. Of course, it requires a tremendous amount of research!


Sometimes people ask us: "Why did you choose Hierakonpolis/Memphis as the main location, and not Thinis or some other important settlements?"

The reply will be: because in order to make the game really historical, our location of choice has to be very well researched. We need a lot of information about the location: events, personalities, buildings, lifestyle. 

The research was done by the game designer, Mikhail, and I think he can now get his master degree as an Egyptologist because he knows A LOT about Ancient Egypt thanks to his research!  xD He did the research by himself for Bronze Age and Marble Age, but then it got too hard to keep up with both research and game design. For the next game, Predynastic Kingdom, we contacted the scientists from the Center For Egyptian Study of Russian Academy of Sciences (CES RAS). We're lucky they agreed to help! Predynastic Egypt was the first game made with their support.

For Egypt Old Kingdom Mikhail created a huge database containing most of the known events, places and personalities of the Old Kingdom period:

5a64470c34901_dffca616076ebecc0b4ebead239864a41.thumb.png.72ad3711babe7a4f859a3caca6d4afbe.png

Every little thing about the period is studied thoroughly in order to immerse the player deeper in the game. We learn about kings’ deeds, their authority, did they properly worship gods or not, did they start any wars or not. We study climate, soil, vegetation, natural disasters of that period. We learn about the appearance of ancient Egyptians, their dress, their food, their houses.

Sketches of Egyptians' appearance:

5a64479231389_4c1e49e02c7cbef62c4d37a685bfcddd1.png.ea1763c326a99dad0ad0f6a0a19e9d10.png

When the database is ready, Mikhail goes over it with the scientists. They check everything, correct what's necessary, provide more information and details. Like every other science,  history has a lot of controversial points. For example, "The White Walls" of Memphis is something that scientists can't agree about. There are two major opinions about what could it be:

1. It is the walls of a palace. 

2. It is the walls of burial grounds.


In our game, we don't want to take sides, so the scientists of CES RAS inform us about such "dangerous" topics as well. This way we can avoid the controversy and let the player decide which theory he prefers.

This is Mikhail (left side) discussing the game events with scientists :) In the middle - Galina Belova, one of the most famous Russian Egyptologists. The director of CES RAS to the right.

5a644bfd20667_de9a44b1a23e268d5a7f26dd5510e15b1.thumb.jpg.adb125edf29c7c9fc6eec38db75997c2.jpg

During this part of the work we sort out all of the events and divide them in groups: the most important events which must be in the game;  less important events which can be beneficial for the atmosphere of the game; insignificant events.  

When this part of work is done, and all of the information is sorted out, the design of the game begins. In the process we still keep in touch with the scientists, because some events are not easy to turn in a game at all.

For example, one of our goals is to make the player fully experience the life of Ancient Egypt. We want to make player think like Ancient Egyptians, to make him exparience the same difficulties. In order to do that we have to know what Egyptians were thinking, and also through the gaming process, we have to put the player in the same conditions as Egyptians had.

Ancient Egyptians strongly believed that if they would not worship their ancestors and gods properly, the country will experience all kinds of disasters. This belief was unconscious and unconditional, that’s why they were building all those funeral complexes, made sacrifices, trying to please their ancestors. Even cities were built only as a way to please gods and ancestors! They were sure if they will stop properly worship them, the country will be doomed, because ancestors will stop to protect them.

We wanted to nudge the player to build all these pyramids for the same reasons as Egyptians, and this is how stat “Divine favor” appeared. This stat is mostly necessary to worship the gods’ cults, and player can earn it by working in temples and worshipping ancestors. But what really makes the player to feel like Egyptians did is the feature of “Divine favor” stat – it degrades by 0,1 every turn. It happens because people are dying; hence, there are more and more ancestors that must be worshipped. If player will not pay attention to this stat and it will degrade too much, more and more disasters will start to happen, such as fires, earthquakes, droughts, etc. If will greatly influence the economy and the result of the game.

That's how we turn history in a game. It can be fun and challenging! There are many other examples of similar transitions. We'll definitely keep working with the scientists, not only Russian, but also foreign. In fact, we hope to engage more and more people in the process of game making.

That's it for now. Thank you for reading! Comments are very welcome!

If you would like to know more about the game and follow our social media, here are links:

Egypt: Old Kingdom on Steam;

Predynastic Egypt on Steam;

Our community on Facebook;

Our Twitter.



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 jb-dev
      This is how loading screens will look like. I still have no idea whenever or not I could show things like tips or anything alike...
    • By Sultown
      Good evening.
      Before I get to my question, I'd like to clarify that this is in a 2D (2.5D) view with pixel graphics. While making mockups, a question on map design came to me. If I were to draw an entire section of a map, including stairs, buildings, etc. would I be able to set constraints so that a character could move realistically on one asset (the room, I guess), Instead of having to place each and every tile for every corner, or variation in design, or every stair?
      I feel like this would be much easier when it comes to very intricate room designs that would be much cleaner and aesthetically pleasing if I could just put wall barriers (native to my engine) where the player can not go.
      Let me know if this needs clarification or if this is in the wrong subforum.
      Thanks.
    • By CyberFlash
      Howdy! I've recently been working on a tower defense game, nothing fancy! In fact "A simple militant styled, tower defense game," is my opening line on the description :P. Anyway I would say I am new to this despite 'learning' for a while. I've definitely got a long way to go before anything 'amazing' is born but I wanted to post the game somewhere and try to get some feedback. https://gamejolt.com/games/3ndl3zz-basedefense/325756 if anyone wanted to try it out please do so! I fully intend to make updates in the coming weeks to improve upon the current application. 
      I started making this using 'Kenney' assets, I met someone through this forum that is interested in getting invovled in stuff like improving the graphics so that alone will make the game better but since i'm not great with designs and creativity I'm looking at this from the technical side and was wondering if anyone would give some feedback about my game/tower defense games in general. Best methods to increase difficulty without ultimately making it crazy impossible. 
      If you try it out and try the endless mode, you'll see what happens as of today... Enemies end up with crazy speed so i'm thinking of trying to cap a max speed in there and just focusing on increasing health or something... 
      Anyway I'll leave this post here.. Apologies if this isn't the correct place to post looking for feedback  I don't really use forums often so I don't know my way around all that well just yet! Like everything else I am Working on it though!
      Many Thanks! 
       
      Edit: Updated to Version 0.1.4 With notes.Thank you for the current feedback! I appreciate it a lot!
       
    • By Programmer One
      I'm currently writing a 2D game engine from scratch for Android. The first iteration of the engine is just going to use the Android Canvas view for drawing. At some point, I want to support OpenGL ES - but not until I finish this first project (which is a very simply game based on this engine). Right now, I'm dealing with Sprites and I've encountered a design challenge that I'm not entirely sure which direction I should go.
      For the sprite bitmaps, I've decided to go down the sprite atlas route (as opposed to individual image files). I'm using Texture Packer and I've written a custom JSON exporter. I didn't really want to limit myself too much, so I decided I'd support sprite rotation and trimming in order to save as much space I can in the atlas. I backed off from supporting polygon trimming for now. If you're unfamiliar with Texture Packer, it's essentially a tool that will allow you to import individual sprite frames, organize them into folders and then have the application generate a sprite map and corresponding coordinate data file. This application supports trimming any blank (alpha) space around the sprite images in order to pack them closer together. It also supports rotation if it makes the image fit better.
      What I'm trying to figure out now is how to deal with loading the sprite image data. Currently, I'm at the point where I can deserialize the JSON map data into "Sprite Frame" objects. These objects contain information about each frame. My format allows grouping of sprite frames in order to organize frames that correspond to the same animation. In essence, the sprite frame object has:
      The original (untrimmed) size of the sprite image. The original position of the sprite image within it's bounding box. The rect of where the image is in the sprite atlas. A flag indicating if it had been trimmed. A flag indicating if it has been rotated (CW). This will give me all the information I need to draw the image onto the Canvas. If I didn't support all the other fancy features I want (packed rotation, trimming) and pre-transformation (i.e. mirroring a sprite so I can reuse it for things like changing the walking animation without having to pack in more sprites), then drawing the image from the sprite atlas onto the canvas would be as simple as a simple Canvas.drawBitmap([Source Bitmap], [Destination Rect], [Source Rect]).
      But, since the image I'd be drawing MIGHT have been rotated, trimmed or otherwise transformed, I can't just simply blit it onto the Canvas. I'd first would need to apply some transformations in order to "undo" changes that were done during packing. This means I would need to either:
      Slice out the child image from the sprite atlas into a new bitmap, and apply the "unpacking" transformations (i.e. rotate back, realign, etc). Apply a transformation to the Canvas itself. (I don't think I want to go down this road since I've read that transforming the Canvas tends to be rather slow). So, I'm probably left with having to create smaller bitmaps from the sprite atlas and then keep those in memory for as long as I would need them. So, for a single sprite character, I'd be looking at around 36 sprite frames (9 different animations, each with 4 frames). What I'm concerned about is memory consumption. So now I'm thinking:
      I should read in all the sprite bitmaps from the sprite atlas and shove them into an LRU cache. This means all the sprite image data is now in memory, all ready to go for whatever animation sequence and frame I want. Once I'm done with the atlas, I dispose of it and just work with what I have in memory. I can perform this caching when I load levels and then clear items from the cache that I no longer need. I should just keep the sprite atlas, blit directly from that onto the canvas, and get rid of the fancy packing features so that I don't have to process any transformations. The only problem with this approach is that I will also have to shelve shearing and rotation on the sprite object itself. TL;DR: Am I being overly memory conscientious or having a couple frames of sprite data in memory not a super big deal?
       
    • By Cee 4our
      Hello there GD.net!  Dead Inside development is currently looking to fill 2 positions on our development team.
      Right now we are a pair of programmers\unity developers working hard on a small Metroidvania title.
      We are looking for people that are as hungry as we are who can work independently, or as a team when need be.
      We are looking for level headed and laid back people to work with!
      All experience levels are welcome! As long as you can produce assets it will be our privilege to watch you grow!
       
      The details:
      These spots are non-compensated until we launch a product and or collect revenue.
      Discord and microphone required.
      Responsibilities for the artist slot include - creating 2d sprite sheets with various animations.  Creating environments, creating concept art, giving creative input where you can.
      responsibilities for composer slot include - creating OSTs for our games, mastering tracks and ensuring everything is the same volume and cohesive, and implementing sound fx.
      The basic ability to follow instructions, and reference design documentation!
       
       
       
×

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!