New project: SurCraft

Hi all,



After playing around with jme for a few moths i decided to start creating my own game. The whole idea is inspired by the game stranded

(or will be more or less a clone of it).



Main idea:

You are thrown out in the wilderness with nothing left. While fighting for survival (hunger and thirst) you will have to use the goods that the

nature is providing. Combining the items you collect will improve your skills to discover new technics for converting materials and production.

After building your basic camp to hide from the night its up to you to explore the world and hunt for animals, or expand your base and

farm the goods you have planted.



I know it is a big project but i like the challenge in this so im quite motivated to do this. I think the worst i can do is to start with everything at

once, so made myself a few flagpoints.


  • Main menu
  • Basic endless terrain
  • Basic character + skills
  • Basic items + inventory
  • Basic hud + ingame menu
  • Collecting items + interaction with i.e. trees
  • Crafting and combining
  • Basic building + placing items
  • Advanced interaction (i.e. furnance)
  • Generation of nature + water
  • Global events (growing, thirst, hunger)
  • Day night change + weather
  • Animals (neutral + bad)
  • Vehicles
  • Saving/Loading



    If you have any suggestions/critics, questions, ideas or even help your welcome. Oh…and sry for my bad english for sure :slight_smile:

need help?

I would not start with something like main menu… Such ‘simple’ things where i do not expect big challanges i usually do when i am stuck on a bigger problem and need time off



I am currently working on a project of similar scale and i started following:


  1. Core Systems

    -EntitySystem

    -DataManagement


  2. Terrain (It’s good to finally see something, once this is done i can also starting programming some game logic)

    -Terrain Loader/Saver

    -Terrain Editor




  3. Game Units + Game Logic



    Always when i need a break from the ‘simple’ code writing i do some artistic stuff (Effects, Shaders… )

I agree with zzuegg - but having said that the main menu isn’t a bad place to start as it at least means you feel like you have something…which you can then build on.

sometimes meniu is quite anoing when yr debugin and need to run game milion times

@eraslt said:
sometimes meniu is quite anoing when yr debugin and need to run game milion times


If you have to klick trought the menu each time you start the game while programming it...it would get insane.. and even more likely hate the menu after some starts
At least i have always a testfile which brings me directly to the feature i am developing..

@eraslt: help? sure :slight_smile: what was on your mind? a specific part or as a team in general?



@zzeugg: i guess your right, but since its my first game in that dimension and with jme itself, i wanted to start

with the easy parts and climb up the ladder while developing. also i can recycle buttons and so on for the

ingame menu and inventory. the thing that follows is data structure for the character/items and crafting

routines. i think thats what you mean with the core part right?



also thanks for interest

If you build a main menu, the first thing you gonna do is to prevent it from starting and hard code to load exactly what you want =]

@wizz07 said:
i guess your right, but since its my first game in that dimension and with jme itself, i wanted to start
with the easy parts and climb up the ladder while developing. also i can recycle buttons and so on for the
ingame menu and inventory. the thing that follows is data structure for the character/items and crafting
routines. i think thats what you mean with the core part right?


I usually implement game features at a time where i can test them (with ingame scenarios) so from my point of view an inventory can only be tested when i have a character/item/picup routines/sell routines/buy routines/use routines. Following this i would implement a inventory very late in the process..

Following your description i would start with laying out the interface for the terrain. After this step i would implement methods for loading terrain. Once done you can start with a simple terrain to test all the previous stuff. If all is ok, you can simply switch to a more complex endless terrain, and rely on the loading part since you are using the same interface.

Once the terrain is done, usually a character prototype is needed. (Maybe just a moving Box) With this basic character, you can already test nearly all of the game logic, implementing and testing feature after feature. (At some point here i would probably start with the inventory)

Ingame menus can of course be developed when needed, and afterwards you can reuse these stuff for all the other menu's.

Just a few toughts from my side....

A few sideinformations:
For a project on this scale i recommand to use version control system.. (I am using this approach: http://nvie.com/posts/a-successful-git-branching-model/ )
2 Likes
@wizz07 said:
@eraslt: help? sure :) what was on your mind? a specific part or as a team in general?

@zzeugg: i guess your right, but since its my first game in that dimension and with jme itself, i wanted to start
with the easy parts and climb up the ladder while developing. also i can recycle buttons and so on for the
ingame menu and inventory. the thing that follows is data structure for the character/items and crafting
routines. i think thats what you mean with the core part right?

also thanks for interest


NiftyGUI is a whole animal unto it's self.

Personal suggestion:

1) Game Planning
-- Game play
-- Component needs for facility peripherals (on land? on sea? in sky? in space?)
-- Component needs to facilitate game play
-- Server needs? to facility game play
-- UI needs to facilitate game play
2) Core logic
-- Build out components needed to facilitate peripherals (These are stand-alone reusable components... terrain generation, skybox, etc, etc)
-- Build core game logic/components needed for game play (Objects... player, npc, item, etc. Physics, Interaction, Attack System, etc, etc)
-- Build out communication & transport layer for client/server using the above to scope out needs. This is only if your game is multiplayer.
3) UI components
-- You've built & tested the components needed for basic game-play. Now, start piecing it together with by building out the UI components to facilitate the visual needs for interaction.

The approach I took, was to implement a pseudo-scripting language to simulating mouse clicks, etc, etc. For example:

/stand
/target playerName
/cast 2
/pause 3.5
/sit

I then tied my UI components back to this pseudo-scripting language, which allowed me the ability to give users who would like more advance game play to write their own action buttons to perform multiple actions with one click.

Another suggestion. Tie default commands to your objects based on distance. if distance > x, player is targeting... if distance <= x player is interacting. Let the object tell you what the player is trying to do.

Basically all this rambling is for one reason: UI makes interaction easier... but is NOT required to build a game and test it. Save it for last when you can do nothing other than focus on making Nifty work for you.
1 Like

Long ago life lesson learned by many examples:

When you don’t know where to start designing/coding your game, making a menu isn’t going to help you find a way in. You’ll just have a bunch of menus that would probably get redone once you have a real game anyway. Beware the trap of wasting time on seemingly productive exploits as a way of putting off the real work of getting started.



In my teen years, I must have had 5 different really nice game opening screens + menus + character creators.

thank you guys, that was really helpfull. im trying to get a small usecase to run asap.

@wizz07 said:
@eraslt: help? sure :) what was on your mind? a specific part or as a team in general?

we could team up :)

do u use skype? mine: eraslt

first thing we need is a plan, writen stuff what when and how to do sutff. coding is the easiest part.

@zzuegg and @t0neg0d sugestions are great! I’d follow them if I were you!

thats why i rated them positive :slight_smile: and i am.



@eraslt: sry didnt see your mail before. send you one back

Sounds a lot like IceTrollTribes:)



Honestly I would rather not use stuff like endless terrain, because it makes some things easier and I would not expect it to have a notable contribution to your game experience. On the other hand, having a skill system might be the selling point of your game, because it is rather unusual and it might give the players a feeling of progress, which might keep them playing.

To keep yourself motivated, I would suggest startig with a very basic shooter with a limited set of actions and basically no entities and expand it step by step with items, crafting and skills. If you want to go for multiplayer, start with multiplayer because it changes everything. It does not matter if your way isnt state of the art because doing something right can cause you to sit down spending like half a year of your spare time coding stuff that has no direct benefit to you loosing all your motivation.

It’s right that a limited terrain makes things much easier, but on the other hand with terra forming and a lot of stuff to build, it kinda makes sense to think about it since you will need a lot of place. my first idea was to make it kinda mmo-style, in the case where people stay on a server and develope their chars get together to create working cyties and trade goods(maybe global and local shops) so infinite was in a way needed. the skill tree will be of course a big point in the game. for now i had 20 skills in mind which affect the things you can build and craft. the main goal is to have a minimal game. after having the item, crafting and building routines, all other items and so on is just filling the game with content.



but we’ll see where the game will come to since eraslt joined the team and we first have to talk about what features will make it into the game.

im not very fond off mmo idea, couse its very hard to implement good server side. i prefer simple client/server with simple data sinch, but that we will decide later, now we just setuping svn and just figuring out from where to start :slight_smile:

how to broadcast data from server not on MessageListener->messageReceived but on time intervals?